Chapter 24

24.1	What does it mean when a system sends an initial SYN segment with a window scale factor of 0?
A:	It means the sending TCP supports the window scale option, but doesn't need to scale its window for this connection. The other end (that receives this SYN) can then specify a window scale factor (that can be 0 or nonzero).
24.2	If the host `bsdi` in Figure 24.7 supported the window scale option, what is the expected value of the 16-bit window size field in the TCP header from `vangogh` in segment 3? Similarly, if the option were in use for the second connection in that figure, what would be the advertised window in segment 13?
A:	64000: the receive buffer size (128000) right shifted 1 bit. 55000: the receive buffer size (220000) right shifted 2 bits.
24.3	Instead of fixing the window scale factor when the connection is established, could the window scale option have been defined to also appear when the scaling factor changes?
A:	No. The problem is that acknowledgments are not reliably delivered (unless they're piggybacked with data) so a scale change appearing on an ACK could get lost.
24.4	At what data rate does sequence number wrap become a problem, assuming an MSL of 2 minutes?
A:	2 ³² — 8 / 120 equals 286 Mbits/sec, 2.86 times the FDDI data rate.
24.5	PAWS is defined to operate within a single connection only. What modifications would have to be made to TCP to use PAWS as a replacement for the 2MSL wait (the TIME_WAIT state)?
A:	Each TCP would have to remember the last timestamp received on any connection from each host. Read Appendix B.2 of RFC 1323 for additional details.
24.6	In our example at the end of Section 24.4, why did our `sock` program output the size of the receive buffer before the line that followed (with the IP addresses and port numbers )?
A:	The application must set the size of the receive buffer before establishing the connection with the other end, since the window scale option is sent in the initial SYN segment.
24.7	Redo the calculations of the throughput in Section 24.8 assuming an MSS of 1024.
A:	If the receiver ACKs every second data segment, the throughput is 1,118,881 bytes/sec. Using a window of 62 segments, with an ACK for every 31 segments, the value is 1,158,675.
24.8	How does the timestamp option affect Karn's algorithm (Section 21.3)?
A:	With this option the timestamp echoed in the ACK is always from the segment that caused the ACK. There is no ambiguity about which retransmitted segment the ACK is for, but the other part of Karn's algorithm, dealing with the exponential backoff on retransmission, is still required.
24.9	If TCP sends data with the SYN segment that's generated by an active open (without using the extensions we described in Section 24.7), what does the receiving TCP do with the data?
A:	The receiving TCP queues the data, but it cannot be passed to the application until the three-way handshake is complete: when the receiving TCP moves into the ESTABLISHED state.
24.10	In Section 24.7 we said that without the T/TCP extensions, even if the active open is sent with data and a FIN, the client delay in receiving the server's response is still twice the RTT plus SPT. Show the segments to account for this.
A:	Five segments are exchanged: Client to server: SYN, data (request), and FIN. The server must queue the data as described in the previous exercise. Server to client: SYN and ACK of client's SYN. Client to server: ACK of server's SYN and client FIN (again). This causes the server to move to the ESTABLISHED state, and the queued data from segment 1 is passed to the server application. Server to client: ACK of client FIN (which also acknowledges client data), data (server's reply), and server's FIN. This assumes that the SPT is short enough to allow this delayed ACK. When the client TCP receives this segment, the reply is passed to the client application, but the total time has been twice the RTT plus the SPT. Client to server: ACK of server's FIN.
24.11	Redo Exercise 18.14 assuming T/TCP support and the minimum RTO supported by Berkeley-derived systems of one-half second.
A:	16,128 transactions per second (64,512 divided by 4).
24.12	If we implement T/TCP and measure the transaction time between two hosts , what can we compare it to, to determine its efficiency?
A:	The transaction time using T/TCP cannot be faster than the time required to exchange a UDP datagram between the two hosts. T/TCP should always take longer, since it still involves state processing that UDP doesn't do.