Re: [multipathtcp] potential MPTCP proxy charter item

[Christoph Paasch <[e-mail]>]

Hello,

On 07/11/16 - 09:00:17, Olivier Bonaventure wrote:
> > > > [Med] Defining another channel to carry the signal "I want to be MPTCP-proxied" outside the MPTCP normal channel will import the same set of hindrances we had with MPTCP design for middlebloxes traversal. The use of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic engineering design.
> > > 
> > > The MP_CONVERT signal has multiple purposes. When signalled with a target IP address in explicit mode, it is a pure application-layer signal, and is separate from the MPTCP connection entering the MCP.
> > > 
> > > In implicit mode this is indeed at a slightly different layer, and yes, you are asking the network to do something. But it’s still not a necessary part of the MPTCP protocol to make this happen. This is similar to a transparent HTTP proxy, or to a NAT - neither requires any changes to HTTP or TCP/IP to work.
> > > 
> > > You could detect MPTCP SYNs and see if your signal is present. If you don’t want to be inspecting every MPTCP SYN in implicit mode, use an existing standard - I suggest RAO. Given this is a controlled environment, you shouldn’t have any deployment concerns here.
> > > 
> > > If RAO is not appropriate for some reason, I might be persuaded that a flag in the MP_CAPABLE that says “proxies should inspect this” could be added to the base protocol. However, the rest of the protocol - i.e. the MP_CONVERT signal - is application-layer and outside MPTCP.
> > > 
> > > Ultimately MPTCP Proxying is an application of MPTCP and should be defined as such.
> > 
> > I'm also late on this thread. But just want to reiterate what I already
> > mentioned before in July.
> > 
> > I also think that proxying between different transport-layer protocols is not
> > an MPTCP-specific operation and as such should not be tied to MPTCP.
> > Making it independent of MPTCP would be much better as it allows to proxy
> > across any kind of transport protocol. So, let's just put it (as already
> > suggested) in the payload, without linking it to MPTCP.
> 
> 
> From an architectural viewpoint, providing addressing information for a
> proxy is clearly outside the bytestream exchanged by the application. It is
> cleaner to place this control plane information inside options instead of
> messing up the bytestream and changing the first few bytes of each
> connection. I think that we should have a clean separation between the
> control plane and the data plane in MPTCP. We already use options to carry
> addressing information related to the endhosts (ADD_ADDR, REMOVE_ADDR), the
> addresses required by the proxy are the same type of information and they
> should also be exchanged as TCP options. Encoding them in the payload would
> likely create more problems in the long term.

Now I'm confused. I thought that the MCP-option already is in the SYN's payload.


Wrt to the layer-separation. I think that having a 0-RTT proxying protocol
in the payload, where the first few bytes of a bytestream indicate the
server's IP-address would be very beneficial. These few bytes would be
placed in the SYN, just like the MCP-option, but without the link to MPTCP.
This would address Med's concerns wrt to additional delay, not interfere
with TFO,...

This would allow for some interesting use-cases:

* I could do a SCTP-proxy where each stream goes to a different server
* I could do a Quic-proxy
* I could do a TCP-RACK proxy that allows me to use TCP-RACK as
  server-support is not there yet (besides Google)
* ...


Cheers,
Christoph