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

[<[e-mail]>]

Hi Joe,

Please see inline.

Cheers,
Med

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


Med,
On 4/19/2017 11:16 PM, [e-mail]<mailto:[e-mail]> wrote:

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]<mailto:[e-mail]>; [e-mail]<mailto:[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.


Great. It would be useful to explain this a lot earlier and at a higher level.


- 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.

So you have three congestion controls running in series? Have you considered the impact on bufferbloat (of the buffers in the proxy) and reactivity?
[Med] A detailed specification will need to discuss these details once we have a WG document.


- 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.

If you strip user-supplied data in the SYN, you're *changing TCP semantics* - esp. for a TFO connection.
[Med] There is a misunderstand here : the user supplied data is NOT striped/altered. What is striped is MP_CONVERT IEs (proxy supplied data).

So you really can't be doing that...
[Med] We are not doing it.



    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.
What happens if you create a segment that's larger than the PMTU? what do you drop or split? (there's no way to do that safely for unknown options)
[Med] This is not specific to this proposal. As a reminder, we have this problem only of the initial SYN. My take on this is to augment the MTU on the CPE and the network side to absorb MP_CONVERT. These details will be worked out in the WG endorsed document. It is likely that we inspire from the recommendations in draft-ietf-rtgwg-dt-encap-02#section-9: "assume well-managed MTU hence no need for fragmentation and reassembly".


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.
If that were the case, you'd simply be defining a new application service and asking for a TCP port number.

And you wouldn't be able to do zero-RTT opens.
[Med] 0-RTT is a key requirement for the WG.

Joe