4.2.3 Outdated Timestamps

4.2.3 Outdated Timestamps

If a connection remains idle long enough for the timestamp
clock of the other TCP to wrap its sign bit, then the value
saved in TS.Recent will become too old; as a result, the PAWS
mechanism will cause all subsequent segments to be rejected,
freezing the connection (until the timestamp clock wraps its
sign bit again).

With the chosen range of timestamp clock frequencies (1 sec to
1 ms), the time to wrap the sign bit will be between 24.8 days
and 24800 days. A TCP connection that is idle for more than 24
days and then comes to life is exceedingly unusual. However,
it is undesirable in principle to place any limitation on TCP
connection lifetimes.

We therefore require that an implementation of PAWS include a
mechanism to "invalidate" the TS.Recent value when a connection
is idle for more than 24 days. (An alternative solution to the
problem of outdated timestamps would be to send keepalive
segments at a very low rate, but still more often than the
wrap-around time for timestamps, e.g., once a day. This would
impose negligible overhead. However, the TCP specification has
never included keepalives, so the solution based upon
invalidation was chosen.)

Note that a TCP does not know the frequency, and therefore, the
wraparound time, of the other TCP, so it must assume the worst.
The validity of TS.Recent needs to be checked only if the basic
PAWS timestamp check fails, i.e., only if SEG.TSval <
TS.Recent. If TS.Recent is found to be invalid, then the
segment is accepted, regardless of the failure of the timestamp
check, and rule R3 updates TS.Recent with the TSval from the
new segment.

To detect how long the connection has been idle, the TCP may
update a clock or timestamp value associated with the
connection whenever TS.Recent is updated, for example. The
details will be implementation-dependent.