Subject: [multipathtcp] Possible future items for mptcp WG

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Jun 2018 00:16:40 -0700

Hello everyone,

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.

Also, if you have some opinions on the status of the WG or suggestions to
the chairs, please let us hear!

We appreciate your feedback

Thanks,
--
Yoshi & Phil

1: API extensions (This is already in our charter)
    draft-hesmans-mptcp-socket
    draft-samar-mptcp-socketapi

2: Feature extensions
    a) robust initial setup
        proposed by Markus, also Kien presented a similar idea

    b) fast subflow setup
        proposed by Quentin

    c) security enhancement
        1) TLS
            draft-bonaventure-mptcp-tls-00
            draft-paasch-mptcp-tls-authentication-00

        2) Utilize proposals from tcpinc?

        3) Elliptic Curve Cryptography
            draft-kim-mptcp-semptcp-00

    d) Solutions for operational issues
         1) how to handle nat64 issue proposed by Quentin
         2) how to handle load balancer proposed by Fabien, Christoph,
Costin

3: Congestion Control (This topic itself should probably be discussed at
ICCRG. But, it may trigger some updates of the protocol or APIs later)
     a) OLIA
          draft-khalili-mptcp-congestion-control-05

     b) mptcp + BBR?
          presented by Jing

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 14 Jun 2018 15:39:34 +0200

Phil, Yoshifumi,
> After we finish 6824bis, we ｗon't have active WG items as the proxy 
> work will be discussed at tcpm WG.
> we've seen interesting presentations for new ideas, experiment results 
> and so on at the meetings and on the ML.
> 
> 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

---

From: Xavier de Foy <[email-masked]>
Date: Thu, 14 Jun 2018 17:01:20 -0400

Yoshifumi & Phil,

  Another potential item under "Feature Extensions" could be dedicated to
interoperability with 5G. We are preparing an update to the "5G
considerations" draft presented in the last session, which can be used as
input for the group to decide if it should be on this list.

  Best Regards,
Xavier

On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida <[email-masked]>
wrote:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 15 Jun 2018 01:03:13 -0700

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:

>> WG (and your willingness to contribute if possible) or there are some more
> 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.
>
> 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.
>
> 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.
>
> 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.
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 15 Jun 2018 01:04:06 -0700

Hi Xavier,

Thank you so much!
Yes, we have thought about 5G stuff as well.
The reason why we haven't included in the list below was it might not be a
short term topic while it can be important for mptcp in future.
New suggestions to mptcp with regard to this topic will always be very
welcome.
--
Yoshi

On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy <[email-masked]>
wrote:

> On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida <[email-masked]
> > wrote:
>
>> Hello everyone,
>>

---

From: Xavier de Foy <[email-masked]>
Date: Tue, 19 Jun 2018 15:45:02 -0400

Hi Yoshi,

  Thanks for the answer. In term of timing: 5G global deployment should
occur in 2020 (with smaller/test deployments before this), so work related
to 5G adaptation may be best completed within 12 to 18 months (just my
understanding, maybe others on the list can share their views on the best
timing for this type of work). Do you think it is too far ahead, or would
it make sense to include 5G related investigations in the list?

  Best Regards,

Xavier

On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida <[email-masked]>
wrote:

>> On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida <
>> [email-masked]> wrote:
>>
>>> Hello everyone,
>>>
>>> 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.
>>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 19 Jun 2018 23:54:44 -0700

Hi Xavier,

Thanks. I think the timing you mentioned won't be a critical issue by
itself.
However, one question is how soon we can have concrete proposals to MPTCP
for 5G networks.
If there are already some solid features in 5G and we have explicit ideas
to update or extend MPTCP for them, I think there will be possibilities.
--
Yoshi

On Tue, Jun 19, 2018 at 12:45 PM, Xavier de Foy <[email-masked]>
wrote:

> On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida <[email-masked]
> > wrote:
>
>> Hi Xavier,
>>
>> Thank you so much!
>> The reason why we haven't included in the list below was it might not be
>> a short term topic while it can be important for mptcp in future.
>>>   Another potential item under "Feature Extensions" could be dedicated
>>> to interoperability with 5G. We are preparing an update to the "5G
>>>> 3: Congestion Control (This topic itself should probably be discussed
>>>> at ICCRG. But, it may trigger some updates of the protocol or APIs later)
>>>>      a) OLIA

---

From: Xavier de Foy <[email-masked]>
Date: Wed, 20 Jun 2018 14:25:17 -0400

Hi Yoshi, thanks for the explanation, it makes sense to me. We will update
the 5G considerations draft shortly, hopefully it will help defining a more
concrete proposal.
Best Regards,
Xavier.

On Wed, Jun 20, 2018 at 2:54 AM, Yoshifumi Nishida <[email-masked]>
wrote:

>> On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida <