Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Wed, 02 November 2016 14:07 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 9F138129504 for <multipathtcp@ietfa.amsl.com>; Wed, 2 Nov 2016 07:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 3za_28FoMA9D for <multipathtcp@ietfa.amsl.com>; Wed, 2 Nov 2016 07:07:02 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 70EB8129491 for <multipathtcp@ietf.org>; Wed, 2 Nov 2016 07:07:02 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id p190so271055589wmp.1 for <multipathtcp@ietf.org>; Wed, 02 Nov 2016 07:07:02 -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 :content-transfer-encoding:message-id:references:to; bh=wAVwxt4ooQymes3snzmDdW4p+BP5VrsgzGWj4eVKJgw=; b=CMuAd0sMK9uLmTidE2/zeYPe21XK+D/jKLXn3r3sJ0X36/M1xNoQ1ABk+G5ZIzYyNL 5VdtzKR0/6zlJYjNB5io0CEKjHwjENrtS5nTywO8mshRMPp7YiL8sxiyOrSeJ6WwOeGQ oo1TpHB4ZdIE2XzXfJvTS2BWeHiJeqQyGig9YnFIwqZ6fE9nIAYijAkRZRKIHZbCHfuG K73/exyaaz4ix2qydbABbFpsfgDg5p0KrNpgf6Idp0andySVV8Ei0pAbHCcbW7pkWDcS wtCxlp6Vb7pyEYTfchlNiip0BE557Ng3dXHBbgTVGTIqma7yD2Y6JtP+RrRlott4U47y UXYw==
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 :content-transfer-encoding:message-id:references:to; bh=wAVwxt4ooQymes3snzmDdW4p+BP5VrsgzGWj4eVKJgw=; b=dO53JVEOXzCOyvu00Yq76ZFEG29I4/1LvPMZwcfFM+BFeqmYeito25ZQQ3Ih49c/8n oipNZJowT3hjCjM+trPRDVR7eM7l02Wn7LpfGE8qw4M11aclDe73uYp8VrAqBujijKy5 2GRkwnYlLZxxDDYI9klXDO/HCJzg0JutHg43/pNWO+UBfb170I5RANwt1uZXotN6+e+X A9lg59jP+YNpz3AhBFCc4H2qwRmcro1dsJjnaAd0moDVEqsh08vhfBjL87d6hiTb9lOs aKjR7tokV5SmMNirYcxX++2ycXgRGIMTPGDPQOQIolmoGpSPNejJYqMOI/UmmZ31OVL8 D1CA==
X-Gm-Message-State: ABUngvei/ftUmPKg9+Z+fUR9/Fu5xIyOuMcNaczieeWBRylfyQDyxzlnY9yzLmQPlmwrew==
X-Received: by 10.28.45.69 with SMTP id t66mr3423828wmt.46.1478095620791; Wed, 02 Nov 2016 07:07:00 -0700 (PDT)
Received: from [10.44.28.203] (host81-142-89-185.in-addr.btopenworld.com. [81.142.89.185]) by smtp.gmail.com with ESMTPSA id 194sm39209360wmj.0.2016.11.02.07.06.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 07:07:00 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Wed, 2 Nov 2016 14:06:57 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <85D52AE4-FE5F-4977-8927-6BDB72614D07@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>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/2mxm1W4iYaFaXFIJsjfqhUVZUzw>
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: Wed, 02 Nov 2016 14:07:05 -0000

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.

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

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

However, I don’t understand the scenario you’ve drawn above. In the “broken” case, the downstream MCP is converting MPTCP to TCP. But what you ideally want is a direct case to the destination? But you’ve already said above that the sender has no knowledge of whether the far end is MPTCP capable or not, so the downstream MCP should default to TCP (i.e. the “broken” case).

And furthermore, why is the client talking MPTCP, and being translated by an upstream MCP, when it’s already MPTCP? 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.

So what is the actual scenario where the above cases will exist?

> 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” ?

> 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? The CPE needs to keep track of what data it sends to the MCP and which it sends direct?

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

> * it is deigned to not break native MPTCP connections

That does not make it MPTCP-specific.

> * it solves current MPTCP deployments problems with SOCKS.

That does not make it MPTCP-specific.

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
- It does not need to be part of the MPTCP protocol in order to be implemented
- It does not need to be read or understood by any devices which are not MCPs or compliant end hosts (i.e. not by any other devices which implement MPTCP)

As specified, it sits in the TCP payload. This is the right place for it. It is a signal purely between an end host and the MCP.

Regards,
Alan