Re: [multipathtcp] Proposed charter text for MPTCP proxy item

Olivier Bonaventure <> Wed, 16 November 2016 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73E571294B6 for <>; Wed, 16 Nov 2016 11:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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, 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 M5EE3-btQdt0 for <>; Wed, 16 Nov 2016 11:48:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 763161293E3 for <>; Wed, 16 Nov 2016 11:48:46 -0800 (PST)
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 4C7DC67DA73; Wed, 16 Nov 2016 20:48:38 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 4C7DC67DA73
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1479325718; bh=c0a+iaOpk/qOM05Hzl7cOLv94cVarg3CSnjyPmysnOI=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=l9qyQPqjVp2FujbpuS5bIfCsHtnkpUWuff/5BrioACjGCwi4pgSy/O9k4miWpO1sH Sn5aTPrD9Rd0dvz1IAt+Am4uH+2h5FWbK/bL2D+ZkS3yUB6fT1eHnFH4Lu2Co7Vz1I yiYupPrirqbwdSsq8oCZfY48mv8Gtqz8KlkN2EA0=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4
References: <> <787AE7BB302AE849A7480A190F8B933009DB4C79@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DB4F9A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Wed, 16 Nov 2016 20:48: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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 4C7DC67DA73.A4448
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] Proposed charter text for MPTCP proxy item
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2016 19:48:49 -0000


> On the question of single-ended proxy as well as 2-ended. Why is the
> former considered by operators? – surely it needs MPTCP in end hosts or
> servers, which unfortunately isn’t there yet? Or do you mean ‘today the
> operators want to deploy 2-ended proxy solution, and make sure the
> solution will work in the future for 1-ended, without any great changes’

The use cases are different.

The single-ended proxy is for MPTCP-enabled smartphones for which 
operators want to combine LTE and WiFi. These smartphones are typically 
sold by the operators themselves with a special firmware. There are a 
least two vendors that have included the open-source Multipath TCP 
implementation in the Linux kernel on several of their recent 
smartphones. This special firmware is typically only deployed in 
countries where there is a WiFi/LTE bonding service. This use case is 
currently supported by using SOCKS, but SOCKS introduces a delay to each 
TCP connection because it exchanges information in the payload. A 
single-ended proxy solution would provide improved performance for this 
use case.

The two-ended proxy is for CPE-routers that are controlled by the 
operators and can be equipped with an LTE connection or attached to an 
LTE gateway in addition to their xDSL line. In this use case, the CPE 
acts as a proxy that converts TCP into MPTCP and then the operator runs 
to proxy to convert it back to regular TCP. These two proxies are 
required because very few endhosts and very few servers support MPTCP 

 > Happy to add 1-ended if operators really want it. It clearly adds work
 > to make sure that the solution works in both cases, as well as protocol
 > work for the first proxy to discover whether a 2^nd proxy exists for
 > this particular receiving end host.

We should cover these two use cases, they are both important for MPTCP.