Hi Tom, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom Herbert > Envoyé : mercredi 19 juillet 2017 00:43 > À : Joe Touch > Cc : tsv-area@ietf.org; Internet Area > Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP > > On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch <to...@isi.edu> wrote: > > Hi, all, > > > > I've noted this before, but to share with other areas: > > > > 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. > > > > TCP must be E2E and fall back to legacy endpoints without a reconnection > > attempt, as required by RFC793. > > > > These aren't generic solutions; they're attacks on a TCP connection, > IMO. > > > I agree. This seems be akin to stateful firewalls model that impose > artificial requirements on networking (like every TCP packet for a > connection must got through some middlebox or the connection is > dropped). We need to move things back to E2E semantics for transport > protocols-- nodes that try to maintain transport state in the network > should be considered the problem not the solution! > [Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support MPTCP. The proposed solution allows to: * elect some flows to benefit from network-assisted MPTCP while avoiding session failures. * Policies are configured to identify traffic that won't be forwarded via a proxy * 0-RTT proxying * MPTCP can be used e2e if both end points are MPTCP-capable (that is, the proxy is withdrawn from the path). * No interference with TCP options to be negotiated between endpoints. Do you have in mind such use cases when you referred to the "stateful firewalls model"? > Tom > > > Joe > > > > > > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: > >> The working group has discussed this issue several times and today we > >> have presented a new design that supports the creation of such > >> functions to convert MPTCP connections into TCP connections and vice > >> versa. The design was done with MPTCP in mind, but the proposed > >> solution could be more generic and applied to other use cases than > >> MPTCP. The draft that describes the new design is available via: > >> > >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp- > converters-01.txt > >> > >> > >> Mirja Kuehlewind suggested to send the document on the int-area and > >> tsv-area mailing lists to see whether other working groups could be > >> interested by this approach. > > > > _______________________________________________ > > Int-area mailing list > > int-a...@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
