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

Joe Touch <touch@isi.edu> Wed, 19 April 2017 18:17 UTC

Return-Path: <touch@isi.edu>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE5129BC5 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 11:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w7ExFTisvEE for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 11:17:17 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8F7129BC1 for <multipathtcp@ietf.org>; Wed, 19 Apr 2017 11:17:16 -0700 (PDT)
Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3JIGsGJ020457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 11:16:54 -0700 (PDT)
To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <d53d6f13-f412-c42f-53a6-04637c7fef9b@isi.edu>
Date: Wed, 19 Apr 2017 11:16:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------482EB168584017596E8E48D7"
X-MailScanner-ID: v3JIGsGJ020457
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/qhG7gpc3bjEtSaP1bXqBcdpt6IY>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 18:17:20 -0000


On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com 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