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

[Joe Touch <[e-mail]>]

On 4/19/2017 11:59 AM, Jordan Melzer wrote:
>
> 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.
>

Why would that not be SCTP?
Joe

>  
>
>  
>
> *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]
> <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?
> - 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
>