Subject: [multipathtcp] Design decisions for Multipath TCP

From: Mark Handley <[email-masked]>
Date: Wed, 21 Jul 2010 22:48:06 +0100

Folks,

To inform the debate next week, Costin and I promised a note on how
the design decisions in multipath TCP were dictated by correctness
criteria.  Here's the note we promised:

http://nrg.cs.ucl.ac.uk/mjh/design-decisions.pdf

It's a little longer than we intended, still a bit rough at the edges,
and there are plenty of middlebox considerations we could discuss but
haven't, including some interesting deadlock cases the current design
avoids.  We intend to add these at some point in the future.  Still,
it does cover the main points:

 - why we need data sequence numbers
 - why mp-capable in syn/ack needs to be acked.
 - why we need data fin.
 - why receive window needs to be connection-level not subflow-level.
 - why data ack is needed for correct flow control.
 - why data ack is needed to free sender buffers.
 - why data ack cannot be payload encoded.
 - the need for data checksums.

We've tried to stick to mechanisms that are strictly required for
correctness.  Please let us know if we've missed something.  What it
does not answer is whether data sequence number mapping needs to be
payload or option encoded.  Either encoding is feasible for
correctness.

My personal view though is that if data acks are mandatory and need to
be option encoded, then there's no advantage to using payload encoding
for data sequence numbers.  In fact using payload encoding for data
sequence numbers and options for data acks seems to have all the
disadvantages of payload encoding and none of the advantages.  So, for
me, this settles the issue:  we should use option encoding.

Cheers,
Mark