To assist in the identification and recovery of lost packets, the receiver in TCP-SC returns an ACK Window to the sender to indicate any holes in the received sequential stream. The ACK Window is similar to the bit vectors used in previous protocols, such as NETBLT [4] and TCP-SACK [5][15]. Unlike TCP-SACK [5][15], our approach provides a new mechanism whereby the receiver is able to report the status of every packet within the current transmission window.1 The ACK Window is maintained as a vector in which each bit represents the receipt of a specified number of bytes beyond the cumulative acknowledgment. The receiver determines an optimal granularity for bits in the vector and indicates this value to the sender via a one-byte field in the header. A maximum of 19 bytes are available for the ACK window in order to meet the 40-byte limit of the TCP option field in the TCP header. The granularity of the bits in the window is bounded by the receiver's advertised window and the 19 bytes available for the ACK window; this can accommodate a 64K window with each bit representing 450 bytes. Ideally, a bit in the vector would represent the MSS of the connection, or the typical packet size. Note this approach is meant for data intensive traffic, therefore bits represent at least 50 bytes of data. If there are no holes in the expected sequential stream at the receiver, then the ACK window is not generated.
Figure 7 shows the transmission of five packets, three of which (1,3, and 5) are lost and are shown in grey. The packets are of variable size and the length of each is indicated by a horizontal arrow. Each bit in the ACK window represents 50 bytes with a 1 if the bytes are present at the receiver and a 0 if they are missing. Once packet #2 is recovered, the receiver would generate a cumulative acknowledgment of 1449 and the bit vector would indicate positive acknowledgments for bytes 1600 through 1849. There is some ambiguity for packets 3 and 4 since the ACK window shows that bytes 1550 - 1599 are missing. The sender knows that this range includes packets 3 and 4 and is able to infer that packet 3 is lost and packet 4 has been received correctly. The sender maintains the information returned in the ACK Window, flushing it only when the window advances. This helps to prevent the unnecessary retransmission of correctly received packets following a timeout when the session enters slow start.