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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'll jump in here ;-)

[e-mail] wrote:
...
> Protocol-related
> 
> ============
> 
>     * IPv4 & IPv6 will have the same high-level design
>           o [Comment: the Charter implies both v4 & v6 are in scope]

Definitely.

>     * The MPTCP connection is identified, from an apps perspective, by
>       the addresses associated with the original path

Yes, IMO.

> (even if that
>       subflow /path closes)

Yes, although, as noted, if the IP address goes away altogether, then
IMO the connection needs to be terminated.

>     * A SYN/ACK exchange (on a single path) checks that both ends
>       support MPTCP, with automatic fall-back to TCP if not

Yes, with as few bytes as possible.

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

Don't care. Seems to make sense for middleboxes that track such things,
but IMO they shouldn't care either, esp. since the packets could be
encrypted.

>     * 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 protocol involves an MPTCP stack at both ends of the MPTCP
>       connection
>           o [Comment: this is in our charter]

Agreed (as per the charter), but seriously this begs the question of
what is "TCP" about the result. I don't like the idea of doing this all
inside TCP solely as NAT camouflage.

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

>     * 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.

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

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

I would assume that both increases and decreases are not coupled. If
they are, it seems like a subflow could use bandwidth on one path to
justify being more aggressive on another, which seems to violate [2] above.

>     * slow start, fast re-transmit and fast recovery are the same as
>       RFC5681

Yes.

> 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".

>     * 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.

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

> 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?]

Let's please not call this "security". Call it a flow identifier, but
it's trivial for on-path attackers to see, and anything small enough to
be appropriate for a SYN is likely to be too small to prevent exhaustion
attacks.

>     * security mechanisms will not interfere with end-to-end
>       authentication etc 

Yes. Specifically IMO there ought to be a TCP-AO mode supported - e.g.,
using socketpair of the original connection for the pseudoheader used
for MAC calculation.

(i.e., where this mentions "security mechanisms" I think of TCP-AO, not
a nonce)

> and will be compatible with legacy middleboxes

Well, legacy middleboxes do all sorts of nasty things - many of which
are more correctly considered attacks - so this can't be a requirement
as worded.

E.g., some middleboxes remove unknown options. That's clearly going to
break things here. Others change packet boundaries (splitting, joining,
etc.). Others rewrite all sorts of header fields.

IMO, be more specific about what you would like to support (e.g., simple
NATs), and make this a goal, not a requirement.


> Modularity
> 
> ========
> 
> ·         the architecture has 2 components, multipath scheduler & path
> manager – meaning that improved /different modules of each can be
> slotted in

This seems to confuse architecture with implementation. Although they
are specified separately, an implementation might conflate the two to
the point where it cannot be modularly modified. I don't know what
you're going for here, but IMO just state that they're independently
*specified*.

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

That might be a place where the implementation cannot reasonably
separate the two specification issues.

> o        [Question: what are the mechanisms for evolvability? How is it
> negotiated which new module (for congestion control or path manager) to
> use?]

This seems like an independent question, i.e., how are versions of the
protocol identified and established for each connection?

> o        [Question: this would seem to imply we need to define an
> interface between the modules?]

Sounds suspiciously like an API - which I think is needed, and is a good
idea, but you ought to get buy-in on this, since it's intraprotocol, and
could be easily confused with an implementation issue.

It'd be important to make sure this is an architecture interface, not an
implementation one.

> ·         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]

See above - version issue.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrveB4ACgkQE5f5cImnZrvxfACg4p2+t723PQIFk8OPB4l1wVfI
fY8AoPENpgkIi56NIWerwlGQT9A4uv4a
=4eEh
-----END PGP SIGNATURE-----