Assume that a 64 KB-per-second satellite link is being used between the two end points. It is possible for one system to transmit all 64 KB of data long before the first byte has arrived. As such, it would have to stop transmitting data, and wait for an acknowledgment from the destination system. Once an acknowledgment arrived, the sender could resume transmitting, only to have to stop again a moment later.

For this reason, RFC 1072 defined a TCP option called Window Scale, which lets a system advertise 30-bit Window values, with a maximum buffer size of 1 GB. This option has been clarified and redefined in RFC 1323, which is the spec that all implementations employ.

The Window Scale option provides a 14-bit "left-shift" value in the option's data field. This value defines the number of bit places that the 16-bit value advertised in the Window field should be moved to the left, letting the receiver advertise up to 30 bits. For example, the "Window Scale" figure (below) shows a 16-bit Window advertisement of 64 KB, but with a two-bit shift being proposed in the Window Scale option. These two new bits are appended to the right edge of the 16 bits provided in the Window field, resulting in 18 bits total (or 256 KB of buffer space).

Using a 256-KB buffer would allow the 64-KB-per-second link described previously to exchange data smoothly--the sender would get through the first 128 KB and then receive an acknowledgment for the first few bytes, allowing the sender to continue forwarding data at a constant and smooth rate.

To use this option, however, both systems must provide the Window Scale option in the TCP "synchronize" segments they exchange during circuit setup. If the Window Scale option is not provided--or if the Window Scale option is provided but a value of zero is advertised--the Window field must be taken at face value.

The shift value is "0," which means that the Windows98 stack understands the Window Scale option, and will implement it if a shift value is provided by the remote Solaris 7 system. However, the "0" also indicates that the Windows98 stack is not actually suggesting a shift value for itself, so the remote endpoint has to use the provided Window value for any data it sends back to the Windows98 system.

Timestamp Another aspect of TCP's flow-control and reliability services is the round-trip delivery times that a virtual circuit is experiencing. In particular, the round-trip delivery time will determine how long TCP will wait before attempting to retransmit a segment that has not been acknowledged.

Because every network has unique latency characteristics, TCP has to understand these characteristics in order to set accurate acknowledgment timer threshold values. LANs typically have very low latency times, and as such TCP can use low values for the acknowledgment timers. If a segment is not acknowledged quickly, a sender can retransmit the questionable data quickly, thereby minimizing any lost bandwidth. However, using a low threshold value on a WAN is sure to cause problems because the acknowledgment timers likely will expire before the original data ever reaches the destination.

Therefore, in order for TCP to accurately set the timer threshold value for a virtual circuit, it has to measure the round-trip delivery times for various segments. Furthermore, it has to monitor additional segments throughout the connection's lifetime to keep up with changes in the network.

Although the use of these two algorithms is mandated in RFC 1122 (an update to the IP and TCP specifications), the implementation details for these algorithms were never standardized. These features are now provided by RFC 1323, however, which offers a timestamp option that can be used by the two end points to exchange stop-watch markers inside the existing TCP data segments.

It's important to note that the data provided in the timestamp field is only used by the system that wrote the data into the field in the first place. The Timestamp option is not meant to provide any form of time synchronization. Rather, it is meant to act as a simple stopwatch for each system, allowing them to measure the amount of time required to send and receive a segment across a particular network.