Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <> Mon, 07 November 2016 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C4AB129616 for <>; Mon, 7 Nov 2016 08:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4PnwPnu09_Lm for <>; Mon, 7 Nov 2016 08:08:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E4ED129629 for <>; Mon, 7 Nov 2016 08:08:28 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id uA7G7ui7005053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Nov 2016 08:07:58 -0800 (PST)
To: Mirja Kühlewind <>,
References: <> <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> <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Mon, 07 Nov 2016 08:07:56 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
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 16:08:34 -0000

Oh - a quick followup.

If you have an option that "poisons" the connection if not confirmed (as
would using long EDO inside the SYN), then you have to retry without
that option. That is *possible*, but there's another problem.

RFC793 defines options as optional. Making any option mandatory would
require updating RFC793. That sort of change is exactly why long EDO
(actually extending the option space, rather than declaring the
capability) is currently prohibited in EDO.


On 11/7/2016 7:56 AM, Joe Touch wrote:
> On 11/7/2016 7:42 AM, Mirja Kühlewind wrote:
>> Do you mean the MCP forwards the original SYN (and basically does nothing if the server supports MPTCP) or does the MCP terminate the TCP connection and start a new TCP connection with MP_CAPABLE towards the server?
>> Mirja
> If you're OK with needing to terminate a failed option exchange, then it
> might be possible to use EDO in the SYN in its current form.
> TCPM decided to prohibit that in the general case, but I could ask them
> to allow that in very limited environments (but it could NEVER be
> default on).
> Note - the use cases I'm hearing appear to assume very strong knowledge
> about the other end of the connection and the path. In that case, you
> probably can skip most - if not all - of the 'negotiation' options and
> just start using them during the SYN too. However, if you say "no, we
> need to confirm", then you would not be able to use EDO inside the SYN.
> Joe