[multipathtcp] Single-ended Multipath TCP Proxy work item

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 11 November 2016 18:01 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28E7F129BDD for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 10:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u8idtwmJdV4F for <multipathtcp@ietfa.amsl.com>; Fri, 11 Nov 2016 10:01:37 -0800 (PST)
Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F99F129BE1 for <multipathtcp@ietf.org>; Fri, 11 Nov 2016 10:01:37 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 04B8567DBEE; Fri, 11 Nov 2016 19:01:28 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 04B8567DBEE
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478887289; bh=G5Jc4aU2vlV7SIrl02LWrZe41s0vwI2DOzxR+cYT0qs=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=UekD6OAU1SP2RJPwo5WpyX9OKxoHJ0dz46SdRs8meWK/27+VlWi5D61SU37fzVgYx wWdT/dxOQSXqPD962YYAtVvEjDoM7AaW/M30a4BTwOW5vuxoMkASIMzv+n6lC4FFiX 06ESum9y4SgXWJypLHZ2q+78kEMVy80qpRln/F2s=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
References: <0898853c01b245aa8b3c45c9da478d6a@rew09926dag03b.domain1.systemhost.net>
To: philip.eardley@bt.com, multipathtcp@ietf.org
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <5aef607f-07a0-ee92-e796-856e51ec29e1@uclouvain.be>
Date: Fri, 11 Nov 2016 19:01:28 +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-MailScanner-ID: 04B8567DBEE.A85C4
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/MiRnjmaEOozGuJPb2Hrm1mxkmKY>
Subject: [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 18:01:39 -0000

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

Let try a first answer to your questions for the single-ended Multipath 
TCP proxy work item.
I'll send my answers to the double-ended proxy in a separate email.
> 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 typical use case is a smartphone that wants to combine its WiFi and 
cellular access networks to reach a server that does not (yet) support 
Multipath TCP.

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

I don't think so but this will be a function of the mechanisms that we 
insert in MPTCP.

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

For this use case, given the mobility of the smartphone, it is unlikely 
that the Proxy will reside on path.
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

The key requirement is that the creation of an MPTCP connection through 
a Proxy does not require additional rtts.