Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Olivier Bonaventure <> Wed, 19 April 2017 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 445F41314B4 for <>; Wed, 19 Apr 2017 00:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y4lXcwkjMU_0 for <>; Wed, 19 Apr 2017 00:37:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0824129426 for <>; Wed, 19 Apr 2017 00:37:25 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3732E67DA45; Wed, 19 Apr 2017 09:37:17 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 3732E67DA45
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1492587437; bh=opCfbUjt4njz7KH0xYKb3KgzbxztT7dXLPBhe4KpAcY=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=peQC4Ww4rRjx3vcxvS7BqSH1TskeVwsr/B5f8qyJ+xyqhmbSXPHUlCUUi1Zpv+DY/ KCUz385DuPuUCBv/3owM3ew8oErvavAAuuFVIvrNyjKb+iNs8sX3T8xZrBiiq0MfUM 5oytVp9ghH1CKWRv2DigCPjC2VpbGsds3oqQnzQA=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3
References: <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Wed, 19 Apr 2017 09:37:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 3732E67DA45.A2045
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Apr 2017 07:37:28 -0000

> During the MPTCP meeting in Chicago we did several hums about potential
> MPTCP proxy work. Our interpretation of these hums is that we should do
> a consensus call for the following work:
> --
> MPTCP is now seeing widespread deployment in networks to bond together
> two accesses, such as fixed and mobile broadband, by using two MPTCP
> proxies, one in the home gateway or Customer Premises Equipment and one
> in the network. The WG develops a solution where the proxies are both
> under the control of the operator and where it is assumed that they are
> not on the default path. The solution is based on using the payload of
> an MPTCP packet to transfer a signalling message between the proxies. It
> is believed the solution will not require changes to RFC6824bis. The
> solution may require a means of configuring set-up information in the
> proxies, which would be done in coordination with other IETF WGs such as
> DHC. The WG does not develop a mechanism for the two proxies to discover
> each other.

I fully support the work on MPTCP proxies. I would not focus on the 
current use case (how gateway and two proxies) but more on the 
importance of :

- being able to terminate Multipath TCP connections on a proxy somewhere 
in the network to bond different access networks when the server is not 
MPTCP capable
- using 0-rtt, i.e. the proposed solution should not require an 
additional rtt to create a connection

The solution will use data in the SYN payload to achieve 0-rtt and 
should not require changes to RFC6824bis

Then different use cases can be built on top of this protocol. The Home 
gateway case that we discussed in Chicago is the first one, but 
smartphones are another one.

I would suggest to separate the work in different documents :
- a first draft describing the syntax of the messages added to the SYN
- a second draft describing how the above protocol can be used to 
support hybrid access networks with two proxies
- a third draft describing how the above protocol can be used on smartphones

Other use cases are possible