Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt

<> Thu, 12 July 2018 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EF5D130DF1 for <>; Thu, 12 Jul 2018 05:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sWlLV_BFNTh1 for <>; Thu, 12 Jul 2018 05:23:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CAA3130DDE for <>; Thu, 12 Jul 2018 05:23:12 -0700 (PDT)
Received: from (unknown [xx.xx.xx.5]) by (ESMTP service) with ESMTP id 41RFTB5kmzz8tRJ for <>; Thu, 12 Jul 2018 14:23:10 +0200 (CEST)
Received: from localhost.localdomain (unknown []) by (ESMTP service) with ESMTP id 41RFTB57TPzCqkY for <>; Thu, 12 Jul 2018 14:23:10 +0200 (CEST)
Received: from by with queue id 626964-29 for; Thu, 12 Jul 2018 12:23:10 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by (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: <>
To: "" <>, "" <>
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: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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. 


> -----Message d'origine-----
> De : tcpm [] De la part de
> Envoyé : jeudi 10 mai 2018 17:51
> À :
> 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: 

"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.

> 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 [] On Behalf Of internet-
> Sent: 05 March 2018 18:17
> To:
> Cc:
> 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> tcpm mailing list
> _______________________________________________
> tcpm mailing list