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

[William Herrin <[e-mail]>]

On Tue, Nov 10, 2009 at 4:12 PM, Joe Touch <[e-mail]> wrote:
> William Herrin wrote:
>> On Mon, Nov 9, 2009 at 10:27 PM, Joe Touch <[e-mail]> wrote:
>>> Right. How do you bury that handshake in an unordered, unreliable stream
>>> without halting it, though?
>>
>> 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.
>
> What happens to retransmitted packets that were first sent before you
> decided to set X?

Hi Joe,

Retransmit as originally sent. Otherwise you could have two very
different packets show up for the same segment. Set X1 only on packets
whose first transmission comes after option X accepted.


>> 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.
>
> So now you have a problem. Some packets are handled as if option X is in
> effect, and some are not. These could arrive in any order. What if the
> option has something to do with the order in which the packets are ACKd?

As I mentioned: constraint on the option in this exchange in that it
can't impact the handling of the sequence number. ACK is handling the
sequence number.

> Or the order in which they're sent to the app?

You mean like URG data? I'm surprised URG hasn't been deprecated given
the inconsistent implementations.

So, I gather we'd have to add a constraint that the use of URG or
reordering options is incompatible with the use of a
post-syn-negotiated stateful option.

Otherwise, there's no ordering problem, right? The stack delivers data
to the app in order by sequence number and will have made all the data
in segments before the first X1 available to the app before the sender
sends the first X2.


>> After you see any packet with
>> X2, all subsequent packets have option X in effect regardless of the
>> presence of X1 or X2.
>
> Not packets sent before X was set at the source.

Excepting any late arriving duplicates (where the data will be
discarded), there's no way for the receiver to get a packet that was
sent before X was set at the source. The source confirmed that by
switching to setting X2 only after everything up to and including the
first X1 packet was acked.


>> 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.
>
> Options can add asynchronous information - which is how they're used
> now. They simply cannot add synchronized info - which is why they can't
> be used to negotiate new options - AFAICT.

By the way, I appreciate you bouncing this back and forth with me. I
don't doubt your conclusions but I find that trying to poke holes in a
conclusion is one of the more effective ways to learn the underlying
issues that brought it about.

Regards,
Bill Herrin


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