Re: [multipathtcp] Some questions for proxy work

<> Thu, 27 April 2017 08:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 840E31243FE for <>; Thu, 27 Apr 2017 01:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vf6vB_vmg9jf for <>; Thu, 27 Apr 2017 01:04:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EE9012EB29 for <>; Thu, 27 Apr 2017 01:04:07 -0700 (PDT)
Received: from (unknown [xx.xx.xx.9]) by (ESMTP service) with ESMTP id 00B9510074B; Thu, 27 Apr 2017 10:04:06 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.53]) by (ESMTP service) with ESMTP id D559BC0072; Thu, 27 Apr 2017 10:04:05 +0200 (CEST)
Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM61.corporate.adroot.infra.ftgroup ([fe80::89e:f34e:3a8e:4519%21]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 10:04:05 +0200
From: <>
To: Yoshifumi Nishida <>, multipathtcp <>
Thread-Topic: [multipathtcp] Some questions for proxy work
Thread-Index: AQHSvyO8ODMkWy8GuEec6w26sRdE7KHY0mPw
Date: Thu, 27 Apr 2017 08:04:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5B4DA@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5B4DAOPEXCNORMADcorp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Some questions for 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, 27 Apr 2017 08:04:10 -0000

Hi Yoshi,

Please see inline.


De : multipathtcp [] De la part de Yoshifumi Nishida
Envoyé : jeudi 27 avril 2017 08:59
À : multipathtcp
Objet : [multipathtcp] Some questions for proxy work


We've seen active discussions on doing proxy work in the WG.
I just would like to clarify several points from simple cases before discussing detailed mechanisms in proxy.

Let's say we have end points E1, E2, middle points M1, M2, and we have a communication path like this.

   E1 ------- M1 ====== M2 ------ E2

Now, we know E1 and E2 use TCP for communication. Also, we know there are multiple paths between M1 and M2.

The bandwidth of E1-M1 and E2-M2 are relatively large compared to any one of paths in M1-M2 or we know there will be heavy congestion in some paths in M1-M2.

In this scenario, do we see any advantages for using MPTCP between M1-M2 or not?
[Med] Whether MPTCP is to be used for a given flow is policy-based. Putting that aside, the advantages of using MPTCP in the first case (i.e., the bandwidth of E1-M1 and E2-M2 are relatively large compared to any one of paths in M1-M2) are:

·         Ensure session continuity in case any of M1/M2 links is broken.

·         The user can complain that he/she cannot use E1/M1 resources at maximum because of the capacity constraints in any of the M1/M2 links. Bundling the resources in the M1/M2 legs allows to soften that.

If heavy congestion is observed in some of the M1/M2 path, MPTCP will react accordingly. This is not the case for tunnel-based solutions. FWIW, my colleagues made tests for combing ADSL/LTE with increasing the LTE delay by 140ms, the conclusions they had is that a tunnel-based approach that does not support means to adjust based on congestion, will lead to a performance worse compared to ADSL-only! Other tests were made by varying the delay perturbation added on the LTE interface from 20ms to 400ms, the downloading of a file when MPTCP is used is about 2 times faster compared to the tunnel solution.

Or, do we see any problems or concerns to use MPTCP here?

Some folks might say we can use routing techniques or bundling IP tunnels here. But, I guess we'll need to handle reorder packets and proper congestion controls across multiple paths.
[Med] Yes, MPTCP will need to be reinvented at the bundling tunnel level.