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

<mohamed.boucadair@orange.com> Mon, 14 November 2016 07:20 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE71295EC for <multipathtcp@ietfa.amsl.com>; Sun, 13 Nov 2016 23:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level:
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JhOLRU-975I for <multipathtcp@ietfa.amsl.com>; Sun, 13 Nov 2016 23:20:24 -0800 (PST)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB721294FD for <multipathtcp@ietf.org>; Sun, 13 Nov 2016 23:20:23 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 25B2BC02CD; Mon, 14 Nov 2016 08:20:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id E13181A0069; Mon, 14 Nov 2016 08:20:21 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 08:20:21 +0100
From: <mohamed.boucadair@orange.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Thread-Topic: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
Thread-Index: AQHSO4eIDFVxCMBGO02fLM+frvBQ06DYFAoQ
Date: Mon, 14 Nov 2016 07:20:20 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DB0C69@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <aad12c71ad5748368c31385e1d099d60@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009DAF424@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249yfcOshFD0eO=mbod4kPAVC-=QGoWUDVy4DYTfL=EFLu3g@mail.gmail.com>
In-Reply-To: <CAO249yfcOshFD0eO=mbod4kPAVC-=QGoWUDVy4DYTfL=EFLu3g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/AItXfe2lq1IkZ0qQ0ricah9CB1U>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2016 07:20:27 -0000

Hi Yoshi, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
> Envoyé : jeudi 10 novembre 2016 20:21
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : philip.eardley@bt.com; multipathtcp@ietf.org
> 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,  <mohamed.boucadair@orange.com>; wrote:
> > Hi Phil,
> >
> >
> >
> > Please see inline.
> >
> >
> >
> > Cheers,
> >
> > Med
> >
> >
> >
> > De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> > philip.eardley@bt.com
> > Envoyé : jeudi 10 novembre 2016 12:40
> > À : multipathtcp@ietf.org
> > 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
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> >