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

Joe Touch <> Wed, 26 April 2017 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFDA81294F9 for <>; Wed, 26 Apr 2017 10:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8tlu6tlELE6s for <>; Wed, 26 Apr 2017 10:34:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E683D131513 for <>; Wed, 26 Apr 2017 10:34:40 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v3QHY9tf025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 10:34:10 -0700 (PDT)
Cc: "" <>, "" <>
References: <> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 26 Apr 2017 10:34:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------320F7C8F6A65801719233CC0"
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2017 17:35:00 -0000


On 4/26/2017 12:11 AM, 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:
> [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.,

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

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.