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

From: <[email-masked]>
Date: Mon, 22 Oct 2018 12:24:20 +0000

Hi Phil, all,

FWIW, an updated version among what it was mentioned in my reply is available online: 

https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ 

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-04

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 12 juillet 2018 14:23
> À : [email-masked]; [email-masked]
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt
> 
> 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:[email-masked]] De la part de
> [email-masked]
> > Envoyé : jeudi 10 mai 2018 17:51
> > À : [email-masked]
> > 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
> >