Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Wed, 02 November 2016 10:24 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 96BF1129AAB for <multipathtcp@ietfa.amsl.com>; Wed, 2 Nov 2016 03:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level:
X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9mM_BRP6UJT1 for <multipathtcp@ietfa.amsl.com>; Wed, 2 Nov 2016 03:24:38 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249E7129AA7 for <multipathtcp@ietf.org>; Wed, 2 Nov 2016 03:24:38 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 5CC9D4032A; Wed, 2 Nov 2016 11:24:36 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 02F721A0062; Wed, 2 Nov 2016 11:24:36 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 11:24:35 +0100
From: <mohamed.boucadair@orange.com>
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSMct3lkWjRHR8/UOwFgD4FUiIN6DFdN0w
Date: Wed, 2 Nov 2016 10:24:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com>
In-Reply-To: <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@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/WvfmF1WCck6FDfhrASaB3N9r2KA>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
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: Wed, 02 Nov 2016 10:24:41 -0000

Hi Alan, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alan Ford [mailto:alan.ford@gmail.com]
> Envoyé : samedi 29 octobre 2016 12:02
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi Med,
> 
> Thank you for updating these drafts, I have been awaiting these with great
> interest!

[Med] Cool, thanks.

> 
> Re draft-nam-mptcp-deployment-considerations-00:
> - The three use cases in S3 make sense

[Med] OK. 

> - But in S4, the two deployment scenarios, focuses purely on Scenarios 1 &
> 3, not 2
> 

[Med] The only UC#2-related deployment scenario I'm aware of is the datacenter case, where MPTCP is used inside the DC. This deployment scenario is not listed there because I thought it cannot be considered as ** network-assisted MPTCP ** deployment scenario.   

> In S5.2.1, the usage model is that data is explicitly targeted to the MCP.

[Med] Yes.

> in S5.2.2, implicit, it only works for Scenario 1 of S4.

[Med] It works for both scenarios of S4.

 By the diagrams,
> it needs to now that a destination is not MPTCP capable - how does it have
> this knowledge?

[Med] The default behavior is that it does convert the MPTCP connection into a TCP connection without requiring any knowledge about the destination. This default behavior is motivated by the current support of MPTCP at the servers side. The text can deal with optimization like the one you suggested, but we left those out of scope for the moment.  

 Should it actually be intercepting the SYN/ACK from RM and
> making adjustments there?

[Med] See above. (various optimization triggers can be considered: inspect SYN/ACK, configured servers whitelist, etc.)

> 
> This continues in the 5.2.2.1 discussion - what is the purpose of
> MP_CONVERT in the implicit mode?

[Med] It is there to distinguish native MPTCP connections that can be established from an MPTCP host from those that are required to be proxied. If the option is not included, this flow will experienced:

    _________________MULTIPLE PATH CLIENT/SERVER___________
   /                                                       \
                |                              |
    |           |                              |           |
    |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
    |<=MPTCP====|=============================>|<-TCP Leg->|
    |    dst:s2@|                              |    dst:s2@|
    |           |                              |           |
   +--+      +-----+                         +-----+      +--+
   |C2|      | MCP |                         | MCP |      |S2|
   +--+      +-----+                         +-----+      +--+
             Upstream                     Downstream

       Example of a Broken E2E MPTCP Connection (On-path)
 
While we wanted to achieve this:

    _________________MULTIPLE PATH CLIENT/SERVER___________
   /                                                       \
                |                              |
    |           |                              |           |
    |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
    |<==========|============MPTCP========================>|
    |    dst:s2@|                              |    dst:s2@|
    |           |                              |           |
   +--+      +-----+                         +-----+      +--+
   |C2|      | MCP |                         | MCP |      |S2|
   +--+      +-----+                         +-----+      +--+
             Upstream                      Downstream

     Example of a Successful E2E MPTCP Connection (On-path)


 Is it just to say “if there’s an MCP on
> this path, I would like it“? This seems different from the use of it as
> described in the plain mode draft (where it appears to be used for
> explicit mode by signalling the target IP address).

[Med] This use is compliant with the plain mode draft: the target IP address is optional. 

 You talk about
> differentiating between “native” and “proxied” MPTCP connections, but how
> would the initiator know this in implicit mode?

[Med] An initiator located behind a CPE does not need to know that.  

> 
> I think this is a valuable document which explains how proxies can be used
> to extend the benefits of MPTCP to connections where one or both end hosts
> are not MPTCP-capable. It think this fits with the proxy charter item
> today.

[Med] Thank you.

> 
> 
> Re draft-boucadair-mptcp-plain-mode-09
> 
> S3.1 - two issues:
> 
> 1) How does the client know the server does not support MPTCP and thus
> should be going through the proxy? Or does everything go through the
> proxy?
> (This is similar to the question in implicit mode of how does the MCP know
> the server does not support MPTCP?)

[Med] Optimization related to the support of MPTCP at the server side are optimizations that are left out of scope for the time being.  

> 
> 2) Why make MP_CONVERT appear to be be part of MPTCP, when it’s not? In S4
> you talk about it being included in the SYN payload - therefore it’s part
> of the TCP payload. This is fine and aligns with what I’ve been saying
> since IETF95 - the proposed protocol is not MPTCP-specific, and is simply
> signalling the target at the start of the TCP payload.

[Med] The option is likely to be included in the payload because of the limited TCP option space. Supplying long options in MPTCP SYN is a generic problem that is worth to be solved by the mptcp wg. A pragmatic approach is to grab some space in the payload to extend the TCP option space. For the sake of interoperability, a meaning will be associated with a flag of MP_CAPBALE to indicate that other options are present in the payload. We are building on that capability.

 This does not need
> to be a MPTCP option to make this happen.
> 
> To be clear - again - I have no issue with this work being done in MPTCP
> WG, it is “how to use proxies to increase deployment of MPTCP”. But this
> particular document is not MPTCP-specific;

[Med] It is MPTCP-specific for various reasons, e.g.,:
* it solves an MPTCP problem (how to make use of MPTCP of one or both peers are not MPTCP compatible). 
* it is deigned to not break native MPTCP connections
* it solves current MPTCP deployments problems with SOCKS.

 whether it is published here or
> elsewhere I don’t care, but it really shouldn’t’ be written as if it’s
> extending the MPTCP spec when there is no reason for it to be.
> 
> Finally, you earlier mentioned the possible effect on the base spec
> regarding a flag, but I see no mention of it in these docs.

[Med] This is indicated as a discussion note in Section 4: 

      DISCUSSION NOTE: ADD DETAILS ABOUT THE NEED FOR AN EXPLICIT SIGNAL
      THAT MPTCP OPTIONS ARE INCLUDED IN THE SYN PAYLOAD

We agreed among authors to initiate a thread on this particular point. 

> 
> Regards,
> Alan
> 
> 
> > On 28 Oct 2016, at 07:44, mohamed.boucadair@orange.com wrote:
> >
> > Hi Phil,
> >
> > I remember, as well :-)
> >
> > The drafts were completely rewritten to take into considerations the
> comments and also to help the chartering effort. Here is the set of the
> Network-Assisted MPTCP documents:
> >
> > * An MPTCP Option for Network-Assisted MPTCP:
> https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
> > * Network-Assisted MPTCP: Use Cases, Deployment Scenarios and
> Operational Considerations: https://tools.ietf.org/html/draft-nam-mptcp-
> deployment-considerations-00
> > * DHCP Options for Network-Assisted Multipath TCP:
> https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06
> > * RADIUS Extensions for Network-Assisted Multipath TCP:
> https://tools.ietf.org/html/draft-boucadair-mptcp-radius-03
> >
> > Questions, comments and suggestions are more than welcome!
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> >> philip.eardley@bt.com
> >> Envoyé : mercredi 26 octobre 2016 10:13
> >> À : mirja.kuehlewind@tik.ee.ethz.ch; JACQUENET Christian IMT/OLN
> >> Cc : multipathtcp@ietf.org
> >> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> >>
> >> Hi,
> >> I remember in Berlin discussion about a new /merged version of Med and
> >> Olivier's drafts - with a nice description of the protocol model to
> make
> >> it easier to understand (both the high-level approach, and the
> assumptions
> >> - especially as these are different to those of RFC6824). I think this
> >> would make it easier to write text for a new charter item. (at least my
> >> attempt to write a new charter item a while back was inaccurate
> >> /inadequate).  Is this possible please?
> >> I agree we want this work to happen - it's great to see MPTCP being
> widely
> >> used and we want standardisation.
> >>
> >> Best wishes
> >> Phil.
> >>
> >> -----Original Message-----
> >> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> >> Mirja Kühlewind
> >> Sent: 25 October 2016 13:07
> >> To: christian.jacquenet@orange.com
> >> Cc: multipathtcp@ietf.org
> >> Subject: Re: [multipathtcp] potential MPTCP proxy charter item
> >>
> >> Hi all, hi Christian,
> >>
> >> see below.
> >>
> >>> Am 20.10.2016 um 08:50 schrieb christian.jacquenet@orange.com:
> >>>
> >>> WG,
> >>>
> >>> Let me second Med's recent replies to Yoshi, Mirja and Alan.
> >>>
> >>> I too believe the mptcp WG is the right placeholder to work on an
> MPTCP
> >> extension that can accommodate use cases which are currently being
> >> investigated, marketed and - yes - deployed (for some of them, with
> their
> >> procession of already-documented drawbacks (TCP-only communications)
> and
> >> flaws, like QoS-affecting signaling delays) by some operators.
> >>>
> >>> These use cases mainly fall under the so-called hybrid access service
> >> offering umbrella, so that end-users can take advantage of various
> access
> >> network technologies for the sake of optimized resource usage, among
> other
> >> incentives.
> >>
> >> I agree that these use case are interesting and work is needed here.
> See
> >> further below.
> >>
> >>>
> >>> I also believe MPTCP is the right solution to address such use cases.
> >>
> >> As I mention previously there are two very different deployment
> scenarios:
> >> a connection-terminating MPTCP proxy or a MPTCP tunnel solution. In
> >> general using TCP as a tunneling technology is challenging and has a
> >> broader scope than just MPTCP.
> >>
> >>
> >>> As I already mentioned a while ago, working on an extension that can
> >> facilitate the establishment of MPTCP connections in a network-assisted
> >> fashion as we call it in the current Plain Transport Mode option draft
> >> will not hinder MPTCP massive adoption but rather encourage it.
> >>>
> >>> I also know there are already prototype implementations of such
> >> extension that are currently being tested.
> >>>
> >>> I therefore support the adoption of the MPTCP proxy charter item by
> the
> >> mptcp WG, as this work addresses very concrete and short term use cases
> >> that have been publicized by several operators.
> >>>
> >>> And I think that this WG should start working asap on the set of
> >> deliverables mentioned by Med in his recent response to Mirja: MPTCP
> >> extension specification, deployment scenarios and operational
> >> considerations and DHCP/RADIUS-based provisioning means.
> >>
> >> An MPTCP extension specification is clearly in scope for MPTCP and can
> be
> >> done right now without a charter change.
> >>
> >> I’m not sure if deployment scenarios need to be documented (in an RFC).
> As
> >> you said above there are already prototype and some real deployments as
> >> well. Not sure why we need additional documentation here.
> >>
> >> Operational consideration might or might not below in the MPTCP working
> >> group. However, there is the BANANA BoF in Seoul that will discuss
> hybrid-
> >> access services (and different approach to provide this service).
> >> Depending where this effort goes that might be a better home or some wg
> in
> >> intarea.
> >>
> >> DHCP/RADIUS extension go into the DHC working group. They are charter
> to
> >> specify these kind of extensions and you can start this work there
> >> immediately.
> >>
> >> I’m not saying we shouldn’t do this work; I’m just saying that MPTCP
> might
> >> not be the right group for all parts of this work. This is my
> >> recommendation as transport AD but I’m sure a rechartering discussion
> in
> >> the IESG would provide similar feedback.
> >>
> >> Mirja
> >>
> >>
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Christian.
> >>>
> >>> -----Message d'origine-----
> >>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> >>> mohamed.boucadair@orange.com Envoyé : jeudi 20 octobre 2016 08:15 À :
> >>> Yoshifumi Nishida; Olivier.Bonaventure@uclouvain.be Cc :
> >>> multipathtcp@ietf.org Objet : Re: [multipathtcp] potential MPTCP proxy
> >>> charter item
> >>>
> >>> Hi Yoshi,
> >>>
> >>> The discussion I had with many operators is that they would like to
> see
> >> both TCP and UDP addressed with the ** same solution**. This is why we
> >> came up with the proposal to leverage MPTCP for other protocols (UDP,
> >> mainly).
> >>>
> >>> So, what I would ideally like to see in the mptcp WG proposed charter
> is
> >> (with "X" being MPTCP):
> >>>
> >>>> 1: Protocol X proxy:
> >>>>   It speaks protocol X on behalf of communicating endpoints .
> >>>>   From one end's point of view, it looks as if the other end speaks
> >>>> protocol X.
> >>>
> >>> And
> >>>
> >>>> 3:  Protocol X-Y / Protocol Y-X gateway
> >>>>    Convert protocol X into protocol Y, or convert protocol Y into
> >>>> protocol X for protocol connectivity/compatibility, etc.
> >>>
> >>> I know Olivier/Stefano have a better name to denote both these cases.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] Envoyé :
> >>>> mercredi 19 octobre 2016 22:57 À : Olivier.Bonaventure@uclouvain.be
> >>>> Cc
> >>>> : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org
> >>>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> >>>>
> >>>> Hello,
> >>>>
> >>>> On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure
> >>>> <Olivier.Bonaventure@uclouvain.be> wrote:
> >>>>> Mirja,
> >>>>>>
> >>>>>>
> >>>>>> there are two cases to distinguish here:
> >>>>>>
> >>>>>> 1) you have one or two MPTCP proxies that terminate the TCP
> >>>>>> connection
> >>>> and
> >>>>>> open a new MPTCP connection
> >>>>>
> >>>>>
> >>>>> There is a very clear demand for this type of solution and there are
> >>>> various
> >>>>> implementations that are available or are being developped. Several
> >>>>> deployments exist and there is a large demand for this type of
> >> services.
> >>>> It
> >>>>> would be silly for the IETF to ignore this use case after having
> >>>>> spent
> >>>> years
> >>>>> to specify the Multipath TCP protocol.
> >>>>
> >>>> I also think we should not ignore the use case.
> >>>> But, I am somehow thinking that we might want to clarify the
> >>>> terminologies a bit more so that we can have more clear focus.
> >>>>
> >>>> I might be wrong, but these words give me the following impressions.
> >>>>
> >>>> 1: Protocol X proxy:
> >>>>   It speaks protocol X on behalf of communicating endpoints .
> >>>>   From one end's point of view, it looks as if the other end speaks
> >>>> protocol X.
> >>>>
> >>>> 2: Tunneling over protocol X
> >>>>    Protocol X carries other protocol Y packets (by using
> >>>> encapsulation)  All info in protocol Y (headers, etc) will be
> >>>> preserved.
> >>>>
> >>>> 3:  Protocol X-Y / Protocol Y-X gateway
> >>>>    Convert protocol X into protocol Y, or convert protocol Y into
> >>>> protocol X for protocol connectivity/compatibility, etc.
> >>>>    Some info in the original protocol might be lost due to the
> >>>> conversion.
> >>>>
> >>>> If I follow these impressions, it seems that some proposals are close
> >>>> to 3. (again, I might be wrong) I might want to check if we want to
> >>>> clarify this point in the charter or leave it ambiguous.
> >>>> I am just wondering if we might need to clarify the terminology or
> >>>> adding some texts to avoid miscommunications.
> >>>>
> >>>> Thanks,
> >>>> --
> >>>> Yoshi
> >>> _______________________________________________
> >>> multipathtcp mailing list
> >>> multipathtcp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/multipathtcp
> >>>
> >>> ______________________________________________________________________
> >>> ___________________________________________________
> >>>
> >>> Ce message et ses pieces jointes peuvent contenir des informations
> >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >>> exploites ou copies sans autorisation. Si vous avez recu ce message
> >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que
> >> les pieces jointes. Les messages electroniques etant susceptibles
> >> d'alteration, Orange decline toute responsabilite si ce message a ete
> >> altere, deforme ou falsifie. Merci.
> >>>
> >>> This message and its attachments may contain confidential or
> >>> privileged information that may be protected by law; they should not
> be
> >> distributed, used or copied without authorisation.
> >>> If you have received this email in error, please notify the sender and
> >> delete this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that have
> >> been modified, changed or falsified.
> >>> Thank you.
> >>>
> >>> _______________________________________________
> >>> multipathtcp mailing list
> >>> multipathtcp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/multipathtcp
> >>
> >> _______________________________________________
> >> multipathtcp mailing list
> >> multipathtcp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/multipathtcp
> >> _______________________________________________
> >> multipathtcp mailing list
> >> multipathtcp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/multipathtcp
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp