Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[Joe Touch <[e-mail]>]

On 9/26/2014 11:29 AM, John Leslie wrote:
> Joe Touch <[e-mail]> wrote:
>> On 9/26/2014 7:50 AM, John Leslie wrote:
>>
>>> For any Experimental-status document, I recommend:
>>>
>>> - that the various on-the-wire formats be kept as similar as possible;
>>
>> I disagree; there's no reason for that.
> 
>    "As possible" to be intepreted liberally...

That imposes a goal that will require cycles to resolve, one that serves
no purpose unless the two options converge naturally.

>>> - that any acknowledgment of extra option space in an initial SYN
>>>   include a checksum or hash of the extra options to ensure that both
>>>   ends have the same view of what options have been signaled;
>>
>> Disagree. Options are ACKd by confirming the options - not by merely
>> sending an ACK.
> 
>    No thanks! _This_ option deserves its own confirmation. We're putting
> options in a funny place -- any number of things could go wrong with
> that. :^(

If the extension works, then you have the extension place in which to
send option confirmation. The extension itself clearly needs to be
confirmed too - like any other options. I don't see the reason for a hash.

...
>>> - that any timing questions be specifically explored as part of the
>>>   experiment. (This includes _whether_ there should be any overlap
>>>   between the experimental SYN and the legacy SYN.)
>>
>> Yes.
>>
>>> - that an explicit allocation of one (or more, possibly) dedicated
>>>   option number be requested from IANA.
>>
>> These can and IMO should use the experimental option IDs until we're
>> ready to move forward.
> 
>    Absolutely. I only meant when we issue a formal Experimental RFC.

It depends on the experiment. The ExID is intended for the potential to
use an option in the public that we might not end up keeping.

>>> The question of separating payload data to go to the application
>>> from extended TCP options clearly requires action by the SYN receiver.
>>> This is fairly simple if the SYN sender can ensure that _none_ of the
>>> payload data should go to the application (and thus not use fastopen
>>> at all): of course the connection must still be aborted if the SYN
>>> receiver doesn't acknowledge separating out the extended options.
>>
>> I don't think that's tenable.
> 
>    What specifically isn't tenable?

I don't think we should declare that SYNs don't have data.

>> SYNs have always been able to include data.
> 
>    Indeed! That by itself complicates things.

But we should allow it.

>> Fastopen just helps that data get to the user faster.
> 
>    Specifically, fastopen (when used) removes the opportunity to abort
> before the application sees the payload data.
> 
>    With 20/20 hindsight, it's obvious that fastopen would have been
> better if it included a byte-count of data to pass to the application
> before the three-way-handshake completes.

TCP is a bytestream protocol. Even with the PSH bit, there's no
guarantee of that boundary anyway.

Joe