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

[John Leslie <[e-mail]>]

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 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. :^(

   (But, of course, the individual options in the extended option space
should get their own confirmations.)

>> - 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.

>> 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?

> SYNs have always been able to include data.

   Indeed! That by itself complicates things.

> 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.

--
John Leslie <[e-mail]>