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

[William Herrin <[e-mail]>]

On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch <[e-mail]> wrote:
> That requires that options are processed on the data after ordered, as
> you note. However, TCP is an unordered protocol.
>
>> My first thought would be a three-part handshake. Request option X,
>> option X accepted, option X in effect. Requires that the receiver
>> understand that order is important after sending X accepted though.
>
> Right. How do you bury that handshake in an unordered, unreliable stream
> without halting it, though?

Hi Joe,

How about a 4-step handshake like this:

Request option X, option X accepted, option X in effect (1), option X
in effect (2).

When you receive X accepted, attach X1 to *every* outgoing packet
until you get an ack for everything up to and including the first X1
packet. Then start sending X2 in every outgoing packet until you get
an ack for any X2 packet. Then stop sending the X option on any packet
that isn't a retransmission of one where X1 or X2 was sent.

At the receiver end: until you receive a packet with X2, only packets
with X1 or X2 have option X in effect. After you see any packet with
X2, all subsequent packets have option X in effect regardless of the
presence of X1 or X2.

Nobody pauses. Options are processed in the order received. And you're
dealing with pretty trivial state changes on each end.

One concern that jumps to mind is if the receiver gets a late copy of
an already received and acked segment where option X is not in effect.
What will the receiver do with the late packet?  Let me narrow that a
bit: assuming option X does not affect the use of the TCP sequence
number in any way, what will the receiver do with a late copy of an
already received packet where it thinks X is in effect but in reality
X was not requested?


On the other hand, if option X has some other intrinsic value (such
has holding the multipath TCP connection ID for middleboxes to decode)
then you can just keep sending it in every packet which uses it for
the remainder of the connection instead of the fancy handshake.

Regards,
Bill Herrin



-- 
William D. Herrin ................ [e-mail]  [e-mail]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004