Re: [multipathtcp] Possible future items for mptcp WG

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

Thank you so much for the inputs!
I agree that there are many possibilities and the topic you mentioned looks
promising.

One thing the chairs would like to know is if there are items we can work
on in (relatively) short term.
If there are promising topics that we can adopt as WG items in our near
feature, please share.
It will be great if we can discuss such items in our next WG meeting.

Thanks,
--
Yoshi

On Thu, Jun 14, 2018 at 6:39 AM, Olivier Bonaventure <Olivier.Bonaventure@
uclouvain.be> wrote:

> 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
>