Re: [multipathtcp] q about on-path proxy

[<[e-mail]>]

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[e-mail]]
Envoyé : jeudi 23 mars 2017 23:38
À : [e-mail]; BOUCADAIR Mohamed IMT/OLN
Cc : multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hello Olivier, Med,

Thanks for providing detailed responses. I feel that things now got clearer than before.
In my understanding, the benefits for on-path mode is MCP can stop intercepting and splitting connection once it learns that both endpoints support MPTCP.  if there're other benefits, please point out.

One thing which is not very clear to me yet is MP_PREFER_PROXY.
Med explained that there is a way to learn the endpoints support MPTCP. I think MCPs can learn it through the method described in Figure 15, however I'm not sure how the sender can learn it.
[Med] An implementation example would look like the following :

·         A sends a SYN message with MP_CAPABLE+MP_PREFER_PROXY to B

·         This SYN is intercepted by an MCP which tracks the connection, that is: it removes the MP_PREFER_PROXY and add filters to intercept relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the next hop and so on, until it reaches B.

·         If the SYN/ACK received from B includes MP_CAPABLE, the MCP will forward it to A. A is now aware that B is MPTCP-capable and they can establish subsequent subflows directly. The MCP does not announce explicitly itself to A.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
[Med] The entity that sets the MP_PREFER_PROXY is likely to be an MCP. This is the typical dual-proxy case. This signal is set so that native MPTCP connections received from hosts of a LAN are distinguished from the connections the MCP transforms into MPTCP. An MCP located at the network side will intercept those connections that are proxied; not the ones that can be managed by endhosts.

This signal is motivated also by the requirements from MCP operators to control the usage of their MCP resources: only proxied MPTCP connections are assisted by an MCP.
The signal is also a guard against MCPs that will by default transform an MPTCP connection into a TCP connection. Allowing native connections to bypass that MCP is good to have.

Instead, I am thinking that using a certain option or flag that indicates "MCP has intercepted this flow" may look more reasonable. This seems to be more explicit signal to the downstream MCP.
[Med] Thank you for sharing your preference. I’m personally neutral on the structure of the MP_PREFER_PROXY signal. The most important point at this stage is to assess whether we need it or not.

Also, even when on-path MCP is not there, the sender might put MP_PREFER_PROXY. This looks the waste of resource.
[Med] This is a fair enough.

Thanks,
--
Yoshi

On Thu, Mar 23, 2017 at 1:11 AM, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>> wrote:
Yoshifumi,

Thanks for the response. I think I got basic idea.  Now I have other
questions..
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can
send MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP
in this approach, which looks simpler to me.

There are three abstract ways to ensure that the packets from the uMCP reach the dMCP.

- influence the control plane (e.g. routing tables by using source specific routing) of the network between the uMCP and the dMCP to ensure that the packets reach the dMCP
- change all network packets (e.g. by using source routing)
- change the destination address of all flows initiated by the client

An advantage of the fist solution is that there is no per-packet overhead. A disadvantage of this solution is that it can be costly in a large network to implement and maintain this source specific routing.

An advantage of the second solution is that the IP addresses of the endpoints are preserved. A drawback of this solution is that there is a per packet overhead.

A drawback of the latter solution is that the network operator does not have visibility anymore on the traffic between the uMCP and the dMCP. All traffic appears as TCP connections to the dMCP. An advantage of this solution is that its overhead is minimised since only the SYN carries an additional TCP option.

There is no clear winner among these solutions and we should let the operators select the approach that better suits their deployment and operational concerns.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it
still wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence
of MCP.
             If so, why we cannot use explicit mode (off-path mode) here?

         b) A sender not sure if the receiver supports MPTCP or not.
But, even if the receiver doesn't support MPTCP, it wants to use MPTCP
in some portions of path at least.
            In this case, uMCP will intercept packets and split the
connection regardless of whether the receiver supports MPTCP.
            The sender cannot know if the receiver supports MPTCP or not
because MCP works transparently.
            So, it can never learn about the receiver.
            If I think this way, it seems MP_PREFER_SIGNAL is not
beneficial when the receiver supports MPTCP.

Currently, the main usage is the following in transparent mode


C --- uMCP ------ R1 ------ dMCP -------- R2 ------ S


The client wants to create a Multipath TCP connection towards S. A typical example is that C is an iPhone using the Siri application and S is Apple's server.

The uMCP and dMCP are useful when either the Client or the Server does not support Multipath TCP. If they both support Multipath TCP, it could be useful to allow the connection to pass through the uMCP and dMCP without terminating it. To achieve this in transparent mode, the dMCP must be able to distinguish between :

- a SYN containing an MP_CAPABLE option that was added by the uMCP and that must be terminated by the dMCP
- a SYN containing an MP_CAPABLE option that was inserted by the Client and should not be terminated by the dMCP

This is basically one bit of information. The MP_PREFER_PROXY option indicates that the MP_CAPABLE option was added by an upstream MCP and the connection should be terminated by a downstream MCP.

There are other use cases where the uMCP does not want the dMCP to terminate the Multipath TCP connections for policy reasons or because the uMCP knows that the server directly supports Multipath TCP.

I'm not a big fan of using an entire Multipath TCP option to carry one bit of information in the SYN. I would prefer to define a Proxy flag inside the MP_CAPABLE option as proposed several years ago on this list. This would be a clean solution with a very small overhead. We have spare bits in the MP_CAPABLE option.



Olivier