Subject: [multipathtcp] towards a potential work item on two-ended proxy

From: <[email-masked]>
Date: Thu, 21 Jul 2016 16:12:50 +0000

We started the discussion yesterday on a potential new work item on "two-ended proxy scenario" - where there's an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.

If I can try and summarise the brief discussion yesterday (plus some side discussions) (please correct my inaccuracies):

-          there are now deployments & products with an MPTCP proxy at each end, plus planned Broadband Forum work (WT-348 is about to be made public, with subsequent work to follow). So IETF work is timely (eg help allow an operator to buy CPE from one vendor and aggregation gateway from another vendor).

-          However, some people object to going beyond the current charter's "one-ended proxy scenario" (since the "two-ended proxy" discourages deployment of MPTCP to all the end hosts, which is the ultimate goal)

-          There are two proposals (transparent & plain mode: draft-boucadair-mptcp-plain-mode-08 & draft-peirens-mptcp-transparent-00). Are these addressing different use cases, or do we need to choose between them? would a (potential) charter item be to standardise existing draft(s), or to solve a problem /scenario?

-          I think there was mention (by Wim??) that there's a third proposal - how does this fit in, or did I get it wrong?

-          One aspect of the plain mode draft is to allow transport of UDP traffic as well as TCP traffic. I think this is a proposal that should be discussed separately  - for instance it needs INT-area expertise.

I think it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there's consensus for it).

Thanks!
Philip Eardley
Research and Innovation
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: <[email-masked]>
Date: Fri, 22 Jul 2016 06:04:22 +0000

Hi Phil,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 21 juillet 2016 18:13
À : [email-masked]
Objet : [multipathtcp] towards a potential work item on two-ended proxy

[Med] Indeed! Endorsing this activity in the MPTCP WG is the natural way to assist in defining interoperable MPTCP proxies. There is a real need expressed by operators and vendors to work on this.

[Med] Both one-ended proxy and two-ended proxy makes sense. These are covered for example in the plain-mode draft. The proposed solution allows to differentiate between native MPTCP connections from proxied connections to help e2e MPTCP connection establishment if both the client and server are MPTCP-capable. Please note that network operators do not have control on the terminals connected behind a CPE, and that those terminals are not even aware of the presence of a proxy in the path.

[Med] As mentioned during the meeting, all these deployment use cases make use of the same option. It is up to the taste of each operator to decide about its own deployment mode. As a WG, we don't need to decide about that.

[Med] That's a fair point. Cross area reviews can always be managed, but the point is to have a starting home for the activity.

I think it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there's consensus foro it).
[Med] I have other sub-items that I would like to see included in the (hopefully) proposed charter update. I will share that when a text proposal is on the table.

Thanks!
Philip Eardley
Research and Innovation

---

From: <[email-masked]>
Date: Fri, 22 Jul 2016 06:55:15 +0000

Hello Philip, all,

I believe the mptcp WG charter should evolve to include MPTCP proxy-related work. As you rightfully mention in your message below, this would be a timely effort (besides what's being cooked by the BBF) that is primarily motivated by the existing and forthcoming development of so-called hybrid access service offerings in Europe and Asia, and possibly in other regions of the world.

I also think that the proposed approaches (namely draft-boucadair and draft-peirens) that have been presented during the mptcp WG session are rather meant to foster massive MPTCP adoption rather than hindering it.

As for the charter update, I would encourage the documentation of a problem statement with companion use cases, as well as the standardization of the corresponding solution, presumably based upon the merging of the aforementioned drafts to accommodate all use cases.

Let me also second Med's recent reply to this message. I too volunteer to contribute to the updated charter text, assuming there's hopefully consensus to move towards that direction.

Cheers,

Christian.

Thanks!
Philip Eardley
Research and Innovation

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 22 Jul 2016 11:19:23 +0200

Hello,

> On Jul 21, 2016, at 6:12 PM, [email-masked] wrote:
> We started the discussion yesterday on a potential new work item on “two-ended proxy scenario” – where there’s an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.
>  
> -          However, some people object to going beyond the current charter’s “one-ended proxy scenario” (since the “two-ended proxy” discourages deployment of MPTCP to all the end hosts, which is the ultimate goal)
> -          I think there was mention (by Wim??) that there’s a third proposal – how does this fit in, or did I get it wrong?

I think the proxy-work is built of two items:

1. The documentation of how a deployment of one-ended and two-ended proxies look a like and the things that one should consider when doing so.

2. The plain-mode-option.

The point 1) is specific to MPTCP and probably useful to include in the charter.

For the point 2), I agree with Alan's comment in that this is entirely independent from MPTCP. It is basically a mechanism for 0-RTT proxying, by communicating the relevant IP-addresses between the proxies. Thus, I don't think that we should specify the plain-mode option in the MPTCP working-group, as the same plain-mode option might be useful in any other transport-layer protocol. And we probably don't want a list of draft-sctp-plain-mode, draft-tcp-plain-mode, ...

Christoph

>  
> I think it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there’s consensus for it).
>  
> Thanks!
> Philip Eardley
> Research and Innovation
> _______________________________________________
> multipathtcp mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>

---

From: <[email-masked]>
Date: Fri, 22 Jul 2016 09:41:58 +0000

Hi Christoph,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Christoph Paasch
Envoyé : vendredi 22 juillet 2016 11:19
À : Philip Eardley
Cc : MultiPath TCP - IETF WG
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Hello,

On Jul 21, 2016, at 6:12 PM, [email-masked]<mailto:[email-masked]> wrote:
We started the discussion yesterday on a potential new work item on “two-ended proxy scenario” – where there’s an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.

For the point 2), I agree with Alan's comment in that this is entirely independent from MPTCP.
[Med] I don’t quite understand this argument, but fwiw the plain mode option is there to address various goals such as:

·         Allow to distinguish native MPTCP connections from proxied MPTCP connections. Without this PM signal, native MPTCP connections may be “broken” by an upstream proxy that will revert them into a TCP connection!

·         Avoid breaking IPv6 applications that make use of address referrals, as the source IPv6 of the terminal located behind a CPE is preserved even when MPTCP proxies are in path.

·         Avoid encapsulation and out of band signaling that will degrade the overall connection setup delay.

BTW, if the argument that signaling an IP address in a TCP option has nothing to do with TCP (which is supposed to deal with layer 4) was made for MPTCP, MPTCP would never been RFCed!

It is basically a mechanism for 0-RTT proxying, by communicating the relevant IP-addresses between the proxies.
[Med] This is ** one ** of the features that is offered by the option in addition to those I mentioned above.

Thus, I don't think that we should specify the plain-mode option in the MPTCP working-group, as the same plain-mode option might be useful in any other transport-layer protocol. And we probably don't want a list of draft-sctp-plain-mode, draft-tcp-plain-mode, ...
[Med] TCP and SCTP were there before MPTCP for so long, so if there were cases in which a “plain mode”-like option is needed, it would have been specified since a while! The plain mode is proposed as an MPTCP solution to an MPTCP problem.

Christoph

Thanks!
Philip Eardley
Research and Innovation

_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 22 Jul 2016 20:45:04 +0000

On our NASA Atmospheric Research vehicles, we are beginning to test MP-TCP.  Current testing is between aircraft communication relay and ground communication relay without a proxy.  But, the attached figure (I could eventually put this in ascii art if need be) shows the need for two proxies.  I suspect this architecture is not that uncommon in mobile communication platforms that may be acting as the communication relay (military, first responders, etc…).

Will

From: multipathtcp <[email-masked]<mailto:[email-masked]>> on behalf of Christoph Paasch <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 22, 2016 at 5:19 AM
To: Philip Eardley <[email-masked]<mailto:[email-masked]>>
Cc: MultiPath TCP - IETF WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hello,

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Sat, 23 Jul 2016 07:16:07 +0000

In-line WH>

From: multipathtcp <[email-masked]<mailto:[email-masked]>> on behalf of "mohamed. boucadair" <[email-masked]<mailto:[email-masked]>>
Date: Friday 22 July 2016 at 11:41
To: Christoph Paasch <[email-masked]<mailto:[email-masked]>>, Philip Eardley <[email-masked]<mailto:[email-masked]>>
Cc: MultiPath TCP - IETF WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Christoph,

Please see inline.

Cheers,
Med

Hello,

WH> On the option, which will be needed in the proxy, I understand it could be generic but we don’t have use cases in other scenario’s (like SCTP). So I propose we can inform people about this but keep the work in MPTCP since this is where the requirement, solution comes from.

Christoph

Thanks!
Philip Eardley
Research and Innovation

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 15:07:52 +0000

So far this discussion has made me a bit confused. Let me ask a specific question:-
Why do we need both transparent and plain mode? If these are addressing different usage scenarios, please explain them (in a paragraph?)  (this is important as a charter item would start by talking about the issue it was tackling - and then may mention some starting points or assumptions about the solution)
Plain mode involves a signalling protocol (extension to mptcp - I assume this would be in scope of a prospective charter); then subsequently a way of handling the actual traffic (UDP seems out of scope; TCP I'm not sure to what extent this would be in scope). Do I understand this right? Comments?
Thanks
phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 21 July 2016 17:13
To: [email-masked]
Subject: [multipathtcp] towards a potential work item on two-ended proxy

Thanks!
Philip Eardley
Research and Innovation

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 26 Jul 2016 17:56:53 +0200

Phil,

> We started the discussion yesterday on a potential new work item on
> “two-ended proxy scenario” – where there’s an MPTCP proxy in both the
> CPE and an aggregation point (for instance). The current charter is that
> one end host is MPTCP.
>
>
>
> If I can try and summarise the brief discussion yesterday (plus some
> side discussions) (please correct my inaccuracies):
>
> -          there are now deployments & products with an MPTCP proxy at
> each end, plus planned Broadband Forum work (WT-348 is about to be made
> public, with subsequent work to follow). So IETF work is timely (eg help
> allow an operator to buy CPE from one vendor and aggregation gateway
> from another vendor).

I fully agree
>
> -          However, some people object to going beyond the current
> charter’s “one-ended proxy scenario” (since the “two-ended proxy”
> discourages deployment of MPTCP to all the end hosts, which is the
> ultimate goal)

I don't think that deploying MPTCP proxies would discourage the 
deployment of MPTCP end-to-end. This deployment shows that MPTCP is a 
valid solution to some problems where bandwidth can be aggregated and 
would convince users that MPTCP would be a good way to solve their problems.

The scenario is the following :

client ----  CPE --------- HAG -------- server
               +-------------+

The network operators want to use MPTCP between the CPE and the HAG 
because MPTCP is from a technical viewpoint the best solution to react 
to congestion and varying traffic conditions (delay, losses, ...) on the 
two access networks that are bonded. Since today's clients and servers 
only support regular TCP, operators want to have :
  - a TCP<->MPTCP proxy on the CPE
  - a MPTCP<->TCP proxy on the HAG

Note that since the CPE and the HAG support MPTCP by design, they could 
be MPTCP<->MPTCP proxies and support MPTCP end-to-end as a series of 
proxied connections. Proxied connections have two advantages in wireless 
networks compared to regular end-to-end MPTCP connections :
  - feedback loops are much shorter, which improves performance as shown 
by the deployment of various TCP optimisers in mobile networks
  - network operators can apply policies to prefer one network over the 
other

If the IETF works on this problem, we can ensure that the solution will 
support by design a scenario where MPTCP is used on the client and MPTCP 
is used as well on the server side.

>
> -          There are two proposals (transparent & plain mode:
> draft-boucadair-mptcp-plain-mode-08 &
> draft-peirens-mptcp-transparent-00). Are these addressing different use
> cases, or do we need to choose between them? would a (potential) charter
> item be to standardise existing draft(s), or to solve a problem /scenario?

The use case is the same : hybrid access networks. They both rely on 
MPTCP-MPTCP proxies. The deployment mode is different.

The plain-mode draft allows the HAG to be placed anywhere in the network 
and the destination address of the SYN is used to reach the HAG. The 
plain-mode option, included in the SYN, contains the final destination 
of the end-to-end connection.

The transparent-mode draft assumes that the HAG is placed on the path 
to/from the CPE. This implies that there is no need to change the 
destination address of the SYN to reach the HAG.

>
> -          I think there was mention (by Wim??) that there’s a third
> proposal – how does this fit in, or did I get it wrong?
>
> -          One aspect of the plain mode draft is to allow transport of
> UDP traffic as well as TCP traffic. I think this is a proposal that
> should be discussed separately  - for instance it needs INT-area expertise.

Agreed, we should focus on the TCP discussion in this WG

> I think it would be good to have more discussion before attempting to
> write some potential charter text (and then seeing if there’s consensus
> for it).
>

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 Jul 2016 10:43:14 +0200

Phil,

> Why do we need both transparent and plain mode? If these are addressing
> different usage scenarios, please explain them (in a paragraph?)

The two modes address different deployment scenarios.

In the transparent mode, the HAG resides on the path to/from the client. 
There are many ways in current networks to ensure that the HAG is on the 
path of the clients that it serves. The transparent mode requires one 
option to distinguish between end-to-end MPTCP connections (directly 
established by the client using an MPTCP stack) and proxied connections. 
During IETF96, the authors of plain-mode and transparent-mode agreed 
that the transparent-mode draft would use an emply plain mode option to 
indicate that a connection has been proxied.

In the plain-mode, the HAG does not need to be on the path to/from the 
client. The plain-mode option is used to signal the original 
source/destination address of the connection depending on the usage.

Olivier

---

From: Rao Shoaib <[email-masked]>
Date: Sun, 31 Jul 2016 14:02:38 -0700

On 07/27/2016 01:43 AM, Olivier Bonaventure wrote:
> In the transparent mode, the HAG resides on the path to/from the 
> client. There are many ways in current networks to ensure that the HAG 
> is on the path of the clients that it serves. The transparent mode 
> requires one option to distinguish between end-to-end MPTCP 
> connections (directly established by the client using an MPTCP stack) 
> and proxied connections. During IETF96, the authors of plain-mode and 
> transparent-mode agreed that the transparent-mode draft would use an 
> emply plain mode option to indicate that a connection has been proxied.
Why is it necessary to know that the connection has been proxied ?
> source/destination address of the connection depending on the usage.
Since we seem to be only considering TCP, will the protocol field be 
removed from the draft ?

Shoaib
> [email-masked]