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

[Alan Ford <[e-mail]>]

Hi Med,

> On 4 Aug 2016, at 06:53, <[e-mail]> <[e-mail]> wrote:
> 
>> As I’ve said before, the plain mode option is not MPTCP-specific and is
>> simple a signal that says “everything that follows is actually targeted
>> for IP address a.b.c.d” - this is entirely transport-agnostic.
> 
> [Med] The plain mode allows for example to distinguish between native and proxied MPTCP connection. 
> I'm puzzled here since MPTCP allows to inform a remote peer about an IP address while this is not TCP-specific. Isn't that information transport-agnostic as per you argument? (not mine).

I don’t get this argument… 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.

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.

This information is carried in the payload, and does not carry any information which is specific to MPTCP.

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. But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies” … If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be), that work should be done somewhere like intarea or tsvarea and referenced by this work.

Regards,
Alan