Re: [multipathtcp] towards a potential work item on two-ended proxy

[<[e-mail]>]

Hi Alan,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:[e-mail]]
Envoyé : jeudi 4 août 2016 14:33
À : BOUCADAIR Mohamed IMT/OLN
Cc : Henderickx, Wim (Nokia - BE); [e-mail]
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Med,

Inline...

De : Alan Ford [mailto:[e-mail]]
Envoyé : jeudi 4 août 2016 10:06
À : BOUCADAIR Mohamed IMT/OLN
Cc : Henderickx, Wim (Nokia - BE); [e-mail]<mailto:[e-mail]>
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy


 I don’t get this argument…
[Med] My point is about “transport-agnostic” part of your comment. One would argue that communication an IP address in a TCP option (which MPTCP is doing) is also “transport-agnostic” but no one is objecting to define such (MP)TCP option.

No, it is not transport-agnostic, it is integral to how MPTCP operates.


You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.
[Med] The PM option is in the payload because of the limited option space. In early versions of the draft, the option can be inserted in the dedicated TCP option space if there is enough space, payload, etc. but we abandoned that design to simply the implementations.

But this information doesn’t need to be read or understood by a MPTCP stack!
[Med] It needs to be read by the “MPTCP proxy” stack.

It is telling the proxy application, which sits above MPTCP,
[Med] This is implementation-specific. We are defining a new functional entity called “MPTCP Proxy”. The internal structure of such element is really implementation-specific.

where to forward the following payload data to.

This signal is a protocol which is not specific to MPTCP, and is in no way integrated with the rest of the MPTCP protocol.
[Med] I still don’t understand this argument as we are defining something “NEW”: Network-assisted MPTCP in addition to the existing end-to-end MPTCP.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows.
[Med] I don’t parse what is meant by “defers” and “stack” here although I suspect those are implementation details that may or may not be followed by a given implementation.

[ Snip]