Paper: ACE: Sending Burstiness Control for High-Quality Real-time Communication
Authors: Xiangjie Huang, Jiayang Xu, Haiping Wang, Hebin Yu, Sandesh Dhawaskar Sathyanarayana, Shu Shi, Zili Meng
Presenter: Zhiqing Li, Central South University
Guest of Honor: Xiangjie Huang, The Hong Kong University of Science and Technology
Q: Is the encoder-and-pacer approach lightweight enough for resource-constrained devices such as mobile phones or IoT devices?
A: The pacing component is lightweight and does not create a major memory or power burden. We validated the design in collaboration with ByteDance in a mobile cloud-gaming setting, where the pacing-side changes could be deployed with relatively small modifications to the RTC code. The more difficult part is encoder control: mobile devices often rely on hardware encoding, and those hardware encoders expose limited configuration flexibility. In practice, the hardware encoder is a more important deployment constraint than the pacer itself.
Q: The paper identifies pacing latency as an overlooked bottleneck. Is that delay independent of the congestion-control algorithm?
A: No. In fact, the pacing delay is closely related to the CCA. RTC congestion-control algorithms often intentionally estimate bandwidth conservatively in order to avoid queues and keep latency low. That behavior is generally desirable, but it becomes problematic when frame sizes fluctuate and an unusually large frame must be sent. The frame can then spend excessive time waiting in the pacer.
Q: Is pacing delay a large fraction of the total delay in every case?
A: No. It is mainly a tail-latency problem. In ordinary cases, the average end-to-end latency is around the normal operating range, and pacing delay is not dominant. The pacing bottleneck becomes important in high-latency tail cases, particularly when unusually large frames appear.
Q: What is the relationship between congestion-control design and RTC-system design?
A: They are tightly connected. RTC systems care strongly about latency, stability, and avoiding visible freezes or stalls, while a general CCA may balance latency against throughput differently. For latency-sensitive RTC applications, queue buildup is especially undesirable, so congestion-control designs are often tuned to be conservative. The boundary is therefore not a clean separation; it is largely a difference in how the trade-offs are prioritized.
Q: Can new general-purpose congestion-control algorithms be adopted directly by RTC systems?
A: Not necessarily. GCC remains widely deployed in RTC, while some newer algorithms that work well in other settings do not translate directly. The speaker gave the example of attempts to adapt BBR-like approaches to WebRTC, where tail latency was not satisfactory and the feature was not kept as the default. This suggests that congestion-control research and RTC research need more interaction rather than assuming that a good general CCA will automatically be good for RTC.
Q: Why does deploying a new CCA in RTC require so much parameter tuning?
A: The network can degrade within a single control loop or RTT, before the system has enough time to react. To avoid a visible stall, RTC systems often have to behave conservatively before the degradation is fully observed. That leaves less room for aggressive throughput/latency trade-offs. In practice, a new CCA may require substantial tuning before it is safe for RTC, and after enough tuning it can even become behaviorally similar to an existing conservative RTC controller.
Q: Does industry also tend to prefer simpler congestion-control algorithms for RTC?
A: Yes, at least in the speaker’s experience. Sophisticated algorithms may look attractive in a paper, but deployment requires predictable behavior and extensive tuning under real network variation. Simpler mechanisms are often easier to make robust in production.
Q: Which part of this research was the most challenging and time-consuming?
A: The encoding side took the most effort. We initially believed the key problem was how to reduce unusually large encoded frames without hurting visual quality, so a large amount of time went into adapting video-encoding techniques to RTC. Ironically, the pacing-side design was developed later and required less effort, yet delivered a larger performance gain. That experience showed how easy it is to spend time optimizing the wrong bottleneck.
Q: How did you know when to stop optimizing the encoder and move to the pacing component?
A: We moved on when experiments showed that aggressive encoder-side tuning could no longer eliminate the extra latency. Even after reducing frame size as much as practical, some tail delays remained. Further profiling showed that packets were waiting inside the pacer, which revealed that the remaining bottleneck had shifted from encoding to the network pacing stage.
Q: How do you find the right trade-off between the encoder optimization and the pacing optimization?
A: In this design, there is not a single explicit “sweet spot” between the two. Each component is expected to do its own job as effectively as possible. The important systems lesson is to locate the actual bottleneck first; if we had identified the pacer bottleneck earlier, we would probably have optimized the pacing side before spending so much effort on encoding.
Q: Why is profiling RTC systems particularly difficult?
A: Tail-latency failures in RTC are often not caused by one component that is clearly broken. Every component may appear functional, yet the end-to-end system still produces a bad tail event because several components are not operating optimally together. That makes conventional fault localization difficult and motivates more systematic RTC profiling.
Q: What new challenges arise if AI agents are used to diagnose RTC systems?
A: Modern RTC deployments already expose large amounts of production telemetry and dashboards, but those interfaces were designed primarily for human operators. Simply giving those dashboards to an AI agent does not mean the agent can diagnose or fix the problem. A key research challenge is therefore to design telemetry and profilers that are machine-readable and structured enough for agents to reason about reliably.
Q: What advice would you give to new graduate students entering this area?
A: Do not force every new problem into the area you already know best. I came from video encoding, so I initially interpreted the problem through that lens and spent a lot of time there. If I could restart the project, I would first profile the whole system and identify the real bottleneck before choosing which component to optimize.