Chapter 20

20.1	In Figure 20.6 we could have shown a byte numbered 0 and a byte numbered 8193. What do these 2 bytes designate ?
A:	Byte number 0 is the SYN and byte number 8193 is the FIN. The SYN and FIN each occupy 1 byte in the sequence number space.
20.2	Look ahead to Figure 22.1 and explain the setting of the PUSH flag by the host `bsdi` .
A:	The first application write causes the first segment to be sent with the PUSH flag. Since BSD/386 always uses slow start, it waits for the first ACK before sending any more data. During this time the next three application writes occur, and the sending TCP buffers the data to send. The next three segments do not contain the PUSH flag since there is more data in the buffer to send. Eventually slow start catches up with the application writes and every application write causes a segment to be sent, and since that segment is the last one in the buffer, the PUSH flag is set.
20.3	In a Usenet posting someone complained about a throughput of 120,000 bits/sec on a 256,000 bits/sec link with a 128-ms delay between the United States and Japan (47% utilization), and a throughput of 33,000 bits/sec when the link was routed over a satellite (13% utilization). What does the window size appear to be for both cases? (Assume a 500-ms delay for the satellite link.) How big should the window be for the satellite link?
A:	Solving the bandwidth-delay equation for the capacity, it is 1,920 bytes for the first case, and 2,062 for the satellite case. It appears that the receiving TCP is only advertising a window of 2,048 bytes. A window greater than 16,000 bytes should be able to saturate the satellite link.
20.4	If the API provided a way for a sending application to tell its TCP to turn on the PUSH flag, and a way for the receiver to tell if the PUSH flag was on in a received segment, could the flag then be used as a record marker?
A:	No, because TCP can repacketize data after a timeout, as we'll see in Section 21.11.
20.5	In Figure 20.3 why aren't segments 15 and 16 combined?
A:	Segment 15 is a window update sent automatically by the TCP module as a result of the application reading data, which causes the window to open . This is similar to segment 9 in that figure. Segment 16, however, is a result of the application closing its end of the connection.
20.6	In Figure 20.13 we assume that the ACKs come back nicely spaced , corresponding to the spacing of the data segments. What happens if the ACKs are queued somewhere on the return path , causing a bunch of them to arrive at the same time at the sender?
A:	This can cause the sender to inject packets into the network at a rate faster than the network can really handle. This is called ACK compression or ACK smashing [Mogul 1993, Sec. 15.8.13]. This reference indicates that ACK compression occurs on the Internet, although it rarely leads to congestion.