How Zhuge Uses the Shortest Congestion‑Control Loop to Achieve Consistent Low‑Latency Real‑Time Wireless Communication

1. The Control‑Loop Expansion Problem

When available bandwidth drops sharply in wireless links—often by a factor of ten at the 99th‑percentile—packets quickly queue at the access point (AP), inflating end‑to‑end delay. Ideally, the sender would react instantly (e.g., lower encoding bitrate), but the congestion‑feedback loop traverses the same path as data packets, so acknowledgments (ACKs) and loss signals reach the sender only after the bottleneck queue delay, making the sender’s reaction the slowest precisely when the queue is forming.

The loop expands because the sender must first receive ACKs from packets already waiting in the AP’s bottleneck queue. This latency in the feedback path (i‑v in the diagram) limits rapid adaptation to wireless bandwidth fluctuations.

2. Zhuge System Overview

Zhuge consists of two modules: the delay‑prediction module Fortune Teller and the congestion‑feedback module Feedback Updater . By deploying algorithms inside the AP, Zhuge observes rapid queue growth on the downlink and either modifies or delays packets on the uplink, allowing congestion signals to reach the sender without incurring the bottleneck‑queue delay.

2.1 Delay‑Prediction Module – Fortune Teller

Fortune Teller predicts the arrival time of each packet at the receiver by decomposing total wireless delay into queueing delay and transmission delay . Queueing delay is further split into long‑term delay (qLong) – the time from packet arrival at the AP to reaching the front of the queue – and short‑term delay (qShort) – the time from the front of the queue to departure. qLong is estimated as the current queue length divided by the average dequeue rate; qShort is derived from the packet’s position near the queue head and MAC‑layer behavior. The sum qLong + qShort yields the predicted queueing delay, while transmission delay tₓ is computed from the average inter‑departure interval of packets leaving the network‑layer queue.

2.2 Congestion‑Feedback Module – Feedback Updater

Zhuge classifies RTC transport protocols into In‑band (feedback embedded in payload, e.g., RTP/RTCP) and Out‑of‑band (feedback via separate ACKs, e.g., TCP). For Out‑of‑band feedback, Zhuge deliberately delays ACKs when congestion is detected, causing the congestion‑control algorithm (CCA) to perceive congestion earlier. For In‑band feedback, Zhuge replaces the payload of feedback packets with the predicted delay information from Fortune Teller.

When a packet arrives at the AP, Fortune Teller predicts its delay. Feedback Updater then injects this estimate into the next uplink feedback packet (ACK or TWCC‑FB). Consequently, the sender receives congestion information ahead of the original ACK that would have been delayed by the bottleneck queue.

3. Experimental Evaluation

The authors evaluated Zhuge on two transport stacks: RTP/RTCP (using GCC) for In‑band feedback and TCP for Out‑of‑band feedback. Experiments were run in five realistic network traces, comparing Zhuge against various AQM policies (e.g., CoDel) and different CCAs. Results show that Zhuge reduces wireless tail latency by up to 75%, improves overall RTC performance by up to 91%, and raises combined network‑and‑application metrics from 17% to 94.7%.

4. References

[1] Zili Meng, Yaning Guo, Chen Sun, Bo Wang, Justine Sherry, Hongqiang Harry Liu, and Mingwei Xu. 2022. Achieving consistent low latency for wireless real‑time communications with the shortest control loop. In Proceedings of the ACM SIGCOMM 2022 Conference (SIGCOMM ’22), 193–206. https://doi.org/10.1145/3544216.3544225.