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

[Joe Touch <[e-mail]>]

Med,


On 4/26/2017 12:11 AM, [e-mail] wrote:
> ...
>
> Trying to create standards to patch the broken idea of a NAT and make
> it less interfering with existing protocols is not the same thing as
> standardizing the NAT itself.
>
> [Med] NAT64 (RFC6146) is not a patch AFAIK.
>
IMO, it is - it's a patch to help support the deprecation of IPv4 in the
global Internet. I don't see that as the role for an MPTCP proxy.

>
> The IETF has also a "Standards Track" document called SOCKSv5
> (RFC1928) that is splitting the TCP connection. We are adhering to the
> logic of that RFC but without the drawbacks of SOCKS.
>
>  
>
> Can you clarify where you see split TCP in RFC1928,
>
> [Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see
> “split TCP” in the plain-mode draft.
>
Nothing in RFC1929 talks about translating SYNs - it doesn't even
mention specific TCP segments at all, but refers only to the standard
TCP API, where user data would be available only after the 3WHS between
the client and the SOCKS proxy.

Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN
generating an outgoing SYN before the client SYN/ACK is returned. You
don't mention split-TCP (and it has taken more than too long to figure
out that's what's going on here), but that is what you show.
>
> or are you confusing it with this, which adds split TCP to a SOCKS proxy:
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf
>
>  
>
> [Med] Bingo. That is exactly my point. We need to avoid mixing
> implementation details with base specifications. That is exactly the
> reason why I said earlier that mptcp proxy documents only describe the
> external behavior.
>
OK, so keep ALL discussions of SYN (or any segment translation) out of
this document - including the figures.

If you can explain this using the existing TCP API, e.g.,
OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.

But nowhere in that API does TCP tell you when a SYN arrives *before*
sending a SYN-ACK.

-----
As to your TFO argument, the problem is this:

    - what happens to the first MPTCP connection from proxy to proxy?
            why do you treat this differently than a typical MPTCP, and
what information lets you do so?

I don't see anything in this doc that qualifies as what TFO calls either
a cookie between sessions or any substitute based on authentication or
authorization.

I agree that you're not strictly cloning TFO - IMO, you're trying to
reinvent TFO without leveraging the experience the community has
developed in that process, and IMO you're repeating some of the mistakes
on that journey.

Joe