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

"Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <> Thu, 20 April 2017 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64DDB13147A for <>; Thu, 20 Apr 2017 07:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, 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 xYLBM0sBTv4P for <>; Thu, 20 Apr 2017 07:36:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C59F0129A91 for <>; Thu, 20 Apr 2017 07:36:31 -0700 (PDT)
X-Comment: SPF check N/A for local connections - client-ip=;;;
DKIM-Filter: OpenDKIM Filter v2.11.0 9E0AA40050C6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=letsgomars; t=1492698990; bh=Q68j7Zs5SltsEHG/cDvh6rDIFn5EwMnqKb/gzwlqOOA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AeJJDKGcvOjl9tA020lJgmLKzuzE10hp26OtMHZ8vZ8ZGKTV7pvwughu+1esy/79Z pVYi5ZddtNWlS+/hSP3sTnzMXiktBGVIC6rE4xpFXH/3U/cnKblZ2LpPMqvU+nqoHJ k/mg9QbA0YxK2ejByLzFp8cueXJjA3rDsFSS0UYTkNkDYoMSKooWipXaP2V/LriaCx 0YfU20wW9Tle881Kvq/ZWsrSs7BmEl4cpG9hQ5r5LYYgz3a2kgCL4nxdB3cUgvUSc+ BS3lOkIGzrVVd51JisEKbzkKeLNAE662wBop2gJxKXaALeUglv6yJpi9uQSLBoDkz8 x/c0su13svNjw==
Received: from ( []) by (Postfix) with ESMTP id 9E0AA40050C6; Thu, 20 Apr 2017 09:36:30 -0500 (CDT)
Received: from pps.filterd ( []) by ( with SMTP id v3KEaSXC015891; Thu, 20 Apr 2017 09:36:30 -0500
Received: from ( []) by with ESMTP id 29xxpvg1h4-4; Thu, 20 Apr 2017 09:36:30 -0500
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 09:32:44 -0500
From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <>
To: "" <>
CC: "" <>, "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAAB4TboAAD/kHAAAhVsoAABLdBYA=
Date: Thu, 20 Apr 2017 14:32:44 +0000
Message-ID: <>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-20_13:, , signatures=0
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: Thu, 20 Apr 2017 14:36:33 -0000

Hi Med,

Thanks for the response.

> On Apr 20, 2017, at 1:32 AM, wrote:
> What I meant by "native MPTCP connections" is that the CPE won't proxy a SYN that contains MP_CPABALE received from an MPTCP-capable client. That is, the CPE won't modify the destination IP address to the one of the network-located proxy. That SYN+MP_CPABALE will be received and handled directly by the remote server.   

I thought this was the case. 

Part of this proposal that I do not support is that network assistance requires connection hijacking. There is no plan to have the network assist 2 MPTCP hosts that want end-to-end connectivity.

Here is a network diagram I drew up:

What I would like to see is a solution that supports the following:

The cell phone and server have on ongoing connection over Path 3. Now this phone wants to add a subflow using the WiFi interface. How could the network assist this connection to enable the use of both Path 1 and Path 2 rather than (Path 1 xor Path 2) in an end-to-end manner? In other words, how could the cell phone discover it should start a second subflow over WiFi?

Maybe there is an MPTCP-based solution. Maybe there is an out of band solution. I have not fleshed anything out at the moment, but I think network assistance in a more general sense is a useful topic to dwell on.