Hi Joe, Please see inline.
Cheers, Med De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch Envoyé : mercredi 19 juillet 2017 01:12 À : Olivier Bonaventure; Internet Area; tsv-area@ietf.org Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP On 7/18/2017 4:05 PM, Olivier Bonaventure wrote: Although I'm not averse to middleboxes as optional optimizations, I find the proposed mechanisms aren't quite optional -- they inject option information into the SYN data. That information would poison a connection to a legacy receiver if (more to the point, when) that info isn't removed by a proxy upstream of the receiver. This paragraph refers to earlier documents discussed in the MPTCP working group. The new design does not inject option information into the SYN data. It works like an application layer protocol that sends messages in the SYN by using the TFO option. There is no risk of poisoning. OK, in that case: - I'm still not averse to middleboxes that accelerate or enhance TCP [Med] The proposal leverages on existing IETF RFCs and BCPs to assist establishing communications over multiple paths even if the remote server is not MPTCP-capable. BTW, we integrated almost all the suggestions you made previously (e.g., use a dedicated service port, figure out how to use TFO to get TFO performance). - IMO, TCP always needs to be able to fall back (which should be true now) [Med] We are not interfering with this. - but I remain concerned with "injection piggybacking" - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection [Med] I don’t understand your reference to the option space. - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all [Med] Two comments here: · It seems that you assume all the traffic will be systematically relayed to a proxy. This is not the assumption we have in the mptcp WG. · The mechanisms you mentioned are known to have issues with NAT; extensions exist to soften some of them. I don’t see a new issue out there when it come to an network-assisted MPTCP proxy. Joe
