Re: [multipathtcp] q about on-path proxy

[Olivier Bonaventure <[e-mail]>]

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