Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Tue, 08 November 2016 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4398129857 for <>; Tue, 8 Nov 2016 04:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yacg7_TXV5Rd for <>; Tue, 8 Nov 2016 04:29:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E240112962F for <>; Tue, 8 Nov 2016 04:29:37 -0800 (PST)
Received: by with SMTP id o141so65932365lff.1 for <>; Tue, 08 Nov 2016 04:29:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njArc0WnnOrMU8TYg4b9OiCx7TDSJebiQpk8p0ovyk8=; b=Ys7/lwZK4uDZ62LBPRYmxqQxzdE/enXGGS+yJaCc0BuIDcTVcrTd6NMzeu6jXgcKYf EDwv3l3tIp2vyRyGE+rx/KV5ZiqyEwCdDXQ+jlFEBMmFr2qlXAWEadl1uWDtOZU6vYXw PkGLl/nAtnLSjovjqGLW0P9A8CqhUBzt/g+RxBgfNVhEwZnD1eDIhsv83WWcMq7QUlQY aDmFYpYonJo9JkdXvtgfx20cf5wx4gRYydfpz4RZeUhwwFQ0JPj2vR8By35vjiPxvLgN TWX/sE3jDLSQargz94ZEHcR0txKeHsCuwva+/UcgxJcr6DuK9NgwHBKg2zfvDabITfZk 0iNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njArc0WnnOrMU8TYg4b9OiCx7TDSJebiQpk8p0ovyk8=; b=fdeQ4mZlj3awjy1ucvP5JdBgnpgemjEfTwx7ymQ0XorLMCZzOmvWzmCk/dUzV1YA/k BH0HBc+IZ64KJdeVMpAGLMOHYs817GPHzpue8/KRBwGBrGWtkRXzAuBIrlhlvoFs5Quy zxizk9Ti9C8ogWNiJUZzG0AnzZHoXUZrlwnR+Di4ZPusjlE60rV60HK+KHhlqN4zyV90 tBoL5bZZvEWL3D4kaRxgoq2pA19ghGYfGgLnb61N82bEPikwHYUAUTKT59YKxDpoabis ZN49DiMdVh+0n7Rk7826IITLusn6pUPbU9DKyVtgrxfIl1Tl+qGpgMCJVRcivVXdr3IB RYCw==
X-Gm-Message-State: ABUngvdvacMK6r4YcEIbaweLdV6klS7rsdyJWfHeDef2kTAWIzZysNxMTa+wMHabayeQqg==
X-Received: by with SMTP id q20mr7093078lff.5.1478608176006; Tue, 08 Nov 2016 04:29:36 -0800 (PST)
Received: from ([]) by with ESMTPSA id o194sm6062191lfo.42.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Nov 2016 04:29:35 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DADEF6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Tue, 08 Nov 2016 12:29:33 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <> <20161107162402.GJ3546@Chimay.local> <787AE7BB302AE849A7480A190F8B933009DADEF6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter 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: Tue, 08 Nov 2016 12:29:40 -0000

Hi Med,


>> -----Message d'origine-----
>> De : multipathtcp [] De la part de
>> Christoph Paasch
>> Envoyé : lundi 7 novembre 2016 17:24
>> À : Olivier Bonaventure
>> Cc :
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>> Hello,
>> On 07/11/16 - 08:56:07, Olivier Bonaventure wrote:
>>> The problem is more complex than this because the connecitivity on the
>> CPE
>>> is not the same as connectivity on the endhost. Consider the following
>>> scenario :
>>> laptop <-----------+
>>>                   |
>>> smartphone <----> cpe <-------> mcp <------> server
>>>    +              +
>>> cellular1     cellular2
>>> The MCP resides on the DSL path between the CPE and the server.
>>> The laptop is connected over WiFi and the CPE converts the TCP
>> connection
>>> onto an MPTCP connection to bond DSL and cellular2.
>>> The smartphone is connected over wifi to the cpe which is connected over
>> DSL
>>> to the server via the MCP. When the smartphone uses MPTCP, it wants to
>> use
>>> WiFi and cellular1. It could start over WiFi and then moves and want to
>>> switch to cellular1. The MCP has no idea of cellular1 and cannot
>> terminate
>>> an MPTCP connection created by the smartphone.
>> I'm not sure, why Alan's suggestion to only proxy based on the SYN/ACK
>> doesn't work here.
>> There are two scenarios here:
>> 1. server supports MPTCP: Then, everything is fine. CPE and MCP will stay
>>   out of the business and native MPTCP will be done from smartphone to
>>   server.
> [Med] Existing network-assisted MPCP documents already cover this case. Native MPTCP connections will be established by that smartphone without even being intercepted by an MCP. The MCP has not to inspect the SYN/ACK. The problem is more on the laptop side. 

But inspecting the SYN/ACK would allow the MCP to provide Multipath capabilities when the smartphone is MPTCP capable but the server is not. However, that’s a side-effect...

> Let's consider a TCP connection from that laptop. This TCP connections is relayed to MPTCP via the fixed line, and the intercepted by the MCP. If the MCP withdraws itself because it receives an MP_CAPBLE in the SYN/ACK from the ultimate server, the secondary subflow (via cellular2) may not be established because only private IPv4 addresses may be assigned in that leg (e.g., dedicated APN is used). In this case, the withdrawal of the MCP will lead to more failures. 

Sorry I don’t follow that scenario. If cellular2 tried to join, it would talk direct to the far end, and not to the MCP,  if the MCP was not in the path… Right? So what’s the problem?

If the MCP remained in the path, then what would be different for this scenario to make it work?

> This is exactly why I'm advocating for a configurable parameter. 
>> 2. server does not support MPTCP: In that case the MCP will announce its
>>   public IP to the smartphone and this one can then create an MPTCP-
>> subflow
>>   via cellular1.

These two scenarios make sense to me (at the moment), I am confused as to why this would not work?