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

[Jordan Melzer <[e-mail]>]

It's a conventional proxy.  There are different sockets on each side of the
proxy, different RTTs, different congestion control.  The proposal is to
find a near-zero overhead way to do this when the proxy is off-path (ie,
when it's not a simple connection hijack).  This may be totally possible
without a new RFC - Christoph Paasch suggested that SOCKS + TFO could
basically become this, but I am not sure anyone who cared either caught it
or agreed.

 

Re b), it's off-topic, but what would you think of a multipath tunnel that
was basically MPTCP with the retransmissions gutted out?  I had thought this
would be what BANANA is doing, but I am not clear there are any two people
in BANANA who agree on what it is.

 

 

From: multipathtcp [mailto:[e-mail]] On Behalf Of Joe
Touch
Sent: April 19, 2017 02:17 PM
To: [e-mail]; [e-mail];
[e-mail]
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work

 

 

 

On 4/18/2017 10:26 PM, [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-ass
isted-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?
- 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
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the
entire packet?
    
    NOTE: if it reconstitutes the packet, what happens when you get an
option you don't understand? E.g., EDO?

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?

Joe