§ 6.2  Module 6 — Surviving the Network: Loss, Congestion, and Jitter

Guessing the Pipe: Bandwidth Estimation and GCC

"The network is reliable." — Fallacy #1 of distributed computingCourse notes

Why loss-based congestion control is too late for real-time: delay-gradient estimation, the arrival-time filter, REMB's receiver-side legacy versus transport-cc's sender-side design, probing, and how BWE couples to the encoder's rate controller.

Cross-references: GCC & Bandwidth Estimation.

6.2.0Learning objectives

• Explain why queuing delay rises before loss appears, and why that ordering matters
• Implement inter-group delay-variation computation and a threshold-based overuse detector
• Implement the AIMD rate controller (increase/hold/decrease) with a loss-based backstop
• Trace the REMB → transport-cc migration and read availableOutgoingBitrate live

6.2.1Bufferbloat; delay gradient as the early-warning signal

A queue announces congestion through rising delay before it drops packets. GCC groups packets, compares send-time and arrival-time deltas, filters the noisy gradient, and lets an AIMD controller reduce the encoder target before bufferbloat consumes the latency budget.

Engineering consequence. Bufferbloat; delay gradient as the early-warning signal. Verify the behavior with a controlled trace before interpreting a live call: establish the expected state, change one variable, and compare deltas rather than isolated values. In production, attach the observation to a timestamp and media direction so the same evidence cannot be mistaken for a different failure.

6.2.2Arrival-time model, per-group deltas, Kalman → trendline evolution

The operational claim is precise: Arrival-time model, per-group deltas, Kalman → trendline evolution. Treat it as an observable contract. Record the state transition or counter that proves it, test the failure path as well as the happy path, and keep units and clock domains explicit. That discipline is what separates a plausible WebRTC explanation from a production diagnosis.

Engineering consequence. Arrival-time model, per-group deltas, Kalman → trendline evolution. Verify the behavior with a controlled trace before interpreting a live call: establish the expected state, change one variable, and compare deltas rather than isolated values. In production, attach the observation to a timestamp and media direction so the same evidence cannot be mistaken for a different failure.

6.2.3AIMD controller

The controller increases cautiously while the path is normal, holds when evidence is ambiguous, and decreases multiplicatively on overuse. A loss backstop remains useful, but waiting for double-digit loss alone reacts after the real-time experience is already damaged.

Engineering consequence. AIMD controller: increase/hold/decrease; loss-based backstop (>10%). Verify the behavior with a controlled trace before interpreting a live call: establish the expected state, change one variable, and compare deltas rather than isolated values. In production, attach the observation to a timestamp and media direction so the same evidence cannot be mistaken for a different failure.

6.2.4REMB (legacy, receiver-side) vs transport-cc (send-side TWCC feedback)

The operational claim is precise: REMB (legacy, receiver-side) vs transport-cc (send-side TWCC feedback). Treat it as an observable contract. Record the state transition or counter that proves it, test the failure path as well as the happy path, and keep units and clock domains explicit. That discipline is what separates a plausible WebRTC explanation from a production diagnosis.

Engineering consequence. REMB (legacy, receiver-side) vs transport-cc (send-side TWCC feedback). Verify the behavior with a controlled trace before interpreting a live call: establish the expected state, change one variable, and compare deltas rather than isolated values. In production, attach the observation to a timestamp and media direction so the same evidence cannot be mistaken for a different failure.

6.2.5Probing, ALR, pacing; BWE → encoder target coupling

The operational claim is precise: Probing, ALR, pacing; BWE → encoder target coupling. Treat it as an observable contract. Record the state transition or counter that proves it, test the failure path as well as the happy path, and keep units and clock domains explicit. That discipline is what separates a plausible WebRTC explanation from a production diagnosis.

Engineering consequence. Probing, ALR, pacing; BWE → encoder target coupling. Verify the behavior with a controlled trace before interpreting a live call: establish the expected state, change one variable, and compare deltas rather than isolated values. In production, attach the observation to a timestamp and media direction so the same evidence cannot be mistaken for a different failure.

6.2.AA worked reasoning trace

Start with the claim “Bufferbloat; delay gradient as the early-warning signal” and turn it into a falsifiable trace. Write down the input condition, the expected state transition, the counter or packet field that should change, and the deadline by which it must change. This prevents a familiar mistake: observing a symptom after several mechanisms have already reacted and assigning it to whichever mechanism has the most recognizable name. The causal order matters. A queue grows before loss; an ICE path fails before a restart selects a new pair; a decoder loses reference state before frames stop rendering. Preserve that order in the evidence.

Now hold every unrelated variable still. Use canned timestamps, SDP, stats-shaped records, or a permission-free loopback source so the same input can be replayed. Record both media directions separately. For cumulative counters, retain two samples and divide the difference by their timestamp interval. For state machines, retain the ordered event sequence rather than the last state alone. For negotiated features, compare the offer, answer, and live stats result. These three views answer different questions: what was proposed, what was accepted, and what the browser actually used.

The first lab, The Delay-Gradient Detective, applies this discipline to a bounded implementation problem. Given canned per-packet-group (sendTime, arrivalTime, size) traces, implement inter-group delay-variation and a trendline/threshold overuse detector emitting normal/overuse/underuse. Assertions: overuse fires within N groups of the known congestion onset, zero false positives on the jittery-but-clean trace (the hard case); hints catch per-packet-instead-of-per-group deltas and single-spike triggering. Before coding, identify the invariant hidden in that brief and the tempting shortcut the tests should reject. Then run the reference trace, perturb one boundary value, and explain why the result changes. If the code passes but the explanation cannot predict the perturbed result, the implementation is memorized rather than understood.

6.2.BVerification protocol

1. Name the budget. State whether the scarce quantity is latency, bitrate, CPU, memory, reliability, or negotiation time, and attach a unit.
2. Choose the observation point. Decide whether proof lives in SDP, an RTP/RTCP field, an API state, an event sequence, decoded output, or a joined stats record.
3. Build the clean control. Establish one trace in which the mechanism succeeds before injecting loss, delay, glare, a codec mismatch, or a network change.
4. Change one variable. Keep clocks, direction, source cadence, and topology fixed so the observed difference has a defensible cause.
5. Test both sides of the threshold. A deadline or bitrate rule is not demonstrated by one passing value; include a value just inside and just outside the boundary.
6. Close the loop. After acting, prove that the intended media outcome changed. Calling an API successfully is not evidence that frames flowed or quality recovered.

6.2.CProduction boundaries

A browser loopback is deliberately cleaner than the internet. It removes signaling latency, hostile NAT behavior, relay geography, wireless contention, device heat, and competing encoders. That makes it ideal for proving protocol and API invariants, but a dangerous basis for capacity claims. Carry the invariant into a second test with a canned hostile trace: reordered packets, a delayed candidate, a missing remote stats object, a bitrate step, or a state transition that recovers before the debounce timer. The implementation should remain correct even when optional fields are absent and events arrive more than once.

Feature detection is also part of correctness. Browser support for a codec, scalability mode, encoded transform, or transport API does not imply that the negotiated peer supports it or that hardware acceleration is active. Prefer capability checks, preserve a standards-based fallback, and label any simulation honestly. The graded result should measure the learner's algorithm; an optional live coda may demonstrate the real API without making a camera, operating-system codec, or network service a hidden test dependency.

Finally, connect the mechanism to the last topic in the lesson: “Probing, ALR, pacing; BWE → encoder target coupling”. Advanced WebRTC failures cross boundaries. Congestion control changes encoder output; layer selection changes keyframe demand; end-to-end encryption constrains what an SFU can inspect; a watchdog can collide with negotiation; observability can mislabel a path if its joins are wrong. At every boundary, define ownership and an idempotent action. A retry must not create duplicate work, a stale event must not overwrite newer state, and an escalation must have a terminal cleanup path.

Use the problem set as an executable notebook. Keep a short record beside each answer: the invariant, the decisive evidence, the rejected alternative, and the production caveat. That record is more valuable than a green checkmark because it can be reused when a real call presents the same mechanism through noisier evidence.

Problems for § 6.2Executable understanding

Implement the decision rules, run every assertion, then use the explanations to distinguish a wrong result from a wrong model.

The Delay-Gradient Detective. Given canned per-packet-group (sendTime, arrivalTime, size) traces, implement inter-group delay-variation and a trendline/threshold overuse detector emitting normal/overuse/underuse. Assertions: overuse fires within N groups of the known congestion onset, zero false positives on the jittery-but-clean trace (the hard case); hints catch per-packet-instead-of-per-group deltas and single-spike triggering.

The AIMD Rate Controller. Implement the rate-control state machine consuming ex1's detector output plus loss reports: 0.85× multiplicative decrease, additive increase, hold state. Run against three canned scenarios (ramp-up, sudden bottleneck, periodic cross-traffic). Assertions: converges within ±20% of bottleneck, backs off within 2s of onset, bounded oscillation, never increases during overuse. A real-api coda observes availableOutgoingBitrate on live loopback stats and confirms transport-cc in the SDP; the coda is feature-detected and never blocks the grade (label reflects the most environment-demanding component per the cadence convention).