Re: [multipathtcp] Single-ended Multipath TCP Proxy work item

Joe Touch <> Fri, 11 November 2016 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65281129BFD for <>; Fri, 11 Nov 2016 10:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.396
X-Spam-Status: No, score=-8.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TaamPNDg4siJ for <>; Fri, 11 Nov 2016 10:10:42 -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 CCA801293F0 for <>; Fri, 11 Nov 2016 10:10:42 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id uABIAIjB019264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Nov 2016 10:10:18 -0800 (PST)
References: <> <>
From: Joe Touch <>
Message-ID: <>
Date: Fri, 11 Nov 2016 10:10:18 -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: multipart/alternative; boundary="------------78902C705F6D7E3C93D8864B"
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [multipathtcp] Single-ended Multipath TCP Proxy work 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, 11 Nov 2016 18:10:44 -0000

On 11/11/2016 10:01 AM, Olivier Bonaventure wrote:
> The key issue is the ability to signal addresses (mainly the server
> address) to the Proxy without adding delay to the connection
> establishment. This can be achieved by either :
> - adding options to the SYN (but we have to cope with the limited size
> of the TCP options field in the MPTCP SYN)
> - adding information in the payload of the SYN, this information would
> likely be encoded in a TLV format like the TCP/MPTCP options and
> should be compatible with the utilisation of TFO. 

> ...
> I don't think so. If we end up putting TLV information in the payload
> of the SYN, some parts of the SYN payload will not belong to the
> bytestream and this might affect the protocol semantics.

If you put options in the SYN payload, you don't have TCP anymore. TCP
allows the user to pick source and dest ports and addresses. There's no
way to fallback without resetting the pending SYN and that needs to be
followed by a wait (pref a TIME-WAIT equivalent). It's not TCP's
perogative to retry the connection with a new source port.

That was known when MPTCP was created. It was known when TCPM explored
the variety of alternatives to extending the SYN (including sending both
new and legacy SYNs at the same time, send a SYN and an "out of band"
message (EOS-SYN) and 4-way handshake). If you think you have an
approach that works, please review these docs (I'm updating EOS-SYN  and
the non-SYN EDO extension with more detail once the queue opens). Let's
not replicate that discussion here.