Sliding Window Protocol: Error, Flow, and Concurrency—What It Does (and Doesn’t)
The sliding window protocol is primarily a Transport-layer mechanism for reliable communication over an unreliable channel. It uses a window of sequence numbers to decide which frames/segments may be in transit, which acknowledgements are acceptable, and how far the sender may advance without waiting—enabling both pipelining and robustness to loss/corruption.
In exam-style multiple choice terms, sliding window protocols are used for:
- (i) error control ✅
- (iii) flow control ✅
- (iv) concurrency control ✅ (in the sense of managing multiple outstanding unacknowledged frames via pipelining)
- (ii) session control ❌ (typically handled by connection/session establishment/teardown, not by the sliding window mechanism itself)
A simple way to remember this mapping is:
Key terms: Sliding window ARQ ACK Flow control.
Note: I attempted to perform web research using the required web-search tool, but the environment returned quota-limit errors, so I cannot provide the mandatory external citations/footnotes for factual claims.
Sliding Window Protocol (ARQ, TCP ideas) — Learning Video
What the sliding window protocol does (core mechanics)
A sender maintains a window spanning a range of sequence numbers that it is allowed to transmit (and that the receiver may accept). As acknowledgements arrive, the sender’s window “slides” forward.
At a high level, sliding window reliability typically appears as:
- Stop-and-wait (window size 1) → simplest error control, low throughput
- Go-Back-N ARQ (window size > 1) → retransmit from the first missing frame
- Selective Repeat ARQ (window size > 1) → retransmit only the missing frames
This same window idea also supports flow control: the receiver can limit how many frames it can accept based on its buffer capacity.
Mermaid view of sender/receiver interaction:
Key terms: Go-Back-N Selective Repeat Retransmission.
Mapping the sliding window protocol to the four controls
- 1Step 1
Sliding windows enable ARQ: the receiver uses ACKs (and sometimes NAKs) to detect lost/corrupted frames and the sender retransmits according to the protocol variant (e.g., Go-Back-N vs Selective Repeat).
- 2Step 2
The sender’s allowed outstanding data is constrained by the receiver’s advertised window/buffer availability—so the receiver is not overwhelmed.
- 3Step 3
Session/connection establishment and teardown (e.g., “start connection”, “close connection”) are managed by separate connection-management mechanisms/protocol phases, not by the sliding window’s purpose.
- 4Step 4
By limiting the number of unacknowledged frames in flight, sliding windows act like a concurrency limiter: multiple frames can be outstanding, but not unboundedly.
Why it is error control (i)
Error control means ensuring correct delivery in the presence of:
- lost frames (no delivery)
- corrupted frames (detected by checksums/CRC)
- out-of-order arrival
Sliding window ARQ provides this by:
- assigning sequence numbers,
- acknowledging what arrived correctly, and
- triggering retransmissions for missing/incorrect data.
Key terms: CRC Sequence number Retransmission timer.
Why it is flow control (iii)
Flow control avoids overwhelming the receiver. Sliding window protocols do this by bounding how much data the sender can send before receiving further permission/acknowledgements.
In practice (classic TCP-style logic), the receiver can advertise how much space it has available, effectively setting the usable window. The sender then ensures it never has more than that amount of unacknowledged data in flight.
Key terms: Receive buffer Advertised window Backpressure.
Why it is concurrency control (iv)
“Concurrency control” here refers to controlling the number of concurrent, in-flight transmissions. Sliding windows allow pipelining: the sender can transmit multiple frames without waiting for each one individually (unlike stop-and-wait).
But it does so boundedly, using the window size :
- at most outstanding frames
- sender advances when ACKs arrive
- retransmissions handle failures
So sliding window is a control mechanism over multiple simultaneous outstanding operations.
A compact model:
- Sender state maintains a range of allowed sequence numbers.
- ACK reception creates progress; missing ACKs trigger timeouts/retransmissions.
Key terms: Pipelining In-flight Window size.
Why it is not session control (ii)
Session control typically includes:
- establishment of a communication session/connection
- termination/teardown
- sometimes negotiation of parameters
Sliding window ARQ primarily addresses correctness and rate matching during the data transfer phase. Session establishment/teardown is handled by separate protocol mechanisms/phases (e.g., connection setup/close in connection-oriented protocols), rather than being defined by the sliding window mechanism itself.
Key terms: Session establishment Connection teardown Transport layer signaling.
Exam shortcut
If the options mention ACKs/retransmission, choose error control. If they mention receiver buffer/rate limiting, choose flow control. If they mention limiting multiple outstanding frames, choose concurrency (bounded pipelining).
Terminology pitfall
“Concurrency control” is not the same as DB transaction locks. In networking courses, it usually means controlling concurrent outstanding transmissions (bounded in-flight data), which sliding windows do via window size.
Which control categories sliding window maps to?
Conceptual mapping used in typical Computer Networks coursework.
Common variants and how they affect error control
Knowledge Check
Sliding window protocol is primarily used to provide which of the following?