Re: [multipathtcp] Towards a Multipath TCP Proxy work item

[<[e-mail]>]

Hi Phil,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[e-mail]] De la part de [e-mail]
Envoyé : jeudi 10 novembre 2016 20:17
À : [e-mail]
Objet : [multipathtcp] Towards a Multipath TCP Proxy work item

Hi,
Perhaps this is speaking too soon, but it looks like the very active discussion is reaching some common understanding?


We're trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we'd assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we'd like discussion on these points to avoid getting into the fine details of one particular existing proposal.

What we'd appreciate is a summary of what the assumptions /understandings are about:

*         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the 'legacy' host it wants to communicate with)

[Med] The main assumptions are:

·         The address(es) of the remote endpoint is/are retrieved using state of the art mechanisms; no change is required.

·         This work does not mandate nor preclude that a proxy is on a default forwarding path. Scenarios with host mobility are likely to require the address(es) of the proxy, though.



*         If any impact is already envisaged on the current MPTCP protocol's fallback behaviour and coping with middleboxes

[Med] This work leverages on that behaviour (because this is MPTCP). Further, it requires a dedicated procedure for negotiating the support of the extension for the very FIRST connection to a given proxy.



*         If we can agree that the solution is based on a new MPTCP option

[Med] I don't think there is an agreement on this but my current collection is as follows:

·         I heard that participants see benefits in 0-RTT MPTCP proxying

·         I didn't hear objecting to insert data in SYN

·         I do personally think that the negotiation of the extension (SYN/AYN-ACK) allows for a safe use on the Internet without violating any of TCP/MPTCP specs.

·         I know Joe still has an issue with this to be defined as a TCP option.



I don't think that we MUST have a consensus on this before chartering this work. I agree this is simple if we have such an agreement, but IMHO it is just fair to leave the final decision for after-charter work.



*         If any impact is already envisaged on the current MPTCP protocol's semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4

[Med] I do think we can do this work without such modification, but this is typically the kind of decisions we can reach once the work item is chartered, not before.



*         If any impact is already envisaged on TCP's semantics, or any mods are needed, or assumptions about its behaviour, etc

[Med] I don't expect any modification to TCP/



*         If any impact is already envisaged on other existing transport protocol's semantics (presuming people still would like non-TCP in scope?)

[Med] There is no expected modification. I do think that handling other protocols will be valuable because this will avoid having a solution for each transport protocols (UDP, namely.



*         Anything else that you think is needed in order to frame the work item

[Med] I would like to add explicit items for DHCP and RADIUS extensions.

It may be clearer to do this for the two use cases (single-ended proxy, ie where only one host is MPTCP-enabled; and double-ended proxy, ie where neither host is MPTCP-enabled).

This may seem like a long list, but most of the answers can be "none" - we'll end up with just a short paragraph or a few bullets in the charter.

We'd also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.

Thanks
Phil & Yoshi