Re: [multipathtcp] High-level design decisions /architecture

[Scott Brim <[e-mail]>]

[e-mail] allegedly wrote on 11/02/2009 12:47 PM:
> Protocol-related
> 
> ============
> 
>     * IPv4 & IPv6 will have the same high-level design
>           o [Comment: the Charter implies both v4 & v6 are in scope]
>     * The MPTCP connection is identified, from an apps perspective, by
>       the addresses associated with the original path (even if that
>       subflow /path closes)

... for a legacy API.  An up-to-date API, with extensions, MUST have a
way of identifying the connection which is independent of addresses.

>     * A SYN/ ACK exchange (on a single path) checks that both ends
>       support MPTCP, with automatic fall-back to TCP if not
>     * each MPTCP subflow looks exactly like an ordinary, semantically
>       independent TCP flow. MPTCP effectively runs on top. So
>       re-transmission, FINs etc are independent on each subflow

retransmission must be sub-flow specific for the moment but we know that
can slow things down so we should actively investigate ways of
retransmitting on any sub-flow.

>     * control of the MPTCP connection (as opposed to the subflows) is
>       carried in TCP options, eg DATA FIN for closing an MPTCP connection
>     * the protocol involves an MPTCP stack at both ends of the MPTCP
>       connection
>           o [Comment: this is in our charter]
>     * Either end of the MPTCP connection can add or remove paths to/from
>       the MPTCP connection
>           o [Comment / Question: this seemed a bit unclear in the
>             protocol i-d, but is presumably required?]

Yes, the protocol must support this.  However, as a meta-issue ... I
suggest that "path" is good for marketing but not technically exact.  An
endpoint can even have multiple addresses associated with a single
interface.  Both of them can.  We should figure out how to restrict the
use of "path" to contexts where its use is accurate.

>     * Subflow end point definition
>           o [Question: Should we allow subflows in a single MPTCP
>             connection to have different ports?]

Don't know.

> Congestion algorithm
> 
> ===============
> 
>     * the goals are: [1] MPTCP is at least as good as TCP would be on
>       the best subflow path; 

This is a hard one.  One use for multipath transport is in environments
where the network situation is (ahem) "dynamic", so it is difficult to
maintain a connection using a single src/dst address pair.  In this
case, if there are problems then multipath transport is certainly
better, but if one of the paths is clean, then just using that path for
a simple TCP gets better goodput then MPTCP would, trying to use that
path plus some poor ones in addition.

Let's try to find some better wording at the meeting.

>       [2] on any path, an MPTCP connection uses
>       less (or the same) capacity as a TCP connection would do; [3]
>       MPTCP moves traffic off more congested paths and onto less
>       congested ones
>     * increases in the congestion windows of the subflows are coupled;
>       for decreases in the congestion windows, each subflow does new
>       reno independently (ie they are not coupled)
>     * slow start, fast re-transmit and fast recovery are the same as
>       RFC5681
> 
> API
> ===
> 
>     * no changes to existing apps are needed to use MPTCP; MPTCP uses
>       the unaltered TCP socket API
>     * There is an optional, extended API
>           o [Question: would both ends need the extended API , with a
>             fall-back if not?]
>           o [Comment: presumably the actual features of the extended API
>             are outside the initial high-level design decisions]

Agree with all.

>     * congestion control state is shared among application-visible
>       transport instances (eg multiple HTTPs between the same pair of
>       hosts)

How do you arrange for this?  Currently, if a single app has multiple
HTTPs running, each one has independent congestion control state.  HTTP
in this case is the "client layer" of transport, so each HTTP would be
an independent client, each getting its own independent MPTCP state.  No?

>     * 3 application profiles are mentioned (Bulk data transport,
>       Latency-sensitive transport with overflow, Latency-sensitive
>       transport with hot stand by)
>           o [Question: how are these supported? Is a negotiation
>             mechanism needed?]            
> 
> Security
> 
> ======
>     * exchange a token in the initial SYN for the MPTCP connection, and
>       include the token when subflows /paths are added to the connection
>           o [Question: Is the same token used whether the sender or
>             receiver (of the MPTCP connection) adds the subflow? Is the
>             same technique used for removing subflows? And closing
>             connections, ie DATA FIN?]
>     * security mechanisms will not interfere with end-to-end
>       authentication etc and will be compatible with legacy middleboxes

The last bullet is difficult because some legacy middleboxes will not
allow unknown TCP options.

I don't know anything about modularity :-)

Thanks ... Scott


> Modularity
> 
> ========
> 
> ·          the architecture has 2 components, multipath scheduler & path
> manager – meaning that improved /different modules of each can be
> slotted in
> 
> o         [Comment: it is unclear from the Architecture i-d how the
> congestion control & protocol i-ds map to these components; some of the
> text (strangely?) appears in a section about implementation]
> 
> o         [Question: what are the mechanisms for evolvability? How is it
> negotiated which new module (for congestion control or path manager) to
> use?]
> 
> o         [Question: this would seem to imply we need to define an
> interface between the modules?]
> 
> ·          there is a default path manager module, meaning it is the
> MUST fall-back option                                                
> 
> o         [Comment: the charter restricts us - the path manager we work
> on will distinguish paths by multiple addresses]