Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09

[<[e-mail]>]

Hi Yoshi, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Yoshifumi Nishida [mailto:[e-mail]]
> Envoyé : mardi 15 novembre 2016 15:35
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Yoshifumi Nishida; [e-mail]; [e-mail]
> Objet : Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-
> boucadair-mptcp-plain-mode-09
> 
> Hi Med,
> Sorry for my slow response. I put comments in lines.
> 
> On Sun, Nov 13, 2016 at 11:20 PM,  <[e-mail]> wrote:
> > Hi Yoshi,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Yoshifumi Nishida [mailto:[e-mail]]
> >> Envoyé : jeudi 10 novembre 2016 20:21
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : [e-mail]; [e-mail]
> >> Objet : Re: [multipathtcp] Questions on
> https://tools.ietf.org/html/draft-
> >> boucadair-mptcp-plain-mode-09
> >>
> >> Hi Med,
> >>
> >> Thanks for the clarification. So, in my understanding,
> >> off-path/on-path concept is like the followings.  (please point out if
> >> I miss something)
> >>
> >> on-path (implicit mode) ... The client doesn't need to know the
> >> presence of MCP. The adpp just specifies the server address for the
> >> end point of mptcp connection.
> >
> > [Med] Yes, this is only for the initial subflow. Subsequent subflows
> will use an address of the proxy.
> >
> >>
> >> off-path (explicit mode) ... The client needs to know the presence of
> >> MCP. The app needs to use MCP's address for the destination. It also
> >> need to get MCP's address (via DHCP or something else) and tells mptcp
> >> stack to put it in MP_CONVERT option (via API?)
> >
> > [Med] this may be one way to implement it, but this is not my favorite
> one. I suggest the following:
> > * The application does not need to know about the on-off/path modes.
> > * This is handled at the MPTCP service level: if an address is
> configured via DHCP (or other means), it will behave in the Explicit mode.
> > * MP_CONVERT option(s) are inserted by the MPTCP server accordingly.
> 
> Hmm. OK. But, DHCP is outside of mptcp. How the info from DHCP will be
> delivered to mptcp without using API?

[Med] This is OS specific. That said, the same methods used to provide a SIP stack with the address of an SBC, a DNS stub-resolver with the DNS Servers list, a DS-Lite B4 element with the address of the AFTR, etc. will be followed to present a list of MCP proxies to an MPTCP service/stack.

> 
> >> In this case, I think the off-path clients need to know that they are
> >> off-path nodes and need to rely on MCP *before* communication starts.
> >
> > [Med] This is typically an information that is provided during network
> attachment, etc. For example,
> > * a cellular device can retrieve the MCP information during the PDP
> context activation by means of a dedicated PCO Information Element.
> > * a CPE will retrieve this information when it bootstraps.
> >
> > Note that  the client needs DNS information and other important service
> elements before to make use of a service. That's not particular to MPTCP.
> >
> >> But, I'm not very sure how they get such knowledge.
> >
> > [Med] Same as for DNS and other services (SBC, etc.). Do you foresee any
> particular issue?
> 
> i might miss something here. but, please let me explain a bit more.
> BTW, I am looking at the figure 1 in the draft.
> Let's say when H1 got address via DHCP, it found a MCP address in the
> option. H1 doesn't know RM supports mptcp or not.
> So, it use MCP as destination for mptcp connection. But, when RM
> happens to be a mptcp node, this will be suboptimal.

[Med] Given the current state of support of MPTCP by servers, the default mode is to relay MPTCP connections (sent explicitly to the proxy) into TCP. A configurable parameter may be tweaked on the proxy so that the communication leg with an MPTCP-capable server relies on MPTCP. 

As discussed on this list, blindly withdrawing the proxy from the path may be sub-optimal, too. Take the example of a dual-stack client communicating via a dual-stack proxy with a remote IPv4-only server. If the client is assigned only an IPv6 prefix by one of its network attachment, it cannot use the resources of that network to communicate directly with a remote IPv4-only MPTCP-capable server. If the MCP is removed from the path, this will lead to an MPTCP connection but without the benefits of MPTCP since additional subflows cannot be placed over IPv6 (i.e., E2E MPTCP is suboptimal compared to the Network-assisted MPTCP)!

> 
> To avoid this, I guess H1 needs to go into on-path mode (ignore MCP
> info and use RM for destination) for this RM.

[Med] Only flows that are eligible to the network-assisted MPTCP server will be forwarded to the MCP. These flows are subject to policies that may be provisioned to a host/CPE (https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html#section-5.6.2). Flows that do not match those policies will be forwarded using legacy means; that is no insertion of the MP_CONVERT option. This traffic is used to be called the bypass traffic. 

> But, this might mean H1 will need to change modes based on
> destinations and looks tricky.

[Med] The key point is to know that a remote server is MPTCP-capable at the first place. If that information is available, communications with native MPTCP servers can be classified as part of the bypass traffic.

> 
> --
> Yoshi