Re: [multipathtcp] potential MPTCP proxy charter item

Mirja Kühlewind <> Mon, 07 November 2016 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2D9C128B44 for <>; Mon, 7 Nov 2016 07:53:22 -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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QZD8Ex0SkttL for <>; Mon, 7 Nov 2016 07:53:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9B87129478 for <>; Mon, 7 Nov 2016 07:53:18 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77234D930D; Mon, 7 Nov 2016 16:53:17 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id ritQCl97P7Ox; Mon, 7 Nov 2016 16:53:17 +0100 (MET)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 2BCB2D9309; Mon, 7 Nov 2016 16:53:17 +0100 (MET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mirja Kühlewind <>
In-Reply-To: <>
Date: Mon, 07 Nov 2016 16:53:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <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> <> <> <> <> <>
X-Mailer: Apple Mail (2.3251)
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 15:53:22 -0000

Hi Olivier,

see inline.

> Am 06.11.2016 um 22:46 schrieb Olivier Bonaventure <>:
> Mirja,
>> I really don’t buy our argument why you should develop such a mechanism for MPTCP only compared to a generic solution that could be used by all (existing and future) TCP extensions. MPTCP is not the only extension that could make use of this (tcpinc is another example) and I’m sure there will more mechanisms in future that would benefit from additional option space in the SYN.
> I'd be very happy if TCPM came up with a solution to this problem that works for any TCP extension, but progress in this domain as been very slow. On the other hand, the deployment of MPTCP could be an opportunity to rethink the way options are negotiated in the SYN and improve that for the future without being forced to support 30 years of history of TCP stacks.

I don’t think supporting TCP stacks is the problem. Network deployment is. And MPTCP will have the same problem than plain TCP has. If there is an (industrial) need for tcp-edo this could drive the working in tcpm forward.

> Tomorrow's hosts will very likely be multihomed and if not, they will probably use multiple IPv6 addresses. On such hosts, the ability to switch from one address to another will a common requirement. MPTCP handles those changes in a clean way.

multipathing can be done on multiple layers of the stack. MPTCP is not the only solution.

> As a working group, let us imagine that MPTCP becomes the default reliable transport protocol by year 202x and that all hosts use MPTCP. Having this dream in mind, what could we do today to ensure that MPTCP is an clean and evolvable protocol. Here are a few ideas :
> - Ensure that the option space in the SYN is large enough to carry the options that are required, e.g. to exchange key material for tcpinc
> - Why not consider that sending MP_CAPABLE implies other options that are negotiated independently today, e.g. :

Because these are independent mechanisms and there is value in keeping them independent. If you want to negotiate all options at once and save option space, then you should specify one new TCP option instead of doing something like this implicit for MPTCP. That’s still work that would go into the tcpm working group. The main purpose of the mptcp working group currently is to specific the bis version of the protocol (and support documentation). However, in the long-term any tcp maintenance including mptcp maintenance should be done in tcpm because mptcp is not an own protocol; it’s a tcp extension.


>   - WScale option (would it make sense in 202x to use a 64KB window ?)
>   - TCP SACK (would it make sense in 202x to create a connection without SACK)
>   - Although timestamp option is often negotiated today and required by RFC7323 for PAWS, MPTCP does not require PAWS since it uses 64bits DSNs
>   - Could we include the TFO negotiation inside the MP_CAPABLE option ?
> This would reduce option space in the SYN and simplify the MPTCP stack.
> Olivier