Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<> Thu, 20 April 2017 06:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2CD0128BB7 for <>; Wed, 19 Apr 2017 23:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BlKuNSvC4xGW for <>; Wed, 19 Apr 2017 23:16:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B293112EB04 for <>; Wed, 19 Apr 2017 23:16:14 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 3B1A8C024C; Thu, 20 Apr 2017 08:16:13 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by (ESMTP service) with ESMTP id 00E76120065; Thu, 20 Apr 2017 08:16:13 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 08:16:12 +0200
To: Joe Touch <>, "" <>, "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSuTkeFYN3Pf6Ey0Kw29UUSw2QvaHNwcPg
Date: Thu, 20 Apr 2017 06:16:11 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50F91OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Apr 2017 06:16:20 -0000


Please see inline.


De : Joe Touch []
Envoyé : mercredi 19 avril 2017 20:17
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/18/2017 10:26 PM,<> wrote:
As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.
I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:

 I really reiterate my comment to read
Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
[Med] We are not multiplexing connections. This is explained in
   The upstream MCP maps an upstream TCP connection onto a downstream
   MPTCP connection (and its associated subflows) . On the upstream MCP,
   an established MPTCP connection can be identified by the local Token
   that was assigned upon reception of the SYN segment from the Client.

- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
[Med] The one to the proxy. This is important for subflows management and traffic distribution.

- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?
[Med] The proxy will need to strop any supplied-data in the initial SYN, and then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doing something similar to SOCKS for the data plane. There are some new features compared to SOCKS that I won't detail here. The reader may refer to

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?
[Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification we are doing at this level is to insert MPTCP options. And even for this case, as shown in slide 30, when there is an exhausted TCP option space in the original SYN, ** no ** MPTCP options are inserted. So, all is safe.

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?
[Med] Interoperability is needed here because the CPE and the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be standardized. Other matters like those you mentioned are key to keep in mind.