Re: [multipathtcp] Consensus call on potential MPTCP proxy work

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[e-mail]]
Envoyé : mercredi 19 avril 2017 20:17
À : BOUCADAIR Mohamed IMT/OLN; [e-mail]; [e-mail]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work




On 4/18/2017 10:26 PM, [e-mail]<mailto:[e-mail]> wrote:
As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.
I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:


 I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
[Med] We are not multiplexing connections. This is explained in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2:
   The upstream MCP maps an upstream TCP connection onto a downstream
   MPTCP connection (and its associated subflows) . On the upstream MCP,
   an established MPTCP connection can be identified by the local Token
   that was assigned upon reception of the SYN segment from the Client.

- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
[Med] The one to the proxy. This is important for subflows management and traffic distribution.

- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?
[Med] The proxy will need to strop any supplied-data in the initial SYN, and then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doing something similar to SOCKS for the data plane. There are some new features compared to SOCKS that I won't detail here. The reader may refer to https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?
[Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification we are doing at this level is to insert MPTCP options. And even for this case, as shown in slide 30, when there is an exhausted TCP option space in the original SYN, ** no ** MPTCP options are inserted. So, all is safe.

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?
[Med] Interoperability is needed here because the CPE and the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be standardized. Other matters like those you mentioned are key to keep in mind.

Joe