Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 03 November 2016 09:26 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 CD489127ABE for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 02:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.116
X-Spam-Level:
X-Spam-Status: No, score=-3.116 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, 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 KtgxR1yFGVoy for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 02:26:07 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7745129490 for <multipathtcp@ietf.org>; Thu, 3 Nov 2016 02:26:06 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 75BF540423; Thu, 3 Nov 2016 10:26:05 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 3F6181A0070; Thu, 3 Nov 2016 10:26:05 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 10:26:05 +0100
From: mohamed.boucadair@orange.com
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNRJiHc0sTHVljEKJBcjlfAJFpaDG99OA
Date: Thu, 03 Nov 2016 09:26:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAAA88@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>
In-Reply-To: <85D52AE4-FE5F-4977-8927-6BDB72614D07@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.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/CO7Yj1HnkaSeZP79CG8q83h5gko>
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:26:10 -0000

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".