Sliding Window Protocol at the Transport Layer: Mechanisms, Algorithms, and TCP/UDP Mapping

In the transport layer, sliding window protocols enable efficient, reliable, and flow-controlled delivery over unreliable networks by combining:

1. sequencing
2. acknowledgment
3. retransmission
4. flow control
5. pipelining

The core idea is that the sender may have multiple unacknowledged segments “in flight” but only up to a size determined by the protocol’s window. As acknowledgments arrive, the window “slides” forward, allowing more segments to be transmitted. This achieves reliability (via re-send on loss) and efficiency (via pipelining), while also supporting receiver buffer constraints (via flow control).

A typical conceptual model is reliable data transfer over a lossy channel, where the receiver returns ACKs indicating which sequence numbers have been received. Sliding window protocols differ mainly in how they handle lost packets and whether the receiver buffers out-of-order segments.

Mermaid view of the sliding window concept (sender perspective):

Key transport-layer entities and terms

• sequence number
• cumulative ACK
• selective ACK
• receive buffer
• timeout

What “sliding window” means formally

Consider sequence numbers increasing by 1 per segment. Let the sender maintain:

• a send window: the range of sequence numbers it is allowed to have outstanding (sent but not yet acknowledged),
• a pointer (base) to the oldest unacknowledged segment,
• and (depending on the variant) possibly a record of which segments are individually acknowledged.

At any time, the sender can transmit new segments while: $\text{nextseqnum} < \text{base} + W$ where:

• $W$ is the window size (maximum number of in-flight segments),
• $\text{base}$ advances when ACKs confirm receipt.

On receipt of ACKs, the sender moves the base forward (sliding the window) and may transmit additional new segments to keep the pipeline full.

[CalloutBlock] below highlights the most common conceptual pitfall.

Reliability model: “lost packets” and how ACKs drive retransmissions

Transport-layer reliability is typically built from:

• a receiver that sends ACKs when segments arrive,
• a sender that retransmits when ACKs don’t arrive by a timeout, or when it infers loss.

Different sliding window protocols define:

• whether ACKs are cumulative or selective,
• which lost packets trigger retransmission (only lost segments vs. all after the gap),
• whether the receiver buffers out-of-order data.

This leads to the standard family:

1. Stop-and-Wait (window size $W=1$)
2. Go-Back-N (fixed window; retransmit from the first lost segment onward)
3. Selective Repeat (retransmit only the missing segments; buffer out-of-order)

Protocol variants: Stop-and-Wait vs Go-Back-N vs Selective Repeat

Stop-and-Wait

• Send one segment.
• Wait for ACK.
• Retransmit on timeout.
• Window size $W=1$.

This is correct but inefficient because it underutilizes the channel when RTT is large.

Go-Back-N (GBN)

• Sender can send up to $W$ segments ahead.
• Receiver acknowledges cumulatively (often ACKs the last in-order segment received).
• If segment $k$ is lost, all later segments $k+1, k+2, \dots$ may be received by the receiver but are discarded (or not delivered) until $k$ arrives.
• Sender retransmits from $k$ when it detects the loss (timeout or duplicate ACK behavior).

Selective Repeat (SR)

• Sender can still have up to $W$ segments in flight.
• Receiver buffers out-of-order segments.
• ACKs are selective (or at least can acknowledge individual segments).
• Sender retransmits only missing segments upon timeout for those segments.

Sliding window mechanics in transport-layer terms

The behavior can be understood as an event-driven state machine:

• Sender events

  • “Can send”: if window has space, send new segments.
  • “ACK received”: mark acknowledged segments; advance base (slide).
  • “Timeout”: retransmit segments that may be lost (variant-dependent).

• Receiver events

  • “Segment arrives in-window”:
    • if in order, deliver to application and possibly deliver buffered segments;
    • if out of order (SR), buffer it and ACK it;
    • if out of order (GBN), discard and ACK last in-order.
  • “Send ACK” reflecting the protocol’s cumulative/selective rules.

Receiver-side behavior (in-order delivery, buffering, and ACK generation)

The receiver’s job is to ensure the application receives data in order, even when the channel reorders or drops segments.

Key mechanisms:

• In-window check: accept segments whose sequence numbers fall within the receiver’s expected receive window.
• Delivery vs buffering:
  • GBN: out-of-order segments are typically discarded.
  • SR: out-of-order segments are buffered until gaps fill.
• ACK rules:
  • GBN: often sends ACK for the last in-order segment (cumulative).
  • SR: sends ACK for each correctly received segment (selective-like behavior).

Mermaid sketch of receiver buffering for SR:

Mapping to TCP: sliding window plus reliability and flow control

TCP is a widely deployed transport-layer protocol that uses a sliding window concept with:

• Cumulative acknowledgments,
• Retransmission when segments are lost (via timeouts and fast retransmit/dup ACK logic),
• Flow control based on the receiver’s advertised window,
• Congestion control that effectively constrains the send rate further.

Receiver-advertised window (flow control)

TCP’s receiver advertises how much buffer space remains. The sender’s effective window is limited by the minimum of:

• the receiver’s advertised window,
• the sender’s congestion window (from congestion control).

This ensures that the sender does not overwhelm receiver buffers while still pipelining data.

Cumulative ACKs

TCP ACKs are cumulative: an ACK for byte $b$ indicates that all bytes before $b$ have been received in order (TCP tracks bytes, not just packets). Missing data therefore eventually prevents the window from advancing, triggering retransmissions.