Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt
<mohamed.boucadair@orange.com> Thu, 12 July 2018 12:23 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5D130DF1 for <tcpm@ietfa.amsl.com>; Thu, 12 Jul 2018 05:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sWlLV_BFNTh1 for <tcpm@ietfa.amsl.com>; Thu, 12 Jul 2018 05:23:12 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAA3130DDE for <tcpm@ietf.org>; Thu, 12 Jul 2018 05:23:12 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB5kmzz8tRJ for <tcpm@ietf.org>; Thu, 12 Jul 2018 14:23:10 +0200 (CEST)
Received: from localhost.localdomain (unknown [127.0.0.1]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB57TPzCqkY for <tcpm@ietf.org>; Thu, 12 Jul 2018 14:23:10 +0200 (CEST)
Received: from opfedar03.bagnolet.francetelecom.fr by opfedar03.bagnolet.francetelecom.fr with queue id 626964-29 for tcpm@ietf.org; Thu, 12 Jul 2018 12:23:10 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 41RFTB4YZHzCqkS; Thu, 12 Jul 2018 14:23:10 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0399.000; Thu, 12 Jul 2018 14:23:10 +0200
From: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt
Thread-Index: AQHTtK4iDI+Mo6jxv0utHg3D/M2BoKQpg4TwgGLB2BA=
Date: Thu, 12 Jul 2018 12:23:10 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF598FD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <152027380186.14624.8843516061240272538@ietfa.amsl.com> <718b17025c25456490724ad442040422@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <718b17025c25456490724ad442040422@rew09926dag03b.domain1.systemhost.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
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/tcpm/JHgcMa2juvunmSYJZcGkT8CDCpc>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 12:23:15 -0000
Hi Phil, Apologies of the delay to answer. Thank you for sharing these comments. Please see inline. Cheers, Med > -----Message d'origine----- > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de philip.eardley@bt.com > Envoyé : jeudi 10 mai 2018 17:51 > À : tcpm@ietf.org > Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt > > Hi, > > I remember in the London discussion there were some comments about things it > would be good to add to the draft - mainly about more examples. I agree with > this, it would be useful I think to cover: > > - The example is for one client. I assume multiple clients each require > their own Ipv6 address on the converter (ie which is the source address for > that client's converter-server(s) connections)? [Med] This is deployment-specific. The converter may behave in address sharing or address preservation modes. A text change is proposed here: https://github.com/obonaventure/draft-tcp-converters/pull/41/commits/de004090c1861f0f8b076285b4119d48f7ab47e8 "The Converter may behave in address preservation or address sharing modes as discussed in Section 5.4 of {{draft-nam-mptcp-deployment-considerations}}. Which behavior to use by a Converter is deployment-specific. If address sharing mode is enabled, the Converter MUST adhere to REQ-2 of RFC6888 which implies a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]) must be supported. This behavior is meant to avoid breaking applications that depend on the external address remaining constant. Also, maintaining the same external IP address for a client is meant to preserve the validity of the TFO cookie." > - How would the client access Ipv4 content? [Med] We would like to avoid overloading the document with deployment-specific examples. Plenty of those are described in draft-nam-mptcp-deployment-considerations. We may add a pointer if needed. > - I assume the client has to be configured somehow with the converter's > address [Med] Yes, we do have the following text in the draft: This document assumes that a client is configured with one or a list of Converters (e.g., [I-D.boucadair-tcpm-dhc-converter]). Configuration means are outside the scope of this document. > - What happens if the converter fails? I suppose the client has to > somehow notice, and (at config time) it gets told the address for a back-up > converter or a DNS name. [Med] I-D.boucadair-tcpm-dhc-converter specifies a procedure to provision one or multiple converters; each identified by a list of IP addresses. The procedure to follow for selecting the address to use will need to be specified. Should we include it in draft-ietf-tcpm-converters or in I-D.boucadair-tcpm-dhc-converter? I do prefer to leave that procedure out of draft-ietf-tcpm-converters because the selection may not only be based on the availability of an address, but based on other criteria. > - What happens if a link fails? I assume if one of the client-converter > links fails, then MPTCP shifts all the traffic to the other path. [Med] This is normal MPTCP behavior. Do we really need to say something there? If the > converter-server connection fails, how does the client discover this? [Med] This is done by means of the "Network Failure (65)" error code: o Network Failure (65): This error indicates that the Converter is experiencing a network failure to relay the request. The Converter MUST send this error code when it experiences forwarding issues to relay a connection. I > assume packets build up at the converter and are dropped, and at some point > the converter informs the client. > > Thanks, > Best wishes, > phil > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 05 March 2018 18:17 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG of > the IETF. > > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Bart Peirens > SungHoon Seo > Anandatirtha Nandugudi > Filename : draft-ietf-tcpm-converters-01.txt > Pages : 37 > Date : 2018-03-05 > > Abstract: > This document specifies an application proxy, called Transport > Converter, to assist the deployment of TCP extensions such as > Multipath TCP. This proxy is designed to avoid inducing extra delay > when involved in a network-assisted connection (that is, 0-RTT). > This specification assumes an explicit model, where the proxy is > explicitly configured on hosts. > > -- Editorial Note (To be removed by RFC Editor) > > Please update these statements with the RFC number to be assigned to > this document: > [This-RFC] > > Please update TBA statements with the port number to be assigned to > the Converter Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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
- [tcpm] I-D Action: draft-ietf-tcpm-converters-01.… internet-drafts
- Re: [tcpm] I-D Action: draft-ietf-tcpm-converters… philip.eardley
- Re: [tcpm] I-D Action: draft-ietf-tcpm-converters… mohamed.boucadair
- Re: [tcpm] I-D Action: draft-ietf-tcpm-converters… mohamed.boucadair