RFC 813
HISTORIC · IDEAS LIVE ONWindow and Acknowledgement Strategy in TCP
David D. Clark (MIT LCS) · July 1982 · original status: Unknown (pre-standards-track memo) · current status: Historic
obsoleted by: RFC 7805
Historic (reclassified by RFC 7805) — but its ideas won: SWS avoidance and delayed ACKs became mandatory host behaviour in RFC 1122 and live on in RFC 9293. This module teaches the problem from the original memo and the rules from the current standards.
This module teaches BOTH the historical problem and today's rules
This document
- RFC 813 §2 — the Silly Window Syndrome
- RFC 813 §3 — improved window algorithms (receiver side)
- RFC 813 §4 — improved acknowledgement strategies (delayed ACK)
- RFC 813 §5 — sender-side SWS avoidance
Where the current rules live
- RFC 9293 §3.8.6.2.1 — sender SWS avoidance (MUST)
- RFC 9293 §3.8.6.2.2 — receiver SWS avoidance (MUST)
- RFC 1122 §4.2.3.2 — delayed ACK (SHOULD; delay < 0.5 s, ACK ≥ every 2nd full segment)
Window & Acknowledgement Strategy (Silly Window Syndrome)
New to these ideas? Switch to the beginner level for a from-zero concept primer.
The problem this document answered
A receiver that advertises every tiny buffer opening invites the sender to fill exactly that crumb; the buffer then opens by another crumb, and the connection locks into tiny-segment equilibrium — ~40 bytes of headers taxing every payload byte. Neither side is 'broken'; the protocol simply permits a stable bad state.
Historical context
RFC 813 (July 1982) was implementation advice, not law — early TCPs genuinely exhibited the syndrome. Its receiver rule (advertise only openings ≥ min(MSS, buffer/2)), sender rule, and delayed-ACK proposal were adopted as requirements by RFC 1122 (1989) and remain MUSTs in RFC 9293 §3.8.6.2.
Current practice
Every production stack implements both SWS-avoidance rules; you will essentially never capture the syndrome from modern hosts. Delayed ACKs (bounded at 500 ms, ACK every 2nd full segment) are near-universal. This module lets you watch the historic pathology — and the cure — on identical applications.
Interactive laboratory
Guided walkthroughs — coached, packet by packet
Watch it on the wire
A 6 KB upload to a well-behaved receiver: full-sized segments, prompt reads, steady cumulative ACKs — window management as intended.
The server app sips 200 bytes at a time and the stack advertises every tiny opening (no SWS avoidance) — watch the connection degenerate into 200-byte crumbs.
Identical sipping application, but the stack follows RFC 9293: window updates held until worth advertising, no crumb segments sent. Same app, healthy wire.
A 4-segment transfer with RFC 1122 §4.2.3.2 delayed ACKs: one ACK per two full segments, and a lone trailing segment ACKed only when the 200 ms timer expires.
Compare correct vs historic / naive behaviour
The identical sipping application on a historic stack (every tiny window opening advertised) and on an RFC 9293-compliant stack (updates held, crumbs suppressed).
⇄ Immediate vs delayed acknowledgementsThe same 4½-segment transfer ACKed two ways: a receipt per segment versus RFC 1122's one-per-two-full-segments with a bounded timer.
Original RFC vs current standard
Receiver window updates
- Original behaviour
- RFC 813 recommends withholding openings below min(MSS, buffer/2) — as advice.
- Current behaviour
- RFC 9293 §3.8.6.2.2 makes receiver SWS avoidance a MUST.
- What changed
- Advisory algorithm became mandatory host behaviour (via RFC 1122 §4.2.3.3).
- Why it changed
- Field experience showed any single non-compliant receiver could degrade shared links.
📷 In a capture: Historic: window updates of a few hundred bytes trailing every read. Modern: updates only in ≥MSS strides.
Acknowledgement timing
- Original behaviour
- RFC 813 §4 proposes delaying ACKs to piggyback on data or cover multiple segments, with no fixed bound.
- Current behaviour
- RFC 1122 §4.2.3.2: delay < 0.5 s, and ACK at least every second full-sized segment (SHOULD).
- What changed
- The idea gained hard numeric bounds.
- Why it changed
- Unbounded delay stalls sender RTO estimation and (later) cwnd growth — the ACK clock must keep ticking.
📷 In a capture: Modern: ACKs covering exactly two segments, or arriving at a fixed delay after a lone segment.
Common misconceptions
- ✗“The receive window and the congestion window are the same thing” — rwnd is the receiver's lease; cwnd (lesson 11) is the sender's own network estimate.
- ✗“Small segments mean a small MSS was negotiated” — in SWS the MSS is fine; the WINDOW quantises the sends.
- ✗“Delayed ACKs are a performance bug” — they are required behaviour with strict bounds; only unbounded delay is non-compliant.
- ✗“The application must be fixed to stop SWS” — the cure lives entirely inside TCP; sipping applications are legitimate.
Glossary terms used here
Knowledge check
1/3 · In the syndrome trace, what quantises the client's segments down to 200 bytes?
2/3 · The compliant receiver holds a window update after the app reads 200 bytes. When must it finally advertise?
3/3 · Troubleshoot: a capture shows hundreds of 180-byte segments, no losses, MSS 1460 on both SYNs, and window updates of 180 following each one. Which diagnosis fits?