Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Fri, 04 November 2016 10:12 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 06CD2129B3C for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 03:12:48 -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 feJ53xYpEfjm for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 03:12:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF252129B37 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 03:12:45 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 22F8F324223; Fri, 4 Nov 2016 11:12:44 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EF8EA23809C; Fri, 4 Nov 2016 11:12:43 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 11:12:43 +0100
From: <mohamed.boucadair@orange.com>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNn6XQgvumHnbm0arzSIWTM7lXaDIkvLw
Date: Fri, 4 Nov 2016 10:12:43 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAC5DE@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> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch>
In-Reply-To: <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch>
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
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/Z5Cm2W7kLBVBeOxKGOAxZ-iAKk4>
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: Fri, 04 Nov 2016 10:12:48 -0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> Envoyé : vendredi 4 novembre 2016 10:34
> À : BOUCADAIR Mohamed IMT/OLN; Alan Ford
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi all,
> 
> first, I agree with Alan that such a signal does not need to/should not be
> part of the MPTCP protocol.

[Med] Defining another channel to carry the signal "I want to be MPTCP-proxied" outside the MPTCP normal channel will import the same set of hindrances we had with MPTCP design for middlebloxes traversal. The use of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic engineering design. 

 MPTCP (as TCP is) is an end2end protocol.

[Med] That's the theory. The deployment reality is as follows: 
* The network can help in some cases to establish (good) TCP connections (https://datatracker.ietf.org/doc/rfc3135/). 
* TCP proxies are deployed in many networks (mainly mobile) for other reasons such as: avoid quick retrieval of (video) content that will consume a subscriber data volume while the user won't view that content.
* MPTCP support is null at the server side. 
* There are some MPTCP-capable client, but those are still rare compared to the installed base.  


 If
> you have one (or two) proxies in the middle, you split up the connection
> into multiple new ‚end2end‘ connections. If you need additional signaling
> information on one of the new connections, that a question for a high-
> layer protocol that uses MPTCP (which is what you do, when you propose it
> to be part of the payload).

[Med] hmm..but our application is "MPTCP proxy"!

> 
> Second, I’m not a big fan of the a two side proxy scenario where one side
> simply assumes that the destination is not MPTCP-capable.

[Med] The current proposal is as follows: 
* MPTCP connections issued from MPTCP-capable hosts will be forwarded as such to their destinations without involving any MPTCP proxy.
* TCP connections that are issued from non MPTCP-capable hosts can benefit from the "Network-Assisted MPTCP". 

Can you please clarify what is "bad" with such design?

 This does not
> support MPTCP deployment but hinders native MPTCP deployment (basically
> ensuring that these proxies stay forever in the network and add additional
> complexity even if all endpoints are MPTCP-enabled one day).

[Med] The current proposals calls the following design goal:

   o  Avoids interference with native MPTCP connections.

Native connections will go direct without being reverted to TCP! Please consider reading https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09#section-7.  

 I guess a
> proxy should always first forward the MCTCP handshake and only if the
> reply does not support MPTCP, then termite the connection, reply the
> initiator accordingly and setup a new TCP to the destination. 

[Med] As I replied to Alan, this is an optimization that can be considered. Waiting for the SYN/ACK is not the only trigger that can be considered, there is also a whitelist approach. Those details can be worked out better once we have (hopefully) a WG document ;-)

This might
> cause additional delay but it provides a big benefit if the destination is
> MPTCP-capable and supports native deployment.
> 
> Mirja
> 
> 
> > Am 03.11.2016 um 15:16 schrieb Alan Ford <alan.ford@gmail.com>om>:
> >
> > Hi Med,
> >
> > Comments inline...
> >
> >> On 3 Nov 2016, at 09:26, mohamed.boucadair@orange.com wrote:
> >>
> >>> -----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
> >>>
> >>>> 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.
> >
> > You corrected this later to “No” … So what does it mean? In fact,
> “please proxy me” ?
> >
> >>>
> >>> 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.
> >
> > OK I understand this scenario now, it is special for implicit mode,
> since if the CPE was acting in explicit mode, it would address the packets
> to the MCP.
> >
> > What are the benefits of using implicit mode in this scenario? This is
> so you can target it to an MCP without knowing the target address. Are
> there any other reasons why this would be used rather than explicit mode?
> And what sort of deployment would this scenario exist in?
> >
> >>>>
> >>>> 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.
> >
> > Whilst the base protocol document may be written that way, there are no
> assumptions in the protocol that require it to be used that way, and
> indeed you are making use of this with your proposal.
> >
> >>>
> >>>> * 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.
> >
> > Why? This has no effect on entities which do not implement your
> proposal.
> >
> >>>> * 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’m making a web page. It has some funny cat pictures on it. This is
> delivered over HTTP. Therefore I should make funny cat pictures an
> extension of HTTP.
> >
> > That’s essentially what you’re saying here!
> >
> > My cat pictures are an application of HTTP, just like your proxying here
> is an application of MPTCP. It doesn’t need an extension of the protocol
> to be delivered.
> >
> >>> 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".
> >
> > But again, this does not require an extension to MPTCP to work.
> >
> > Your protocol, as specified, is a signal in the payload. There is no
> need to make this signal like an MPTCP option, since it does not need to
> be handled by the MPTCP implementation.
> >
> > The one slightly more complex case here is implicit mode. However, if
> you want devices to be able to inspect this signal without inspecting the
> payload of every MPTCP SYN, IP already has a standard in the form of RAO
> for alerting devices - RFCs 2113 and 2711.
> >
> > Regards,
> > Alan
> >
> >
> >
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp