However, the Timestamp field used for Windows98's round-trip calculations probably shouldn't be set to zero, but rather should reflect the local system's actual clock. It is unclear why Microsoft has chosen to seed the initial timestamp field with zero, rather than using the local system clock for this purpose as specified in RFC 1323.

Although both systems must send the Timestamp option during the initial handshake sequence to enable its use, this option can also be used (and should be used) with any subsequent segment that is sent during the lifetime of the connection. The screen at right shows the Timestamp option being repeated, with the Windows98 system putting another (higher) value in the Timestamp field, and returning the value it received from the Solaris 7 host's Timestamp option in the Timestamp Reply field.

Selective Acknowledgments One of the more common complaints about TCP is that it uses a cumulatively implicit acknowledgment scheme (as opposed to an explicit one), suggesting that all data up to the sequence number specified in the Acknowledgment Identifier field has been received. Once a sender has received an acknowledgment, it can assume that all data sent to that point has been received successfully. Conversely, if a sender receives multiple acknowledgments for the same byte of data, then it must assume that any data sent after that point has been lost.

Although this works very well when data is flowing smoothly, the lack of a detailed acknowledgment scheme prevents quick recovery when one segment from a batch is lost in transit. There are no mechanisms for a receiver to state "I'm still waiting for bytes N through P, but have received bytes Q through Z." If segments arrive out of order and there's a hole in the receiver's queue, the only thing it can do is keep saying "I got everything up to N." The sender has to recognize that the presence of multiple duplicate acknowledgments indicates a problem, and then resume transmitting data from that point.

To provide for more robust recovery services, RFC 1072 specified a selective acknowledgment mechanism. This work was expanded upon and enhanced in RFC 2018, which is the specification used by Windows98 and other implementations. The two options defined in RFC 2018 are Selective Acknowledgments Permitted, which is used in the Synchronize segments sent during the handshake sequence, and the Selective Acknowledgment option, which is sent whenever a selective acknowledgment is required, as shown on at right.

The Selective Acknowledgment option is used to supplement the existing Acknowledgment Identifier field that is present in every TCP header. If a recipient has a hole in the data it has received, it issues a segment with the Acknowledgment Identifier field pointing to the last cumulative byte of data received, while the Selective Acknowledgment option points to any additional blocks of data that it has also received after the missing data.

The original sender of the data can then examine the Acknowledgment Identifier field and the Selective Acknowledgment option, determine which block of data was lost in transit and then send only that segment, resuming transfer from the high watermark specified by the Selective Acknowledgment option.

For example, in the screen below, you can see that the Windows98 client is still waiting for byte 4,228,994,268. But the Selective Acknowledgment option shows that the Windows98 client has also received bytes 4,228,997,080 through 4,228,998,486. Therefore, it is missing bytes 4,228,994,268 through 4,228,997,079, so the Solaris 7 host should only resend the missing 2,810 bytes, rather than restarting the entire transfer at byte number 4,228,994,268.

When lost data is a problem (due to congestion or link failure), the use of the Selective Acknowledgment option can help quickly recover the data transfer. And, when combined with the Timestamp and Window Scale options, TCP virtual circuits can perform substantially better than they could in the past, particularly when used with slow and problematic links.

Eric A. Hall is president of EHS Co., a network technology research and testing firm in San Mateo, Calif. Send your comments on this article to him at ehall@ehsco.com.