Summary

  • Silly Window Syndrome is a feedback pattern in which small window advances keep producing small TCP segments long after the first small boundary has passed.
  • TCP avoids the pattern by making the receiver delay small window updates and the sender delay inefficient sends, while an override timer prevents restraint from becoming deadlock.

Suppose a receiving application consumes only a few bytes from a nearly full buffer. Its TCP now has a few bytes of real space. It could advertise that space at once, and the sender would be entitled to fill it. When those few bytes arrive and are consumed, the same amount becomes available again. A perfectly valid window update has created a perfectly valid small segment, whose progress invites another update of the same size. Nothing is broken packet by packet. The trouble is the rhythm they form.

David Clark's RFC 813 gave that rhythm a name in 1982: Silly Window Syndrome. The memo did not define SWS as any isolated small packet. It described a stable degeneration in a long transfer, one in which the stream becomes divided into small pieces and cannot naturally recombine. The network carries more headers and acknowledgements for the same useful data; hosts perform more protocol work; loss and retransmission can compound the damage. RFC 813 reported historical cases in which the average segment was one tenth of the size the endpoints could handle and retransmissions multiplied.

Those observations belong to that period, not to every modern network, but they made the mechanism impossible to dismiss as cosmetic inefficiency.

The important distinction was between the window a receiver offers and the window a sender can actually use. If the receiver advertises 1,000 bytes while 950 bytes remain unacknowledged, the sender has only 50 usable bytes. Send those 50, receive an acknowledgement that advances the right edge by another 50, and the next usable allowance is again 50. A natural boundary—perhaps the end of a pushed unit—can split an otherwise efficient allocation. Thereafter, acknowledgement and window arithmetic reproduce the fragment.

RFC 813's receiver-side answer was counterintuitive only if every available byte had to be announced immediately. After the application freed a small amount, the receiver could keep the advertised right edge fixed. It would account for the space locally but withhold it from the sender. Once enough space had accumulated, it would advance the window in one useful jump. Waiting too long might briefly empty the pipeline and cost time. Opening too frequently could consume bandwidth and CPU while also cutting throughput.

Clark argued that an implementation should err toward restraint and make each reopening large enough for a reasonably substantial segment.

RFC 1122 turned the lesson into paired host requirements. Section 4.2.3.3 required an SWS avoidance algorithm in the receiver. Its suggested rule holds RCV.NXT + RCV.WND fixed until the unadvertised space reaches the smaller of two thresholds: a fraction of the receive buffer or one effective send MSS. The recommended fraction is one half. For realistic buffers, the practical effect is often to open the window by roughly one segment rather than byte by byte.

The sender also has to refuse invitations that are legal but inefficient. RFC 1122 §4.2.3.4 required a sender-side SWS avoidance algorithm and recommended sending when one of four conditions is met: a full-sized segment fits; pushed data can all be sent under the stated conditions; at least one half of the maximum observed window can be used; or an override timer expires. The sender therefore treats a small usable window as permission that may prudently wait, not as an instruction that must be exercised immediately.

That algorithm contains an uncertainty the receiver does not face. The receiver knows its buffer size; the sender does not. It can use the largest send window observed on the connection as an estimate of receiver capacity, but the estimate may become stale if the receiver changes its buffer. A rule that waited forever for a fraction of an obsolete maximum could deadlock. The override timer is the escape hatch: batching improves efficiency, but eventually the sender transmits despite the batching rule.

RFC 9293 retains a recommended range of 0.1 to 1.0 seconds for that override, while leaving actual implementation behavior outside what these sources prove.

The modern consolidated TCP specification preserves both obligations. RFC 9293 says implementations must include SWS avoidance in the sender and in the receiver. It also preserves a distinction often blurred in shorthand explanations. The Nagle algorithm discourages tiny segments when an application supplies data in small increments. Sender SWS avoidance discourages tiny segments caused by the receive window's right edge advancing in small increments. They can cooperate, but they answer different causes.