Loading learning content...
We've analyzed the efficiency formulas. We've quantified the complexity costs. Now comes the practical question every network engineer must answer: Which protocol should I use for this specific scenario?
This page synthesizes our analyses into a decision framework. Rather than abstract comparisons, we'll examine concrete deployment scenarios—from IoT sensors to intercontinental data centers—and determine the optimal protocol for each. You'll leave with actionable guidelines applicable to real system design.
By the end of this page, you will be able to select the optimal ARQ protocol for any scenario by evaluating bandwidth-delay product, error rates, resource constraints, and application requirements. You'll understand the decision criteria used in real protocols (HDLC, PPP, TCP, WiFi) and be able to justify protocol choices with quantitative reasoning.
Protocol selection isn't a single-factor decision. Multiple variables interact, and the optimal choice emerges from balancing competing concerns.
Primary Decision Factors:
The Decision Tree:
The following decision tree captures the structured approach to protocol selection:
Is a > 0.1?
/ \
No Yes
| |
Stop-and-Wait Is error rate p > 0.01?
(sufficient) / \
No Yes
| |
Is receiver memory Is receiver memory
constrained? available?
/ \ / \
Yes No No Yes
| | | |
Go-Back-N Either OK Go-Back-N Selective
(saves (GBN (accept Repeat
memory) simpler) inefficiency) (optimal)
This simplifies the multi-factor decision into a sequential evaluation.
Small 'a', low errors → Stop-and-Wait. Large 'a', low errors, constrained receiver → Go-Back-N. Large 'a', high errors, or when throughput is paramount → Selective Repeat. This covers 90% of decisions.
Despite its efficiency limitations, Stop-and-Wait remains the right choice for many scenarios. Its simplicity provides reliability, low resource requirements, and ease of implementation that more complex protocols cannot match.
Ideal Conditions for Stop-and-Wait:
| Application | Why Stop-and-Wait | Key Characteristic |
|---|---|---|
| XMODEM file transfer | Simple, widely implemented, 8-bit micro compatible | Legacy over serial links |
| TFTP (Trivial FTP) | UDP-based, minimal state, early bootloader use | Simple file download |
| Modbus RTU (polling) | Industrial sensors, 9600 baud typical | Low-speed serial |
| I²C protocol | On-chip communication, nanosecond propagation | Negligible BDP |
| Bootloader protocols | Runs before OS, minimal RAM available | Constrained state |
| Simple serial consoles | Interactive, human typing speed is bottleneck | Irrelevant efficiency |
| Flash reprogramming over SWD | Reliability paramount, speed acceptable | Safety-critical path |
Numerical Justification:
Consider a Modbus sensor network:
Calculations: $$t_f = \frac{2048}{9600} = 213 \text{ ms}$$ $$a = \frac{1 \text{ ms}}{213 \text{ ms}} = 0.0047$$ $$\eta_{SW} = \frac{1}{1 + 2(0.0047)} = 99.1%$$
Stop-and-Wait achieves 99.1% efficiency! Pipelining would add complexity for <1% improvement. This is a perfect Stop-and-Wait scenario.
Stop-and-Wait naturally provides flow control—the sender cannot overwhelm the receiver because it waits for acknowledgment before continuing. This implicit flow control is valuable when receiver processing speed varies or is unknown. Pipelined protocols must explicitly manage flow control.
Go-Back-N occupies the middle ground—substantial efficiency improvement over Stop-and-Wait with moderate complexity increase. It's particularly suited to scenarios with high BDP but reliable channels.
Ideal Conditions for Go-Back-N:
| Application | Why Go-Back-N | Key Characteristic |
|---|---|---|
| HDLC (High-Level Data Link Control) | Standard for WANs, well-established | N=7 or N=127 typical |
| LAPB (X.25 Layer 2) | Legacy packet networks, reliable WAN | Balanced configuration |
| PPP (Point-to-Point Protocol) | Modern dial-up, DSL encapsulation | Modem/phone links |
| Frame Relay | WAN service, PVC circuits | Provider network links |
| Early TCP implementations | Before SACK, cumulative ACK only | Historical simplicity |
| Bluetooth L2CAP (basic mode) | Simple flow control mode | Short-range wireless |
| Satellite modems (basic) | Simple receiver for mobile terminals | Power-constrained RX |
Numerical Justification:
Consider an HDLC link to a branch office:
Calculations: $$t_f = \frac{8000}{2 \times 10^6} = 4 \text{ ms}$$ $$a = \frac{10 \text{ ms}}{4 \text{ ms}} = 2.5$$ $$1 + 2a = 6 \quad \text{and} \quad N = 7 \geq 6 \quad \checkmark$$
Error-free efficiency: 100% (window sufficient)
With errors: $$\eta_{GBN} = \frac{1 - 0.001}{1 + 7 \times 0.001} = \frac{0.999}{1.007} = 99.2%$$
At 0.1% error rate, GBN is 99.2% efficient. Selective Repeat would provide 99.9%, but the 0.7% difference doesn't justify the added complexity. This is a classic GBN scenario.
If the error rate were 5% instead of 0.1%, GBN efficiency drops to 73.6% while SR maintains 95%. The crossover point varies with window size—larger windows make GBN's error sensitivity worse. Always check the expected error rate when choosing GBN.
Selective Repeat is the protocol of choice when throughput maximization justifies the complexity investment. High error rates, expensive bandwidth, or demanding applications make SR's efficiency essential.
Ideal Conditions for Selective Repeat:
| Application | Why Selective Repeat | Key Characteristic |
|---|---|---|
| TCP with SACK option | Dominant Internet transport, SR semantics | High-BDP paths, diverse errors |
| SCTP (Stream Control TP) | Multi-streaming, mobile handoff | Advanced transport needs |
| WiFi 802.11 Block ACK | Wireless error rates, aggregation | OFDM frame bursting |
| Satellite DVB-S2 RCS2 | 500ms RTT, expensive bandwidth | GEO satellite links |
| 5G NR HARQ | Hybrid ARQ with SR scheduling | High-speed mobile |
| QUIC protocol | HTTP/3 transport, loss recovery | Modern web transport |
| iSCSI/FCoE storage | Data integrity critical, high throughput | Datacenter storage |
Numerical Justification:
Consider a GEO satellite internet terminal:
Calculations: $$t_f = \frac{12000}{50 \times 10^6} = 0.24 \text{ ms}$$ $$a = \frac{270 \text{ ms}}{0.24 \text{ ms}} = 1125$$ $$1 + 2a = 2251 \quad \text{and} \quad N = 4096 \geq 2251 \quad \checkmark$$
Go-Back-N efficiency: $$\eta_{GBN} = \frac{1 - 0.02}{1 + 4096 \times 0.02} = \frac{0.98}{82.92} = 1.18%$$
Selective Repeat efficiency: $$\eta_{SR} = 1 - 0.02 = 98%$$
Throughput difference:
Selective Repeat provides 83× higher throughput in this scenario. The complexity investment is overwhelmingly justified.
On any modern system with adequate memory, Selective Repeat is the default choice for significant data transfer. TCP SACK is enabled by default on virtually all operating systems. The question has shifted from 'Can we afford SR complexity?' to 'Why would we accept anything less?'
Real-world protocols often combine features from multiple ARQ approaches or adapt their behavior based on channel conditions. This section examines these hybrid strategies.
TCP: The Premier Hybrid Example
TCP demonstrates how protocol design evolves beyond textbook categories:
Adaptive Protocol Design:
Some protocols adapt strategy based on observed conditions:
802.11 (WiFi) Block ACK:
LTE/5G HARQ:
SCTP Multi-streaming:
Benefits of Adaptation:
| Benefit | Description | Example |
|---|---|---|
| Graceful degradation | Works with less-capable endpoints | TCP without SACK falls back to GBN |
| Optimal efficiency | Matches strategy to current conditions | WiFi switches Normal/Block ACK |
| Resource scaling | Uses complexity only when needed | SACK processing only on loss |
| Backwards compatibility | New versions work with old | TCP SACK is optional |
| Resilience | Multiple mechanisms provide redundancy | Fast retransmit + timeout as backup |
When designing new protocols, consider building in extension mechanisms (like TCP options). Starting simple with room for enhancement allows deployment on constrained devices while enabling optimization on capable ones. The entire progression from SW to GBN to SR can then be traversed as the ecosystem matures.
Let's apply our decision framework to diverse real-world scenarios, demonstrating the reasoning process for protocol selection.
Scenario: Agricultural IoT sensors reporting soil moisture to a gateway.
Characteristics:
Analysis: $$t_f = \frac{408 \text{ bits}}{5500 \text{ bps}} = 74 \text{ ms}$$ $$a = \frac{0.017 \text{ ms}}{74 \text{ ms}} \approx 0.0002$$
With a = 0.0002, Stop-and-Wait efficiency is 99.96%. Additionally:
Decision: Stop-and-Wait (LoRaWAN uses confirmed messages with SW semantics)
Notice the patterns: IoT and legacy = Stop-and-Wait; datacenter and satellite = Selective Repeat; moderate WAN with good reliability = Go-Back-N. The bandwidth-delay product and error rate are the dominant factors, with resource constraints as a tiebreaker.
The following matrix consolidates protocol selection guidance. Use the parameters of your scenario to identify the recommended protocol.
| BDP (a) | Error Rate (p) | Receiver Memory | Recommended Protocol |
|---|---|---|---|
| Low (a < 0.2) | Any | Any | Stop-and-Wait |
| Medium (0.2 ≤ a < 10) | Low (p < 0.5%) | Constrained | Go-Back-N |
| Medium (0.2 ≤ a < 10) | Low (p < 0.5%) | Available | GBN or SR (either acceptable) |
| Medium (0.2 ≤ a < 10) | High (p ≥ 0.5%) | Constrained | GBN (accept efficiency loss) |
| Medium (0.2 ≤ a < 10) | High (p ≥ 0.5%) | Available | Selective Repeat |
| High (a ≥ 10) | Low (p < 0.1%) | Constrained | Go-Back-N |
| High (a ≥ 10) | Low (p < 0.1%) | Available | SR (future-proofs for errors) |
| High (a ≥ 10) | Medium (0.1% ≤ p < 1%) | Any | Selective Repeat |
| High (a ≥ 10) | High (p ≥ 1%) | Any | Selective Repeat |
Quick Reference Formulas:
When deciding between protocols, these formulas help quantify the benefit:
Stop-and-Wait efficiency check: If η_SW = 1/(1+2a) > 80%, Stop-and-Wait is probably sufficient. This requires a < 0.125.
GBN vs SR crossover: The efficiency ratio is η_SR/η_GBN = (1+Np) when window is sufficient. SR is 2× better when Np = 1, i.e., when N × p = 1.
For N=127, this means SR is 2× better at p = 0.8%. For N=7, SR is 2× better at p = 14%.
Required window size: For full efficiency: N ≥ 1 + 2a Practical margin: N ≥ 1.5 × (1 + 2a) to handle burst losses
The matrix focuses on performance. If implementation time is constrained or verification requirements are stringent, bias toward simpler protocols. A working Stop-and-Wait today beats a buggy Selective Repeat next month.
We've developed a complete framework for ARQ protocol selection, combining efficiency formulas, complexity analysis, and practical considerations:
What's Next:
With protocol selection mastered, the final page applies everything to numerical problem-solving. We'll work through comprehensive exam-style problems that require calculating efficiency, comparing protocols, and determining optimal configurations—cementing your ability to apply these concepts quantitatively.
You can now select the optimal ARQ protocol for any scenario by systematically evaluating bandwidth-delay product, error rate, and resource constraints. You understand when each protocol excels and have seen real-world case studies demonstrating the selection process. Next, we'll reinforce these skills through numerical problem practice.