Connected: An Internet Encyclopedia
3.4 Which Timestamp to Echo

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1323
Up: 3. RTTM: ROUND-TRIP TIME MEASUREMENT
Prev: 3.3 The RTTM Mechanism
Next: 4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS

3.4 Which Timestamp to Echo

3.4 Which Timestamp to Echo

If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block.

There are three situations to consider:

  1. Delayed ACKs.

    Many TCP's acknowledge only every Kth segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver should reply with the TSval field from the earliest unacknowledged segment.

  2. A hole in the sequence space (segment(s) have been lost).

    The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit").

    The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window.

    The same situation occurs if segments are re-ordered by the network.

  3. A filled hole in the sequence space.

    The segment that fills the hole represents the most recent measurement of the network characteristics. On the other hand, an RTT computed from an earlier segment would probably include the sender's retransmit time-out, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) must be echoed.

An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection:

  1. The connection state is augmented with two 32-bit slots: TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when ACKs have been delayed.

  2. If Last.ACK.sent falls within the range of sequence numbers of an incoming segment:

                  SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
    

    then the TSval from the segment is copied to TS.Recent; otherwise, the TSval is ignored.

  3. When a TSopt is sent, its TSecr field is set to the current TS.Recent value.

The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity.


Next: 4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS

Connected: An Internet Encyclopedia
3.4 Which Timestamp to Echo