Difference Between Open-Loop and Closed-Loop Congestion Control

Congestion control in computer networks can be organized by whether the sender explicitly uses feedback from the network when deciding how fast to transmit. In this framing:

• Open-loop congestion control makes transmission-rate decisions without (or with minimal) real-time feedback from the instantaneous congestion state.
• Closed-loop congestion control continuously (or periodically) measures/infers congestion signals and adjusts the sending rate accordingly.

A helpful mental model is control theory: open-loop is like running a controller without measuring the output, while closed-loop measures outcomes and corrects errors.

However, “open vs closed loop” can mean different granularities in networking literature: some schemes are loosely closed-loop (e.g., longer sampling intervals or indirect signals), while many real systems are hybrid (e.g., pacing + feedback).

Major reference terms to track in this section: Feedback signal; Control loop; ECN; Queueing delay.

To compare the two approaches precisely, it helps to separate (1) what the controller is using, (2) how quickly it reacts, and (3) what stability/accuracy guarantees you can expect.

1) Signal path: with or without feedback

• Open-loop: The sender follows a pre-planned policy derived from estimates (e.g., historical RTT, capacity provisioning, or statistical models). The controller does not directly “measure congestion now → adjust now” in the same control interval.
• Closed-loop: The sender reads congestion indicators (loss, ECN marks, growing RTT/queueing delay) and then modifies the rate.

In control-theory language: open-loop uses an input $u(t)$ and a model, while closed-loop uses an additional measured output/error term $e(t)$ to correct actions.

2) Reaction time and tracking

Closed-loop schemes can, in principle, track changing conditions because they use measurements (feedback). Open-loop schemes can be simpler and may require less per-packet/round-trip inference, but they may drift when the network conditions differ from the model.

3) Stability and oscillations

In closed-loop control, aggressive feedback can cause oscillations (e.g., periodic overshoot/undershoot). Open-loop can avoid feedback-induced oscillations, but it may be unstable relative to mismatch between model and reality (e.g., underestimating cross-traffic can still overload buffers).

Open-loop congestion control: characteristics, strengths, limitations

Open-loop congestion control typically includes:

Common characteristics

• Model-driven decisions: Uses prior measurements or provisioning data (e.g., estimated available bandwidth).
• No immediate congestion correction: Rate doesn’t directly respond to instantaneous congestion indicators each control interval.
• May use probabilistic shaping: Sometimes uses statistical multiplexing assumptions.

Strengths

• Low complexity and minimal dependence on fast feedback channels.
• Can work reasonably well if traffic conditions match the model.

Limitations

• Susceptible to model mismatch: if cross-traffic changes abruptly, the sender may inject too fast (causing queues/loss) or too slow (underutilization).
• Harder to guarantee fairness and responsiveness under dynamic conditions without feedback.

Closed-loop congestion control: characteristics, strengths, limitations

Closed-loop congestion control typically includes:

Common characteristics

• Feedback signals: loss (e.g., packet drops), ECN marks, increasing delay/RTT, or queue occupancy estimates.
• Control law updates: sender updates congestion window/rate based on feedback.
• Iterative correction: repeated measurement-action cycles.

Strengths

• Better responsiveness to changing network conditions.
• Can be designed to achieve fairness and stability properties (depending on algorithm).

Limitations

• Feedback delay and quantization can degrade stability (e.g., delayed signals cause overcorrection).
• More complex than open-loop and may require careful parameter tuning.

Concrete examples (how the “loop” appears in practice)

Real systems often blur the boundary:

• Pure open-loop (rare in practice): A sender sets a rate from a schedule/capacity estimate and does not adjust in response to observed congestion.
• Classic closed-loop (common): TCP-style algorithms adjust the congestion window based on inferred congestion signals (e.g., loss or delay).
• Hybrid approaches: Some parts are open-loop (e.g., pacing based on a rate estimate), while corrections come from closed-loop feedback.

To classify a scheme, ask: “If the network becomes congested right now, does the sender change behavior based on a signal observed at that time scale?”

• If yes → closed-loop.
• If no → open-loop (or not fully closed-loop).