Sliding Window Protocol: Network Engineering Guide

Introduction and Core Concepts

Sliding window protocol is a fundamental flow control and error control mechanism that enables efficient, reliable data transmission over unreliable network channels. Unlike basic stop-and-wait protocols that transmit a single frame and wait for acknowledgment before sending the next, the sliding window protocol allows a sender to transmit multiple frames without waiting for individual acknowledgments, dramatically improving throughput and link utilization.

At its core, the sliding window protocol is a logical abstraction that defines a contiguous range of sequence numbers that the sender is permitted to transmit and the receiver is prepared to accept. This "window" slides forward as acknowledgments are received, hence the name. The protocol elegantly solves three critical networking problems simultaneously: it prevents the sender from overwhelming the receiver (flow control), it ensures reliable delivery despite packet loss or corruption (error control), and it maximizes bandwidth utilization by keeping the communication channel busy.

The importance of sliding window protocol in modern networking cannot be overstated. It forms the theoretical and practical foundation for the Transmission Control Protocol (TCP), which powers the vast majority of internet communication. Every web page load, file transfer, video stream, and API call relies on a variant of sliding window flow control. Understanding this protocol is essential for network engineers, backend developers, and anyone preparing for system design or networking interviews. Without sliding window techniques, high-latency, high-bandwidth networks such as transcontinental fiber links and satellite connections would operate at a fraction of their capacity.

Why Sliding Window Matters for Network Performance

Consider a link with a 100ms round-trip time (RTT) and a bandwidth of 1 Gbps. A stop-and-wait protocol sending 1500-byte frames would achieve only about 120 Kbps of throughput, wasting over 99.9% of available bandwidth while waiting for acknowledgments. Sliding window protocol eliminates this idle time by pipelining transmissions, allowing dozens or hundreds of frames to be in flight simultaneously.

The protocol also decouples the sender's transmission rate from the receiver's processing rate. A fast sender can burst data into the network, while a slower receiver can advertise a smaller window to throttle the sender, preventing buffer overflow and packet drops. This dynamic negotiation is what makes TCP adaptive to diverse network conditions and heterogeneous device capabilities.

Key Terminology

To understand sliding window protocol, you must be familiar with several core concepts. The Send Window is the range of sequence numbers the sender can transmit without acknowledgment. The Receive Window is the range the receiver is willing to accept. Sequence Numbers uniquely identify each frame, typically modulo 2^n where n is the number of bits in the sequence field. The Window Size (W) determines how many unacknowledged frames can be outstanding. Acknowledgments (ACKs) can be cumulative, confirming all frames up to a certain sequence number, or selective, confirming individual frames. Understanding these terms is prerequisite to analyzing the protocol's behavior and implementing it correctly.

How It Works

The sliding window protocol operates through a coordinated dance between sender and receiver, each maintaining its own window state. The sender maintains three critical variables: Send Window Size (SWS), Last Acknowledgment Received (LAR), and Last Frame Sent (LFS). The invariant maintained is LFS - LAR <= SWS. The sender can transmit any frame with a sequence number in the range (LAR+1) to (LAR+SWS), and must buffer all unacknowledged frames for potential retransmission.

The receiver maintains Receive Window Size (RWS), Last Frame Received (LFR), and Largest Acceptable Frame (LAF), where LAF = LFR + RWS. When a frame arrives, the receiver checks if its sequence number falls within the receive window. If it does and arrives in order, it is passed to the upper layer and an ACK is sent. If it arrives out of order, behavior depends on the variant: Go-Back-N discards it, while Selective Repeat buffers it. The receiver then slides its window forward and advertises its current window size to the sender via ACKs, providing explicit flow control feedback.

Sequence number management is a subtle but critical aspect. Because sequence numbers are finite and wrap around, the protocol must ensure that old duplicate frames are not mistaken for new ones. This imposes a fundamental constraint: for Go-Back-N, SWS < 2^n, and for Selective Repeat, SWS <= 2^(n-1). Violating these constraints leads to ambiguity where the receiver cannot distinguish a retransmitted old frame from a new frame with the same sequence number.

The Sliding Mechanism in Detail

Initially, both windows start at sequence number 0. As the sender transmits frames 0, 1, 2, etc., the left edge of its window remains fixed until ACKs arrive. When an ACK for frame 0 arrives, LAR advances to 0, and the window slides forward to cover 1 through SWS. This sliding is not necessarily one-by-one; a cumulative ACK for frame 3 acknowledges frames 0-3 simultaneously, causing the window to jump forward by four positions at once. This cumulative property provides robustness against ACK loss.

Timeout and retransmission are integral to reliability. The sender starts a timer for each transmitted frame or for the oldest unacknowledged frame. If the timer expires before an ACK arrives, the sender assumes loss and retransmits. The timeout value must be carefully tuned: too short causes spurious retransmissions, too long increases recovery latency. Modern implementations use adaptive algorithms like Jacobson's algorithm to estimate RTT and set timeouts dynamically.

Flow Control and Congestion Control Interaction

While sliding window protocol primarily provides flow control (receiver-driven throttling), TCP extends it to provide congestion control (network-driven throttling). The effective window is min(advertised window, congestion window). The advertised window is controlled by the receiver, while the congestion window is controlled by the sender's estimate of network capacity using algorithms like Slow Start, Congestion Avoidance, and Fast Recovery. This dual-window model is why TCP can adapt to both receiver overload and network congestion.

Implementation

Implementing sliding window protocol requires careful state management, timer handling, and buffer control. The following Python examples simulate the core logic in a clear, educational form without requiring raw sockets. These simulations capture the essential algorithmic behavior that underpins real protocol stacks.

Basic Sliding Window Sender

This first example models a generic sender with a configurable window size, sequence number space, and simulated unreliable channel. It demonstrates window sliding, buffering, and cumulative acknowledgment handling.

import collections
import time
import random

class SlidingWindowSender:
    def __init__(self, window_size=4, seq_bits=3, timeout=1.0):
        self.window_size = window_size
        self.max_seq = 2 ** seq_bits  # Sequence numbers 0 .. 2^n - 1
        self.timeout = timeout
        self.base = 0  # LAR + 1, left edge of window
        self.next_seq = 0  # LFS + 1, next sequence to use
        self.buffer = {}  # seq_num -> (frame, timestamp)
        self.seq_bits = seq_bits

    def can_send(self):
        # Check if window is not full: (next_seq - base) < window_size
        # Handle wrap-around with modulo arithmetic
        outstanding = (self.next_seq - self.base) % self.max_seq
        # Simpler for simulation without wrap: use absolute counters
        return (self.next_seq - self.base) < self.window_size

    def send(self, data):
        if not self.can_send():
            print(f"Window full! base={self.base}, next_seq={self.next_seq}")
            return None
        seq = self.next_seq % self.max_seq
        frame = {"seq": seq, "data": data, "abs_seq": self.next_seq}
        self.buffer[self.next_seq] = (frame, time.time())
        print(f"Sent frame seq={seq} (abs={self.next_seq}) data={data}")
        self.next_seq += 1
        return frame

    def receive_ack(self, ack_num):
        # Cumulative ACK: ack_num is next expected seq (abs)
        if ack_num > self.base and ack_num <= self.next_seq:
            print(f"Received cumulative ACK {ack_num}, sliding window")
            # Remove acknowledged frames from buffer
            for seq in list(self.buffer.keys()):
                if seq < ack_num:
                    del self.buffer[seq]
            self.base = ack_num
        else:
            print(f"Duplicate or invalid ACK {ack_num} ignored")

    def check_timeout(self):
        now = time.time()
        for abs_seq, (frame, sent_time) in list(self.buffer.items()):
            if now - sent_time > self.timeout:
                print(f"Timeout for seq {frame['seq']} (abs={abs_seq}), retransmitting")
                self.buffer[abs_seq] = (frame, now)
                return frame
        return None

# Example usage
sender = SlidingWindowSender(window_size=4, seq_bits=3)
for i in range(6):
    sender.send(f"msg-{i}")
sender.receive_ack(2)  # ACKs 0 and 1
sender.send("msg-6")  # Now window has space
sender.send("msg-7")

Cumulative ACK Receiver

The receiver must handle in-order delivery, duplicate detection, and window advertisement. This example shows a Go-Back-N style receiver that only accepts in-order frames and sends cumulative ACKs.

class GoBackNReceiver:
    def __init__(self, window_size=4, seq_bits=3):
        self.expected_seq = 0  # LFR + 1, next in-order seq expected (absolute)
        self.max_seq = 2 ** seq_bits
        self.window_size = window_size
        self.received_data = []

    def receive(self, frame):
        if frame is None:
            return None
        abs_seq = frame["abs_seq"]
        seq = frame["seq"]
        # Check if frame is the expected next in-order frame
        if abs_seq == self.expected_seq:
            print(f"Receiver: Accepted in-order frame seq={seq} abs={abs_seq}")
            self.received_data.append(frame["data"])
            self.expected_seq += 1
            # Cumulative ACK: next expected
            ack = self.expected_seq
            print(f"Receiver: Sending ACK {ack}")
            return ack
        elif abs_seq < self.expected_seq:
            print(f"Receiver: Duplicate frame seq={seq} abs={abs_seq}, resending ACK {self.expected_seq}")
            return self.expected_seq
        else:
            # Out-of-order, discard (Go-Back-N behavior)
            print(f"Receiver: Out-of-order frame seq={seq} abs={abs_seq} expected {self.expected_seq}, discarded")
            return self.expected_seq

    def get_delivered(self):
        return self.received_data

# Simulate loss and reordering
receiver = GoBackNReceiver(window_size=4, seq_bits=3)
sender = SlidingWindowSender(window_size=4, seq_bits=3)

frames = [sender.send(f"pkt-{i}") for i in range(4)]
# Deliver in order
for f in frames[:2]:
    ack = receiver.receive(f)
    sender.receive_ack(ack)
# Simulate frame 2 lost, frame 3 arrives out-of-order
ack = receiver.receive(frames[3])
sender.receive_ack(ack)  # Will be duplicate ACK

Selective Repeat Sender and Receiver

Selective Repeat improves efficiency by buffering out-of-order frames and acknowledging each frame individually. This requires more complex state but avoids retransmitting correctly received frames after a single loss.

class SelectiveRepeatReceiver:
    def __init__(self, window_size=4, seq_bits=3):
        self.base = 0  # LFR + 1
        self.window_size = window_size
        self.max_seq = 2 ** seq_bits
        self.buffer = {}  # abs_seq -> frame
        self.delivered = []

    def receive(self, frame):
        abs_seq = frame["abs_seq"]
        # Check if within receive window: base <= abs_seq < base + window_size
        if abs_seq < self.base or abs_seq >= self.base + self.window_size:
            print(f"SR Receiver: seq {abs_seq} outside window [{self.base}, {self.base+self.window_size}), ignored")
            # Still ACK if it was already delivered (duplicate)
            if abs_seq < self.base:
                return abs_seq + 1  # Individual ACK
            return None

        if abs_seq in self.buffer:
            print(f"SR Receiver: Duplicate seq {abs_seq} buffered already")
            return abs_seq + 1

        print(f"SR Receiver: Buffered out-of-order seq {abs_seq}")
        self.buffer[abs_seq] = frame

        # Deliver in-order contiguous frames
        while self.base in self.buffer:
            f = self.buffer.pop(self.base)
            self.delivered.append(f["data"])
            print(f"SR Receiver: Delivered seq {self.base} to application")
            self.base += 1

        # Selective ACK: ACK the specific frame
        return abs_seq + 1

class SelectiveRepeatSender:
    def __init__(self, window_size=4, seq_bits=3, timeout=1.0):
        self.window_size = window_size
        self.base = 0
        self.next_seq = 0
        self.max_seq = 2 ** seq_bits
        self.buffer = {}
        self.acked = set()
        self.timeout = timeout

    def can_send(self):
        return (self.next_seq - self.base) < self.window_size

    def send(self, data):
        if not self.can_send():
            return None
        frame = {"abs_seq": self.next_seq, "seq": self.next_seq % self.max_seq, "data": data}
        self.buffer[self.next_seq] = (frame, time.time())
        print(f"SR Sender: Sent seq {frame['seq']} abs={self.next_seq}")
        self.next_seq += 1
        return frame

    def receive_ack(self, ack_num):
        # Selective ACK: ack_num = abs_seq + 1
        acked_seq = ack_num - 1
        if acked_seq >= self.base and acked_seq < self.next_seq:
            print(f"SR Sender: Received ACK for {acked_seq}")
            self.acked.add(acked_seq)
            # Slide window if base is acked
            while self.base in self.acked:
                self.acked.remove(self.base)
                del self.buffer[self.base]
                self.base += 1
            print(f"SR Sender: Window now [{self.base}, {self.base+self.window_size})")

Adaptive Window with Simulated Network Conditions

Real networks experience variable RTT and loss. This example shows how a sender can dynamically adjust its effective window based on simulated ACK timing and packet loss, mimicking TCP's congestion control interaction with the sliding window.

import random

def simulate_sliding_window_transfer(num_packets=20, window_size=5, loss_prob=0.2):
    sender = SelectiveRepeatSender(window_size=window_size, seq_bits=4)
    receiver = SelectiveRepeatReceiver(window_size=window_size, seq_bits=4)
    abs_seq = 0
    delivered_order = []

    # Simulate sending all packets with possible loss
    frames_in_flight = []
    for i in range(num_packets):
        if sender.can_send():
            f = sender.send(f"data-{i}")
            frames_in_flight.append(f)
        else:
            # Window full, process ACKs first
            if frames_in_flight:
                f = frames_in_flight.pop(0)
                if random.random() > loss_prob:  # Not lost
                    ack = receiver.receive(f)
                    if ack:
                        sender.receive_ack(ack)
                else:
                    print(f"Network: Packet abs={f['abs_seq']} LOST")

    # Drain remaining frames
    for f in frames_in_flight:
        if random.random() > loss_prob:
            ack = receiver.receive(f)
            if ack:
                sender.receive_ack(ack)

    # Retransmit unacked frames (simplified timeout)
    for seq, (frame, _) in list(sender.buffer.items()):
        if seq not in sender.acked:
            print(f"Retransmitting abs={seq}")
            ack = receiver.receive(frame)
            if ack:
                sender.receive_ack(ack)

    print(f"Delivered {len(receiver.delivered)} / {num_packets} packets")
    print(f"Receiver delivered in order: {receiver.delivered[:10]}")
    return receiver.delivered

# Run simulation
random.seed(42)
simulate_sliding_window_transfer(num_packets=12, window_size=4, loss_prob=0.15)

Step-by-Step Example

To solidify understanding, let us walk through a concrete example using Go-Back-N with a window size of 3 and sequence numbers modulo 8 (3 bits). The sender wants to transmit frames 0 through 5 to the receiver. We will trace window positions, transmissions, ACKs, and a loss event.

Initial State: Sender window = [0,1,2] (base=0, next_seq=0, SWS=3). Receiver expects 0 (expected_seq=0, RWS=3, window [0,1,2]). Both windows are empty and ready.

Step 1 - Pipelined Transmission: The sender transmits frames 0, 1, and 2 back-to-back without waiting. After sending, next_seq=3, base=0, so outstanding frames are 0,1,2. The window is now full. All three frames are buffered for possible retransmission and timers are started. The frames are now in flight across the network.

Step 2 - In-Order Reception and Cumulative ACK: The receiver receives frame 0 correctly. It delivers data 0 to the application, increments expected_seq to 1, and sends ACK 1 (meaning "I have received all frames up to 0, next I expect 1"). When the sender receives ACK 1, it slides its window to [1,2,3] (base=1), discards frame 0 from its buffer, and now has space to send frame 3. The sender immediately transmits frame 3 (seq=3).

Step 3 - Loss Event: Frame 1 is lost due to congestion, but frames 2 and 3 arrive at the receiver. In Go-Back-N, the receiver discards out-of-order frames 2 and 3 because it still expects frame 1. It resends ACK 1 for each discarded frame (duplicate ACKs). The sender receives duplicate ACK 1s but takes no window action, as cumulative ACKs only slide forward on new ACKs.

Step 4 - Timeout and Retransmission: The sender's timer for frame 1 expires (since ACK 1 was the last new ACK). Go-Back-N mandates retransmission of all outstanding frames from the base: frames 1, 2, and 3 are all resent, even though 2 and 3 had previously arrived at the receiver. This is the primary inefficiency of Go-Back-N.

Step 5 - Recovery: This time, frames 1, 2, and 3 all arrive correctly and in order. The receiver accepts 1, sends ACK 2, accepts 2, sends ACK 3, accepts 3, sends ACK 4. As each ACK arrives, the sender slides its window: after ACK 2 window is [2,3,4], after ACK 3 window is [3,4,5], after ACK 4 window is [4,5,6]. The sender can now transmit frames 4 and 5, completing the transfer. The final ACK 6 confirms all data.

What Selective Repeat Would Do Differently

In the same loss scenario with Selective Repeat (RWS=3), the receiver would have buffered frames 2 and 3 upon arrival, even though frame 1 was missing. It would send selective ACKs for 2 and 3 individually. The sender would only need to retransmit frame 1. Upon receiving retransmitted frame 1, the receiver would deliver 1, 2, and 3 in order to the application and send a cumulative ACK for 4. This saves two retransmissions and is far more efficient on lossy or high-bandwidth-delay-product links.

This example highlights the trade-off: Go-Back-N is simpler (receiver needs no buffering, sender retransmits in bulk), while Selective Repeat is more efficient but requires more memory and complex logic on both sides. The choice depends on error rate, bandwidth, and implementation constraints.

Complexity Analysis

Analyzing sliding window protocol requires distinguishing between per-operation costs and overall throughput characteristics. The protocol's efficiency is not just about CPU cycles but about channel utilization and recovery overhead.

For a transfer of N frames with window size W, the ideal case with no loss achieves O(N) total transmissions, as each frame is sent exactly once and each ACK is processed once. The sender and receiver each perform O(1) work per frame for window checks and buffer management, leading to O(N) total time. Space complexity is O(W) for buffering unacknowledged frames at the sender and, for Selective Repeat, O(W) at the receiver for out-of-order buffering.

Loss changes the analysis dramatically. In Go-Back-N, a single loss can cause O(W) retransmissions, leading to worst-case O(N*W) transmissions if every window suffers a loss. Selective Repeat reduces this to O(N + L) where L is the number of lost frames, since only lost frames are retransmitted. However, Selective Repeat pays with more complex ACK tracking and timer management per frame.

Sequence number handling is O(1) with modulo arithmetic, but window sliding itself is amortized O(1) when using circular buffers or deque structures. Timeout checking can be O(W) if scanning all timers linearly, but optimized implementations use a single timer for the oldest unacknowledged frame (Go-Back-N) or a timer wheel for O(1) average timeout management.

The key takeaway is that window size W is the critical tuning parameter. Larger W improves throughput up to the bandwidth-delay product (BDP) but increases memory and recovery cost. Setting W > BDP wastes memory without throughput gain, while W < BDP underutilizes the link. Optimal W = ceil(Bandwidth * RTT / Frame Size).

Variations and Optimizations

The basic sliding window protocol has evolved into several well-defined variants, each optimizing for different network conditions and trade-offs between complexity and efficiency.

Go-Back-N (GBN) is the simplest sliding window variant. The receiver window size is 1, meaning it only accepts in-order frames. Any out-of-order frame is discarded, and the receiver resends the last cumulative ACK. The sender uses a single timer for the oldest unacknowledged frame and retransmits all outstanding frames on timeout. GBN is easy to implement and requires minimal receiver buffering, making it suitable for low-error-rate links where retransmission overhead is rare. However, it wastes bandwidth on lossy links.

Selective Repeat (SR) allows the receiver window to be larger than 1, typically equal to the send window. The receiver buffers out-of-order frames and sends individual selective ACKs (SACKs). The sender maintains a timer per frame and retransmits only the lost frames. SR achieves near-optimal throughput even with high loss rates but requires more memory and sophisticated buffer management. TCP's SACK option is a direct implementation of selective repeat principles.

Selective Reject is a hybrid where the receiver discards out-of-order frames like GBN but uses a NAK (negative acknowledgment) to explicitly request retransmission of the missing frame, rather than waiting for timeout. This reduces recovery latency when the receiver can detect gaps quickly.

Advanced Optimizations

Modern implementations layer numerous optimizations atop the basic sliding window. Adaptive Window Sizing dynamically adjusts W based on RTT measurements and loss feedback, as seen in TCP Cubic, BBR, and Reno. Piggybacking combines data and ACKs in the same frame for bidirectional traffic, halving ACK overhead. Fast Retransmit and Fast Recovery use duplicate ACK counting (typically 3 duplicate ACKs) to infer loss without waiting for timeout, cutting recovery time from seconds to milliseconds.

Window Scaling (RFC 7323) extends the 16-bit TCP window field to support windows up to 1GB, essential for high-BDP paths like 100 Gbps transatlantic links. Without scaling, the maximum window of 64KB would limit throughput to about 5 Mbps on a 100ms RTT path, regardless of physical bandwidth. Delayed ACKs reduce ACK traffic by acknowledging every second frame or after a 40ms delay, trading a small latency increase for significant overhead reduction.

Another critical optimization is Nagle's Algorithm and Clark's Silly Window Syndrome avoidance, which prevent the sliding window from being used inefficiently for tiny segments. Nagle coalesces small writes into larger segments when unacknowledged data is outstanding, while the receiver avoids advertising tiny windows that would cause the sender to transmit inefficiently small frames.

Real-World Applications

Sliding window protocol is not an academic curiosity; it is embedded in virtually every reliable communication system in production today.

Transmission Control Protocol (TCP) is the most prominent application. Every TCP connection negotiates window sizes during the three-way handshake, advertises receive windows in every ACK, and uses sliding window flow control combined with congestion control to adapt to network conditions. Web servers like Nginx and Apache, databases like PostgreSQL, and cloud load balancers all rely on the OS's TCP stack, which is a highly optimized sliding window implementation. Performance tuning for high-throughput services often involves adjusting socket buffer sizes (SO_RCVBUF, SO_SNDBUF), which directly control the sliding window.

Data Link Layer Protocols such as HDLC, PPP, and the Logical Link Control (LLC) use sliding window for hop-by-hop reliability. In cellular networks, the Radio Link Control (RLC) layer in 4G/5G uses selective repeat sliding window to handle the high error rates of wireless channels without burdening end-to-end TCP with excessive retransmissions.

Satellite and High-Latency Links depend critically on large sliding windows. A geostationary satellite link has an RTT of ~550ms. With a 10 Mbps link and 1500-byte frames, the BDP is about 458 frames. A window size of 1 would achieve only 21 Kbps; a window of 500 is needed to saturate the link. Protocols like SCPS-TP (Space Communications Protocol Standards - Transport Protocol) are TCP variants with huge windows tuned for space.

QUIC and HTTP/3 generalize sliding window to the application layer. QUIC implements per-stream flow control windows in addition to connection-level windows, allowing independent sliding windows for each HTTP/3 stream. This prevents a lost packet on one stream from blocking delivery on others, solving TCP's head-of-line blocking problem while retaining sliding window's efficiency.

Even at the application layer, the pattern recurs. Message brokers like Kafka and RabbitMQ use credit-based flow control that is logically identical to sliding window: consumers advertise credits (window size), producers send up to that many messages, and credits are replenished as messages are processed. Database replication streams and distributed consensus protocols like Raft use sliding window pipelining to replicate log entries efficiently.

Comparison with Alternatives

Sliding window protocol should be understood in contrast to simpler and alternative flow control strategies. The choice of protocol has profound implications for throughput, complexity, and resource usage.

Stop-and-Wait is the baseline: send one frame, wait for ACK, send next. It is trivial to implement and requires minimal buffering, but its channel utilization is U = 1 / (1 + 2*propagation/transmission), which approaches zero on high-latency links. It is only suitable for very low-speed or half-duplex links where simplicity outweighs performance.

Rate-Based Control is an alternative to window-based control where the sender is limited to a maximum sending rate (bytes per second) rather than outstanding bytes. Rate-based control, used in some real-time protocols and BBR congestion control, provides smoother traffic and avoids burstiness, but requires precise timers and does not provide the same hard bound on outstanding data that prevents receiver overflow.

Credit-Based Flow Control is used in lossless networks like InfiniBand and data center fabrics. Instead of ACKs, the receiver explicitly grants credits for each frame, and the sender decrements credits on transmission. It is functionally similar to sliding window but with explicit credit messages, providing tighter control and avoiding ACK ambiguity.

The table makes clear that sliding window variants dominate when throughput matters. Stop-and-wait is never optimal for modern networks, while rate-based control complements window-based control rather than replacing it; indeed, TCP BBR combines both, using a window for flow control and a rate for congestion control.

Common Mistakes and Best Practices

Implementing or configuring sliding window protocol incorrectly can lead to subtle bugs, performance collapse, or deadlocks. Awareness of common pitfalls is essential for robust network engineering.

Mistake 1: Incorrect Sequence Number Space and Window Size Relationship. A classic error is setting window size too large relative to sequence number bits. For example, with 3-bit sequence numbers (0-7), setting W=8 for Selective Repeat causes ambiguity: after sending 0-7 and receiving ACKs, the sender slides to 0-7 again, but the receiver cannot tell if a frame with seq 0 is a retransmission of the old 0 or the new 0. The rule W <= 2^(n-1) for Selective Repeat and W < 2^n for Go-Back-N must be enforced. Best practice is to use at least 32-bit sequence numbers (as TCP does) and validate window sizes at configuration time.

Mistake 2: Static Timeout Values. Using a fixed timeout (e.g., 1 second) fails across diverse RTTs. On a LAN with 0.5ms RTT, a 1-second timeout wastes 2000x time on loss recovery. On a satellite link with 600ms RTT, a 1-second timeout causes spurious retransmissions. Best practice is to implement adaptive RTT estimation using exponential weighted moving average (EWMA) and set timeout = SRTT + 4*RTTVAR, as specified in RFC 6298. Also implement exponential backoff on repeated timeouts.

Mistake 3: Ignoring Silly Window Syndrome and Nagle Interaction. Advertising a 1-byte window or sending 1-byte segments due to application behavior can cause catastrophic throughput collapse, with more header bytes than data. Best practice is to implement Clark's avoidance (receiver should not advertise small windows) and Nagle's algorithm (sender should coalesce small writes) or use TCP_NODELAY judiciously for latency-sensitive applications. Application-level batching is also critical.

Mistake 4: Not Handling Window Scale and Buffer Sizing. Many engineers leave OS default socket buffers at 64KB, which caps throughput on high-BDP paths. For a 10 Gbps link with 50ms RTT, BDP is 62.5 MB, requiring window scaling and buffer sizes of that magnitude to saturate the link. Best practice is to tune net.core.rmem_max, net.core.wmem_max, and use setsockopt SO_RCVBUF/SO_SNDBUF based on measured BDP. Monitor with ss -i or netstat to verify advertised windows.

Mistake 5: Confusing Flow Control with Congestion Control. Treating the advertised window as the only limit ignores network congestion. A large advertised window can still cause congestion collapse if the network is overloaded. Best practice is to respect both windows: effective window = min(advertised window, congestion window). Implement or enable modern congestion control (CUBIC, BBR) and do not disable it. For custom protocols, implement separate congestion feedback like ECN or packet loss signals.

Best Practices Checklist

• Validate W <= 2^(n-1) for Selective Repeat; use 32-bit sequence numbers.
• Implement adaptive RTT estimation and exponential backoff for timers.
• Use selective acknowledgments (SACK) to avoid retransmitting correctly received data.
• Enable window scaling (RFC 7323) and tune buffers to BDP for high-throughput paths.
• Implement fast retransmit on 3 duplicate ACKs to avoid timeout delays.
• Monitor window utilization, retransmission rate, and RTT variance in production.
• Test with simulated loss, reordering, and delay using tools like tc netem.
• Document whether your protocol uses cumulative, selective, or hybrid ACKs.

Interview Questions

Sliding window protocol is a staple of networking and system design interviews. Expect questions that test conceptual understanding, quantitative analysis, and trade-off reasoning.

Question 1: Why is the maximum window size for Selective Repeat 2^(n-1) and not 2^n - 1?

Answer: This tests understanding of sequence number ambiguity. With n bits, there are 2^n distinct sequence numbers. Suppose n=2 (0-3) and W=3 (which is 2^n -1). Sender sends 0,1,2. Receiver receives all and ACKs, sliding to expect 3,0,1. All ACKs are lost. Sender times out and retransmits 0,1,2. Receiver, expecting 3,0,1, sees 0 and thinks it is the new 0 (since 0 is in its window), accepting a duplicate as new data. With W=2 (2^(n-1)), sender sends 0,1. Receiver expects 2,3. Retransmitted 0,1 fall outside window [2,3] and are correctly detected as duplicates. The constraint ensures send and receive windows never overlap after wrap-around, preventing ambiguity. Draw the sequence number circle to illustrate.

Question 2: Calculate the optimal window size for a 1 Gbps link with 20ms RTT and 1500-byte frames. What is the utilization with window size 10?

Answer: Bandwidth-Delay Product BDP = Bandwidth * RTT = 1e9 bits/s * 0.02 s = 20e6 bits = 2.5 MB. Frame size = 1500 bytes = 12,000 bits. Optimal W = BDP / Frame Size = 20e6 / 12e3 ≈ 1667 frames. Alternatively, in bytes, window should be 2.5 MB. With W=10, max outstanding = 10*1500=15KB. Throughput = W*Frame / RTT = 10*12000 / 0.02 = 6 Mbps. Utilization = 6 Mbps / 1000 Mbps = 0.6%. This shows why small windows cripple high-speed links. Mention that TCP window scaling is needed since 2.5 MB > 64KB default.

Question 3: Compare Go-Back-N and Selective Repeat in terms of throughput under 5% packet loss with window size 100.

Answer: Under 5% loss, Go-Back-N retransmits on average W frames per loss, so effective transmissions = N + 0.05*N*W = N*6 for W=100, meaning 6x overhead and throughput collapses to ~16% of ideal. Selective Repeat retransmits only lost frames: N + 0.05*N = 1.05N, overhead 5%, throughput ~95% of ideal. However, Selective Repeat requires receiver buffering of 100 frames and per-frame timers, increasing memory and complexity. Choose GBN when error rate is <0.1% and simplicity matters (e.g., hardware), SR when error rate is high or BDP is large (e.g., wireless, satellite, high-speed TCP with SACK).

Question 4: How does TCP use sliding window for both flow control and congestion control? What happens if you confuse them?

Answer: TCP maintains two windows: rwnd (receiver advertised window, flow control) and cwnd (congestion window, congestion control). Effective window = min(rwnd, cwnd). rwnd is set by receiver based on available buffer, preventing overflow. cwnd is set by sender based on network congestion signals (loss, ECN, RTT), using algorithms like Slow Start and Congestion Avoidance. Confusing them leads to either receiver overflow (ignoring rwnd) or congestion collapse (ignoring cwnd and blasting at rwnd). Interviewers want to hear about Slow Start (cwnd doubles per RTT), AIMD, and how BBR estimates bottleneck bandwidth separately. Mention that flow control is end-to-end, congestion control is network-wide.

Question 5: Design a sliding window protocol for a bidirectional link with piggybacking. How do you handle ACKs?

Answer: For bidirectional traffic, each side is both sender and receiver. Piggybacking optimizes by carrying ACKs in data frame headers instead of separate ACK frames. Each frame contains seq, ack_num, and ack_valid flag, plus window advertisement. When A sends data to B, it includes ack_num = next expected from B. If A has no data to send but needs to ACK, it sends a standalone ACK after a short delay (delayed ACK, ~40ms) to allow piggybacking opportunity. Must handle cumulative ACKs: ack_num acknowledges all frames < ack_num. Need to manage two independent windows (A->B and B->A) with separate base/next_seq. Mention that piggybacking reduces overhead by ~50% for symmetric traffic like SSH or database replication, but adds complexity for timer management since ACKs are delayed.