[tcpm] RE: RFC 1323: Timestamps option

["Mahdavi, Jamshid" <[e-mail]>]

Just to echo some of the comments from Matt and Mark, I've always felt that the overhead of 12 bytes per packet (and ACK) was pretty unbearable and usually recommend for turning off timestamps if that is possible in an application.

Clearly, we need some solution for PAWS, and I think the comments about turning on timestamps based on rate or volume of data sent in those cases make good sense, so I'd be in favor of that.

For the cases where you don't need timestamps for PAWS, why not simply allow a host to transmit a timestamp option whenever it wants to measure the RTT?  Then hosts would have the freedom to use timestamps at whatever rate they feel is best.  Having read some of the comments about frequency of measurements, it occurs to me that it might actually be better to do one measurement per fixed unit of time (say, once per second) rather than once per packet or once per RTT.  I don't think there would be any reason to think that variability of network delay would be correlated to RTT; it seems much more likely to be correlated to fixed constants in the network (like routing protocol update intervals) or fixed constants in the real world (like business hours).

Of course, from my point of view the advantage to this is that you'd be adding 24 bytes per second (or whatever the chosen interval is) to the data transmitted rather than 18 bytes per packet (taking into account delayed ACK) which is more than 1% additional overhead for fairly nebulous benefit.

I realize this suggestion would probably require a more significant change to the operation of the timestamp option, but I think it would be worthwhile.

--J

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm