Sliding Window

Imagine a water pipeline connecting two cities. If City A pumps water at maximum capacity without regard for City B's storage tanks, the tanks overflow, water is wasted, and the system grinds to a halt while crews clean up the mess. The naive solution—wait for confirmation after each small batch—works but crawls at a glacial pace. What we need is continuous flow with intelligent throttling.

This is precisely the challenge TCP faces. The sender wants to transmit data as fast as possible to maximize throughput. The receiver has finite buffer space and processing capacity. The network path between them has limited bandwidth and introduces delays. How do we achieve maximum throughput without overwhelming any component?

The answer is the TCP Sliding Window—one of the most elegant mechanisms in networking, simultaneously solving flow control, enabling pipelining, and providing the foundation for reliable delivery. Understanding this mechanism is essential for anyone who wants to truly comprehend how TCP achieves its remarkable combination of speed and reliability.

To appreciate the sliding window, we must first understand the protocol it supersedes: Stop-and-Wait. In stop-and-wait, the sender transmits one segment, then waits for an acknowledgment before sending the next. This approach is simple and guarantees the receiver is never overwhelmed—but it's catastrophically inefficient.

Consider a concrete example:

You're transferring data between San Francisco and Tokyo. The round-trip time (RTT) is 100ms, and you're using segments of 1,000 bytes on a 10 Mbps link.

The fundamental problem is the bandwidth-delay product:

The bandwidth-delay product (BDP) represents the amount of data "in flight" that can exist between sender and receiver at any instant:

BDP = Bandwidth × Round-Trip Time
BDP = 10,000,000 bps × 0.1 seconds = 1,000,000 bits = 125,000 bytes

This means the network "pipe" between San Francisco and Tokyo can hold 125,000 bytes at any moment. With stop-and-wait, you're putting only 1,000 bytes in that pipe, then waiting. The pipe is 99.2% empty at all times.

The solution is obvious: keep the pipe full. Instead of waiting for each acknowledgment, send enough data to fill the bandwidth-delay product. This is exactly what the sliding window enables.

The sliding window protocol solves the stop-and-wait inefficiency by allowing the sender to transmit multiple segments before requiring acknowledgment. The "window" represents the range of sequence numbers the sender is permitted to transmit without waiting for ACKs.

Core principles:

1. The window is a range of permissible sequence numbers — The sender maintains a window of bytes it's allowed to send. This window "slides" forward as acknowledgments arrive.

2. The receiver advertises its capacity — The receiver tells the sender how much buffer space it has available. This prevents buffer overflow.

3. Bytes transition through states — Each byte in the sender's buffer is in one of several states: not yet sendable, sendable, sent but unacknowledged, or acknowledged.

4. The window slides, never jumps — As ACKs arrive, the left edge of the window advances. The right edge advances based on the receiver's advertised capacity.

Visualizing the sliding window:

Consider a stream of bytes numbered 0 through infinity. At any moment, the sender's view of this stream is divided into four regions:

The sliding mechanism:

The beauty of this design is how naturally the window "slides" forward:

1. Sender transmits: Bytes move from "Sendable" to "Sent, Unacknowledged"
2. Time passes: Segments travel through the network; ACKs return
3. ACK arrives: Bytes move from "Sent, Unacknowledged" to "Acknowledged"
4. Window slides: The left edge advances to match the cumulative ACK
5. New bytes become sendable: Previously blocked bytes enter the window

This creates a continuous flow: as fast as the receiver acknowledges data, the sender can transmit new data. The window acts as a governor, ensuring the sender never outpaces the receiver's ability to accept data.

The sliding window enables pipelining—having multiple segments in flight simultaneously. This is the key to high throughput over high-latency networks.

Revisiting our San Francisco to Tokyo example:

Recall our parameters: 10 Mbps link, 100ms RTT, 1,000-byte segments. With stop-and-wait, we achieved a pitiful 0.79% utilization. Let's see what happens with a sliding window.

The throughput formula:

For a sliding window protocol, throughput is governed by:

Throughput = min(Window Size / RTT, Link Bandwidth)

This reveals a critical insight: throughput is limited by the smaller of two factors:

1. Window Size / RTT: How fast the sender is allowed to inject data (flow control limit)
2. Link Bandwidth: How fast the network can physically carry data (capacity limit)

When Window Size ≥ BDP, throughput becomes bandwidth-limited (the ideal case). When Window Size < BDP, throughput is artificially constrained by the window—we have unused capacity.

Why this matters for modern networks:

High-bandwidth, high-latency networks (common in cloud computing, intercontinental links, and satellite communications) have enormous bandwidth-delay products. A 1 Gbps transatlantic link with 80ms RTT has a BDP of 10 megabytes. If your TCP connection can't advertise a window that large, you'll never come close to 1 Gbps throughput.

Unlike some protocols that count segments, TCP's sliding window counts bytes. This is a crucial detail that affects how everything works.

Why bytes, not segments?

1. Variable segment sizes: TCP can send segments of different sizes. A byte-oriented window ensures consistent measurement regardless of segmentation.

2. Partial acknowledgments: The receiver can acknowledge exactly how many bytes it received, allowing for fine-grained flow control.

3. Buffer management: Receiver buffers are measured in bytes, so a byte-oriented window directly corresponds to buffer capacity.

4. Application alignment: Applications write and read bytes, not segments. The byte abstraction maintains end-to-end consistency.

The TCP header's window field:

The TCP header contains a 16-bit Window field that the receiver uses to advertise how many bytes it can accept:

• Minimum value: 0 (receiver says "stop sending, I'm full")
• Maximum value: 65,535 bytes (approximately 64 KB)
• Interpretation: "You may send up to [Window] bytes beyond the last acknowledged byte"

This 16-bit limitation was a design decision from TCP's 1981 specification (RFC 793). At the time, 64 KB seemed generous. Today, it's a critical bottleneck that required the Window Scale option to overcome (covered in a later page).

The sliding window mechanism provides the foundation for TCP's receiver-based flow control. This ensures the sender never transmits faster than the receiver can handle, preventing buffer overflow and data loss.

How receiver-based flow control works:

1. Buffer allocation: The receiver allocates a buffer to hold incoming data before the application reads it.

2. Window advertisement: In every ACK, the receiver advertises its current available buffer space (the window).

3. Sender constraint: The sender limits its transmissions to stay within the advertised window.

4. Dynamic adjustment: As the application reads data, buffer space frees up, and the receiver advertises a larger window.

5. Continuous cycle: This creates a feedback loop where transmission rate adapts to receiver capacity.

Contrast with congestion control:

It's essential to distinguish flow control from congestion control:

TCP uses both mechanisms simultaneously. The actual transmission window is the minimum of rwnd and cwnd—the sender is constrained by both the receiver's capacity and the network's capacity.

Let's trace through the precise mechanics of how the sliding window operates in TCP. Understanding these details is crucial for debugging performance issues and implementing TCP stacks.

Key variables at the sender:

The send window boundaries:

The sender can transmit bytes in the range:

[SND.UNA, SND.UNA + SND.WND)

Bytes from SND.UNA to SND.NXT - 1 have already been sent but are awaiting acknowledgment. Bytes from SND.NXT to SND.UNA + SND.WND - 1 may be sent immediately.

The usable window calculation:

Usable Window = SND.WND - (SND.NXT - SND.UNA)
             = (SND.UNA + SND.WND) - SND.NXT

This represents how many more bytes the sender can transmit right now.

Understanding the sliding window has direct practical implications for system administrators, application developers, and network engineers.

Diagnosing throughput problems:

When TCP throughput is lower than expected, the sliding window is often the culprit. Common issues include:

Tuning recommendations:

For high-performance networking, consider these window-related tuning strategies:

1. Increase socket buffer sizes: OS defaults may be too small. On Linux, adjust net.core.rmem_max, net.core.wmem_max, and the TCP-specific equivalents.

2. Enable window scaling: Modern systems enable this by default (RFC 7323), but verify it's active for your connections.

3. Enable TCP buffer auto-tuning: Modern operating systems can automatically adjust buffer sizes based on observed RTT. Ensure auto-tuning is enabled.

4. Match buffer to BDP: For known high-latency connections (e.g., to specific cloud regions), ensure buffers are at least as large as the expected BDP.

5. Monitor with packet captures: Tools like Wireshark can display window sizes and identify window-limited connections.

We've covered the foundational concepts of TCP's sliding window mechanism. Let's consolidate the key takeaways:

What's next:

Now that we understand the sliding window concept, we'll examine its two components in detail: the send window (the sender's perspective on what can be transmitted) and the receive window (the receiver's buffer management and advertisement). These perspectives are complementary but have distinct mechanisms and considerations.