Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 03 November 2016 09:29 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 E7C7A127ABE for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 02:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level:
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 mCWlgwzoV2TJ for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 02:29:53 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DBF129437 for <multipathtcp@ietf.org>; Thu, 3 Nov 2016 02:29:53 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A86E8324301; Thu, 3 Nov 2016 10:29:51 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 854B1238071; Thu, 3 Nov 2016 10:29:51 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 10:29:51 +0100
From: mohamed.boucadair@orange.com
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNRJiHc0sTHVljEKJBcjlfAJFpaDG99OAgAAHTXA=
Date: Thu, 03 Nov 2016 09:29:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAAA9E@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> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0uqRSETcirhljCyL3w9wvQoFNhc>
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: Thu, 03 Nov 2016 09:29:56 -0000

Alan, 

One clarification about this part of the message: 

==
> OK, so this is saying “I’ve already been proxied, don’t proxy me again”.

[Med] Yes.
===

Actually, I wanted to say, "NO".

Sorry.

Cheers,
Med


> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoyé : jeudi 3 novembre 2016 10:26
> À : Alan Ford
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi Alan,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Alan Ford [mailto:alan.ford@gmail.com]
> > Envoyé : mercredi 2 novembre 2016 15:07
> > À : BOUCADAIR Mohamed IMT/OLN
> > Cc : multipathtcp@ietf.org
> > Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> >
> > Hi Med,
> >
> > >> - 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.
> >
> > It’s in a document entitled “Network-Assisted MPTCP” :-)
> >
> > But in all seriousness it could be just as network-assisted as the other
> > scenarios, if it were to transparently intercept the traffic.
> >
> 
> [Med] Will consider adding some text about the DC 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.
> >
> > OK, the diagram suggests only Scenario 1, but I can see how Scenario 3
> > would work as well. Could be worth adding another diagram.
> 
> [Med] will do, happily.
> 
> >
> > > 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)
> >
> > OK, so this is saying “I’ve already been proxied, don’t proxy me again”.
> 
> [Med] Yes.
> 
> >
> > However, I don’t understand the scenario you’ve drawn above.
> 
> [Med] The scenario is about an MPTCP-capable host located behind a
> CPE(MCP). This is typically an iPhone connected behind a CPE. We want that
> MPTCP communications issued from this host are forwarded as such to their
> destination without soliciting the downstream MCP.
> 
>  In the
> > “broken” case, the downstream MCP is converting MPTCP to TCP. But what
> you
> > ideally want is a direct case to the destination?
> 
> [Med] Yes.
> 
>  But you’ve already said
> > above that the sender has no knowledge of whether the far end is MPTCP
> > capable or not,
> 
> [Med] I confirm. The MPTCP hosted located behind the CPE does not need to
> have this knowledge.
> 
>  so the downstream MCP should default to TCP (i.e. the
> > “broken” case).
> 
> [Med] It will default to TCP because it has no means to distinguich an
> MPTCP connection initiated by an MPTCP host from an proxied MPTCP
> connection, because all these connections will have the same source IP
> address (CPE's WAN IP address).
> 
> >
> > And furthermore, why is the client talking MPTCP, and being translated
> by
> > an upstream MCP, when it’s already MPTCP?
> 
> [Med]  The upstream MCP is on the default path (this is your CPE,
> typically). The upstream MCP does not touch to MPTCP signal. All what the
> CPE does is to translate the source IP address of the MCTCP client to an
> external IP address assigned to the CPE.
> 
>  It’s either going to be explicit
> > - and addressed to the MCP - or implicit, and intercepted - and in
> either
> > way by the spec it will then be converted to TCP.
> 
> [Med] The upstream MCP is implicit; the MPCPT client is not aware there is
> an MCP on-path.
> 
> >
> > So what is the actual scenario where the above cases will exist?
> [Med] I'm not sure to understand the question, but the scenario is
> characterized as follows:
> * an MPTCP-capable client located behind a CPE that embeds an MCP.
> * The upstream MCP is instructed to not alter MPTCP connections issued
> from that MPTCP-capable client (native MPTCP connections)
> * The downstream MCP is implicit.
> * The downstream will need a trigger to avoid converting native MPTCP
> connections to TCP.
> 
> >
> > > 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.
> >
> > So what does that mean? Does that mean “if there’s an MCP on the path I
> > would like to use it” ?
> >
> 
> [Med] Yes.
> 
> > > 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.
> >
> > So who does?
> 
> [Med] The CPE will track the connections it proxies.
> 
>  The CPE needs to keep track of what data it sends to the MCP
> > and which it sends direct?
> 
> [Med] As per its normal operations, the CPE needs to keep track of NAT
> sessions. Native MPTCP connections will be handled as any of these NAT
> sessions. The connections the MCP proxies to MPTCP will be tracked in a
> dedicated binding tables.
> 
> >
> > >> 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).
> >
> > That does not affect the protocol itself.
> 
> [Med] It does as the base protocol asumes a deployment model when both
> endpoints are MPTCP-cabaple.
> 
> >
> > > * it is deigned to not break native MPTCP connections
> >
> > That does not make it MPTCP-specific.
> 
> [Med] It does because we need a clear indicator to distinguish native
> MPTCP connections from proxied ones. We don't want to break e2d MPTCP,
> when it is possible.
> 
> >
> > > * it solves current MPTCP deployments problems with SOCKS.
> >
> > That does not make it MPTCP-specific.
> 
> [Med] It is specific to MPTCP because it is about MPTCP deployment. That's
> obvious for me!
> 
> >
> > I feel like a broken record here but this signal does not need to be an
> > MPTCP option because:
> > - It does not signal any information which is specific to the operation
> of
> > MPTCP
> 
> [Med] We are not in the e2e MPTCP model, but "network-assisted MPTCP".
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp