Revisiting Congestion Control for WiFi Networks

文章目录

- 摘要
- [CCS 概念](#CCS 概念)
- 关键词
- [1 引言](#1 引言)
- [2 WiFi 数据路径](#2 WiFi 数据路径)
- [3 观察与洞察](#3 观察与洞察)
- - [3.1 观察](#3.1 观察)
  - [3.2 交互问题](#3.2 交互问题)
  - [3.3 新信号与新目标](#3.3 新信号与新目标)
- [4 Cupid 设计](#4 Cupid 设计)
- - [4.1 连接启动：线速增长](#4.1 连接启动：线速增长)
  - [4.2 稳态：拥塞避免](#4.2 稳态：拥塞避免)
- [5 初步结果](#5 初步结果)
- [6 讨论与未来工作](#6 讨论与未来工作)
- [7 相关工作](#7 相关工作)
- [8 结论](#8 结论)

摘要

WiFi 网络被无线设备广泛使用，如今已经变成越来越复杂且拥塞的环境，导致端到端网络流出现明显的时延、抖动和吞吐下降。通过细致的实验观察，本文识别出 WiFi 中的 TCP 受害者问题（TCP victim problem）：TCP 错误地检测拥塞，并与 WiFi 路由器的行为相互作用，导致某些主机吞吐量显著下降。

本文提出 Cupid，一种新的拥塞控制算法，它依赖接收端侧的 WiFi 物理层测量。Cupid 通过测量 airtime utilization、concurrency 和 rate 等参数来准确评估拥塞，从而进行精确的速率调整。结果表明，无论单独使用还是与其他拥塞控制算法共同使用，Cupid 都可以有效缓解 TCP 受害者问题。此外，当 Cupid 独立使用时，它还能降低时延。

CCS 概念

Networks -> Transport protocols.

关键词

WiFi Networks, Congestion Control

1 引言

WiFi 网络信道是端到端数据流到达移动终端的主要连接方式，这会带来更高时延、时延波动、丢包和带宽约束 $10, 18$ 。已知 TCP 及其变体，例如 NewReno $8$ 、Cubic $11$ 和 BBR $6$ ，在 WiFi 网络上的表现并不好，原因包括容量高度可变、与拥塞无关的随机丢包（stochastic packet losses），以及较大的带宽时延积（Bandwidth-Delay Product, BDP） $10, 24, 25$ 。一方面，WiFi 物理层信道快速变化，使 TCP 难以及时调整 $10, 25$ 。WiFi 5 $1$ （433-6933 Mbps）、WiFi 6 $2$ （574-9608 Mbps）以及最新 WiFi 7 $3$ （1376-46120 Mbps）等标准的带宽持续提升，也使它们更容易受到信号干扰。另一方面，多用户竞争和用户移动性进一步造成信道波动。

图 1：WiFi 中 TCP 受害者问题的示例。

除了上述广为人知的问题之外，本文发现了一个新问题：它会阻止 WiFi 中的 TCP 主机获得可用带宽。我们将这一现象称为 WiFi 场景中的 TCP 受害者问题（the TCP victim problem）：当多个主机并发下载时，总有一部分主机无法获得足够带宽，尤其是距离无线路由器较远的主机。图 1 给出了一个示例。在图 1 中，两部手机通过同一台无线路由器连接 WiFi。其中一部手机靠近 WiFi 路由器，另一部距离更远；两者都从服务器下载数据。单独下载时，信号质量较差的远端手机（Remote）吞吐约为 141 Mbps，而信号质量较好的近端手机（Near）吞吐可达 800 Mbps。然而，当二者并发下载时，信号较差手机的吞吐下降超过 14 倍，而信号较好手机的吞吐仅下降 1.17 倍。在理想情况下，并发下载时两部手机的吞吐都应该下降到各自单独发送吞吐的一半。

WiFi 中的 TCP 受害者问题源于不准确的拥塞检测（due to inaccurate congestion detection），导致带宽收敛到错误值；它并不是由于物理层无法为弱信号主机分配更多带宽造成的。对于基于丢包的拥塞控制，例如 Cubic $11$ ，弱信号主机会因为与拥塞无关的随机丢包和批处理不足而减速。对于基于探测速率的拥塞控制，例如 BBR $6$ ，弱信号主机的速率探测不够激进，因而获得较低带宽。

我们必须研究新的拥塞信号，以便更好地分配 WiFi 中的无线信道使用，并克服传统 WiFi 拥塞检测方法和速率调整规律的限制。本文提出 Cupid，一种基于 WiFi 物理层带宽测量的新型拥塞控制方法，测量发生在移动端点（the mobile endpoint）。Cupid 包含两个模块：

a）一种细粒度的拥塞检测与识别机制，可以高度准确地测量 WiFi 链路中的 airtime utilization、concurrency 和 rate 等信息，使发送端在尝试让发送速率匹配可用无线容量时能够更精确地控制速率，前提是瓶颈容量位于无线链路本身；
b）一种接收端驱动的速率调整规则，可以加快速率调整收敛速度，对突发流量具有鲁棒性，并适应链路容量变化。

本文中，Cupid 只处理 WiFi 网络中的拥塞；Internet 瓶颈拥塞（Internet bottleneck congestion）留作未来工作。

本文在 UDP 之上实现了 Cupid 原型，并构建了一个小型测试床来初步验证 Cupid 的有效性。实验发现：(1) Cupid 可以准确测量网络带宽并调整发送速率，从而实现高吞吐、低时延和公平性；(2) 与 Cubic 和 BBR 相比，Cupid 可以解决受害者问题，使弱用户吞吐提升 50 倍、时延降低 5 倍；(3) 当 Cupid 与其他算法共存时，如果 Cupid 是受害者，它会主动竞争带宽；反之，如果 Cupid 不是受害者，它会主动让出带宽，从而最大化整体网络效率。

2 WiFi 数据路径

为了理解 WiFi 路由器中的排队模型，以及它与有线路由器的区别，本文先介绍 WiFi 的数据路径。图 2 展示了一个数据包在 WiFi 路由器中的生命周期。

图 2：WiFi 路由器中的数据路径。

每个数据包进入无线路由器时，会经过一个输入仲裁器（input arbiter），以识别该数据包的目标移动设备。
通过仲裁器之后，每个数据包会进入对应用户的 per-user queue。
通过 per-user queue 之后，每个数据包进入 batch queue。为了提高 WiFi 空口信道效率，WiFi 路由器会将数据包聚合成批次发送，例如 A-MSDU 和 A-MPDU $9$ 。因此，在 batch queue 中，数据包不仅要等待单独发送，还要等待被聚合进一个批次。
具体的队列调度过程相当复杂，涉及底层物理调度信息、帧聚合以及其他因素，例如 OFDMA 调度、MU-MIMO 调度和 SU 调度 $17$ 。为了便于理解，本文在这里简化模型，并近似为轮询（Round-Robin, RR）算法。然而在队列调度中，batch queue 已满的队列会被优先调度。
注：
- 轮询算法（Round-Robin, RR）. 在这里指调度器按照固定顺序依次检查每个用户的队列：轮到某个用户且其队列中有数据时，就给它一次发送机会，然后继续检查下一个用户；如果某个用户队列为空，则跳过它。作者使用 RR 只是为了简化真实 WiFi 调度过程，真实调度还会受到帧聚合、OFDMA、MU-MIMO、SU 调度以及 batch queue 是否已满等因素影响。
由于无线空口介质是一种共享资源，同一时刻空间中只能传输一组数据。一般来说，无线路由器通常一次只为一个用户传输数据。每个用户都会根据距离、干扰、调制与编码方案（Modulation and Coding Scheme, MCS）以及天线数量等因素匹配一个底层物理速率 $21$ 。随着条件变化，该速率也会变化。

在更底层，CSMA/CA 和 RTS/CTS 控制介质，使其一次只能被一个用户访问。由于物理层技术和频域信号复用，例如 OFDMA、MU-MIMO $17$ 的进步，多个用户同时接收是可能的。然而，这些技术的使用条件很严格，大多数情况下仍然一次只有一个用户在接收。

总之，与传统有线路由器相比，无线 WiFi 路由器具有以下特点：(1) 每个用户都有自己的队列；(2) 这些队列需要进行批处理（need to be batch processed）；(3) 已满的 batch queue 优先级较高；(4) 每个用户有不同的物理带宽。

3 观察与洞察

由于容量可变、随机丢包和带宽增长，TCP 及其变体在 WiFi 网络中面临挑战。动态 WiFi 信道、多用户竞争和移动性共同造成了这些问题。除了上述已知问题之外，本文还识别出 WiFi 中的 TCP 受害者问题：当多个主机同时下载时，总有一部分主机无法获得足够带宽，尤其是距离无线路由器较远的主机。接下来，本文通过实验展示 WiFi 中的 TCP 受害者问题，分析其根因，并介绍 Cupid 所提供的洞察。

3.1 观察

本文使用如下测试床刻画 WiFi 中的 TCP 受害者问题：支持 WiFi 6 的智能手机，每部手机配备两根天线；一台带有六根天线的 WiFi 6 无线路由器连接到 Ubuntu 服务器。智能手机与 WiFi 路由器握手时的空口信道带宽最高可达 1201 Mbps，而单用户实际 TCP 吞吐约为 800 Mbps。本文使用 iPerf3 $19$ 生成流量，改变所使用的拥塞控制算法，包括 Cubic、BBR 和 UDP，其中 UDP 表示没有拥塞控制。本文还使用 ping 测量往返时间（Round-Trip Time, RTT）。

注：

1201 Mbps 是物理层链路速率. 这里的 1201 Mbps 指手机和 WiFi 路由器在握手/速率协商后得到的 PHY rate，也就是无线空口在当前信道宽度、MCS、空间流数量和保护间隔等条件下的理论发送档位。它描述的是"无线符号在空口上最多能承载多少比特"，不是应用层真正能收到多少 TCP 有效载荷。

800 Mbps 是 TCP 实际有效吞吐. 这里的 800 Mbps 是用 iPerf3 等工具在单用户场景下测到的 TCP throughput，统计的是 TCP 成功传到接收端的有效数据。约 800 / 1201 ≈ 66.6 % 800/1201 \approx 66.6\% 800/1201≈66.6% 的比例在 WiFi 中并不反常，因为物理层速率本来就不能完全转化为传输层吞吐。

可能导致差距的因素. 一类是 WiFi MAC/PHY 固定开销，包括物理层前导码、MAC 头、FCS、帧间隔（如 SIFS/DIFS）、随机退避、ACK/Block ACK 和控制帧；这些内容都会占用空口时间，但不计入 TCP 有效载荷。另一类是共享介质带来的等待和竞争，即使只有一个 TCP 用户，设备也仍需遵守 CSMA/CA、退避和半双工发送规则。还有一类来自帧聚合与链路质量：A-MPDU/A-MSDU 聚合不可能总是达到最优长度，信道波动、干扰、速率自适应和重传也会进一步降低有效吞吐。

协议栈和设备实现也会消耗速率. TCP/IP 头部、TCP ACK、操作系统网络栈、驱动、网卡/手机芯片处理能力、加密解密以及路由器转发能力都可能成为额外损耗。因此论文后文用 δ ( ⋅ ) \delta(\cdot) δ(⋅) 表示从底层物理带宽到传输层吞吐的映射，本质上就是把这些协议和实现开销折算进去。

图 3：TCP 受害者问题中三部智能手机之间的公平性结果。

首先，本文测试公平性。我们将三部智能手机放在靠近路由器的位置，每隔 5 秒开始发送一次（spaced 5 seconds apart in their sending starts），每部手机发送 15 秒。图 3 展示了结果。在图 3(a) 和图 3(b) 中，当 flow 2 和 flow 3 开始时，Cubic 和 BBR 无法获得足够带宽，使后启动的流成为受害者。在图 3© 中，Cupid 保证了所有流之间的公平性。这种不公平具有概率性，但当信号质量存在差异时，不公平会变得不可避免。

注：

图 3 的读法. 横轴是时间，纵轴是吞吐量；三条曲线分别对应三台手机上的 Flow 1、Flow 2 和 Flow 3。实验中 Flow 1 大约在 0 s 启动并持续 15 s，Flow 2 在 5 s 启动并持续 15 s，Flow 3 在 10 s 启动并持续 15 s。因此，5-15 s 是 Flow 1 和 Flow 2 竞争，10-15 s 是三个 flow 同时竞争，15 s 之后 Flow 1 结束，20 s 之后 Flow 2 结束。

图 3(a) Cubic. Flow 1 先启动后很快占据接近单用户上限的吞吐；Flow 2 和 Flow 3 后启动后，在很长一段时间内几乎拿不到足够带宽，直到前面的 flow 结束后才明显恢复。这说明基于丢包/窗口调整的 Cubic 在该 WiFi 场景中会让后启动流陷入受害者状态。

图 3(b) BBR. BBR 也没有稳定地保证公平性。Flow 1 先占据主要带宽，Flow 2 和 Flow 3 后续吞吐波动很大，有时接近被饿死。原因在于 BBR 依赖带宽探测，但 WiFi 中的队列批处理和调度行为会让后启动流难以及时探测到真实可用带宽。

图 3© Cupid. Cupid 下，多个 flow 重叠时都能获得一定吞吐；当某个 flow 结束后，剩余 flow 能继续利用释放出来的带宽。这里要强调的是，三台手机都放在靠近路由器的位置，所以图 3 展示的不公平并不是简单由远近/信号强弱造成的，而是传统 TCP 拥塞控制与 WiFi 队列、批处理和空口调度机制相互作用后产生的 TCP victim problem。

图 4：TCP 受害者问题中四部智能手机的近端-远端结果。

接下来，本文测试不同距离场景下的公平性。我们将两部智能手机放在距离无线路由器较远的位置，另外两部放在较近的位置，并让服务器同时向四部智能手机发送数据。图 4(a) 展示吞吐结果，可以看到 TCP 中远端用户的吞吐极低：(1) 对 Cubic 而言，弱主机吞吐为 0.03-0.51 Mbps，而强主机吞吐为 388-425 Mbps；(2) 对 BBR 而言，弱主机吞吐仅为 0.02-0.28 Mbps，而强主机吞吐为 406-465 Mbps；(3) 对 Cupid 而言，弱主机吞吐为 35-54 Mbps，而强主机吞吐为 180-188 Mbps；(4) 对没有拥塞控制的 UDP 而言，弱主机吞吐为 35-54 Mbps，而强主机吞吐为 83-86 Mbps。

图 5：WiFi 中 TCP 受害者问题的原因。

UDP 不限制弱主机速率，因此可以避免 TCP 受害者问题，使弱主机获得高吞吐。然而，在完全无序的发送情况下，整体 airtime 带宽利用率会下降，UDP 总吞吐会损失 68%，从而在 airtime utilization 层面导致另一种形式的不公平。图 4(b) 展示了 airtime utilization 的对比。可以看到，使用 UDP 时两个弱主机几乎占据了 80% 的 airtime。BBR、Cubic 和 UDP 都无法公平利用 airtime，而 Cupid 可以。

此外，在 WiFi 场景中还会出现一种更特殊的现象：如图 4© 所示，Cubic 和 BBR 中弱主机的时延保持得异常高。与 TCP 相比，UDP 由于填满缓冲区而始终表现出高时延；而 Cupid 则能持续维持相对较低的时延。

注：

图 4 的核心含义. 你的理解基本正确：相对于 Cubic 和 BBR，Cupid 的总吞吐（SUM throughput）确实下降了，但它换来了更好的公平性，尤其是远端用户不再被饿死。Cubic 和 BBR 的总吞吐较高，主要是因为近端用户占据了大部分发送机会；远端用户吞吐几乎为 0，所以这种"高总吞吐"并不代表公平。

airtime 是什么. airtime 指某个用户占用 WiFi 无线空口进行传输的时间份额，而不是传输了多少数据量。比如在 1 秒统计窗口内，如果 Near 1 的帧传输、等待响应和相关空口占用合计用了 0.25 秒，那么它的 airtime utilization 就约为 25%。图 4(b) 的纵轴 Air Time (%) 衡量的就是每台手机分到了多少无线信道时间。

为什么 UDP 下 remote 反而占用更多 airtime. 这里的关键不是 UDP 会更公平，而是 UDP 没有 TCP 式拥塞控制，不会因为远端吞吐低、ACK 慢或 RTT 高而主动降速，因此会持续把数据塞进 AP 对应用户的队列，使 remote 的 batch queue 也能保持有包可发。与此同时，remote 用户因为距离远、信号弱，PHY rate 更低，发送同样大小的一批数据需要占用更长空口时间。简化地看， a i r t i m e ≈ d a t a / P H Y r a t e airtime \approx data / PHY\ rate airtime≈data/PHY rate；如果 near 的 PHY rate 是 remote 的 10 倍，那么发送同样数据量时 remote 需要约 10 倍的空口时间。因此 UDP 避免了 TCP 中 remote 被饿死的问题，但又走向另一端：低速 remote 用户占据大量 airtime，压低 near 用户吞吐，并降低整体空口效率。

公平性主要指 airtime fairness. 在 WiFi 中，近端用户和远端用户的 PHY rate 不同：近端用户单位空口时间能传更多 bit，远端用户单位空口时间能传更少 bit。因此，Cupid 并不是追求每个用户 Mbps 完全一样，而是让每个用户获得相近的空口时间份额。图 4(b) 中 Cupid 让 Near 1、Near 2、Remote 1、Remote 2 的 airtime utilization 更接近，这比只看吞吐更能反映 WiFi 中的公平性。

为什么总吞吐会下降. 当 Cupid 把一部分 airtime 分给远端用户时，由于远端用户物理速率较低，同样的空口时间只能传更少数据，所以整体 Mbps 总和会低于只服务近端用户时的 Cubic/BBR。但这不是纯粹的性能退化，而是用一部分总吞吐换取远端用户可用吞吐、更均衡的 airtime，以及图 4© 中更低、更稳定的 RTT。相比完全无拥塞控制的 UDP，Cupid 又避免了强主机吞吐被严重压低和队列时延过高的问题。

通过上述分析可以看到，CUBIC 和 BBR 会损害弱主机的吞吐，而 UDP 会损害强主机的吞吐。下一节将仔细分析这些现象产生的根本原因。

3.2 交互问题

WiFi 中的 TCP 受害者问题会导致吞吐上的极端不公平，从而造成用户体验的显著差异。图 5 展示了受害者问题的成因。对于原本带宽较低的弱 TCP 用户：

TCP 中不准确的拥塞信号或慢启动可能导致一些错误降速，也就是降低拥塞窗口（Congestion Window, Cwnd）。
WiFi 路由器的队列调度算法会优先调度 batch queue 已满的用户。因此，如果弱主机的 Cwnd 小于 batch queue 的队列长度，弱主机必须等待强主机发送完成之后才能传输。
弱主机在提高发送速率时面临挑战。它需要 ACK 来增大 Cwnd，但 ACK 要求数据包先到达接收端。数据包必须等到 batch queue 填满之后才能发送，而填满 batch queue 又要求弱主机增大 Cwnd。这形成了一个死锁，使弱主机很难提升发送速率，直到强主机发送结束。

UDP 使强主机的利用率显著低于公平份额。(1) UDP 没有拥塞控制，因此会不加限制地用数据包填充队列。(2) batch queue 保证每次传输为每个主机发送一致数量的数据。(3) 因此，吞吐更高的用户发送更快，但占用更少 airtime；吞吐更低的用户发送较慢，却占用更多 airtime。

综上，现有拥塞控制机制缺少准确的拥塞信号，并且难以在 WiFi 场景中收敛到合适的目标。我们需要新的拥塞控制方法，利用新的拥塞信号收敛到定义明确的公平目标状态。

3.3 新信号与新目标

Cupid 需要新的拥塞信号和拥塞控制目标。传统传输层拥塞信号，例如 RTT、丢包和速率检测，在 WiFi 中都不够准确。只有物理层的实际带宽占用才能准确反映真实的 WiFi 拥塞。

传统拥塞控制缺少准确的拥塞信息，因此只能通过探测到达目标速率。重新审视所有拥塞控制的根本目标（the fundamental goal of all congestion control），就是让发送速率匹配：(1) 公平的剩余带宽；(2) 可用的剩余带宽。从全知视角看（a god's-eye view），如果每个发送端都能准确知道瓶颈链路容量 C C C 和并发发送端数量 N N N，那么每个发送端将发送速率设置为 C / N C/N C/N 就能准确匹配速率，从而完成拥塞控制的使命。然而，由于无法准确确定可用带宽和并发连接数量，现有拥塞控制机制需要通过 probing 来探索和检测。

图 7：Cupid 的一个示例。

Cupid 使用 airtime occupancy 来测量拥塞，并通过统计并发发送端数量来控制公平性。在 WiFi 中，每个用户具有不同的 airtime rate，不能将带宽视为共享资源。基于 WiFi 的特性，同一时刻 airtime 上只传输一组数据。尽管每组数据的速率可能不同，但它们共享的是时间资源。如果 airtime 上持续存在传输，就说明存在拥塞。如果每个用户占用相同的 airtime，则它们在时间维度上是公平的。因此，Cupid 采用：(1) airtime occupancy 作为拥塞信号；(2) airtime fairness 作为拥塞控制目标。

4 Cupid 设计

Cupid 是一种专门面向 WiFi 的端到端拥塞控制算法，适用于终止在通过 WiFi 网络连接的移动设备上的流。Cupid 移动客户端测量 WiFi 物理信道，获得可用 airtime 无线容量以及并发用户数量。借助细粒度容量估计，当瓶颈是无线跳时，Cupid 可以快速增大发送速率来捕获新的可用容量，而不会造成拥塞；当与其他移动用户竞争或无线信道竞争降低无线容量时，Cupid 也会相应降低发送速率。图 6 展示了 Cupid 的概览。

图 6：Cupid 拥塞控制概览。移动客户端解码 WiFi 信道，计算详细的可用无线容量。Cupid 发送端根据移动用户显式返回的估计瓶颈容量，或根据接收端 ACK 的存在，控制自己的发送速率。

由于流量模式高度动态，端到端连接会面对两种可能的网络状态，具体取决于 Internet 与 WiFi 链路中瓶颈链路的相对容量。多数情况下，连接处于本文称为无线瓶颈状态（wireless bottleneck state）的状态，即无线 WiFi 链路是整个端到端连接的瓶颈。在该状态下，Cupid 移动用户可以通过测量 WiFi 物理控制信道（the WiFi physical control channel）来估计和跟踪整个连接的瓶颈容量。Cupid 发送端将其传输速率匹配到移动用户显式反馈的瓶颈容量，从而几乎充分利用容量，同时在网络中造成最少的数据包缓冲。

另一方面，如果 Internet 瓶颈容量小于无线蜂窝链路容量，则连接处于 Internet 瓶颈状态。本文不覆盖这一部分，并将其作为未来工作；第 6 节中会进行进一步讨论。

4.1 连接启动：线速增长

连接启动时，Cupid 发送端 i i i 执行线速增长，以接近瓶颈容量的公平份额。通过测量 WiFi 信道，每个 Cupid 用户都知道共享 WiFi 带宽的其他用户数量，如图 6 所示。因此，Cupid 使用该时隙中的总可用带宽和活跃用户数量，包括移动端自身，计算预期公平份额 R i i n i t ( t ) R^{init}_i(t) Riinit(t)：

R i i n i t ( t ) = η δ ( C i ( t ) ) N (1) R^{init}_i(t)=\eta \frac{\delta(C_i(t))}{N} \tag{1} Riinit(t)=ηNδ(Ci(t))(1)

其中， η \eta η 是接近 1 的常数，例如 0.8，表示整个空口信道带宽的期望利用率。函数 δ ( ⋅ ) \delta(\cdot) δ(⋅) 表示从底层物理带宽到传输层吞吐的映射，因为由于分组头和控制消息开销，WiFi 层的实际带宽无法被完全达到。 C i ( t ) C_i(t) Ci(t) 表示时刻 t t t 的当前物理信道带宽。

注：

谁来测量 C i ( t ) C_i(t) Ci(t) 和 N N N. 这里的"UE"在论文语境中更准确地说是 WiFi mobile client / STA。Cupid 不是让发送端 TCP 自己通过吞吐探测来猜 C i ( t ) C_i(t) Ci(t) 和 N N N，而是让移动端解码/测量 WiFi 物理信道或物理控制信道，得到 rate、airtime utilization 和 concurrency 等信息，再把估计结果反馈给发送端。

C i ( t ) C_i(t) Ci(t) 如何得到. C i ( t ) C_i(t) Ci(t) 可以理解为用户 i i i 当前 WiFi 链路的物理信道容量，和该用户当前的 PHY rate 接近。移动端可以从 WiFi 物理层/MAC 层观测中估计它，例如当前 MCS、信道宽度、空间流数量、保护间隔、AP 给该用户发送帧时使用的速率，以及速率自适应后的实际传输情况。论文没有把具体字段解析算法展开，但明确假设移动端能够通过 WiFi 物理控制信道估计并跟踪无线瓶颈容量。

N N N 如何得到. N N N 指当前共享 WiFi 空口的活跃用户数量，不是路由器上关联过的所有设备数量。移动端可以在一个时间窗口内观察空口中哪些接收端/用户正在获得传输机会，例如通过帧目的地址、控制/调度信息或非零 airtime 占用来统计 concurrency。一个连接到 WiFi 但此刻没有数据传输的设备，通常不应计入这个活跃用户数。

为什么不同用户可以有不同的 C i ( t ) C_i(t) Ci(t). 在 WiFi 中，近端用户和远端用户的信道质量、MCS、空间流数量和干扰情况不同，因此每个用户测到的物理信道带宽 C i ( t ) C_i(t) Ci(t) 本来就可能不同。公式 (1) 不是让所有用户获得相同的 Mbps，而是让每个用户按照自己的可用物理速率获得相近的 airtime 份额。

从公式看 airtime fairness. 用户 i i i 的空口占用可以粗略理解为 R i ( t ) / δ ( C i ( t ) ) R_i(t)/\delta(C_i(t)) Ri(t)/δ(Ci(t))。把公式 (1) 代入后有 R i i n i t ( t ) / δ ( C i ( t ) ) = η / N R^{init}_i(t)/\delta(C_i(t))=\eta/N Riinit(t)/δ(Ci(t))=η/N，其中 δ ( C i ( t ) ) \delta(C_i(t)) δ(Ci(t)) 被约掉了。这说明即使不同用户的 C i ( t ) C_i(t) Ci(t) 不同，Cupid 仍然会给它们分配相近的空口时间；近端用户 Mbps 更高，远端用户 Mbps 更低，但 airtime 目标相同。

用户退出启动阶段的条件是：达到公平带宽点 η δ ( C i ( t ) ) / N \eta\delta(C_i(t))/N ηδ(Ci(t))/N，或者在 3 个 RTT 内速率不再增加。

4.2 稳态：拥塞避免

当用户 i i i 进入稳态时，应执行如下速率调整：

R i ( t ) = { η δ ( C i ( t ) ) N , i f U ( t ) ≥ η ( M D ) , R i r e c e i v e r ( t − 1 ) + R A I ( t ) , i f U ( t ) < η ( A I ) . (2) R_i(t)= \left\{ \begin{array}{ll} \eta\frac{\delta(C_i(t))}{N}, & \mathrm{if}\ U(t)\ge \eta\ \mathrm{(MD)},\\ R^{receiver}i(t-1)+R{AI}(t), & \mathrm{if}\ U(t)<\eta\ \mathrm{(AI)}. \end{array} \right. \tag{2} Ri(t)={ηNδ(Ci(t)),Rireceiver(t−1)+RAI(t),if U(t)≥η (MD),if U(t)<η (AI).(2)

这里， U ( t ) U(t) U(t) 表示时刻 t t t 的 airtime utilization。如果 U ( t ) ≥ η U(t)\ge\eta U(t)≥η，说明存在拥塞，需要乘性下降（Multiplicative Decrease, MD）。因此，发送端 i i i 将其速率设置为公平份额 η δ ( C i ( t ) ) / N \eta\delta(C_i(t))/N ηδ(Ci(t))/N。相反，如果利用率不足，发送端 i i i 将线性增大（Additive Increase, AI）其发送速率。增量是上一时刻接收端速率 R i r e c e i v e r ( t − 1 ) R^{receiver}i(t-1) Rireceiver(t−1) 加上一个线性增量 R A I ( t ) R{AI}(t) RAI(t)。

注：

U ( t ) U(t) U(t) 是整体 WiFi 空口利用率. 这里的 U ( t ) U(t) U(t) 不是某一个 UE/STA 自己的 airtime，而是当前测量窗口内整个共享 WiFi 空口被所有活跃用户合计占用的时间比例。例如 Near 1、Near 2、Remote 1、Remote 2 各占用约 20% airtime 时，整体 U ( t ) U(t) U(t) 约为 80%。

和单用户 airtime 的区别. 单个用户 i i i 的 airtime 可以粗略写成 R i ( t ) / δ ( C i ( t ) ) R_i(t)/\delta(C_i(t)) Ri(t)/δ(Ci(t))；而 U ( t ) U(t) U(t) 是这些活跃用户 airtime 的总和。Cupid 根据整体 U ( t ) U(t) U(t) 判断空口是否过满，再调整每个发送端的速率，使总利用率靠近目标 η \eta η，同时让每个用户占用接近 η / N \eta/N η/N 的空口时间。

为什么 AI 不一定让每个用户立刻公平. 当 U ( t ) < η U(t)<\eta U(t)<η 时，公式 (3) 会把整体空口缺口 η − U ( t ) \eta-U(t) η−U(t) 按 N N N 份分给每个用户，因此整体 U ( t ) U(t) U(t) 可能一步接近 η \eta η，但单个用户的 airtime 不一定立刻达到 η / N \eta/N η/N。例如 η = 0.8 \eta=0.8 η=0.8、 N = 2 N=2 N=2，当前用户 A 的 airtime 为 0.1，用户 B 为 0.5，则整体 U ( t ) = 0.6 U(t)=0.6 U(t)=0.6，还差 0.2；AI 会让每个用户各增加 0.1 airtime，得到 A=0.2、B=0.6，总和变成 0.8。此时整体利用率到了目标附近，但两用户仍不公平；后续若 U ( t ) ≥ η U(t)\ge\eta U(t)≥η，MD 分支会把每个用户直接拉回公平份额 η / N = 0.4 \eta/N=0.4 η/N=0.4。

R A I ( t ) = ( η − U ( t ) ) δ ( C i ( t ) ) N (3) R_{AI}(t)=(\eta-U(t))\frac{\delta(C_i(t))}{N} \tag{3} RAI(t)=(η−U(t))Nδ(Ci(t))(3)

R A I ( t ) R_{AI}(t) RAI(t) 表示剩余带宽的 1 / N 1/N 1/N，用于保证整体 airtime utilization。

图 7 展示了 Cupid 算法的一个示例。开始时，用户 1 可以将速率设置为 η δ ( C 1 ( t ) ) \eta\delta(C_1(t)) ηδ(C1(t))，从而占满整个 airtime。当用户 2 出现时，用户 2 直接将速度设置为 0.5 η δ ( C 2 ( t ) ) 0.5\eta\delta(C_2(t)) 0.5ηδ(C2(t))；用户 1 注意到利用率 U ( t ) U(t) U(t) 超过 η \eta η，因此也将自身速率调整为 0.5 η δ ( C 1 ( t ) ) 0.5\eta\delta(C_1(t)) 0.5ηδ(C1(t))。当用户 3 发送结束时，用户 1 和用户 2 立即检测到有用户离开，并快速调整为各自占据一半可用带宽。在时刻 9，用户 2 没有足够数据发送，因此释放空闲带宽。此时，用户 1 通过线性增大（AI）提高发送速率，以获得剩余带宽。通过上述步骤，Cupid 可以快速、准确且公平地执行拥塞控制。

5 初步结果

本文在 UDP 之上开发了 Cupid 原型，并构建了一个小型测试床，用于初步评估 Cupid。客户端侧 Cupid 模块接收测量结果作为输入，并通过一部连接到主机 PC 的商用手机与发送端通信，如图 6(b) 所示。部分关键实验结果已经在第 3 节的图 3 和图 4 中展示。

在图 3© 中，Cupid 保证了所有流之间的公平性。在图 4(a) 中可以看到，与 Cubic 和 BBR 相比，Cupid 可以使远端受害者的吞吐不再退化，从 0.5 Mbps 提升到 41 Mbps，表明 Cupid 能有效解决受害者问题，使受害者吞吐最高提升 50 倍。与 UDP 相比，Cupid 不会牺牲近端主机吞吐，近端吞吐从 83 Mbps 提升到 180 Mbps。

在图 4© 中，与 Cubic 和 BBR 相比，Cupid 的 RTT 也显著更低。由于能够竞争带宽，Cupid 在远端的平均 RTT 可以从 2000 ms 降低到 375 ms，使弱用户时延降低 5 倍。与缺少准确带宽估计的 UDP 相比，Cupid 也实现了类似的 RTT 降低，从 500 ms 降低到 375 ms。

本文还测试了 Cupid 与其他算法共存的情况。图 8 展示了远端使用 Cupid，而近端使用不同算法的场景。结果表明，如果受害者采用 Cupid 算法，那么无论其他用户使用什么算法，它都不会受到影响。不过，与所有用户都使用 Cupid 的场景相比，RTT 可能略有升高。

图 8：所有远端主机使用 Cupid 时的结果。

图 9 展示了近端使用 Cupid，而远端使用其他算法的场景。Cupid 会为远端 BBR 和 Cubic 用户保留带宽，确保所有用户公平共享。然而，如果远端使用 UDP，近端 Cupid 的性能也会受损。

图 9：所有近端主机使用 Cupid 时的结果。

总之，如果所有人都使用 Cupid，它可以同时保证高吞吐和低时延。如果多种算法共存，当 Cupid 自身受害时，它会主动获取带宽；当 Cupid 不受害时，它会为受害者保留带宽。

6 讨论与未来工作

测量准确性： 当移动设备距离 WiFi 路由器较远时，由于无线介质中的信号衰减，测量可能变得不准确，使设备漏掉某些信号。在这种情况下，需要校准测量结果。Cupid 计划调整收敛速度和参数来修正这一问题。

Internet 瓶颈拥塞与 WiFi 拥塞： Cupid 旨在解决 WiFi 网络中的拥塞，并假设拥塞发生在空口传输中。然而在真实场景下，拥塞也可能发生在 Internet 瓶颈网络中。因此，Cupid 还需要判断拥塞位置，并相应调整拥塞控制。

更多测试场景： 其他更详细的测试，例如比较更多拥塞控制方法、Internet 瓶颈拥塞、移动性、参数敏感性分析等，留作未来工作。

7 相关工作

拥塞控制： 与 Cupid 最相似的工作是 PBE-CC $25$ ，它关注蜂窝网络中的拥塞控制。PBE-CC $25$ 是一种面向 5G 网络设计的拥塞控制协议。它测量 5G 网络中的控制帧，以实现准确的拥塞控制。

无线路由器也可以提供拥塞信号。ABC $10$ 观察无线路由器上的队列行为，并使用 ECN 进行拥塞控制。Zhuge $18$ 将无线部分和有线部分分离，使无线路由器可以提供快速拥塞反馈，以在队列中维持低时延。Cupid 也可以部署在路由器上，准确地把速率放入 ACK，并将其返回给发送端。

基于丢包的算法 $8, 11, 14, 23$ 和基于时延/速率的算法 $4-6, 15$ 在与并发的基于丢包的算法竞争时，容量利用率较差 $4, 23$ 。Sprout $24$ 使用分组到达时间预测网络路径中的链路容量变化。类似地，ExLL $20$ 根据分组到达模式和蜂窝带宽使用情况调整发送速率。不同于这些方法，Verus $26$ 试图学习一个 delay profile，将目标发送窗口大小与端到端时延关联起来。然而，正如本文所示，这些仅依赖端到端统计信息的算法可能受到速率估计不准确和网络动态敏感性的影响。

Airtime 公平性： 802.11 Airtime Fairness Anomaly $12$ 是 WiFi 网络的一个众所周知的特性：如果网络中的设备以不同速率工作，MAC 协议会保证它们之间的吞吐公平，这意味着所有站点实际上都会以最低速率传输。尽管文献中提出了多种缓解策略，例如 $7, 13, 16, 22$ ，但这些方案仍缺少广泛的真实部署；第 3.1 节中近端 UDP 主机吞吐较低的观察也证明了这一点。上述假设是有足够数据可供批处理。本文还发现，TCP 会导致没有足够数据可供批处理，从而引发另一种不公平。

8 结论

本文首先展示了 WiFi 网络中的 TCP 受害者问题：传统 TCP 无法获得带宽。随后，本文提出 Cupid，一种专门为 WiFi 网络设计的新拥塞控制方法。Cupid 通过测量 airtime utilization、concurrency 和 rate 等参数，准确评估无线 WiFi 网络中的拥塞，从而实现精确的速率调整。结果表明，Cupid 可以有效解决受害者问题，使受害者吞吐最高提升 50 倍。