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

[Joe Touch <[e-mail]>]

Med,

On 4/19/2017 11:16 PM, [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];
> [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?

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

So you really can't be doing that...

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

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

Joe