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

[Joe Touch <[e-mail]>]

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



William Herrin wrote:
> On Mon, Nov 9, 2009 at 7:42 PM, Joe Touch <[e-mail]> wrote:
>>> Is there a good discussion on this somewhere so I can read up on the
>>> rationale that brought it into being?
>> Since it's an artifact, I don't think there is. The issue is that
>> unknown options are ignored (as per RFC1122). The only time when you can
>> find out if an option is supported in a way that you know will preceded
>> all other segments is to put it in the SYN.
>>
>> If you put it in a later segment, you don't know when the segment will
>> be received. Here's the problem, when A sends to B (assuming the
>> connection is already open):
>>
>>        A sends segment #223 with option X
>>                presuming this is the first segment A sends
>>                with option X
>>
>> Does A stop sending segments beyond 223 until option X is ACK'd? This
>> violates window processing. If A sends segment 224 with option X, and B
>> receives segment 224 before 223, it MUST ignore option X.
> 
> Hi Joe,
> 
> I'm missing something here. I would have expected TCP to hold segment
> 224 and not process it (except perhaps for selective ack or to
> retransmit 222's ack) until after 223 had been received and processed.
> In other words, unless the option was defined to be unordered, I'd
> expect the receiver to process it in the same order as the packet
> sequence numbers.

That requires that options are processed on the data after ordered, as
you note. However, TCP is an unordered protocol. So here's the catch.
Let's say you introduce option X in segment 224.

- - can you send it in 225, or does the protocol come to a grinding halt?

If this is the first option, you need to ACK it. But you can't ACK 225.

So first, until everything up to 225 is ACKd, you can't send 226.

And second, while that's happening the reciever can't ACK 225, because
224 might have an option that's incompatible with the one in 225. So the
transmitter keeps sending 225, and the receiver keeps ignoring it.

Ultimately, what you need is a separate sequence number space and
retransmission mechanism for these options, and rules for how they tie
to TCP's data path.

That's a HUGE, non-backward compatible change to TCP.

> That's not how TCP functions? The options are required to be processed
> in order received rather than ordered by sequence? 

Yes. Options are part of the control plane, and that's processed when
the segment is received - including ACKs. Data is passed up to the app
after reordering - it's only data that is queued.

> Or is it just that
> all options to date have been designed to be processed in the order
> received? I can see the point of doing that; I'm just trying to get a
> scope on the issue.

See above. Doing otherwise requires a sequence space that doesn't exist.

>> So you can't put in a new option that has a required effect or is
>> confirmed; there's no way to 'stop the stream' until the endpoints sync.
>> The only times the endpoints sync is during the SYN.
> 
> 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?

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

iEYEARECAAYFAkr43acACgkQE5f5cImnZrvVLACg/kQ0SrBx8JEELMQWYpODzo8m
vvQAoM+JpZ69JBm3IBP8BlVpWXKYh3gI
=+Jxu
-----END PGP SIGNATURE-----