Feedback-Based Control

At its essence, flow control is a feedback control system. The receiver measures its state (buffer occupancy, processing rate, delay), generates a signal (ACK, window advertisement, PAUSE frame, credits), transmits it to the sender, and the sender adjusts its behavior. This feedback loop—sense, signal, respond, repeat—is the fundamental mechanism by which flow control prevents overflow.

Understanding feedback dynamics is crucial because the behavior of this loop determines whether flow control is effective. Poorly designed feedback can lead to oscillations (alternating between overflow and under-utilization), instability (runaway behavior), slow convergence (taking too long to reach optimal operation), or excessive overhead (signaling consuming bandwidth meant for data).

In this final module page, we'll analyze feedback-based flow control from a control systems perspective, examining the design principles that lead to stable, efficient operation.

A flow control feedback loop consists of five essential components, each with specific roles and design considerations:

1. Sensor (Measurement)

The receiver must measure some quantity that indicates its ability to accept more data:

• Buffer occupancy: How full are receive buffers? (bytes or percentage)
• Processing rate: How fast are frames being consumed? (frames/sec)
• Queue delay: How long are frames waiting? (time)
• Arrival rate: How fast are frames arriving? (for rate detection)

Design considerations:

• Measurement frequency: Too slow misses problems; too fast adds overhead
• Averaging: Instantaneous values are noisy; averaging provides stability but adds lag
• Threshold selection: Where does 'fine' become 'concerning'?

2. Controller (Decision Logic)

Based on sensor readings, the controller decides what action to take:

• Binary decisions: 'Stop transmitting' or 'Continue'
• Proportional decisions: 'Reduce rate by X%' or 'Window is now Y'
• Predictive decisions: 'Will overflow in T seconds at current rate'

Design considerations:

• Response function: Linear? Exponential? Step function?
• Hysteresis: Should there be a gap between 'trigger' and 'release' thresholds?
• Damping: Avoid overreaction to transient conditions

3. Signaling Mechanism (Communication)

The decision must be communicated to the sender:

• Implicit signaling: No explicit message; sender infers from ACK patterns (delayed ACK = slow down)
• Explicit signaling: Dedicated control messages (PAUSE frames, window updates)
• Piggyback signaling: Control information carried on data frames (TCP window field)

Design considerations:

• Bandwidth overhead: How much capacity do control messages consume?
• Latency: How quickly does the signal reach the sender?
• Reliability: What if a control message is lost?

4. Actuator (Sender Response)

The sender must act on received feedback:

• Rate limiting: Adjust transmission rate (packets per second)
• Window management: Track allowed outstanding data
• Timer management: Stop/start transmission timers

Design considerations:

• Response latency: How quickly can the sender change behavior?
• Granularity: Can it make small adjustments or only coarse changes?
• Buffer handling: What happens to queued data during pause?

5. Plant (The Physical System)

The link, receiver buffers, and processing constitute the 'plant' being controlled:

• Transmission delay: Data in transit from sender to receiver
• Processing delay: Time from frame arrival to processing complete
• Feedback delay: Control signal transit from receiver to sender

Design considerations:

• Total loop delay limits response speed
• Plant dynamics (buffer fill rate) determine required control aggressiveness

The choice of signaling mechanism significantly impacts flow control effectiveness, overhead, and complexity.

Implicit Signaling

No dedicated control messages; sender infers receiver state from observable behavior:

ACK Timing:

• Slow ACKs suggest receiver is busy processing
• Sender can self-regulate based on ACK arrival rate
• No explicit 'slow down' message needed

ACK Clocking:

• In TCP-like protocols, each ACK 'clocks' one segment transmission
• Receiver processing rate directly paces sender
• Self-regulating when properly implemented

Pros:

• Zero signaling overhead
• Works with legacy senders

Cons:

• Imprecise (sender guesses receiver state)
• Delayed response (wait for ACK timing to change)
• Doesn't work for broadcast/multicast

Explicit Signaling

Dedicated control messages describe receiver state:

Binary Signals (ON/OFF):

• PAUSE/Resume: Stop completely, restart when indicated
• XON/XOFF: Classic serial flow control
• Simple but all-or-nothing

Scalar Signals (Window/Credit):

• Window advertisement: 'My buffer has N bytes free'
• Credit grant: 'You may send N more frames'
• Proportional control possible

Vector Signals (Per-Class/Per-Flow):

• PFC: Separate pause per priority class
• ECN + congestion notification: Per-flow feedback
• Enables differentiated treatment

Piggyback vs. Standalone

Piggyback Signaling:

• Control info in existing traffic (ACKs, data frames)
• Example: TCP advertised window in ACK header
• Efficient if traffic is bidirectional
• Delayed if no return traffic

Standalone Signaling:

• Dedicated control frames
• Example: Ethernet PAUSE, PFC
• Always available regardless of traffic direction
• Consumes bandwidth even when not strictly needed

Flow control can be analyzed using classical control theory concepts. This provides a rigorous framework for understanding stability, convergence, and oscillation behavior.

The Flow Control System Model

We can model flow control as a linear feedback system:

• Input (Reference): Desired buffer level (e.g., 50% occupancy)
• Output: Actual buffer level
• Error: Difference between desired and actual (what controller acts on)
• Controller: Adjusts transmission rate based on error
• Plant: Buffer fill dynamics (arrival rate - service rate × dt)
• Feedback Path: Signaling from receiver to sender (with delay)

Transfer Function Representation

For a simplified model:

Buffer level change: dB/dt = R(t-τ) - μ

Where:

• B = Buffer occupancy
• R(t-τ) = Transmission rate, delayed by τ (one-way delay)
• μ = Receiver processing rate (assumed constant for simplicity)
• τ = One-way propagation delay

The total feedback loop has delay 2τ (sender→receiver→sender), which fundamentally limits control bandwidth.

Stability Considerations

Delay-Induced Instability:

Feedback delay creates phase lag that can cause instability. If the controller responds too aggressively, and the system hasn't yet felt the effect of the previous control action (due to delay), the controller overcorrects.

Stability criterion (approximate): Controller gain × RTT < constant (often ~π/2 for simple systems)

This means:

• High RTT links require gentle (low-gain) control
• Low RTT links can use aggressive control
• Same controller parameters don't work for all link types

Proportional Control:

Rate adjustment proportional to buffer error: R = R₀ - K × (B - B_target)

Where K is the proportional gain.

If K is too high: oscillations, possible instability If K is too low: slow convergence to target, buffer may overflow before control takes effect

Proportional-Integral (PI) Control:

Adds integral term to eliminate steady-state error: R = R₀ - Kp × (B - B_target) - Ki × ∫(B - B_target)dt

The integral term ensures we eventually reach exactly the target, but adds complexity and can cause 'integral windup' if not properly limited.

Beyond stability, we need flow control to converge quickly to efficient operation. Convergence speed depends on feedback timing, step sizes, and the starting point.

Convergence Considerations

Initial Conditions:

• If sender starts from zero, how quickly does it ramp to full utilization?
• If sender starts from overload, how quickly does it back off?
• Asymmetric behavior is often desirable: slow ramp-up, fast backoff

Step Size vs. Convergence Speed:

Larger adjustments per feedback cycle → Faster convergence But: Larger adjustments → More overshoot, oscillation risk

This creates the classic 'exploration vs. exploitation' tradeoff.

Feedback Frequency:

Continuous feedback:

• Every packet carries feedback (window in every ACK)
• Finest control granularity
• Higher overhead

Periodic feedback:

• Feedback sent at fixed intervals
• Lower overhead
• Coarser control, may miss rapid changes

Event-driven feedback:

• Feedback sent on threshold crossing
• Minimal overhead during steady state
• Risk of missing gradual degradation

AIMD: Additive Increase, Multiplicative Decrease

The most successful convergence algorithm is AIMD, used in TCP and many other protocols:

Additive Increase:

• When no congestion signal: Rate = Rate + α
• Linear growth, probing for available capacity
• Slow but safe exploration

Multiplicative Decrease:

• When congestion signal received: Rate = β × Rate (β < 1, typically 0.5)
• Rapid backoff from overload condition
• Fast recovery to safe operating point

Why AIMD Works:

1. Efficiency: Additive increase probes all available capacity over time
2. Fairness: Converges to equal shares regardless of starting point
3. Stability: Multiplicative decrease is aggressive enough to clear congestion
4. Responsiveness: Responds to congestion in one RTT

AIMD Dynamics:

Rate oscillates between W/2 and W in sawtooth pattern:

• Increase by α each RTT until loss/signal
• Immediately cut to 50% of current rate
• Resume additive increase

Average utilization: 75% of maximum (midpoint of sawtooth)

Even well-designed feedback systems can exhibit pathological behavior under certain conditions. Recognizing these pathologies helps in debugging and design.

Oscillation

Symptom: Buffer occupancy swings between extremes; sender alternates between full speed and stopped.

Cause: Controller gain too high relative to feedback delay; insufficient damping.

Solutions:

• Add hysteresis (different trigger and release thresholds)
• Reduce controller gain
• Use exponential smoothing on measurements
• Introduce proportional (not just on/off) control

Slow Convergence

Symptom: Takes many RTTs to reach efficient operation; poor utilization during startup.

Cause: Conservative control parameters; initial window too small.

Solutions:

• Use slow-start (exponential increase) for initial ramp-up
• Increase additive increment parameter
• Cache and reuse learned parameters (TCP persistent state)

Unfairness

Symptom: Some flows get much more bandwidth than others.

Cause: Different RTTs cause different convergence rates; non-AIMD algorithms; initial starting point advantages.

Solutions:

• Use AIMD (proven fair convergence)
• RTT-aware algorithms (adjust step size by RTT)
• Explicit fairness enforcement at switches (WFQ)

Global Synchronization

Symptom: All flows detect congestion simultaneously, back off together, then increase together. Creates waves of congestion.

Cause: Tail-drop causes simultaneous loss for all flows.

Solutions:

• Random Early Detection (RED): probabilistic early drops spread losses over time
• ECN marking: marks packets instead of dropping, less synchronized response
• Jitter in increase timing: randomize increment to desynchronize flows

Starvation

Symptom: Some flows get zero bandwidth; cannot enter the system.

Cause: Priority starvation (high priority exhausts capacity); unfair access during contention.

Solutions:

• Guaranteed minimum bandwidth per flow/class
• WFQ or similar scheduling
• Admission control to prevent oversubscription

Bufferbloat

Symptom: Very high latency during congestion; buffers fill completely before any backpressure.

Cause: Oversized buffers absorbing data that should trigger congestion signals; late detection.

Solutions:

• Size buffers to BDP, not 'as large as possible'
• Active queue management (CoDel, PIE)
• ECN to signal before queue is full

Real networks have multiple flow control mechanisms operating simultaneously at different layers and timescales. Understanding how these interact is crucial for system-level performance.

Layer Hierarchy

Typical layered flow control:

Physical/Link (microseconds):

• Ethernet PAUSE, PFC
• Credit-based (InfiniBand)
• Operates per-link, very fast

Transport (milliseconds):

• TCP sliding window
• End-to-end, spans multiple links
• Reacts to losses and RTT changes

Application (seconds):

• Rate limiting at application level
• Intentional throttling (API rate limits)
• Business logic constraints

Interactions Between Layers

Positive interaction: Lower layer protects link while higher layer optimizes end-to-end.

• Link layer PAUSE prevents immediate overflow
• TCP backs off due to increased RTT (from PAUSE-induced queuing)
• System stabilizes with both layers cooperating

Negative interaction: Layers fight each other.

• Link layer PAUSE causes RTT spike
• TCP interprets as extreme congestion, drastically reduces window
• When PAUSE releases, TCP is far below actual capacity
• Severe under-utilization until TCP slowly recovers

Design Principles for Multi-Loop Systems

Time Scale Separation:

• Fast loops handle fast transients (microsecond PAUSE)
• Slow loops handle slow phenomena (second-scale congestion)
• Loops shouldn't interfere if timescales differ by 10x+

Authority Hierarchy:

• Inner loops have local authority only
• Outer loops can override inner loops if needed
• Prevents local optimization from harming global performance

Information Sharing:

• Lower layers should expose state to higher layers (not hide it)
• Allows higher layers to interpret correctly (RTT spike due to PAUSE, not loss)
• Explicit signals (ECN) better than implicit inference

Conservative Coupling:

• When in doubt, have each layer operate independently
• Avoid tight coupling that creates complex dynamics
• Simple, loosely-coupled systems are more robust

Modern high-performance networks employ sophisticated feedback techniques that go beyond simple threshold-based control.

Model-Based Control

Instead of reacting to observed state, predict future state using a model:

Rate-based prediction:

• Measure arrival rate (λ) and service rate (μ)
• Predict buffer level: B(t+Δ) = B(t) + (λ - μ) × Δ
• Signal backpressure when predicted level exceeds threshold
• Acts before overflow, not after

Advantages:

• Proactive rather than reactive
• Smoother control (gradual rate adjustment)
• Better for high-BDP links

Challenges:

• Rate estimation is noisy
• Model may not match reality
• Prediction errors accumulate

Delay-Based Control

Control based on measured queue delay rather than queue size:

Principle:

• Queue delay = queue depth / service rate
• Delay is what users experience, measure what matters
• Low delay = light load = room to increase rate
• High delay = heavy load = should back off

Implementation (Vegas, FAST, BBR concepts):

• Measure RTT during uncongested period (RTTmin)
• Measure current RTT (RTTcurrent)
• Queue delay estimate = RTTcurrent - RTTmin
• Adjust rate to target queue delay

Explicit Rate Feedback

Instead of binary signals, communicate exact sustainable rate:

ATM ABR (Available Bit Rate):

• Switches annotate cells with 'fair share' rate
• Source adjusts to minimum rate seen along path
• Explicit, precise, but complex

QCN (Quantized Congestion Notification):

• Congested switch sends CNM with congestion quantification
• Source reduces rate proportional to severity
• Gradually increases when no further CNMs

RoCEv2/DCQCN:

• Combines ECN marking with rate-based recovery
• Rate reduction on first ECN, gradual recovery
• Optimized for data center RDMA traffic

Machine Learning Approaches

Emerging area: use ML to learn optimal control:

Reinforcement Learning:

• Agent (sender) takes actions (rate adjustments)
• Environment (network) provides reward (throughput - latency penalty)
• Learn control policy that maximizes reward

Challenges:

• Training requires significant traffic
• Generalization to unseen conditions
• Stability guarantees unclear
• Interpretability and debugging