Hi Valdimir, Thank you for your answer.
Please see inline. Cheers, Med De : Vladimir Olteanu [mailto:[email protected]] Envoyé : mercredi 5 juillet 2017 01:35 À : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : [email protected]; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as inspiration for SOCKS 6. When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT overhead. [Med] Glad to see that we are pursuing the same goal. That's said I'm not sure about the 0-RTT in the current proposal given this text that puts a dependency on the server side: In the fast case, when authentication is properly set up, the proxy attempts to create the socket immediately after the receipt of the request, thus achieving an operational conection in one RTT (provided TFO functionality is available at the client, proxy, and server). ^^^^^^^^ It can also be stacked as many times as desired for arbitrarily long proxy chains. However: * We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy). [Med] This is also true for MP_CONVERT Information Element which is not a TCP option, but a data supplied for proxy purposes in the SYN payload. The magic number at the start of the MP_CONVERT element implies that if any MPTCP stream happens to start with 0xFAA8FAA8, the client should not use TFO. [Med] This can be fixed by registering a service port for the proxy service because, after all, the ultimate destination port is conveyed in the MP_CONVERT. I think moving up the protocol stack is a more desirable alternative. * We support authentication. Connections to the proxy can also be initiated from networks outside of the operator's control (e.g. home WiFis). [Med] Authentication/authorization can be supported by various means. This depends on the deployment scheme. * SOCKS 6 is easier to extend. If the client needs to request some special behavior from the proxy (e.g. what packet scheduler to use), all we have to do is define (and standardize) a new SOCKS option. [Med] That's also true for MP_CONVERT Information Element. You can define new "Types" if needed. Can you please let me know if the proposal supports the following features: · Support incoming connections (Proxy<---Remote Host): That is the proxy intercept a TCP connection that it transforms into an MPTCP one. · If such feature is supported, how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections? · Use MPTCP in the leg between the proxy and server · Notify the client that the server is also MPTCP-capable (so that the proxy can be withdrawn from the communication) · Relay untouched the set of TCP options supplied by the client/server without any alteration from the proxy · IPv6 source address/prefix preservation (I've also CCed the MPTCP WG). [Med] Thanks. Cheers, Vlad On 07/04/2017 12:09 PM, [email protected]<mailto:[email protected]> wrote: Hi Vladimir, all, (focusing only on this part of the message). I do fully agree that shortening MPTCP connections setup is key. Having 0-RTT is an important requirement for this effort. Achieving it without out-of-band signaling would be even ideal. Can you please elaborate on the benefits of your proposal compared to https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf which allows to achieve 0-RTT proxying. Thank you. Cheers, Med De : Int-area [mailto:[email protected]] De la part de Vladimir Olteanu Envoyé : vendredi 30 juin 2017 23:37 À : David Schinazi Cc : [email protected]<mailto:[email protected]> Objet : Re: [Int-area] SOCKS 6 Draft Hi David, [SNIP] - Out of curiosity, what specific use case are you using this protocol for? We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg. Cheers, Vlad
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
