[multipathtcp] Single-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?

Let try a first answer to your questions for the single-ended Multipath 
TCP proxy work item.
I'll send my answers to the double-ended proxy in a separate email.
>
> 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 typical use case is a smartphone that wants to combine its WiFi and 
cellular access networks to reach a server that does not (yet) support 
Multipath TCP.

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

I don't think so but this will be a function of the mechanisms that we 
insert in MPTCP.

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

For this use case, given the mobility of the smartphone, it is unlikely 
that the Proxy will reside on path.
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
>

The key requirement is that the creation of an MPTCP connection through 
a Proxy does not require additional rtts.


Olivier