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

[<[e-mail]>]

Hi Joe, 

Thank you for clarifying. This is helpful. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:[e-mail]]
> Envoyé : mardi 5 décembre 2017 15:39
> À : BOUCADAIR Mohamed IMT/OLN; Scharf, Michael (Nokia - DE/Stuttgart);
> [e-mail]; multipathtcp
> Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> Med,
> 
> Cutting to the points:
> 
> - expressing the IP/port in-band is fine; saying it is "in the SYN"
> directly is not
>     - as a user of TCP, an application-layer program does not have that
> control
> 
> - if this is really (as you say) an application proxy"

[Med] I confirm. We are adhering to Section 3 of RFC1919: 
   * Listen for client sessions.
   * Receive from a client the address of the final target server.
   * Setup a session to the final server.
   * ...

 then let's assume
> you just indicate "send the IP/port as the first data in the stream"
>     - in that case, you are an application and not a change to TCP, so
> *out of scope for* TCPM

[Med] This is actually a fair comment. The document does not change TCP, sure. It is scoped initially to assist establishing MPTCP connections when servers are not MPTCP-capable while ensuring a 0-RTT proxy service and without inducing an overhead. Because some voiced that this proposal may be generalized to assist deploying other TCP options, hence this discussion. 

>     - in that case, you also basically undermine a given service (moving
> its port AND changing its stream contents) for the purpose of increasing
> use of some TCP options (this is where the history of TCPMUX RFC1078 is
> useful - see RFC7805).

[Med] I already commented on tcpmux and RFC7805. Most of items in 7805 do not apply to the converter specification. 

If the only reason is: 

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

I'd like to warrant that this is exactly what popular protocols are doing (e.g. SOCKS). Should the IETF obsoletes SOCKS for that? I guess, no.  

> 
> Either way, my view is this document should not be adopted by TCPM.
> 
> Joe