[multipathtcp] Dual-ended Multipath TCP Proxy work item

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 11 November 2016 18:07 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 44418129C03 for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 10:07:40 -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 5JiDn8-UkfzB for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 10:07:38 -0800 (PST)
Received: from smtp4.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 4276E129BF3 for <multipathtcp@ietf.org>; Fri, 11 Nov 2016 10:07:38 -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@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5383D67DA8C; Fri, 11 Nov 2016 19:01:38 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be 5383D67DA8C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478887298; bh=8FRP9eKuqiDA0lWUDKeFfiJZ56r37AvpA7Uu+gk0WO0=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=OzBq8/TVazahDj+AfLA/wjyrF9Ian6C0J1wMYHXc8jizGMfptGKR9BGtwnKA7306z 8xzY9QmmojmF3+5xU9KWF0qz0z/j1tA0oVvGQTB0vAgt3Ezlcc7Q6jePsuJt2WVML+ +sE1pafFyUPF0HB+5aeyitwSup7tV8zHHMCc3oFk=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-4
References: <0898853c01b245aa8b3c45c9da478d6a@rew09926dag03b.domain1.systemhost.net>
To: philip.eardley@bt.com, multipathtcp@ietf.org
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <7b2ef6b9-c058-2544-500a-51780e587891@uclouvain.be>
Date: Fri, 11 Nov 2016 19:01:37 +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: <0898853c01b245aa8b3c45c9da478d6a@rew09926dag03b.domain1.systemhost.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: 5383D67DA8C.A72A8
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/9hRQCv9f-rwpGCJO0TEgG17xqOk>
Subject: [multipathtcp] Dual-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 18:07:40 -0000

Phil,
>
> Perhaps this is speaking too soon, but it looks like the very active
> discussion is reaching some common understanding?
>

Please find some comments related to the dual-ended proxy Multipath TCP 
Proxy use case. In this use case, there are two proxies :
- an on-path upstream proxy that resides typically in the CPE
- a downstream proxy. This proxy may be on-path or off-path. My answers 
relate to the off-path proxy unless otherwise noted

>
>
> What we’d appreciate is a summary of what the assumptions
> /understandings are about:
>
> ·         The scenario (for instance: the MPTCP-enabled host knows the
> address of the proxy (eg through configuration); and it knows the
> address of the ‘legacy’ host it wants to communicate with)

The scenario is a laptop that does not support MPTCP connected to a CPE 
and the CPE is itself connected to two access networks (typically xDSL 
and cellular). The upstream proxy is included in the CPE. The downstream 
CPE is typically installed inside the network of the access provider.

>
> ·         If any impact is already envisaged on the current MPTCP
> protocol’s fallback behaviour and coping with middleboxes

I don't think so. If the proxies are deployed by a network operator, it 
is possible to ensure that there are no middleboxes that mess with MPTCP 
on the paths between the two proxies.

>
> ·         If we can agree that the solution is based on a new MPTCP option

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.
>
> ·         If any impact is already envisaged on the current MPTCP
> protocol’s semantics (other than the new option) eg in terms of
> https://tools.ietf.org/html/rfc6824#section-4


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 any impact is already envisaged on TCP’s semantics, or any
> mods are needed, or assumptions about its behaviour, etc

I don't think so.


> ·         If any impact is already envisaged on other existing transport
> protocol’s semantics (presuming people still would like non-TCP in scope?)

I'm not personally convinced by the benefits of transporting an non 
bytestream transport protocol into TCP.

> ·         Anything else that you think is needed in order to frame the
> work item
>

This use case is considered by various network operators. They are in a 
position to ensure that there is no middlebox between the two proxies. 
We should take this fact into account by designing a solution that is 
optimised for the case where there is no middlebox on the path. In this 
use case, there are a large number of MPTCP connections between the 
upstream and downstream proxies. We are not in the same situation as a 
host trying to establish a single MPTCP connection towards a random 
server over a random path. We should leverage this knowledge in our design.

As for the single-ended proxy, the key requirement is that the creation 
of an MPTCP connection through a Proxy does not require additional rtts.


Olivier