Re: [multipathtcp] potential MPTCP proxy charter item

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 04 November 2016 09:34 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 648541296AD for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 02:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 XlU_x5wnMUt8 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 02:34:11 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10A2129539 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 02:34:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F32BED9310; Fri, 4 Nov 2016 10:34:09 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IoTXgfOE9Lwx; Fri, 4 Nov 2016 10:34:09 +0100 (MET)
Received: from [192.168.178.33] (p5DEC2F5C.dip0.t-ipconnect.de [93.236.47.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AAC00D930B; Fri, 4 Nov 2016 10:34:09 +0100 (MET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <D2630820-7586-4361-A626-3278F22C319C@gmail.com>
Date: Fri, 04 Nov 2016 10:34:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch>
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>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>, Alan Ford <alan.ford@gmail.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0FLJpbJ7DDaDmpe-R1WNAZ6scgo>
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 09:34:15 -0000

Hi all,

first, I agree with Alan that such a signal does not need to/should not be part of the MPTCP protocol. MPTCP (as TCP is) is an end2end protocol. 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).

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. 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). 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. 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>:
> 
> 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