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

Joe Touch <touch@isi.edu> Fri, 11 November 2016 20:22 UTC

Return-Path: <touch@isi.edu>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370F7129CD4 for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 12:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8MvGmfoz0VF for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 12:22:15 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AE9129CD1 for <multipathtcp@ietf.org>; Fri, 11 Nov 2016 12:22:15 -0800 (PST)
Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uABKLu6h013417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Nov 2016 12:21:57 -0800 (PST)
To: Olivier.Bonaventure@uclouvain.be, philip.eardley@bt.com, multipathtcp@ietf.org
References: <0898853c01b245aa8b3c45c9da478d6a@rew09926dag03b.domain1.systemhost.net> <5aef607f-07a0-ee92-e796-856e51ec29e1@uclouvain.be> <1e4ffa54-963d-3e14-8b6c-41ca63695643@isi.edu> <fe26175f-679c-c7c1-b95f-5051201f03f7@uclouvain.be>
From: Joe Touch <touch@isi.edu>
Message-ID: <31d5a987-b2bd-4e5e-7c6c-e822c2f2b0cd@isi.edu>
Date: Fri, 11 Nov 2016 12:21: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: <fe26175f-679c-c7c1-b95f-5051201f03f7@uclouvain.be>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/RWTQQcLlcZO2aTlYNGfm8RfPUlE>
Subject: Re: [multipathtcp] Single-ended Multipath TCP Proxy work item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2016 20:22:17 -0000


On 11/11/2016 12:08 PM, Olivier Bonaventure wrote:
> Joe,
>>
>> 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.
>
>
> With the words TLV-format, I wanted to report some of the suggestions
> made on the list, namely to explore the possiblity of placing the
> proxy information as a shim application that exchanged the proxy
> information inside the SYN and SYN+ACK and leaves all the other data
> for the normal bytestream. It might work, but I'd need some time to
> think about it in details.

This is not backward compatible with legacy TCP. All information in the
TCP SYN can be kept by the legacy server and can thus pollute the data
stream of the legacy connection. TCPM already explored this.


>>
>>> ...
>>>
>>> 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).
>
> With the single-ended proxy, we are in a specific use case.
>
> The application issues connect(server, port)
>
> The stack does connect(proxy, port) and informs the proxy of the
> server address and port number. The proxy then connects the server and
> port.
> Since the client will issue many connections towards this proxy, we
> can define a test to verify that there is no middlebox on the path
> between the client and the proxy (and fallback to regular TCP if a
> problem is detected).

None of this matters... what matters is the legacy.
>
> If the SYN to the proxy fails, a possible fallback is to send a SYN
> directly to the server. This does not require any timewait since the
> connection is towards a different destination address.

You're describing the behavior of an application (to TCP). The problem
is that you want to create a new TCP, one where an option that isn't
reflected in the SYN-ACK results in a failed connection. Having any
option have this property is (by definition) breaking backward
compatibility when that option is used.

The problem with such "MUST use" options is that there is no way to
*ensure* that this capability is used only by a particular application
for a particular use.

Joe