单流检测：KCC 在独享链路时的行为切换
单流检测：KCC 在独享链路时的行为切换
我们给 KCC 加了卡尔曼滤波、ECN 退避、ACK 聚合补偿。多流测试结果不错。但单流测试出现了意外：吞吐比纯 BBR 低 5–8%，延迟也更高。
问题出在哪？卡尔曼滤波估计的传播时延存在微小正偏（排队噪声的单向性导致），单流时这个正偏让 BDP 偏大，队列排不空。ECN 退避偶尔因零星 CE 标记而降低 cwnd_gain。LT 带宽检测也可能误触发。
这些“增强”在多流竞争时是铠甲，在单流时反而成了累赘。而纯 BBR 在单流场景下本就高效——滑动窗口最小值，无正偏，无退避。
所以我们需要一个机制：当 KCC 确认自己是唯一活动流时，暂时退化到近似 BBR 的行为；一旦检测到竞争，立即恢复全部保护。
1. 检测信号：六个条件同时成立
我们尝试过只用 qdelay 或只用 ECN，都不够。多流竞争的空隙也会出现短暂的空队列，单靠一个信号会导致频繁误切换。最终我们选了六个正交信号，只有全部满足才判定为单流。
各信号含义：
- qdelay_avg < 1ms：多流竞争下通常存在 1–2ms 的排队（BBR 的 pacing margin 加 TSO burst）。
- jitter_ewma < 2ms：竞争流交织发送会产生明显抖动，单流时只有 ACK‑clock 的微抖动。
- ecn_ewma == 0：任何 AQM 在队列超过阈值时就会产生 CE 标记。
- lt_use_bw == 0（或配置为忽略）：带宽整形器才会触发 LT BW。
- agg_state ≤ SUSPECTED：ACK 聚合在多流时会被放大，单流时最多处于“怀疑”状态。
- Kalman 已收敛：前五个信号的可信度前提。
这六个条件同时成立的几率在多流环境下极低。实测 8 条流竞争，从未误触发。
2. 进入与退出：3 轮确认，1 轮退出
为了避免在竞争间隙中频繁切换，我们加入了 hysteresis：
- 进入门槛：连续 3 个 round boundaries 全部满足六个条件，才将
alone_on_path置为 1。 - 退出：任意一轮有一个条件不满足，立即清零
alone_on_path并重置计数器。
进入慢（约 3 个 RTT），退出快（1 个 RTT）。这样设计是因为：误进入单流模式的代价高于误退出。宁可多留在多流模式，也不要赖在单流模式里。
3. 单流模式的行为变化
当alone_on_path == 1时：
| 原本行为 | 单流模式行为 |
|---|---|
RTT 估计使用卡尔曼x_est（略偏大） | 使用滑动窗口min_rtt_us |
ECN backoff 可能降低cwnd_gain | 完全跳过（kcc_alone_bypass_ecn默认 1） |
| LT BW 状态影响模式判断 | 忽略（kcc_alone_bypass_lt_bw默认 1） |
效果：单流时 KCC 的行为接近纯 BBR。测试表明单流吞吐与 BBR 相差不到 1%。
4. 局限性
这套机制不完美，有几点我们清楚：
- 响应较慢：需要 3 个 RTT 确认。对 200ms 的链路约 0.6 秒。如果链路状态变化极快，这个延迟可能偏大。
- 阈值固定：1ms、2ms 是绝对数值，不是比例。在 10ms RTT 的数据中心，1ms 队列已经很大；在 200ms RTT 的长肥链路，1ms 队列几乎为零。理想情况应使用
min_rtt * 系数，但我们没有实现。 - agg_state 严格度：某些有固有 ACK 聚合的路径（如 WiFi、开启延迟 ACK 的对端），单流时
agg_state也可能达到 CONFIRMED。为此提供了kcc_alone_agg_state_level参数（可放宽到 2），但这是工程补丁。 - 退出无冷却：计数器直接归零。若竞争强度在边界抖动，可能频繁进出。我们未加冷却计时器，是刻意保持简单。
如果这些局限影响你的场景，可通过 sysctl 参数调整或修改源码。
5. 可调参数
| 参数 | 默认 | 说明 |
|---|---|---|
kcc_alone_confirm_rounds | 3 | 连续满足轮数门槛 |
kcc_alone_qdelay_thresh_us | 1000 | qdelay 上限 (µs) |
kcc_alone_jitter_thresh_us | 2000 | jitter 上限 (µs) |
kcc_alone_agg_state_level | 1 | 0=IDLE, 1=SUSPECTED, 2=CONFIRMED |
kcc_alone_bypass_ecn | 1 | 单流时跳过 ECN backoff |
kcc_alone_bypass_lt_bw | 1 | 单流时忽略 LT BW 状态 |
位于/proc/sys/net/kcc/。多数场景不需要调整。
6. 总结
单流检测的出发点很朴素：算法应该知道当前处于什么环境，并选择合适的行为模式。我们不是第一个这么做的，也不是做得最精致的。但它解决了我们实测中的一个具体问题——增强特性在基础场景下的负收益。
如果你也在设计拥塞控制算法，建议考虑场景识别。不需要复杂，六个条件、3 轮 hysteresis，已经足够可靠。承认自己的不完美，留出调参接口，用户会自己找到适合的值。