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

[Joe Touch <[e-mail]>]

On 9/26/2014 7:50 AM, John Leslie wrote:
...
>    Hopefully I don't need to draw attention to draft-touch-tcpm-edo.
> This seems to be moving towards consensus on how to increase the option
> space on every packet _after_ the initial SYN.
> 
>    Thus, in most cases, for today's traffic there is little need to
> worry about extending the option space in the initial SYN. There seems
> to be plenty of time to experiment...

I don't know if the need is as small, but I agree that experimentation
is needed to proceed.

...
>    I agree with Bob that we don't need formal Experimental status to
> test how often an OOB packet will fail to pass a middlebox.

Agreed; that's on our to-do list.

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

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

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

>    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. SYNs have always been able to include
data. Fastopen just helps that data get to the user faster.

Joe