Zhuge: Achieving Consistent Low Latency for Wireless Real-Time Communications with the Shortest Control Loop

核心问题与背景

• 实时通信 (RTC) 应用 (如视频会议, 云游戏) 需要持续的低延迟体验
• 尽管无线网络 (如 WiFi, 蜂窝网络) 的中位数延迟令人满意, 但由于无线带宽的频繁和大幅波动, 其尾部延迟 (tail latency) 非常严重
• 当无线接入点 (AP) 发生拥塞时, RTC 应用的发送速率控制环路会被拉长, 导致发送端无法及时适应无线网络的动态变化
• 传统的解决方案受限于这种被拉长的控制环路, 因为 拥塞信号 (如延迟或丢包) 必须穿过拥塞的队列才能反馈给发送端

Zhuge 解决方案

论文提出了一种名为 Zhuge 的纯无线 AP 端解决方案, 其核心思想是: 通过将拥塞反馈与拥塞队列分离开来, 从而缩短 RTC 应用的控制环路

• 该方案包含一个 Fortune Teller (预测器) 模块, 能够在数据包到达无线 AP 时, 精确预估每个数据包的无线延迟
• 为了实现大规模部署, Zhuge 还设计了一个 Feedback Updater (反馈更新器)
  • 该更新器能将预估的延迟转化为不同协议 (如带内反馈或带外反馈协议) 能理解的反馈消息, 并立即将其传回给发送端进行速率自适应调整
  • 这种设计只需修改最后一公里的路由器 (AP), 无需修改发送端或接收端的主机, 极大降低了部署门槛

Introduction

(1) 背景与面临的尾部延迟问题

• RTC 应用的严苛需求: 实时通信 (RTC) 应用需要持续的低延迟来保证无缝的交互体验
• 无线网络的尾部缺陷: 尽管目前无线网络 (WiFi, 蜂窝网络) 的中位数延迟表现良好 (低于 100ms), 但其 99 分位的尾部延迟常常高达约 400ms, 导致无线用户的视频缓冲卡顿频率是普通以太网用户的两倍
• 拥塞成因: 这种瞬时的尾部延迟主要是由于无线可用带宽突然下降, 导致数据包在接入点 (AP) 的队列中迅速堆积造成的

(2) 现有解决方案的根本局限性

• 控制环路过长: 如 Figure 1 所示, 现有的控制信号 (如时间戳或丢包信息) 必须与数据包走完完全相同的拥塞路径才能传回发送端.
• 反馈不及时:
  • 发送端在网络最拥塞, 最需要调整速率的时候, 接收拥塞信号的速度反而是最慢的
  • 无论是端到端的拥塞控制算法 (CCAs) 还是网内的队列管理 (AQMs), 都受困于这种被拉长的控制环路, 无法快速适应带宽的突变

发送端在网络最拥塞, 最需要调整速率的时候, 接收拥塞信号的速度反而是最慢的

"Put simply, to observe that the bottleneck queue is filling, a sender must first receive an acknowledgement from a packet that has actually waited in that queue.

Hence, congestion indicators like timestamps or losses take longer to reach the sender when the sender most needs these indicators."

(3) Zhuge 的核心洞察与应对挑战

• 核心思路: Zhuge 的关键思路是将控制环路从数据包完整传输路径中解耦出来, 如 Figure 1 所示:

  • 当 AP 观察到 下行队列 (即 Figure 1 中的 i) 开始堆积时, 可以直接修改或延迟 上行队列 (即 Figure 1 中的 iv) 中的数据包, 从而让拥塞信号绕过拥塞瓶颈直接到达发送端

• 面临的两大挑战:

  • 挑战一: 如何在带宽剧烈波动的情况下, 准确预测尚未发送的数据包的未来延迟
  • 挑战二: 如何在不修改发送端和接收端协议的前提下, 以易于大规模部署的方式将预估的延迟信息反馈给发送端

(4) Zhuge 的架构设计与效果

• Fortune Teller (预测器): 在数据包到达无线 AP 时, 预测器会分别估算影响排队延迟的多个因素, 从而 精确预测出该数据包将要面临的延迟
• Feedback Updater (反馈更新器): 负责修改上游数据包, 将预估的延迟转化为各类协议能够理解的反馈消息, 并立即 回传给发送端用于速率自适应
• 效果显著: 真实环境与基于数据轨迹的评估表明, Zhuge 能够将严重的尾部延迟和 RTC 性能下降比例降低 17% 到 95%

Background and Motivation

这一部分主要阐述了无线网络尾部延迟的成因, 现有方案的不足, 以及作者提出新方案的核心思路.

2.1 Understanding Wireless Tail Latency

• 尾部延迟对 RTC 体验的破坏性:

  • 虽然无线网络大部分时间能提供小于 100ms 的中位数延迟, 但其 99 分位延迟可能高达 400ms 以上
  • 如 Figure 2 所示, 由于高尾部延迟, 无线网络用户的视频卡顿频率是以太网用户的 2 倍, 视频停顿率是以太网的 10 倍

• 尾部延迟的根本原因: 延迟的激增是由发送端速率与瓶颈处可用带宽 (ABW) 的 "瞬时极度不匹配" 造成的

  • 如 Figure 3(a) 所示, 当带宽突然下降 \(k\) 倍时, 拥塞控制算法 (CCA) 需要一个完整的控制环路 (\(r\)) 的时间来降低发送速率
  • 在这段时间内, 发送端多发出的数据包会在队列中积压, 并且由于带宽已下降, 排空这些过度发送的数据包需要花费 \(k \times r\) 的时间, 从而导致严重的延迟

• 无线网络带宽极易剧烈波动:

  • 如 Figure 3(b) 所示, 在包含 5G 和 WiFi 的数据集中, 可用带宽骤降 10 倍以上的概率高达 0.6% 到 7.3%, 而有线网络的这一概率不到 0.1%

2.2 Existing Solutions

• 基于端主机的方案 (CCA) 控制环路过长:

  • 现代拥塞控制算法 (如 BBR, Copa 等) 纯粹依赖端到端信号, 当拥塞发生时, 信号需要 经过完整的, 已经被拉长的控制环路 才能到达发送端
  • 如 Figure 4 所示, 当带宽骤降时, 这些算法都会经历长达数秒的 RTT 恶化阶段, 无法及时反应

• 网内方案 (AQM 与端网协同) 反馈不及时:

  • 如 CoDel 等主动队列管理机制 (AQM) 试图通过在 AP 队列前端丢包来发出信号
  • 但这些信号 仍需经过漫长的无线链路 传回发送端
  • 此外, 许多延迟敏感型的 CCA 对丢包并不敏感 (如 Figure 4(a) 所示, CoDel 几乎无法改善 Copa 的性能)
  • 现有的端网协同方案 (如 ABC) 依然需要走完完整的控制环路

2.3 Our Proposal: Reducing the Control Loop

• 寻找最早的拥塞信号:

  • 当一个数据包抵达瓶颈队列时, 它立刻就能通过整个队列的状态 (例如用队列长度除以出队速率) 来预测自己即将遭遇的排队延迟
  • 这比等待数据包丢失或在接收端测量到的 RTT 增加要早得多.

• 快速传递信号:

  • Zhuge 的核心思路是利用这个 "最早的信号", 从瓶颈路由器 (AP) 直接将其传递给发送端!
  • 从而绕过控制环路中发生拥塞和膨胀的部分 (对应 Figure 1 中的 i, ii, iii 下行和上行无线传输部分)

• 兼顾大规模可部署性 (仅修改 AP):

  • 历史上的许多传输层创新方案因为需要同时修改服务器和路由器而无法落地
  • Zhuge 被设计为 仅需修改最后一公里 AP (路由器) 的方案, 这大大降低了部署门槛, 普通家庭用户只需升级路由器就能获得性能提升, 无需内容提供商的配合

Zhuge Design

3.1 Design Challenges

Zhuge 旨在通过缩短控制环路来控制无线网络的尾部延迟, 但在此过程中面临两大主要挑战:

挑战一: 对 RTC 流量进行及时, 精准的数据包级延迟预估

• 瓶颈队列在亚 RTT (sub-RTT) 级别存在瞬时波动, 使得精确预估变得困难

• 这种波动来源于两个方面的 "突发性":

  1. RTC 应用通常以视频帧为单位突发性地发送数据包
  2. 无线信道为了缓解竞争, 通常会将多个数据包聚合成一个 MAC 帧 (如 WiFi 的 AMPDU) 同时突发性出队

• 传统的 "队列长度除以出队速率" 的预估方法会陷入 "瞬态-平衡困境 (transience-equilibrium nexus)", 难以兼顾稳态时的准确性和瞬态时的灵敏度

挑战二: 为各种繁杂的协议和拥塞控制算法 (CCA) 提供有效的消息反馈

• 为了便于大规模部署, Zhuge 被设计为不修改发送端的纯 AP 端方案

• 然而, 实际应用中的传输协议种类繁多 (如未加密的 TCP, 加密的 QUIC, 以及 WebRTC 特有的反馈包等), 且它们依赖不同的信号来调整速率, 这使得在不修改协议的前提下将网络状况反馈给发送端极具挑战

3.2 Framework Overview

为了应对上述挑战, Zhuge 引入了两个核心组件: Fortune Teller (预测器) 和 Feedback Updater (反馈更新器)

整体工作流程如 Figure 5 所示:

(1) Fortune Teller

• 负责在每个数据包到达时预测其未来的延迟命运
• 为了克服瞬态-平衡困境, 它将延迟拆分为不同部分, 分别引入了长期和短期预估器:
  • 通过测量 平均出队速率 来计算 长期排队延迟
  • 通过测量 队头数据包的停留时间 来响应 短期的波动

解决上述 challenge 1. 细节查看 chapter 4, 本文省略

(2) Feedback Updater

• 负责将预估的网络状况转化为发送端能够理解的信号, 并及时通知发送端
• 它将现有 RTC 应用的协议分为两类, Zhuge 分别为这两类协议设计了不同的反馈机制:
  • 带外反馈 (out-of-band, 如依靠 ACK 包到达作为信号的 TCP)
  • 带内反馈 (in-band, 如在反馈包载荷中直接写入网络状况的 WebRTC TWCC-FB)

解决上述 challenge 2. 细节查看 chapter 5, 本文省略

in-band 和 out-of-band

一言以蔽之:

• in-band 指的是网络状况信息直接写在数据包的 Payload 里, 发送端在收到这个包时就能 直接读取 到这些信息.
• out-of-band 指的是网络状况信息不直接写在数据包里, 发送端需要通过测量包的到达时间间隔等 "外部方式" 来 推断网络状况.

在 zhuge 这里:

• 信息是 pkt 自身携带 (In-band):

  • 因为具体的时间或延迟数据已经明文写在数据包里了, 所以 Zhuge 采取的策略相当于 "篡改信件"
  • 它在路由器端截获这些反馈包, 把预测到的真实延迟数据更新到 Payload 里, 然后再发给发送端

• 端侧自行推断 (Out-of-band):

  • 因为反馈包里没有写具体数据, 全靠发送端自己测量包的到达时间间隔来推断网络状况. 所以 Zhuge 采取的策略是 "物理拖延"
  • 它会在 AP 端故意把 ACK 包按照预估的延迟时间扣留一小会儿再发出去. 这样发送端在收到 ACK 时, 就会自行推断出 "网络变卡了"

(3) 缩短控制环路的工作流

1. 当数据包从以太网端口到达无线 AP 时, Fortune Teller 会预测其延迟并正常将其送入下行队列
2. Feedback Updater 会立即将该预估延迟信息更新到反方向 (上行) 的反馈数据包中
3. 这种机制使得 最早的拥塞信号 可以直接借由 上行反馈包回传至发送端, 完美绕过了下行排队和无线传输所带来的延迟 (即绕过了 Figure 1 中的 i 到 iii 阶段)

Fortune Teller

没细看, ai 学习的

为了实现对 RTC 流量及时且精准的数据包级延迟预估, 论文设计了 Fortune Teller (预测器) 模块. 它的核心思想是将排队延迟 "解耦" 为长期和短期两个部分分别进行预测:

• 用 "短期排队延迟 (qShort)" 捕捉突发出队:

  • qShort 的计算方式是测量当前队列 队头 数据包的等待时间
    • 当无线带宽骤降或底层发生 MAC 帧突发出队时, 队头数据包需要等待更长的时间才能被发送
    • qShort 能够极快地捕捉到这种毫秒级的短时波动, 从而立刻反映出可用带宽的下降

• 用 "长期排队延迟 (qLong)" 应对突发到达与稳态评估:

  • qLong 依然使用当前队列长度除以平均出队速率来计算, 用于覆盖由无线竞争和突发 RTC 流量造成的宏观延迟波动
    • 为了抵消底层并发发包 (突发离开) 带来的误差, Zhuge 在计算队列长度时会减去一个 "最大突发大小 (maxBurstSize)"
    • 当队列已经稳定堆积后, qLong 能提供极其稳定和准确的延迟预估

• 综合得出精准预测:

  • 最终的预测延迟是将 qLong, qShort 以及底层的传输延迟 (tx) 叠加
  • 这使得 Zhuge 既具备瞬态的极高灵敏度, 又保证了稳态的准确性

Feedback Updater

没细看, ai 学习的

为了在不修改发送端代码的前提下兼容各种繁杂的协议, 论文设计了 Feedback Updater (反馈更新器) 模块

它将所有协议分为 "带外反馈" 和 "带内反馈" 两类, 并采取了完全不同的 "欺骗" 策略:

针对带外反馈协议 (Out-of-band, 如 TCP, QUIC)

• 策略: 物理延迟 ACK 包.

  • 既然发送端完全依靠测量反馈包的到达时间来推断网络状况, Zhuge 的做法是在 AP 端 故意延迟上行链路中的 ACK 反馈包, 以此向发送端暗示 "网络变卡了"

• 精准传递亚 RTT 波动:

  • 为了不破坏稳态下的 RTT 评估, Zhuge 并没有简单粗暴地加上绝对延迟, 而是记录相邻下行数据包的 延迟差值 (delay deltas)
  • 它通过维护这些差值的分布, 并随机采样应用于上行的 ACK 包, 从而完美模拟出短期的延迟波动

• 防止乱序: 引入了 "延迟令牌 (delay token)" 机制, 确保后续到达的 ACK 包不会因为被分配了更短的延迟而跑到前面去, 从而避免了发送端的乱序误判

• 兼容加密: 因为整个过程只需根据五元组识别数据流并物理扣留数据包, 完全不需要解密或读取包内载荷, 所以该方案天然支持 QUIC 等端到端加密协议

针对带内反馈协议 (In-band, 如 WebRTC 的 RTP/RTCP):

• 策略: 重构载荷 (Updating Payloads).

  • 这类协议会将延迟信息明文写在反馈包里, 因此 Zhuge 的做法是直接更新这些反馈包的载荷内容

• 伪装接收端:

  • Zhuge 会记录每个下行 RTP 包的预估命运及序号, 当需要反馈网络状况时, 它会伪装成接收端, 直接构造包含最新预估延迟的 TWCC 反馈包发送给服务器
  • 同时, 它会丢弃真实客户端发来的对应旧反馈包, 以保证时间戳的绝对一致性

• 应对加密:

  • 如果 RTP/RTCP 数据包被端到端加密, 只要连接初始阶段服务器和客户端在明文中共享了公钥, Zhuge 就可以截获该公钥, 并使用它来加密自己伪造的反馈包, 确保发送端能够正常解码

Related Work

研究类别	现有研究成果与方案	现有方案的局限性	与 Zhuge 的对比及关联
无线性能优化	设计特定的拥塞控制算法 (CCAs), 如 Sprout 和 Verus. 解耦有线与无线连接, 或更好地管理路由器的重传. 通过跨层设计来提升无线网络的性能.	虽然代理独立管理链路发送速率能缩短传输层控制环路, 但 RTC 应用的内容是由发送端 (编码器) 生成的, 因此在应用层的控制环路依然很长. 跨层设计的解决方案需要在服务器或客户端进行大量集成, 这阻碍了它们的大规模部署.	Zhuge 在设计上能够与这些特定的 CCAs 协同工作 (类似于其与 Copa 的结合使用).
瞬态性能	近期在传输层研究中, 对广域网 (WAN) 和数据中心中 CCA 的瞬态性能进行分析或量化.	这些现有的解决方案依然是从服务器端 (Server) 的视角来解决或分析瞬态性能问题的.	相比之下, Zhuge 从无线网络接入点 (AP) 的视角出发, 提供了一种易于部署的提升瞬态性能的解决方案.
RTC 的传输优化	优化 RTC 应用的重传机制. 让数据流编码器适应网络状况, 从而减少应用性能 (例如帧延迟) 的退化.	由外部因素导致的带宽下降是无法被提前预测 house.	Zhuge 专注于对网络状况做出及时的反应, 并且能够与上述这些研究成果协同工作.

Conclusion

本文提出了 Zhuge, 这是一种基于无线接入点 (AP) 的解决方案, 旨在通过缩短控制环路来缓解无线网络中实时通信 (RTC) 应用的尾部延迟.

Zhuge 利用 "预测器" (Fortune Teller) 在每个数据包到达时预估其传输命运 (即延迟状况), 并通过 "反馈更新器" (Feedback Updater) 兼容多种协议, 将上述预估信息快速反馈至发送端

我们通过基于真实网络轨迹驱动的仿真以及测试床部署, 对 Zhuge 的性能进行了全面评估. 实验结果表明, 在多种不同场景下, Zhuge 能将长尾延迟及 RTC 应用性能的衰退幅度显著降低 17% 至 95%.

本研究不涉及任何伦理问题.