Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Fri, 04 November 2016 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBA4A129C1F for <>; Fri, 4 Nov 2016 04:07:43 -0700 (PDT)
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 5O3p6mhjIR2e for <>; Fri, 4 Nov 2016 04:07:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD8A2129C13 for <>; Fri, 4 Nov 2016 04:07:41 -0700 (PDT)
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 C437967DA75; Fri, 4 Nov 2016 12:07:34 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 C437967DA75
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478257654; bh=b1QaTWGVDDAff/JvSqK92pdL6A3fKcbWhWMgsMBdhC8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=l+Vu6eqoG13aJGMrRwLUXeu2kxz5kwsEFw+C74jaxs4G2CtQeVThp8gI/G1YYyu1T BEaz4R7Q1ccW61KTB3wTK6pQHRFYVazaxbMpL6v+BVcVPo1zl/C0qYTSL2deAM8/Zp PyvuRiM4V/Yvhjw6JDRuxXCE2+7CQvo8TSqRCzHc=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-6
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: Alan Ford <>,
From: Olivier Bonaventure <>
Message-ID: <>
Date: Fri, 04 Nov 2016 12:07:33 +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: C437967DA75.A5F46
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: Fri, 04 Nov 2016 11:07:43 -0000

> Thank you for updating these drafts, I have been awaiting these with great interest!
> To be clear - again - I have no issue with this work being done in MPTCP WG, it is “how to use proxies to increase deployment of MPTCP”. But this particular document is not MPTCP-specific; whether it is published here or elsewhere I don’t care, but it really shouldn’t’ be written as if it’s extending the MPTCP spec when there is no reason for it to be.
> Finally, you earlier mentioned the possible effect on the base spec regarding a flag, but I see no mention of it in these docs.

Sorry for the late reply. The main problem with the current MPTCP draft 
is the length of the TCP options in the SYN segment. With network 
assisted MPTCP, we could need to encode one or two IP addresses inside 
TCP options in the SYN segment. With IPv4, this might be possible 
depending on the other options that are used. With IPv6, this becomes 
quickly a problem.

As we redefine MP_CAPABLE when moving to RFC6824bis, I think that we 
should try to design a generic solution to allow a SYN segment to carry 
long TCP options. This should be part of the Multipath TCP standard 
specification to ensure that it is future-proof and can be extended later.

Different designs are possible and some have been discussed in the TCPM 
working group. Instead of defining a specific option to allow longer 
options, I would suggest to include this feature directly inside 
Multipath TCP. This would be cleaner and Multipath TCP is anyway the TCP 
variant that mostly requires this feature. Here are a few possible 
designs to start the discussion :

- always force the TCP SYN segment containing MP_CAPABLE to contain 
options in the SYN payload. If all options can fit in the extended TCP 
header, then the payload only contains the TCP EOL option. If there are 
TCP options in the payload, then the last option is always the EOL option.

- add a flag to MP_CAPABLE option to indicate whether the SYN payload 
contains TCP options (terminated by EOL) or not. Same as above for 
encoding the options in the SYN payload

- add a length field to MP_CAPABLE option to indicate the number of 
bytes (or words) of the SYN payload that contain TCP options. In this 
case, we do not need to terminate the options in the payload with EOL.

If RFC6824bis could include a reasonable solution that allows to place 
TCP options in the SYN payload, we would make a huge step to ensure that 
MPTCP is future-proof and that it will be possible to extend it in the 
future. In the short term, the solution could be limited to networks 
where it is known that there are no middleboxes that interfere with TCP 
options, but this would be a strong message to middlebox vendors that 
they will need to support TCP options in the SYN payload in the future.

I won't unfortunately be able to attend the next IETF meeting in Seoul 
but I'd be happy to discuss this by email