Subject: [multipathtcp] MPTCP proxies, and the BANANA BoF

From: Brian Trammell <[email-masked]>
Date: Fri, 4 Nov 2016 14:27:17 +0100

Greetings, all,

First, for those of you who aren't aware, there's a non-WG forming BoF in Seoul on Thursday afternoon, on using multipath bonding for broadband access networks, BANANA. One of the solutions we'll be looking at is MPTCP-proxy based; those interested, please come by!

On this point, Mirja said:

> first, I agree with Alan that such a signal does not need to/should not be part of the MPTCP protocol. MPTCP (as TCP is) is an end2end protocol. If you have one (or two) proxies in the middle, you split up the connection into multiple new ‚end2end‘ connections. If you need additional signaling information on one of the new connections, that a question for a high-layer protocol that uses MPTCP (which is what you do, when you propose it to be part of the payload).

+1. One of the attractive things about MPTCP-based solutions for this particular use case, IMO, is that there's a clear path from a two-proxy situation (which is what BANANA foresees) to a one-proxy situation (MPTCP aware smartphones can use their LTE connection natively, and connect to the far-side bonding proxy directly, if they can be so configured), and eventually to a zero-proxy situation (when content providers also provide multipath services). That pretty much requires that the MPTCP part remain end-to-end, while the proxy selection (and any other interproxy communication) happen out of that band.

Cheers,

Brian

---

From: <[email-masked]>
Date: Fri, 4 Nov 2016 14:05:45 +0000

Hi Brian, 

I don't understand the causality effect in your statement:

That pretty much requires that the MPTCP part remain
> end-to-end, while the proxy selection (and any other interproxy
> communication) happen out of that band.

https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html describes how native MPTCP communications can be established by an MPTCP-capable host without involving any proxy with in-band signaling!

In those deployment models, the MPTCP connections is establish (obviously) between MPTCP-capable nodes:
* either between an MPTCP-capable client and a proxy
* between two MPTCP proxies.

I don't also quit understand your comment about "proxy selection" given that all the proposals on the table for selecting a proxy are out of band (e.g., https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06).

Out of band communications suffer from an extra delay to establish MPTCP communications vs TCP ones. Several 10s of ms are required in some cases before the MPTCP connection flies. We don't have such problems with in-band signaling.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Brian Trammell
> Envoyé : vendredi 4 novembre 2016 14:27
> À : [email-masked]
> Objet : [multipathtcp] MPTCP proxies, and the BANANA BoF
> 
> Greetings, all,
> 
> First, for those of you who aren't aware, there's a non-WG forming BoF in
> Seoul on Thursday afternoon, on using multipath bonding for broadband
> access networks, BANANA. One of the solutions we'll be looking at is
> MPTCP-proxy based; those interested, please come by!
> 
> > first, I agree with Alan that such a signal does not need to/should not
> be part of the MPTCP protocol. MPTCP (as TCP is) is an end2end protocol.
> If you have one (or two) proxies in the middle, you split up the
> connection into multiple new ‚end2end‘ connections. If you need additional
> signaling information on one of the new connections, that a question for a
> high-layer protocol that uses MPTCP (which is what you do, when you
> propose it to be part of the payload).
> 
> +1. One of the attractive things about MPTCP-based solutions for this
> particular use case, IMO, is that there's a clear path from a two-proxy
> situation (which is what BANANA foresees) to a one-proxy situation (MPTCP
> aware smartphones can use their LTE connection natively, and connect to
> the far-side bonding proxy directly, if they can be so configured), and
> eventually to a zero-proxy situation (when content providers also provide
> multipath services). That pretty much requires that the MPTCP part remain
> end-to-end, while the proxy selection (and any other interproxy
> communication) happen out of that band.
> 
> Cheers,
> 
> Brian