Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Sun, 06 November 2016 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70DC4129A24 for <>; Sun, 6 Nov 2016 13:47:02 -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 ZcNwOulxCkHJ for <>; Sun, 6 Nov 2016 13:47:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 049BE129A27 for <>; Sun, 6 Nov 2016 13:47:01 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 0DCEE67DACD; Sun, 6 Nov 2016 22:46:54 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 0DCEE67DACD
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478468814; bh=f2FTvj/xlbyFnHUw90sNzKvXsi22GQ9H5vv4hn+FeUU=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=GOHOHVbyr9DKu5r16m8Yz7j91puIJkJ4I3RslzwsCq6r5MqucQxJB7VtOsq42BI5M eTxxiuH9JZ+IlOCI06LZkyr13Q92uXIKWZervEnLTGU7DTmREyjj+fYs+Df708xiSN 3Zx1I6i0VLya4G9XgYsuRrtbuO5PrIKVFdSi6r74=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-4
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> <> <> <> <>
To: Mirja Kühlewind <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Sun, 06 Nov 2016 22:46:53 +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: 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: Sun, 06 Nov 2016 21:47:02 -0000

> 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.

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.

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. :

    - 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.