4.2 Using the Echo Options

If we wish to use the Echo/Echo Reply options for RTT measurement, we have to define what the receiver does when there is not a one-to-one correspondence between data and ACK segments. Assuming that we want to minimize the state kept in the receiver (i.e., the number of unprocessed Echo options), we can plan on a receiver remembering the information value from at most one Echo between ACKs. 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 ACK's". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACK's, or else it will retransmit unnecessarily. Thus, when delayed ACK's are in use, the receiver should reply with the Echo option information 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 we may be generating ACKs as these out-of-order segments arrive (e.g., for the SACK information or to aid "fast retransmit"). An Echo Reply option will tell the sender the RTT of some recently sent segment (since the ACK can only contain the sequence number of the hole, the sender may not be able to determine which segment, but that doesn't matter). If the loss was due to congestion, these RTTs may be particularly valuable to the sender since they reflect the network characteristics immediately after the congestion.

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.

Case (1) suggests the receiver should remember and return the Echo option information from the oldest unacknowledged segment. Cases (2) and (3) suggest that the option should come from the most recent unacknowledged segment. An algorithm that covers all three cases is for the receiver to return the Echo option information from the newest segment with the oldest sequence number, as specified earlier.

A model implementation of these options is as follows.

1. Receiver Implementation

   A 32-bit slot for Echo option data, rcv.echodata, is added to the receiver connection state, together with a flag, rcv.echopresent, that indicates whether there is anything in the slot. When the receiver generates a segment, it checks rcv.echopresent and, if it is set, adds an echo-reply option containing rcv.echodata to the outgoing segment then clears rcv.echopresent.

   If an incoming segment is in the window and contains an echo option, the receiver checks rcv.echopresent. If it isn't set, the value of the echo option is copied to rcv.echodata and rcv.echopresent is set. If rcv.echopresent is already set, the receiver checks whether the segment is at the left edge of the window. If so, the segment's echo option value is copied to rcv.echodata (this is situation (C) above). Otherwise, the segment's echo option is ignored.

2. Sender Implementation

   The sender's connection state has a single flag bit, snd.echoallowed, added. If snd.echoallowed is set or if the segment contains a SYN, the sender is free to add a TCP Echo option (presumably containing the current time in some units convenient to the sender) to every outgoing segment.

   Snd.echoallowed should be set if a SYN is received with a TCP Echo option (presumably, a host that implements the option will attempt to use it to time the SYN segment).