Re: [Weekly meetings] MoM - 10th of March 2022

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]


On Thu, 10 Mar 2022, Matthieu Baerts wrote:

> 12758809: Needs ACK: [mptcp-next,1/4] mptcp: prefer ip address in syn
> skb instead of listen sk bound address
> 12758808: Needs ACK: [mptcp-next,2/4] tcp: add mptcp join demultiplex hooks
> 12758810: Needs ACK: [mptcp-next,3/4] mptcp: handle join requests via
> pernet listen socket
> 12758811: Needs ACK: [mptcp-next,4/4] mptcp: remove per-address
> listening sockets:
> 12765701: RFC: [5/4] mptcp: handle join requests early:
>    - series: mptcp: replace per-addr listener sockets
>
>    - Kishen found a couple of possible issues (bind race conditions)
>
>    - Paolo gave his view of the situation:
>        - initial need:
> https://github.com/multipath-tcp/mptcp_net-next/issues/203
>        - (who opened that really...)
>        - need: accept new subflows for existing connections but where
> the listening socket has been closed
>
>        - 2 approaches have been taken:
>            - Kishen: create listening sockets (from the PM, with
> options not to do that, etc;)
>            - Florian: accept MPJ without having to create additional
> sockets
>        - these 2 approaches have pros and cons.
>
>    - Issue 203 is a nice to have, maybe not even a bug depending on the
> point of view
>
>    - → probably not a good idea to add too much complexity in the
> kernel, important bugs might come
>
>    - → maybe easier to let the userspace PM to create listening socket
> and not let the kernel doing that all the time.
>
>    - → the complexity to addresses races discussed on the ML would be
> managed from the userspace and maybe not even visible if opening
> listening would be done only in specific cases
>
>    - → idea would be to let the userspace PM (mptcpd) to do the bind +
> listen:
>        - not to have the complexity on the kernel side where we cannot
> change the behaviour
>        - having the kernel creating so many listening sockets "doesn't
> smell good", we will likely have complex issues to fix
>        - if we can do it from the userspace, probably best to let it do
> that
>        - 203 can then be fixed with mptcpd by creating listening
> sockets if needed


Ok, after this community discussion today, I think we should go with the 
"userspace (mptcpd) handles the listening sockets" approach. Kishen and 
Ossama are on board with this too.

In addition to the points just above (complexity, possible hidden issues, 
flexibility), this will leave the in-kernel PM implementation as-is for 
now. It also remains possible to change the kernel listening behavior for 
MPTCP joins at some point in the future, but will unblock the userspace 
PM.

Kishen is working on modifying the userspace PM patch set to add selftest 
support for these listening sockets in pm_nl_ctl. Ossama is looking at the 
mptcpd changes we'll need.


Paolo brought up and advocated this solution today, so it seems likely 
that he will concur. Considering the active participants in these 
discussions in recent meetings and email threads, I think we have a good 
consensus on this approach to the listening sockets. Questions/comments, 
anyone?

Thanks,

--
Mat Martineau
Intel