Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt)

[Joe Touch <[e-mail]>]

On 6/2/2014 10:50 AM, Mark Allman wrote:
>
>> Late negotiation has too many problems, as have been repeatedly
>> raised on this list:
>>
>> 	- prevents use of the timestamp to help address PAWS for
>> 	the initial SYN
>
> In the limit you're right that it is better to have a stronger
> indication that the arriving SYN / SYN+ACK is not way old.  It is hard
> to argue against such an ideal.  But, we run a whole bunch of
> connections without timestamps today and it doesn't seem to have caused
> us a whole bunch of problems.  So, while I can see your point I think it
> is pretty esoteric.
>
> Also, I'd like to know if OSes actually do consult the TS value in the
> 3WHS to try to hunt for old packets.  I have no idea.  Does anyone know?
> (Either answer wouldn't surprise me, actually.)

The TWHS establishes the TS for the new connection, which means old 
packets will be seen as old and discarded by TS processing.

>> 	- a new connection that either avoids TS in SYN or
>> 	uses just "use TS" (two-byte) flag can't know when
>> 	to engage the timestamp and what initial value to use
>
> This is just bogus.  On both counts.

FWIW, I'm saying that receiver has these problems. You're correct that 
the first TS value in an *acked* segment should be the one used and that 
the sender can know when to turn it on.

However, what if the receiver doesn't support TS at that point? How does 
it say so? At the least, TS-capable must be negotiated during the TWHS.

One question is - how many connections use TS that don't expect to use 
long connections or large numbers of connections where the sequence 
number wrap is an issue?

Joe