Re: [tcpm] RFC 1323: Timestamps option

A difficulty with the suggested enabling mechanism for Option #2 is
that a major TCP stack already (mis)behaves in a similar way for current
TCP connections.

> Option #2
> ---------
...
> The question then is, how do you negotiate Timestamps without turning  
> them on?  My suggestion would be to send a Timestamps option with the  
> special format TSval=0,TSecr=0.  If you receive this in a SYN, then  
> the request is to negotiate knowledge of the Timestamps option.  The  
> returning SYN,ACK would also need to contain TSval=0,TSecr=0 to  
> complete the negotiation.

The Windows TCP stack currently replies SYN,ACK TSval=0,TSecr=0 to a
regular SYN TSval=xxx,TSecr=0.

So if you send SYN TSval=0,TSecr=0, and get back SYN,ACK TSval=0,TSecr=0
you may be talking to a TCP stack that understands the new enabling
semantics, or a Windows TCP stack that does not.

You could argue this does not really matter, as the Windows TCP stack
will go on using Timestamps (I presume), immediately enabling it on the
fly under the new semantics, so in the end all is fairly well (except
Windows TCP may be sent a few segments with no Timestamps that it does
not expect, until on the fly enabling is completed).  However I don't
think this confusing situation is desirable.

I think Windows TCP behaves in this way because it does not create a
full TCP state block until after SYN,ACK processing, so has nowhere
to record the initial TSvals.  If we are updating RFC1323, I wonder if
this Windows behaviour should be explicitly allowed, since in practice
we have to allow for it now, and it has some merit.

Trying to find legitimacy for the Windows TCP behaviour, it could
be said that 3.2 of RFC1323 wasn't entirely clear in this regard.
It says "When TSecr is not valid, its value must be zero." - I can
conceive of this being understood (out of context) as meaning: if you
do not have a valid TSecr available for some reason, then send a zero;
an interpretation that would permit the Windows TCP behaviour, and make
the suggested enabling mechanism ambiguous.

	Richard
-- 
Richard Wendland				richard@codeburst.co.uk

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm