Q & A on TCP These questions relate to TCP. Q: Suppose a TCP connection is made, used, and terminated. Then suppose a segment arrives for the connection. Will the extra segment confuse TCP? Does it matter whether the reset (RST) bit is set in the CODE BITS field of the segment? A: No. TCP is designed to handle duplicate and delayed segments. Once the connection is terminated, an incoming segment for that connection will have no effect. Furthermore, when TCP creates a new connection, it chooses a new sequence number (at random). Thus, even in the unlikely event that both the sender's and receiver's IP addresses and protocol port numbers match the old connection, the sequence number will not match. So, it doesn't matter whether the segment specifies reset, shutdown, urgent data, push, etc. -- TCP will reject the incoming segment before examining those bits. Q: The original TCP had a problem known as Silly Window Syndrome (described in volume I., p. 223 and 224), and a mechanism for the sending side was invented to solve it. Can you explain the problem and the solution? A: The problem consisted of a steady state in which a receiving TCP advertised available buffer space (i.e., a "window"), and the sender transmitted extremely small segments. It was named "silly window syndrome" because sending small segments results in very low throughput. A: The TCP standard specifies that a sending TCP use a mechanism known as "clumping" -- the sending TCP waits until it has either filled a segment or all outstanding acknowledgments have arrived before transmitting the segment. You can think of it as a form of "buffering." Q: Doesn't TCP allow a sending application to "push" data? Does that defeat the silly window avoidance mechanism? A: Yes, TCP allows a sending application to specify that data must be "pushed" immediately, without waiting. When an application requests TCP to push, TCP should send the data that has accumulated without waiting to fill the segment. Q: So, does that mean PUSH causes low throughput? A: A little. The clumping mechanism used to avoid silly window syndrome has precedence over push requests, so push does not cause silly window syndrome to start. However, the pushed data will be sent as soon as an acknowledgment arrives for all the data that has already been sent. Thus, it is possible for TCP to send a small amount of data, making throughput less than the maximum possible. Q: Why is PUSH allowed? A: Sometimes, throughput is not the goal. For example, consider remote login like TELNET. The TELNET application needs to send each keystroke immediately after the user enters it, without waiting to buffer multiple keystrokes. (Imagine trying to use remote login if TELNET waited until you made 1000 keystrokes before transmitting them in a segment!) Consequently, TELNET issues a "push" after each character. Q: What does waiting for acknowledgments have to do with clumping? A: It's a tricky way to determine how long to wait. If TCP is operating across a LAN, acknowledgments come back quickly, meaning that the sender will not have accumulated much data. However, sending small packets is OK in a LAN because a LAN has both high throughput and low delay. If TCP is operating across an internet to a distant host, however, the delay will be greater. In that case, the sender will wait longer to fill a segment, resulting in fewer packets and better throughput. Such schemes are called "self-clocking" -- instead of building a set of assumptions into TCP, such schemes allow TCP to adjust automatically to the conditions in the Internet and to use more clumping when delays are longer.