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

Hi Joe, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Joe Touch
> Envoyé : dimanche 3 décembre 2017 21:30
> À : Scharf, Michael (Nokia - DE/Stuttgart); tcpm@ietf.org; multipathtcp
> Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> 
> 
> 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.

[Med] The data that are inserted in ONE single SYN is the application (proxy) data. What's is wrong with that? 

 At best, the mechanism attempts to re-create an
> extension of TCPMUX, which was deprecated for good reason.

[Med] I don't understand the reference to TCP tcpmux. But even if we assume there is a similarity between the two proposals, let's assess whether the technical reasons for deprecating tcpmux, as called in RFC7805, apply for the converter case:

      *  It modifies the TCP connection establishment semantics by also
         completing the three-way handshake when a service is not
         available.

Not applicable.

      *  It requires all new connections to be received on a single
         port, which limits the number of connections between two
         machines.

Only TCP connections that are eligible to a network-assistance service are forwarded to the converter, which listens on a service port. We used to have a design which does not restrict connections to be bound to a port number, but we modified the design as per your recommendation. If you now think that your recommendation was not a good advice for us, we can easily fix this.  

      *  It complicates firewall implementation and management because
         all services share the same port number.

This one is debatable because it is really deployment-specific. A deploying in 

      *  There are very limited deployments, and these are not used in
         an Internet context.  (The only reported use is for SGI's Data
         Migration Facility in private networks.)

Not applicable. 

> 
> 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
>     - Whether the doc is adopted or not, I have no interest in
> continuing to try to repair its significant (and IMO fatal) flaws

[Med] Joe, we have taken into account many of the comments you raised in the past (e.g., define the proposal as an application proxy, make use of a service port, better integrate with TFO). It would be helpful to list some of the "fatal flaws" so that we can determine whether these are new issues. Thank you.

> 
> Joe
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm