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

[<[e-mail]>]

Hi Joe,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:[e-mail]]
> Envoyé : mardi 5 décembre 2017 01:36
> À : BOUCADAIR Mohamed IMT/OLN; Scharf, Michael (Nokia - DE/Stuttgart);
> [e-mail]; multipathtcp
> Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> Hi, Med,
> 
> 
> On 12/3/2017 11:00 PM, [e-mail] wrote:
> > ...
> >>   "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?
> 
> If this is an application layer proxy, then you have no direct control
> over segment contents. The best you can say is that you write this
> information to the socket. If you do that, then you are a simple TCP
> service, not unlike any other TCP service which uses - but does not
> alter - TCP, and not in-scope for TCPM.
> 
> To understand why intending to insert out-of-band info in the SYN is a
> problem, see Sec 8.7 of draft-ietf-tcpm-tcp-edo.

[Med] Thank you for the pointer (which I'm very familiar with), but I failed to identify the exact text you are pointing to. 

As a reminder, the proxy-data supplied in a SYN to a converter is made after a negotiation happened between a host and a converter. So, it is safe to supply that proxy-data to the converter.

> >  ...
> >
> > 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.
> 
> I did, above.

[Med] We did also seriously considered the design to take into account your inputs. What is amazing is that some of these inputs are now presented as "flaws": e.g., the use of a service port (refer to your pointer to tcpmux) or that TFO is broken in presence of middleboxes.

 Continuing to avoid each fatal flaw does not ensure you
> will find a solution that is viable.

[Med] Listing what you think are "fatal flaws" would be natural in a technical discussion. Claiming without sharing/revealing is not helpful, IMO. Thank you.

> 
> Joe