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é : 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. 

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

 Even if they get a
> MCP address via DHCP, there might be possibility that the MCP is
> actually on-path.

[Med] this is exactly why https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html#section-5.2 uses Implicit/Explicit terminology.  

> 
> Thanks,
> --
> Yoshi
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Nov 10, 2016 at 4:54 AM,  <[e-mail]> wrote:
> > Hi Phil,
> >
> >
> >
> > Please see inline.
> >
> >
> >
> > Cheers,
> >
> > Med
> >
> >
> >
> > De : multipathtcp [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoyé : jeudi 10 novembre 2016 12:40
> > À : [e-mail]
> > Objet : [multipathtcp] Questions on
> > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
> >
> >
> >
> > A few questions
> >
> >
> >
> > Sections 4 & 5 discuss operation with a single-ended proxy, ie one end
> host
> > is MPTCP-enabled and the other end host is ‘legacy’ TCP. The figures and
> > discussion seem to assume the MPTCP-enabled end host initiates the
> > connection. Is the case also covered where the TCP end host initiates
> the
> > connection?
> >
> > [Med] Yes. We already have those details in -08 of the draft and some of
> the
> > details were presented in Buenos Aires meeting (see slide 14 of
> > https://www.ietf.org/proceedings/95/slides/slides-95-mptcp-1.pdf) We
> > removed these details because we wanted to make sure that the base
> behaviour
> > is well understood.
> >
> >
> >
> > In Sections 4 & 5, the MPTCP-enabled end host is assumed to know the
> address
> > of the TCP end host. I assume this is through existing techniques.
> >
> > [Med] Yes.
> >
> >
> >
> > It may mean that an operator has to be careful, for instance if they’re
> > doing caching at the edge of the network and the proxy is more central.
> from
> > the point of view of the path packets take, this seems the same drawback
> as
> > if tunnelling is present – not sure if there could be unpleasant mptcp
> > protocol interactions?
> >
> > [Med] Two comments here:
> >
> > ·         This is an issue for MPTCP in general:
> > https://tools.ietf.org/html/draft-ietf-mptcp-experience-07#section-3.9
> >
> > ·         The location of the MCP is deployment-specific. An operator
> that
> > controls both access legs is likely to make sure that DNS service is
> > appropriately configured. An example would be to collocate the MCP with
> the
> > BNG function and mandate the use of the DNS server provisioned via the
> fixed
> > line. Other approaches can be considered but this is really
> > deployment-specific.
> >
> >
> >
> > In section 6, two-ended MPTCP proxy (neither end host is MPTCP-enabled)
> >
> > <<  If the downstream MCP is deployed on-path, it only terminates MPTCP
> >
> >    connections that carry an empty MP_CONVERT option inside their SYN
> >
> >    (i.e., no address is conveyed).  If the MCP receives a SYN segment
> >
> >    that contains the MP_CAPABLE option but no MP_CONVERT option, it MUST
> >
> >    forward the SYN to its final destination without any modification.
> >
> >>>
> >
> > Comment: I found the description confusing. Not sure what downstream and
> > upstream mean, as the figure shows bi-directional communications.
> >
> > [Med] Section 6 clearly indicates what is meant by Upstream and
> Downstream
> > MCP
> >
> >
> >
> >              Upstream        Downstream
> >
> >         C <---> MCP <===========> MCP <------------> S
> >
> >                   +<=============>+
> >
> >
> >
> >    Legend:
> >
> >         <===>: MPTCP leg
> >
> >         <--->: TCP leg
> >
> >
> >
> >    Figure 7: A Client interacts with a Server through an upstream and a
> >
> >                   downstream Multipath Conversion Points
> >
> >
> >
> > and
> >
> >
> >
> >              Upstream                     Downstream
> >
> >    +--+      +-----+                        +-----+      +--+
> >
> >    |C1|      | MCP |                        | MCP |      |S1|
> >
> >    +--+      +-----+                        +-----+      +--+
> >
> >     C@1   uMCP@1 uMCP@2                       dMCP@       S@
> >
> > …
> >
> >
> >
> > Further, the use case section states the following:
> >
> >
> >
> > ==
> >
> >    In this use case, neither the Client nor the Server support MPTCP.
> >
> >    Two MCPs are used as illustrated in Figure 2.  The upstream MCP is
> >
> >    embedded in the CPE while the downstream MCP is located in the
> >
> >    provider's network.  The CPE is attached to multiple access networks
> >
> >    (e.g., xDSL and LTE).  The upstream MCP transparently terminates the
> >
> >    TCP connections initiated by the Client and converts them into MPTCP
> >
> >    connections.
> >
> >
> >
> >                   Upstream                      Downstream
> >
> >         +--+      +-----+                         +-----+      +--+
> >
> >         |H1|      | MCP |                         | MCP |      |RM|
> >
> >         +--+      +-----+                         +-----+      +--+
> >
> >          |           |                              |           |
> >
> >          |<---TCP--->|<========MPTCP Leg===========>|<---TCP--->|
> >
> >          |           |                              |           |
> >
> >
> >
> >             Figure 2: Network-assisted MPTCP (CPE-based Model)
> >
> >
> >
> > ==
> >
> >
> >
> > Off path and on path I also found confusing.
> >
> > [Med] Fair comment. We thought that the reader is familiar with the
> > deployment models in:
> > https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-
> 00.html#section-5.2
> >
> >
> >
> > If I get it right, on path means that you guarantee the first subflow
> goes
> > through the proxy
> >
> > [Med] Yes. For example, the proxy is on the default forwarding path of a
> > primary link.
> >
> >
> >
> > – what happens if it doesn’t?
> >
> > [Med] Network-assisted MPTCP connections will fail. Note that if the
> primary
> > link is unavailable for some reason, (1) the service cannot be provided
> > through the secondary link in situations where only private IPv4
> addresses
> > are assigned on the secondary link or (2) some communications may not be
> > established if only IPv6 prefixes are assigned in that link.
> >
> >
> >
> > what benefit does having this extra on-path (implicit mode) mechanism
> bring?
> > (I know there’s been some discussion on this, is there a summary of the
> > conclusion?)
> >
> > [Med] It may allow for quick network-assisted MPTCP deployments if a
> > provider does not want to wait for the MP_CONVERT to be fully endorsed.
> > Native MPTCP connections will be broken because the MCP will
> systematically
> > revert them to TCP. The support MP_CONVERT will solve that problem for
> the
> > implicit mode. BTW, as an editor of the document, I’m trying to avoid
> > mandating explicit or implicit as this should be the responsibility of
> each
> > operator.
> >
> >
> >
> > How does the first proxy know the address of the most appropriate second
> > proxy (ie the proxy nearest the other end host)?
> >
> > [Med] This is done by means of DHCP, for instance. Please refer to
> Section
> > 6.2.2:
> >
> >
> >
> >    In this section, we assume that the upstream MCP has been configured
> >
> >    with one address of the downstream MCP.  This address can be
> >
> >    configured statically, dynamically distributed by means of a DHCP
> >
> >    option [I-D.boucadair-mptcp-dhc] or by any other means that are
> >
> >    outside the scope of this document.
> >
> >
> >
> >
> >
> > The mechanism mentions a token, is this a re-use of one of the existing
> > tokens in https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/
> or a
> > new one?
> >
> > [Med] This is the token defined in https://tools.ietf.org/html/rfc6824:
> >
> >
> >
> >    Token:  A locally unique identifier given to a multipath connection
> >
> >       by a host.  May also be referred to as a "Connection ID".
> >
> >
> >
> > Thanks
> >
> > [Med] Thank you.
> >
> > phil
> >
> >
> > _______________________________________________
> > multipathtcp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> >