Re: [Int-area] Middleboxes to aid the deployment of MPTCP

[<[e-mail]>]

Hi Joe,

Please see inline.

Cheers,
Med

De : Int-area [mailto:[e-mail]] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 01:12
À : Olivier Bonaventure; Internet Area; [e-mail]
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