Re: [PATCH mptcp-next 08/21] mptcp: attempt to add listening sockets for announced addrs

[Kishen Maloor <kishen.maloor@intel.com>]

On 12/29/21 6:03 AM, Matthieu Baerts wrote:
> On 21/12/2021 08:34, Kishen Maloor wrote:
>> On 12/17/21 8:34 AM, Matthieu Baerts wrote:
>>> Hi Kishen,
>>>
>>> On 16/12/2021 23:23, Kishen Maloor wrote:
>>>> When ADD_ADDR announcements use the port associated with an
>>>> active subflow, this change ensures that a listening socket is
>>>> bound to the announced address and port for subsequently
>>>> receiving MP_JOINs from the remote end. In case there's
>>>> a recorded lsk bound to that address+port, it is reused.
>>>> But if a listening socket for this address is already held by the
>>>> application then no further action is taken.
>>>
>>> Do you think we should add an option not to do that?
>>
>> I can't immediately see why that would be necessary. I would think that a machine that
>> wants to restrict MPJs could choose to not issue ADD_ADDR advertisements. 
>> So it could be more a matter of path management policy?
> 
> Yes but likely, the PM is a daemon separated from apps creating
> connections. Maybe some apps want to add restrictions on purpose and it
> would not be practical for the PM to check what kind of lsk has been
> created to know if it has to send an ADD_ADDR (+ create a new lsk) or
> not to respect restrictions set by the linked app.

Yes, the PM daemon operates independently of the application and within the scope
of its namespace. The PM daemon could be the enforcement point for any application-specific
restrictions.

It could expose an API that applications call into to set PM policy (e.g. don't
advertise addresses over this connection), or may be the he admin/app deployment configures 
the PM as such for that namespace? 

The kernel PM has an API to set "limits" and I'm not sure what's its usage model wrt address
advertisements (like who decides to not add_addr on a machine running a client application?).
So userspace PMs could be modeled similarly but with much more fine-grained controls.

> 
>> However, for PMs that do issue ADD_ADDR messages, this change merely attempts to create
>> or reuse a (previously established) lsk (which was stored in the kernel context).
>> But if the lsk is held by the application, then no action is taken.
> 
> I didn't look what was the cost exactly -- probably a look-up in a table
> without locks? -- but maybe on a busy server, you don't want to do extra
> actions if you know they are not needed.

When one end of a connection issues ADD_ADDR messages, an attempt is made to
create a lsk or reuse a previously created lsk.
If the application happens to be listening on the wildcard address (which may be most of
the cases), then no lsk is created. 
You could say that this change is at its core mostly covering corner cases that were previously
left out.

If an ADD_ADDR message is not issued (based on PM policy, for e.g.), then I think essentially 
nothing extra happens.

> 
>> There's a separate change in the series to allow subflows to be initiated from either
>> end of the connection. So in a scenario where a machine that happens to be running a MPTCP 
>> client application issues an ADD_ADDR message (and reusing the subflow port), an lsk would
>> be created as a consequence of this change.
> 
> Even if it looks very unusual to me to create subflows from the server
> side, it is good to have this option! Thanks for adding it!
> But we can also have an option for these two changes :)
> 
> Cheers,
> Matt