Re: [multipathtcp] potential MPTCP proxy charter item

[Alan Ford <[e-mail]>]

Hi Med,

Inline...

> De : Alan Ford [mailto:[e-mail] <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.

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/rfc6052>
> ·         https://tools.ietf.org/html/rfc6146 <https://tools.ietf.org/html/rfc6146>
> ·         https://tools.ietf.org/html/rfc6877 <https://tools.ietf.org/html/rfc6877>  
>  

As far as I can see, none of those involve changes at the transport layer.

Regards,
Alan