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

[Alan Ford <[e-mail]>]

Hi Med,

Inline...

> De : Alan Ford [mailto:[e-mail] <mailto:[e-mail]>] 
> Envoyé : jeudi 4 août 2016 10:06
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Henderickx, Wim (Nokia - BE); [e-mail] <mailto:[e-mail]>
> Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy
>  
> 
>  I don’t get this argument… 
> [Med] My point is about “transport-agnostic” part of your comment. One would argue that communication an IP address in a TCP option (which MPTCP is doing) is also “transport-agnostic” but no one is objecting to define such (MP)TCP option.

No, it is not transport-agnostic, it is integral to how MPTCP operates.

> You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.
> [Med] The PM option is in the payload because of the limited option space. In early versions of the draft, the option can be inserted in the dedicated TCP option space if there is enough space, payload, etc. but we abandoned that design to simply the implementations.

But this information doesn’t need to be read or understood by a MPTCP stack!

It is telling the proxy application, which sits above MPTCP, where to forward the following payload data to.

This signal is a protocol which is not specific to MPTCP, and is in no way integrated with the rest of the MPTCP protocol.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows. This is all standard MPTCP behaviour and does not require any additional signalling.

> Your MPTCP proxy leverages MPTCP in order to apply new IP addresses to an existing MPTCP connection, which is great, but does not require any protocol extensions to do this. The only additional information it needs is the target, in the initial subflow, and this is provided by information in the payload.
> [Med] It is in the payload because of the limited space and because of the lack of mature proposals to extend the SYN option space.
>  
> This information is carried in the payload, and does not carry any information which is specific to MPTCP.
> [Med] It is specific to MPTCP as it allows, in addition to conveying a target/source IP address, to avoid interfering with native MPTCP connections. Also, the option allows to offload the MPTCP concentrator from the path if both endpoints are MPTCP-capable. All these aspects are specific to MPTCP.  

I agree that something would be needed at a higher-layer for a true transparent proxy implementation, since it needs to know which traffic to intercept and which to let through. However, this does not necessarily need to be at the MPTCP layer. IP Router Alert Option is one alternative possibility here (RFCs 2113 / 2711) - given this is proposed for use in a controlled network, I would hope that deployment issues for RAO are not of such a concern here.

For plain mode where an explicit proxy address is given, there is no need for any network alert, since the packets will either be addressed to the proxy, or they won’t.

> To be clear on this - I am not opposed to doing this work, and indeed I would be entirely happy to see the charter clarified to support work on two-ended proxies. This is valuable work.
> [Med] Ok. Let’s then agree on the charter update.
>  
> But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies”
> [Med] That should be part of the work, indeed. But there are other aspects that are important such as avoiding interfering with native MPTCP connections, offload an MPTCP proxy from the path if both endpoints are MPTCP-capable, avoid extra delays to establish network assisted MPTCP connections, etc.  
>  
> … If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be),
> [Med] I still disagree here. The proposal we have on the table is specific to MPTCP.

Your proposal uses MPTCP as a multipath transport, however the protocol you have specified for signalling target address is not an MPTCP extension, it is a separate protocol.

However, we are arguing over a non-existent proposal right now. At IETF96 it was said a combined draft would be issued which brought everything together. I await this with interest so we can see how this combined proposal fits with MPTCP.

Regards,
Alan