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

Joe Touch <> Thu, 20 April 2017 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B61831201FA for <>; Thu, 20 Apr 2017 10:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.89
X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FaAO4LzWVSLc for <>; Thu, 20 Apr 2017 10:31:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77AEF13149F for <>; Thu, 20 Apr 2017 10:31:50 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v3KHUVhF007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Apr 2017 10:30:32 -0700 (PDT)
To:, "" <>, "" <>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <>
Message-ID: <>
Date: Thu, 20 Apr 2017 10:30:29 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------DA20779EA38FC7FA2D4D28B9"
X-ISI-4-43-8-MailScanner: Found to be clean
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 17:31:56 -0000


On 4/19/2017 11:16 PM, wrote:
> Re-,
> Please see inline.
> Cheers,
> Med
> *De :*Joe Touch []
> *Envoyé :* mercredi 19 avril 2017 20:17
> *À :* BOUCADAIR Mohamed IMT/OLN;;
> *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.

Great. It would be useful to explain this a lot earlier and at a higher

> - 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.
So you have three congestion controls running in series? Have you
considered the impact on bufferbloat (of the buffers in the proxy) and

> - 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
If you strip user-supplied data in the SYN, you're *changing TCP
semantics* - esp. for a TFO connection.

So you really can't be doing that...

>     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.
What happens if you create a segment that's larger than the PMTU? what
do you drop or split? (there's no way to do that safely for unknown options)

> 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.
If that were the case, you'd simply be defining a new application
service and asking for a TCP port number.

And you wouldn't be able to do zero-RTT opens.