Re: [multipathtcp] Possible future items for mptcp WG

[Olivier Bonaventure <[e-mail]>]

Phil, Yoshifumi,
> 
> Phil and I have been discussing the next step for the WG.
> After we finish 6824bis, we ｗon't have active WG items as the proxy 
> work will be discussed at tcpm WG.
> One suggestion might be to close the WG or to put it in dormant state, 
> however, we are thinking there still might be some more working items as 
> we've seen interesting presentations for new ideas, experiment results 
> and so on at the meetings and on the ML.
> 
> Below is the list of potential working items from the chairs' point of view.
> Please let us know if you think some of them are important items for the 
> WG (and your willingness to contribute if possible) or there are some 
> more items, or this is not something we should work on, etc.

I think that the socket API still makes sense and it would be useful to 
have an agreement on an API that is supported by different 
implementations. At this point, I'm only aware of API efforts on the 
Linux implementation.

Concerning the extensions, I think that it makes sense to reconsider the 
extensions that we have not included in rfc6824bis and evaluate whether 
they could be of benefit for Multipath TCP.

Congestion control is probably a more difficult topic since ICCRG is the 
natural place for work on new congestion control schemes. Maybe we 
should encourage the development of new coupled congestion control schemes.

Another direction that the WG could pursue are the interactions with 
other working groups where Multipath TCP could play a role.

For example, v6ops and spring develop the Segment Routing architecture. 
The IPv6 variant of SR brings a nice framework to allow the 
establishment of Multipath TCP subflows over specific paths. As IPv6 SR 
is available on Linux, it becomes possible to perform experiments and 
think about the interactions between SR and MPTCP.

Another example is happy eyeballs. This technique works with HTTP on 
dual-stack machines. It could also be applied to MPTCP (e.g. with the 
parallel establishment idea)

A third example are the interactions between MPTCP and applications. It 
would be interesting to interact with WG developing application level 
protocols to see how to map them on MPTCP.

A fourth example is IPv6 multihoming. The rtgwg will soon publish a 
recommendation on techniques to support IPv6 multihoming. This document 
mainly assumes that endhosts use single path transport protocols. It 
would be interesting to work with rtgwg to describe the benefits that 
MPTCP could bring in this environment.

Another example is intermittent connectivity. MPTCP can use multiple 
paths simultaneously, but it also supports seamless handovers on mobile. 
On mobiles that have only WiFi connectivity, MPTCP could support 
intermittent connectivity, i.e. connections that start on one AP, then 
move a few seconds, minutes or hours later on another AP. This could 
require to maintain MPTCP connections without an associated subflow for 
a longer period of time that the default used by TCP.

I guess that there are many other possiblities


Best regards,


Olivier