Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Jordan Melzer <> Tue, 05 July 2016 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDD5612D0AA for <>; Tue, 5 Jul 2016 08:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4lRlRV6J4AJ8 for <>; Tue, 5 Jul 2016 08:48:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6D5D712B004 for <>; Tue, 5 Jul 2016 08:48:00 -0700 (PDT)
DomainKey-Signature: s=donder.nssi;; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HsX+JgMp9wqMuYBP8j1abov9tMwkaSHjZDSDzbSgZ8l5/eRvrNs92Jmk 9Rm5Rl8h6wImlkY8O7muKymFG/Hq4xg6JTWJOmNFODAUJdq1FamzfJMbe eHWXZwl+doysKfxOjRhacytKj6N2j+UZRVydtqwqZ2iHlWHKB9kuAnhyR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.26,580,1459814400"; d="scan'208";a="534899993"
Received: from unknown (HELO ([]) by with ESMTP/TLS/AES128-SHA; 05 Jul 2016 15:47:57 +0000
Received: from ([::1]) by ([::1]) with mapi; Tue, 5 Jul 2016 09:47:57 -0600
From: Jordan Melzer <>
To: Joe Touch <>
Date: Tue, 5 Jul 2016 09:47:55 -0600
Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
Thread-Index: AdHTvfdIGR2fbGVHRB6rTxFRFD3TsQCPkb4w
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: " Mailing List \(\)" <>
Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
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, 05 Jul 2016 15:48:03 -0000

Hi Joe,

The main RFC reference for performance enhancing proxies is here:

It gives consideration to the end-to-end principle and describes deployments (current as of 2001).

Do you have an informational RFC (or other BCP) reference for routing-based approaches to multipathing individual-user traffic?

Re TCP over TCP approaches, if they could work, would you like them better than a proxy approach?  Eg, (untested) MP-DCTCP lower layer?


-----Original Message-----
From: multipathtcp [] On Behalf Of Joe Touch
Sent: July 1, 2016 01:27 PM
To:; Mingui Zhang;;;
Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

On 7/1/2016 12:01 AM, Olivier Bonaventure wrote:
> Hello,
>> In the paired MPTCP proxies mechanism, there is user's TCP session 
>> and there is also multipath TCP session. It is a TCP over TCP idea, 
>> correct?
> No, there are three TCP connections in this scenario :
> - one (regular) TCP connection between client and CPE
> - one Multipath TCP connection between the CPE and the Concentrator
> - one (regular) TCP connection between the Concentrator and the remote 
> server
>> As for TCP over TCP, the following page explains why an internal 
>> meltdown effect would take place due to the interaction between two 
>> leveled retransmission mechanisms.
> This is a well known issue.
>> Do we have solid solutions for this issue nowadays?
> The solution is to terminate the TCP connections transparently. This 
> is what most TCP optimisers used in mobile networks do already.

Is there a current standard or BCP endorsing this practice?

AFAICT, it's in direct opposition of RFC1122. I hope we don't want to create a new RFC that flies in the face of what few standards we have unless we're prepared to revise those standards first.

"deployed in the wild" is not a sufficient justification, IMO.


multipathtcp mailing list