[multipathtcp] Dual-ended Multipath TCP Proxy work item

[Olivier Bonaventure <[e-mail]>]

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

Please find some comments related to the dual-ended proxy Multipath TCP 
Proxy use case. In this use case, there are two proxies :
- an on-path upstream proxy that resides typically in the CPE
- a downstream proxy. This proxy may be on-path or off-path. My answers 
relate to the off-path proxy unless otherwise noted

>
>
> 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)

The scenario is a laptop that does not support MPTCP connected to a CPE 
and the CPE is itself connected to two access networks (typically xDSL 
and cellular). The upstream proxy is included in the CPE. The downstream 
CPE is typically installed inside the network of the access provider.

>
> ·         If any impact is already envisaged on the current MPTCP
> protocol’s fallback behaviour and coping with middleboxes

I don't think so. If the proxies are deployed by a network operator, it 
is possible to ensure that there are no middleboxes that mess with MPTCP 
on the paths between the two proxies.

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

The key issue is the ability to signal addresses (mainly the server 
address) to the Proxy without adding delay to the connection 
establishment. This can be achieved by either :
- adding options to the SYN (but we have to cope with the limited size 
of the TCP options field in the MPTCP SYN)
- adding information in the payload of the SYN, this information would 
likely be encoded in a TLV format like the TCP/MPTCP options and should 
be compatible with the utilisation of TFO.
>
> ·         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


I don't think so. If we end up putting TLV information in the payload of 
the SYN, some parts of the SYN payload will not belong to the bytestream 
and this might affect the protocol semantics.
>
> ·         If any impact is already envisaged on TCP’s semantics, or any
> mods are needed, or assumptions about its behaviour, etc

I don't think so.


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

I'm not personally convinced by the benefits of transporting an non 
bytestream transport protocol into TCP.

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

This use case is considered by various network operators. They are in a 
position to ensure that there is no middlebox between the two proxies. 
We should take this fact into account by designing a solution that is 
optimised for the case where there is no middlebox on the path. In this 
use case, there are a large number of MPTCP connections between the 
upstream and downstream proxies. We are not in the same situation as a 
host trying to establish a single MPTCP connection towards a random 
server over a random path. We should leverage this knowledge in our design.

As for the single-ended proxy, the key requirement is that the creation 
of an MPTCP connection through a Proxy does not require additional rtts.


Olivier