Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Mon, 07 November 2016 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 055C1129AAA for <>; Sun, 6 Nov 2016 23:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f8VPMmoTp1v0 for <>; Sun, 6 Nov 2016 23:50:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F7541295B0 for <>; Sun, 6 Nov 2016 23:50:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id AB65D67DACB; Mon, 7 Nov 2016 08:50:16 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 AB65D67DACB
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478505016; bh=R4MCRKHyb7UpXocgsV+Hn6b7QgVY07i0oASrE505upQ=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=JoRNA2uVcdqlX+KZbzBELj7ylUeOTtwkjjrdGL+MJNPuiwiQhI4szsvPVCikeawwU rVNrvcEsSe3lldw79KmCJuM0Ae+SmPvD4bTF+ze68pTKSJOOMQjrHrxThJnF1vgQQ5 6AI/8YHREWJq7HHLe/kNlgZFd7hPhJkf/5RFn7Fo=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-3
References: <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <>
To: Alan Ford <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Mon, 07 Nov 2016 08:50:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: AB65D67DACB.A6C16
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
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: Mon, 07 Nov 2016 07:50:26 -0000


>> Indeed, the same could apply for TCP, SCTP and probably any transport
>> protocol.
> Good, I’m glad we agree here :-)
>>> Why are you trying to make it a MPTCP option?
>> The need comes from MPTCP. It could be defined as a TCP option instead
>> of an MPTCP option. I think that explicitly specifying a proxy node is
>> a useful feature that should be part of the transport protocol and not
>> tied to a specific application. We are less and less in a pure
>> end-to-end deployment model for the Internet and making those
>> transport proxies explicit would make sense.
> Why is it an /option/, however? When you are explicitly targeting a
> proxy node, surely the proxy is just as capable of pulling the data out
> of the payload here?

Because the addressing information that is used for the proxy is part of 
the control plane and not part of the bytestream. I think that it is 
very important from an architectural viewpoint to maintain a clean 
separation between the byte stream that is exchanged between the 
applications and all control information that should be placed inside 

We explore the possibility of adding information in the bytestream for 
MPTCP and eventually decided to place all control information in 
options. If you look at HTTP, proxy-related information is part of the 
HTTP headers and not part of the payload. This is the same type of problem.