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

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 11 November 2016 20:08 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 52838129627 for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 12:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 SAHfTrmwiAm8 for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 12:08:31 -0800 (PST)
Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD528129616 for <multipathtcp@ietf.org>; Fri, 11 Nov 2016 12:08:30 -0800 (PST)
Received: from [192.168.1.2] (unknown [87.66.240.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D8FF367DA5E; Fri, 11 Nov 2016 21:08:19 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be D8FF367DA5E
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478894902; bh=ngmp5hDuJr6FZJvO1xxKiBZxQu0wQvXn4pBnOsu5Y2M=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=wi7qZalv4WNK9hkCW56oMmQ1qmYc8eR3gsNMT3WNZqd08Btx5Jjo9PwAboITlxviP MAqBwhv9q18B8cC/6RzOtrKlRMGwpzJfDIJs17T5oqZ308duKWt3Hj0aPw8+FFlAY7 6PETOsV5E0l1XHjo7Thr/2l8WVGJsawLGILV9Mnc=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-1
References: <0898853c01b245aa8b3c45c9da478d6a@rew09926dag03b.domain1.systemhost.net> <5aef607f-07a0-ee92-e796-856e51ec29e1@uclouvain.be> <1e4ffa54-963d-3e14-8b6c-41ca63695643@isi.edu>
To: Joe Touch <touch@isi.edu>, philip.eardley@bt.com, multipathtcp@ietf.org
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <fe26175f-679c-c7c1-b95f-5051201f03f7@uclouvain.be>
Date: Fri, 11 Nov 2016 21:08:19 +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: <1e4ffa54-963d-3e14-8b6c-41ca63695643@isi.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: D8FF367DA5E.A7F0E
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/c810yMPIeKqMuuy2h8E04Sy5oQw>
Subject: Re: [multipathtcp] Single-ended Multipath TCP Proxy work item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
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:08:32 -0000

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

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.

 > It's not TCP's
 > perogative to retry the connection with a new source port.

I'm not suggesting that.
>
> 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.

I've already read several versions of these docs and would be ready to 
read and review the next ones.


Olivier