Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Thu, 03 November 2016 14:16 UTC

Return-Path: <alan.ford@gmail.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 832C41296D4 for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 07:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6C6jMcYnyEZs for <multipathtcp@ietfa.amsl.com>; Thu, 3 Nov 2016 07:16:07 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3528F1299F9 for <multipathtcp@ietf.org>; Thu, 3 Nov 2016 07:16:07 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id t79so103798645wmt.0 for <multipathtcp@ietf.org>; Thu, 03 Nov 2016 07:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8FwF7PdK2q9GA55Ln4exKd3n231vV96+CSlBDnRRPpo=; b=dfm/3MVe5rZ6jUF/NkWIENWW6o2/13XZNi3eIcbSWClyQ8vswYViZ/hW/hNrXozBlv U4NqmZYUJTc4lSbA5eWwdEzqL6KGqEDkiLfMzKMwwUCsmw/jL/XmuN8n2aAf/Qc4Ysz9 32UrXrM0ZKq56QFcIvnWpFP667mbGZ/a0BEUYEwNM/HhJs/A5z1jpOSAEWqE0NJPvREA lM24JQT77agTFZdLWI9rt6bKEZTA5dNBuH5JWnJxSwtrjswgddO49fad1W+HQ0Xx0tbt TbLs2SX7sUHK5Cgl3zczoq2ZCDYewCP0gA2k5blnWi98USxlw4R+3TJ0CV8CWqsaObfW 0MwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8FwF7PdK2q9GA55Ln4exKd3n231vV96+CSlBDnRRPpo=; b=CkVDkoC/hmjcc/nRfFAxLyaaDsCrb7CoUyn3UYK5L/aJqu6/VfjVMtUPZEx93qZWxQ UO+geL0ep9Uf6RVwlwiTG/hZZOOZyQ4dkKuq6GBvM64Hz9sIwY5ykkpNmtK/VlyQH3fI 4mSogA8y6k5yMP/Bt2OsPf6Rfdu0MfSz1eg0BY199oENut2n7en0VbR2H67Pd0n6KlkA 2g7gpMugRtZEg1VtzIYEbjV747tWpqMKIaxnhYCRVGb+ax7U6qE70haxWbiNuXN9N1vD G7NzZEOLt707y91hTjOB4qqBouev8VRXsypIeQxxqN9GlQQ7XqlGuuwKeJ/3galCz+r+ d18w==
X-Gm-Message-State: ABUngveePHB5oyJwlzEbkHI8HJSZlR4RlfgIxn77xJ+Xej2jBwkYM1nOLb90u/7NPg/02Q==
X-Received: by 10.28.196.79 with SMTP id u76mr2356782wmf.25.1478182565599; Thu, 03 Nov 2016 07:16:05 -0700 (PDT)
Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id uq6sm8821733wjc.37.2016.11.03.07.16.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Nov 2016 07:16:05 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D62EE80-8561-4276-BDE0-71BA70512C71"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 3 Nov 2016 14:16:03 +0000
Message-Id: <D2630820-7586-4361-A626-3278F22C319C@gmail.com>
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>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/dGMGuys5zOIEWMBz-AF3dZ0ecWg>
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 14:16:09 -0000

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