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

[Mark Allman <[e-mail]>]

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

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

(1) A TCP can in fact know when it should engage because it can in fact
    gauge its sending rate and relate that to the MSL.  And, if that is
    too complicated for a TCP to do---and it strikes me as such---then
    the TCP can turn it on when it approaches sequence wrap for the
    first time (i.e., sending 4GB of data).

(2) I don't see how the initial value we use here is different from the
    initial value we use at the beginning of a connection.  

Do we have to account for sending a TS mid-stream and it not being
supported by the other end?  Sure.  It seems the answer is to ensure the
sending rate is less than 4GB/MSL.  Is that extra work?  Sure.  Is it
worth it to save a wad of useless bytes in lots of packets on the
Internet?  That is a judgment call where reasonable people could
disagree, I guess.

allman