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

["Ford, Alan" <[e-mail]>]

Hi Joe, all,

> >     * control of the MPTCP connection (as opposed to the subflows) is
> >       carried in TCP options, eg DATA FIN for closing an MPTCP connection
> 
> I disagree. The option stream is neither reliable or ordered, and so
> it's a bad idea to put state management there. If you want a control
> channel, open a separate connection IMO.

The current proposal contains quite a lot to meet the limitations of options. Specifically: Data Sequence Mapping is done so that a data-level sequence number does not have to appear exactly at the correct point; address management has no requirement to be reliable or in-order; and DATA FIN is applied to a FIN only.

> >     * 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?]
> 
> Depends on when the paths are created.
> 
> If they are created at SYN time, then it's OK IMO to develop support
> asymmetrically.
> 
> If they can be created once open, AFAICT TCP is memoryless w.r.t. who
> opened the connection, so I can't see why either side would have
> privileged rights (or could even tell).

Yes, indeed (from the TCP level). Plus, the idea of who opens the subflow (i.e. sends the SYN) may not be the same endpoint who has requested this to happen (see address management stuff). 

> >     * Subflow end point definition
> >           o [Question: Should we allow subflows in a single MPTCP
> >             connection to have different ports?]
> 
> Seems like you'd have to - or you have to coordinate port use on
> different addresses at a single endpoint constantly.

Yes, and we have a demuxing value (the token) anyway. However, for optimality it is proposed that the same ports are used on the same (and maybe different) addresses per connection.

> > Congestion algorithm
> >
> > ===============
> >
> >     * the goals are: [1] MPTCP is at least as good as TCP would be on
> >       the best subflow path; [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
> 
> These sound OK, though it might be useful to consider that [1] and [2]
> are requirements (IMO), where [3] is an optimization goal, and thus OK
> to break.

Interesting point - a narrow distinction but a valid one. There is certain linkage between [2] and [3], however, in that while it may be okay to break [3] you can't do it to the detriment of other users ([2]).

> > API
> >
> > ===
> >
> >     * no changes to existing apps are needed to use MPTCP; MPTCP uses
> >       the unaltered TCP socket API
> 
> I would say this in a way that flows into the next idea below better,
> e.g., "no changes are required to use MPTCP in its simplest mode".

Agreed.

> >     * There is an optional, extended API
> >           o [Question: would both ends need the extended API, with a
> >             fall-back if not?]
> 
> Seems like one end could want the extended API for explicit control of
> flows, but the other end doesn't need to care.

Yep.

> >           o [Comment: presumably the actual features of the extended API
> >             are outside the initial high-level design decisions]
> >     * congestion control state is shared among application-visible
> >       transport instances (eg multiple HTTPs between the same pair of
> >       hosts)
> 
> IMO (RFC2140, e.g.), yes ;-)
> 
> >     * 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?]
> 
> Seems at odds with the claims above for [1],[2],[3]. I.e., bulk
> transport seems compatible with all three, but latency-sensitive seems
> like it might not be compatible with any of these.

Latency-sensitive would still be compatible with [1] and [2] but is not so concerned with congestion sharing. Having said that, it would be likely that the least congested path is optimal for most cases of latency-sensitive transport!

Regards,
Alan