1. Introduction
Over the years and the need to expand networks, TCP has required adjustments to keep up with these advances. One of the adjustments designed was the Timestamp Option, which improves the protocol’s performance by providing valuable temporal information.
In this tutorial, we’ll explore the benefits of using TCP Timestamps and their applications. Both are defined by RFC 7323.
2. TCP Receiving Window Challenges
The size of the receive window initially designed for the TCP was unable to satisfy the demands of the new technologies. Hence, they implemented the Window Scale Option to enable larger windows.
However, the use of large receive windows can induce other problems. One type of error is the reuse of TCP sequence numbers in data segments. This can happen in two ways:
- In the case of segment delays, a sufficiently high throughput within the same session can cause the 32-bit TCP sequence number to cycle.
- In cases where a closes and reopens a connection, it may happen that a segment from the previous connection that’s delayed falls into the current window and is accepted as valid.
3. The Function of TCP Timestamp
To solve these new challenges, the protocol needed to have a notion of time, which led to the implementation of the TCP Timestamp Option (TSopt).
TSopt contains two timestamp fields: TSval and TSecr. The TSval field contains the current timestamp value of the TCP starting the connection or sending the option. The TSecr field echoes the value recently received by the TSval field. The TSecr field is valid only if the ACK bit is set in the TCP header. Both field values have no direct relationship.
We’ve to negotiate the TSopt during the initial handshake process. So, the sender forwards an initial segment (SYN) containing a symbolic timestamp value via the TSval field. When forwarding the reply (SYN, ACK), this same field must also contain a symbolic timestamp of the receiver. Also, the TSecr field must echo the value of the timestamp received from the sender. The connection will fail if the value in this field differs from the value sent by the initial SYN.
Each side of the connection provides an increasing value of 4 bytes in its respective field. That’s, the value in the TSval field on each side increases continuously for as long as the connection persists. The values from the opposite side have no real meaning for the recipient. It just echoes to the original sender.
Once this process is complete, with the exception of the RST segments, all other segments must contain information equivalent to the option. If TCP receives any segments without the expected TSopt or with arbitrary values, it ignores them. With the exception of the initial handshake, TCP shouldn’t abort the connection in cases where the segment doesn’t have the expected TSopt value.
4. Main Benefits
We can solve Case 2 mentioned above by applying a Maximum Segment Life from the TCP specification. However, this mechanism isn’t enough for Case 1. For that, they proposed the PAWS (Protection Against Wrapped Sequence Numbers) scheme, which discards segments arriving with old timestamps and eliminates the problem of duplicates.
TCP can only use the PAWS scheme if the TSopt is enabled. In simple terms, PAWS assumes that received TCP segments, whether data or ACK, contain a timestamp whose values increase with time. This means that when the system receives a segment with a lesser timestamp than one recently received on the same connection, it’ll discard it as an old duplicate.
To perform the check, store the value of the most recent timestamp in the TS.Recent field. Since these are 32-bit unsigned integer values, the same techniques used to define TCP sequence numbers determine “less than”. In other words, if 
and 
are timestamp values, 
if 0 < (
) < 
. This ensures that the input timestamps saved and consequently delivered to the layer above have monotonically non-decreasing values.
It’s important to note that the PAWS subjects all received segments to the same test. Also, the receiver only carries out this check the first time the segment arrives, even if it’s in the correct sequence or requires queuing for later delivery.
Another benefit of the TSopt is the possibility of measuring packets’ round-trip time (RTTM). This estimate helps to adapt to changes in traffic conditions. It also serves as the basis for calculating the Retransmission Timeout (RTO). Basically, RTTM calculates an average time difference between a packet sent and the confirmation received:
The example above shows that the first segment sent has a value of 0 in TSecr. This is because the sender doesn’t have a value to echo at the start of the connection. However, when sending it again, it echoes the most recent timestamp value received.
On the other hand, the receiver already holds the value to echo in the first forwarded segment. We can observe the sender’s time progressing, so when the acknowledgment echoes the value, it’ll process it, and then calculate the RTTM, which in this example is 12 milliseconds (8510-8522=12). The same happens with the receiver in the last 2 segments, where the estimated time is 15 milliseconds.
5. Conclusion
In this article, we studied the benefits of using the TCP timestamp. We’ve seen that by using TSopt, we can prevent spurious segments from affecting communication and also obtain estimates of network performance. Finally, TCP timestamps and their applications are fundamental in optimizing network communications.