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

[<[e-mail]>]

Hi Phil, all,

“Transparent” is usually used to denote that the presence of an (MPTCP) proxy is not “visible” to the endpoints. This means, in particular, that the source IP address of packets won’t be modified by the MPTCP proxy that intercepts these packets. This behavior is supported by ** both ** the plain mode and transparent drafts. They differ in how the solution is actually engineered:

·         The transparent draft assumes that the MPTCP proxy ** must ** be in-path of the ** initial ** subflow, while

·         The plain mode draft does not make any assumption about the location of the proxy. The proxy can be located anywhere in the network (e.g., on-path, supported by a service card in a router, a standalone device, enabled in a datacenter, can be in any of the access networks, etc.). The proxy can behave in the transparent mode if is instructed with a source address preservation policy (e.g., preserve the source IP address used to place the initial subflow) or when it receives a plain-mode option with a D-flag set.

In addition, there are some engineering decisions to be made by an operator:

·         How to involve an MPTCP concentrator for outgoing packets: This can be done by modifying the underlying routing/forwarding to make sure that an MPTCP proxy will be on-path (transparent draft) or by explicitly configuring a proxy to a CPE (plain mode draft). Note that the transparent draft can also rely on an explicit proxy configuration for the placement of additional subflows. As a side note, the handling of additional subflows is similar in both the plain-mode and transparent drafts: an IP address of the proxy is used to forward them.

·         How to steer incoming traffic to an MPTCP proxy: this can be done by configuring a dedicated address pool to the proxy that will be used for address/prefix rewriting (supported by the plain mode draft) or by tweaking routing/forwarding policies (supported by both the transparent and plain-mode drafts).

Both transparent and non-transparent behaviors should be supported because they address distinct requirements and constraints that are, by definition, specific to each deployment. The proposed “merged” approach presented in Berlin accommodates that as it leaves to the operators to decide about their local policies.

As rightfully mentioned by Wim, a single MPTCP option is proposed to that aim.

Cheers,
Med

De : multipathtcp [mailto:[e-mail]] De la part de Henderickx, Wim (Nokia - BE)
Envoyé : mardi 26 juillet 2016 20:39
À : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Phil, it is hard to answer this in an easy way. Here is a take

  *   one distinction is about how traffic gets route to the proxy: transparent assumes network policies outside the proxy handle this, whilst the plain mode route to an explicit address of the proxy. Depending on the deployment operators prefer one over the other
  *   Both of them need additional info for the proxy to operate

     *   Indication to distinguish E2E MPTCP flows vs proxied MPTCP flows
     *   Indication of addressing
     *   Indication of other protocols
     *   etc

From: multipathtcp <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 26 July 2016 at 17:07
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

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:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 21 July 2016 17:13
To: [e-mail]<mailto:[e-mail]>
Subject: [multipathtcp] towards a potential work item on two-ended proxy

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