IETF Logo Mail Archive

Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

<mohamed.boucadair@orange.com> Tue, 05 December 2017 07:14 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 6B401126CBF; Mon, 4 Dec 2017 23:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 37AZuavhYjcb; Mon, 4 Dec 2017 23:14:46 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C19124234; Mon, 4 Dec 2017 23:14:46 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 63D4740B58; Tue, 5 Dec 2017 08:14:44 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 459AB120063; Tue, 5 Dec 2017 08:14:44 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 08:14:43 +0100
From: mohamed.boucadair@orange.com
To: Yuchung Cheng <ycheng@google.com>, Joe Touch <touch@strayalpha.com>
CC: multipathtcp <multipathtcp@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ?
Thread-Index: AQHTbS1LfQqYV0PDzkqfP3vT/hvFTKM0VFOQ
Date: Tue, 05 Dec 2017 07:14:43 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A08621E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <AM5PR0701MB25475FD66E9553F2947DD22C933F0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <AM5PR0701MB25470B276B0889170FC309FE933F0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <CAK6E8=f0GG+Y45NqQ3zb_ChFWpWZ4mS5sgeQVPO7e0zmTbOyeA@mail.gmail.com>
In-Reply-To: <CAK6E8=f0GG+Y45NqQ3zb_ChFWpWZ4mS5sgeQVPO7e0zmTbOyeA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/FkTYm3fIYrOiYNx1gzpivHlOTzE>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?
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: Tue, 05 Dec 2017 07:14:48 -0000

Hi Yucheng, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung Cheng
> Envoyé : lundi 4 décembre 2017 19:25
> À : Joe Touch
> Cc : multipathtcp; tcpm@ietf.org
> Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch <touch@strayalpha.com> wrote:
> >
> >
> >
> > On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> > > The TCPM charter states that the "WG mostly focuses on maintenance
> issues
> > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and
> > > interfaces that maintain TCP's utility". Assisting the deployment of
> new TCP
> > > extensions could be understood as one way to ensure TCP's utility.
> >
> >   "The client places the destination address and port number of the
> >    target Server in the payload of the SYN sent to the Converter by
> >    leveraging TCP Fast Open [RFC7413]."
> >
> > I disagree with any use of TCP SYN payloads as anything other than
> > application data. At best, the mechanism attempts to re-create an
> > extension of TCPMUX, which was deprecated for good reason.
> >
> > Additionally, this is claimed to be an application proxy, which would be
> > out of scope both for TCPM and to modify the definition of the contents
> > or directly manipulate the headers of any TCP segments.
> >
> > My position is as follows:
> >     - I don't think this doc should be adopted by the WG
> I too do not support the adoption for similar reasons above, even
> though I'd love to see more usage of TFO and MPTCP.
> 
> TFO today is still facing bad middle-boxes issues and
> demands extreme conservative heuristics to deploy (see last
> presentation by Praveen in tcpm). Ultimately they need to be
> applied by either the client or the proposed converters.
> 

[Med] I'm not sure to understand this point about "TFO today is still facing bad middle-boxes issues". Please note: 
- The proposal does not interfere with the deployment of TFO and its usage when supported by both endpoints. Better, it allows to pass safely TFO option. 
- The proposal leverages on TFO to establish 0-RTT proxied MPTCP connections. A first connection is established between the host and converter to retrieve a TFO cookie that is used for proxy-purposes. That cookie will be supplied by the host when including proxy-supplied data in a SYN of a subsequent connection. 


> >     - Whether the doc is adopted or not, I have no interest in
> > continuing to try to repair its significant (and IMO fatal) flaws
> >
> > Joe
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email