Re: [multipathtcp] potential MPTCP proxy charter item

[<[e-mail]>]

Hi Alan,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:[e-mail]]
Envoyé : vendredi 4 novembre 2016 17:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Err, exactly the way you’re proposing doing it today. In the TCP payload.
[Med] Good to know we agree on this.

Just don’t pretend it’s an MPTCP option when it’s not.
[Med] I think here is our disconnect. Let’s put this one aside for the moment.

I was hoping that when these drafts were merged there would be a single desired deployment model, but it seems not. Explicit mode and Implicit mode are very different. Explicit mode is a proxy solution purely at the application layer and is not MPTCP-specific. You signal to a proxy - which is expecting it - information in the payload to define where the data is to be proxied on to.

The problem seems to be for implicit mode only. And more than that, it’s for implicit mode between two MCPs. I.e. scenario 3 in your document.

Looking again at the implicit mode scenario, in draft-nam-mptcp-deployment-considerations-00.txt, you have a case of a host (H1) which sends data to the far end; this is intercepted by the MCP, sent on as TCP-only, and the MCP inserts its own addresses. This does not need any additional signals to operate.

[Med] The problem as discussed in draft-nam is that the MCP needs to demux native MPTCP connections from proxied ones. The extra signal is needed to avoid breaking MPTCP connections. It may also be needed for transporting other protocols inside the MPTCP connections, but this one is left out of scope.

You later raised a scenario in an email which is not specifically stated in the document - one where you have TCP -> MCP1 -> MPTCP -> MCP2 -> TCP and you need to know if it’s come from another MCP or from the endpoint. Only data coming from MCP1 should be proxied. And MCP1 does not know about MCP2 so cannot address it directly.

[Med] FWIW, this is mentioned in Section 5.2.2.1 of the draft-nam and discussed with more details in the document defining the MP_CONVERT option.

But normal implicit mode operation would still work here, wouldn’t it? MCP2 could blindly add itself to the path in all cases. Does it actually matter if the MPTCP is coming from MCP1 or the end host?
[Med] It will revert to TCP those MPTCP connections that do not need the help of an MCP. We don’t want to interfere with those connections.

Your email described a desire not to revert to TCP after MCP2 if the end host, rather than MCP1, had sent the MPTCP signalling. But surely that problem would go away if you decided to proxy based on the far end’s MPTCP capability - i.e. on the SYN/ACK, not the SYN?
[Med] That’s an extra cost for the provider. The model is to avoid as soon as possible to involve MCPs when we know those are able to handle their MPTCP connections. There is no point to “MPTCP assist” MPTCP capable application. Having the signal has the advantage to be deterministic and optimized for the provider that deploys MCPs.

I came into this email thinking I’d finally understood the scenario where a signal is required, but I’m now confused again. Please help me understand here!

Regards,
Alan

On 4 Nov 2016, at 15:55, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:

Re-,

If not an MPTCP option, which channel you would use to pass in-band some information between two MPTCP peers (client/proxy, proxy/proxy) while allowing for variable data to be exchanged, multiple instances to be included, no interference with TFO, etc. AND ensure interoperability between MPTCP peers?

Cheers,
Med

De : Alan Ford [mailto:[e-mail]]
Envoyé : vendredi 4 novembre 2016 16:18
À : [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 4 Nov 2016, at 14:17, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>> wrote:



Thanks for the comments, Olivier. If the working group thinks it would be a good idea, I would not be opposed to embedding some extended options support in MPTCP - as you say it seems a good chance to do so. I haven’t thought deeply yet about the various options below, all have their merits, but the flag sounds possibly easiest. Whatever extension was used, it could be particularly useful in the future for improved cryptographic handshakes.

This does not change my view, however, that MPTCP options should not be used for application-layer purposes, and that’s my main issue with MP_CONVERT as written - it’s a non-MPTCP-specific application-layer signal masquerading as a MPTCP option.

It's clear that a proxy can be developed entirely as an application. SOCKSv5 is one example. The main drawback with SOCKS is that this adds several round-trip-times to each connection establishment to setup the proxy. With an option in the SYN, a proxy to operate with zero-rtt overhead. Reducing latency is an objective that is shared by other working groups, see e.g. TLS 1.3, QUIC and others...

One of us is clearly missing some key piece of information, since I still don’t know how we can be arguing something that seems so fundamentally clear to me.

This is a clear-cut application on top of MPTCP. In explicit mode, the application protocol is:

- a few bytes of signal that defines the real target address
- followed by the proxied payload

I’m not saying “use SOCKS” - you have a proposal for a 0-RTT proxy signalling protocol here. That’s fine. But it’s not MPTCP-specific. Why are you trying to make it a MPTCP option?

As I said in the reply to Med, the implicit mode is slightly more difficult since you are expecting interception of MPTCP traffic based on some logic. That logic could be a “proxy alert” flag, or it could be inspection of all MPTCP SYNs’ payloads (data-on-SYN issues are probably not such big deal in your relatively controlled environments), or it could be using RFC 2113 RAO. It does not need to be an MPTCP option specific to this extension.

Regards,
Alan