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

[Joe Touch <[e-mail]>]

On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote:
>     > Hi Joe,
>     >
>     > It's not tunneling. The proxy converts a tcp connection into a mptcp
>     > connection and converts it back to a tcp connection (if necessary)
>     > So, it won't be tcp over tcp.
>     OK, but that's not proxying either.
>
>     That's (at best) connection hijacking.
>
>
> I won't deny it as I'm not 100% sure whether proxy is a good name or not. 
> But, I am thinking you might want to call NAT hijacking as well.
Yes, but we do know what a NAT is responsible for - i.e., it is 1:1
translation of only addresses and ports.

Doing more than that has never been part of an IETF standard, AFAICT -
for many reasons.

>
>     > MPTCP will convey control data for application (proxy) in payload.
>     > But, MPTCP of course doesn't care the contents of payload.
>     > It just carries data and app will parse the data. Putting data
>     in SYN
>     > is trying to reduce the latency and no other meaning as far as I
>     > understand.
>
>     MPTCP is TCP. Putting the data in the SYN of a TCP connection is
>     hazardous. The goal is irrelevant.
>
>  
> In TCP, we already have a precedence such as TFO.

Sorry, to be more clear:
    Data in the SYN has been part of TCP since it was standardized.

Using the SYN data as control information is the hazardous part.

> I think what the solution does won't exceed what TFO does.
TFO changes when the SYN data is delivered, based on the fact that past
cookie information "accelerates" the 3WHS.

It does not put control plane information in the data area of the SYN.

Joe