Re: [multipathtcp] potential MPTCP proxy charter item

Mirja Kühlewind <> Tue, 08 November 2016 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C19512007C for <>; Tue, 8 Nov 2016 07:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.697
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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MehHx3v-OsFc for <>; Tue, 8 Nov 2016 07:22:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B99BB1295F5 for <>; Tue, 8 Nov 2016 07:13:44 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DCE1D9303; Tue, 8 Nov 2016 16:13:43 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id PLBStqum1z9Q; Tue, 8 Nov 2016 16:13:42 +0100 (MET)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id C3F2DD9305; Tue, 8 Nov 2016 16:13:42 +0100 (MET)
To: Christoph Paasch <>, Olivier Bonaventure <>
References: <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <20161104181615.GP40488@Chimay.local> <> <20161107164831.GK3546@Chimay.local>
From: Mirja Kühlewind <>
Message-ID: <>
Date: Tue, 08 Nov 2016 16:13:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161107164831.GK3546@Chimay.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2016 15:22:52 -0000

Hi all, hi Olivier,

see below.

On 07.11.2016 17:48, Christoph Paasch wrote:
> Hello,
> On 07/11/16 - 09:00:17, Olivier Bonaventure wrote:
>> From an architectural viewpoint, providing addressing information for a
>> proxy is clearly outside the bytestream exchanged by the application. It is
>> cleaner to place this control plane information inside options instead of
>> messing up the bytestream and changing the first few bytes of each
>> connection. I think that we should have a clean separation between the
>> control plane and the data plane in MPTCP. We already use options to carry
>> addressing information related to the endhosts (ADD_ADDR, REMOVE_ADDR), the
>> addresses required by the proxy are the same type of information and they
>> should also be exchanged as TCP options. Encoding them in the payload would
>> likely create more problems in the long term.

 From an architectural point of view it's not part of the application 
bytestream (as you call it; which is the data the application wants to get 
from one point to the other) but also not part of the end-to-end transport 
protocol (which makes sure that these data are delivered in some specified 
way). It should probably be part of the network layer or somewhere in 
between, however, that layer doesn't really exists (see PLUS problem statement).

If you put this information in the (MP)TCP payload in the SYN as proposed, 
you should see this as a shim layer and not part of the bytestream.

> Now I'm confused. I thought that the MCP-option already is in the SYN's payload.
> Wrt to the layer-separation. I think that having a 0-RTT proxying protocol
> in the payload, where the first few bytes of a bytestream indicate the
> server's IP-address would be very beneficial. These few bytes would be
> placed in the SYN, just like the MCP-option, but without the link to MPTCP.
> This would address Med's concerns wrt to additional delay, not interfere
> with TFO,...
> This would allow for some interesting use-cases:
> * I could do a SCTP-proxy where each stream goes to a different server
> * I could do a Quic-proxy
> * I could do a TCP-RACK proxy that allows me to use TCP-RACK as
>   server-support is not there yet (besides Google)
> * ...

Yes, given this is not a specific problem to MPTCP tunnels, that's why we 
have the BANANA BoF!


> Cheers,
> Christoph
> _______________________________________________
> multipathtcp mailing list