Subject: [multipathtcp] Some questions for proxy work

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 26 Apr 2017 23:58:40 -0700

Hello,

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? 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.

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Thu, 27 Apr 2017 08:04:04 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

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

Hello,

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.

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.

Thanks,
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 10:17:41 -0700

On 4/27/2017 1:04 AM, [email-masked] wrote:
>
> 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.*//*
>
You have it backwards.

MPTCP reinvents existing channel bonding mechanisms, but with additional
constraints.

E.g.:
    - reordering by one MPTCP proxy-proxy connection might be undermined
by later reordering over a subsequent multipath sub-path
        it's more efficient to let the final hop reorder everything, and
there's no way that a MPTCP proxy knows it's the last hop

    - retransmission might be less efficient and incur higher delays
than FEC, e.g., which some channel bonding systems implement

Joe