Re: [multipathtcp] Consensus call on potential MPTCP proxy work
Joe Touch <touch@isi.edu> Thu, 20 April 2017 17:31 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 B61831201FA for <multipathtcp@ietfa.amsl.com>; Thu, 20 Apr 2017 10:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.89
X-Spam-Level:
X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 FaAO4LzWVSLc for <multipathtcp@ietfa.amsl.com>; Thu, 20 Apr 2017 10:31:53 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 77AEF13149F for <multipathtcp@ietf.org>; Thu, 20 Apr 2017 10:31:50 -0700 (PDT)
Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3KHUVhF007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Apr 2017 10:30:32 -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> <d53d6f13-f412-c42f-53a6-04637c7fef9b@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu>
Date: Thu, 20 Apr 2017 10:30:29 -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: <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------DA20779EA38FC7FA2D4D28B9"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/-lLkZPqlYabdGgE3pZ4hvKhj2kg>
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: Thu, 20 Apr 2017 17:31:56 -0000
Med, On 4/19/2017 11:16 PM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* mercredi 19 avril 2017 20:17 > *À :* BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work > > > > > > > > On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com > <mailto: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? > > [Med] We are not multiplexing connections. This is explained in > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2: > > The upstream MCP maps an upstream TCP connection onto a downstream > > MPTCP connection (and its associated subflows) . On the upstream MCP, > > an established MPTCP connection can be identified by the local Token > > that was assigned upon reception of the SYN segment from the Client. > > Great. It would be useful to explain this a lot earlier and at a higher level. > - 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 > > [Med] The one to the proxy. This is important for subflows management > and traffic distribution. > > So you have three congestion controls running in series? Have you considered the impact on bufferbloat (of the buffers in the proxy) and reactivity? > - what is the proxy relaying? > is it TCP data, or is it somehow trying to tunnel and reconstitute > the entire packet? > > [Med] The proxy will need to strop any supplied-data in the initial > SYN, and then create a state to be used for handling subsequent > packets of that connection. Once a state is created, we are doing > something similar to SOCKS for the data plane. There are some new > features compared to SOCKS that I won’t detail here. The reader may > refer to > https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01. > > If you strip user-supplied data in the SYN, you're *changing TCP semantics* - esp. for a TFO connection. So you really can't be doing that... > NOTE: if it reconstitutes the packet, what happens when you get an > option you don't understand? E.g., EDO? > > [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not > touch options that are inserted by a TCP endpoint. The proxy is not > required to understand those options. The only modification we are > doing at this level is to insert MPTCP options. And even for this > case, as shown in slide 30, when there is an exhausted TCP option > space in the original SYN, ** no ** MPTCP options are inserted. So, > all is safe. > What happens if you create a segment that's larger than the PMTU? what do you drop or split? (there's no way to do that safely for unknown options) > 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? > > [Med] Interoperability is needed here because the CPE and the > network-located proxy are provided by distinct vendors. For example, > the format, location, and processing of the supplied proxy data is to > be standardized. Other matters like those you mentioned are key to > keep in mind. > If that were the case, you'd simply be defining a new application service and asking for a TCP port number. And you wouldn't be able to do zero-RTT opens. Joe
- [multipathtcp] Consensus call on potential MPTCP … philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… christian.jacquenet
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Stefano Secci
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… David Allan I
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Costin Raiciu
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Markus.Brunner3
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Robert Skog
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Jordan Melzer
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… Sébastien Barré
- Re: [multipathtcp] Consensus call on potential MP… Wouter Cloetens
- [multipathtcp] Increasing usage of MPTCP [was: Co… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… SungHoon Seo
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Matt Sargent
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Meyer, Ullrich, Vodafone DE
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair