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

[<[e-mail]>]

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<https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09#ref-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