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

[Yoshifumi Nishida <[e-mail]>]

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.

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

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.
But, I'm not very sure how they get such knowledge. Even if they get a
MCP address via DHCP, there might be possibility that the MCP is
actually on-path.

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
>