Re: [multipathtcp] potential MPTCP proxy charter item

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:[e-mail]]
Envoyé : mardi 8 novembre 2016 13:41
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Med,

Inline...


De : Alan Ford [mailto:[e-mail]]
Envoyé : lundi 7 novembre 2016 17:37
À : [e-mail]<mailto:[e-mail]>
Cc : BOUCADAIR Mohamed IMT/OLN; [e-mail]<mailto:[e-mail]>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Olivier,

On 7 Nov 2016, at 07:50, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>> wrote:


Why is it an /option/, however? When you are explicitly targeting a
proxy node, surely the proxy is just as capable of pulling the data out
of the payload here?

Because the addressing information that is used for the proxy is part of the control plane and not part of the bytestream. I think that it is very important from an architectural viewpoint to maintain a clean separation between the byte stream that is exchanged between the applications and all control information that should be placed inside options.

We explore the possibility of adding information in the bytestream for MPTCP and eventually decided to place all control information in options. If you look at HTTP, proxy-related information is part of the HTTP headers and not part of the payload. This is the same type of problem.

And this appears to be where we fundamentally disagree. I don’t see this as part of the control plane, I see proxying (at least in explicit mode) as an application of MPTCP, and should be at the application layer.

[Med] I still don’t understand this subtlety between “application of MPTCP” (you claim) and “MPTCP-specific use case” (we claim). If we extrapolate your argument, one can object that multi-pathing is an “application of TCP” (not even specific to TCP), and should not be defined as a TCP option. But the reality is that there is a TCP option for multi-patting.

This is a layering issue. MPTCP provides an end-to-end transport. Proxying solutions are also end-to-end protocols - one end encapsulates in a different transport (from TCP to MPTC), and the other end decapsulates (from MPTCP to TCP). It does not make sense (to me) to apply an end-to-end application (proxying) at the transport layer.
[Med] Yes, the MPTCP connection in the network-assisted case is managed between two MCPs or between an MPTCP-capable host and an MCP. I don’t see why defining an MPTCP option to help the gluing of MPTCP/TCP or avoid breaking an MPTCP connection is harmful.

Network translation is different and relies on changing fields in the same transport, not changing to a different one (I am coming at this from the perspective that MPTCP, although an extension to TCP, provides sufficiently different functionality that it it a different transport for the purposes of this discussion).


It seems too specific an application to be embedded in the protocol. This does not seem equivalent to NAT, since it is requiring additional signalling.

[Med] FWIW, instructing NAT state with in-band signaling information is specified by the IETF and widely deployed:
•         https://tools.ietf.org/html/rfc6052
•         https://tools.ietf.org/html/rfc6146
•         https://tools.ietf.org/html/rfc6877


As far as I can see, none of those involve changes at the transport layer.
[Med] I didn’t claimed that. I was answering to this part of your answer “This does not seem equivalent to NAT, since it is requiring additional signaling.”. What I’m saying is that there are NATs that require (in-band) signaling.

Regards,
Alan