作为rate-based的TCP BBR-CSDN博客

绝对多数cc都是cwnd-based，rate-based cc一直只是理论。

BBR属rate-based，看样子cwnd便无用了，但现实中，cwnd仍作为secondary control parameter起作用：

A secondary parameter, cwnd_gain, bounds inflight to a small multiple of the BDP to handle common network and receiver pathologies (see the later section on Delayed and Stretched ACKs).

若重构BBR，必须忘掉cwnd，虽Delayed & Stretched ACKs场景，亦可忽略cwnd，完全依测量值delivery rate计算pacing rate：

但BBR始终存在cwnd约束，源自范雅各布森。没有任何证据和理由表明必须用cwnd进行拥塞控制。为什么不能彻底放弃cwnd呢？

以数据包守恒展开。

进入TCP_CA_Recovery状态，BBR开始数据包守恒，限制cwnd可做到。这实属继承了Reno/CUBIC的策略，BBR声称对丢包不敏感，但还是敏感了。总之，我以为BBR在TCP_CA_Recovery状态数据包守恒徒增复杂，没有必要，且不应如此处理。

相反一面，若顺着cwnd约束的意义说，也有道理：

• 非拥塞丢包，10 rounds内很快就能restore cwnd，不伤大雅。
• 有新流侵入，坚持10 rounds后会采集到新分配的bandwidth。

但仔细推敲就发现不对：

• 若有新流侵入导致拥塞，坚持10 rounds太久，丢包会带来更高重传率。
• 10 rounds之后，新采bandwidth可能是cwnd限制导致而非实际带宽采集。
• 数据包守恒终究要restore，但新流侵入场景并不适合restore。

另一面，从数据包守恒本身来讲，也不对：

• 数据包守恒仅约束自己，对新流侵入场景，便无意义。
• 数据包守恒基于inflight，基于lost计数，它属预测计数。

基于预测计数做策略，不可行：

• 预测lost计数较实际偏多，inflight会偏小，retrans会偏多，重传率偏高。
• 预测lost计数较实际偏少，inflight会偏大，retrans会过慢，恢复期过久。

高低都不行，数据包守恒无法收敛到最优解，向两个糟糕发散。除非预测准确，而这不可能。

但数据包守恒工作得很不错，我认为它只是守住了一个下界，避免事情变糟。尝试放弃cwnd后效果不佳并不意味着这不可行，我们可能尚未找到正确的方法。

以下随便看看。

若果真彻底放弃cwnd，不妨尝试影响AQM：

• 若无丢包，则完全按照delivery rate计算max-filtered bandwidth。
• 若丢包，则使用乘法减小max-filtered bandwidth后的pacing rate。

乘法减小pacing rate可加大queue中数据包之间的gap并减少数据包总量，影响显著：

• 加大数据包gap，AQM丢本流数据包的概率将减小。
• 减少数据包数量，可促进queue排空。

若非拥塞噪声丢包，max-filtered bandwidth尚未滑走，丢包恢复后可继续使用，若新流侵入或出现突发拥塞，max-filtered bandwidth总会滑走，期间乘法减小的pacing rate确保两点：

• 数据包gap增加，故当前流丢包不会加重。
• 数据包总量减少，故当前流不会制造拥塞。

待拥塞解除，从乘法减小后的rate处重新probe，颇有AIMD的意思(真的AIMD需要用pacing rate和minRTT换算成BDP再用currRTT反算pacing rate)，对待全局公平性也有帮助。

应对持续拥塞时AQM随机丢包，散开单流的数据包十分重要，这将降低AQM考察时间gap时命中丢包的概率。总之，rate-based才能避免拥塞已经发生时丢包加剧，使用cwnd限制并不能缓解。

必须强调，纯粹的rate-based并非对大家都有益，pacing对网络友好但全凭CPU精准调制，便对主机无益，burst与pacing相对，便是主机网络优化的常用手段，CPU将一个长报文一次性送往网卡切割成数据包(如TSO)，此举有效提高了主机吞吐但却必须将切割而成的多个数据包一并burst发出，便与pacing相悖了。最多容忍多少数据包burst，便又是另一种trade-off了。

难道最理想情况不是要基于bit做pacing吗？至少也要是byte，但网络协议的PDU单位是数据包，到处都需要trade-off。

BBR保留cwnd control parameter的必要性，一开始我就存疑，但屡次与人交流间我竟无言以对，我想这是我的无知，但再重启问题又觉得不对，于是如此反复。已经存在了30年的cwnd-based cc是范雅各布森(Van Jacobson)的杰作，它被解释了30年，已经成了范式，无论如何能找到一个合理的理由辩证它存在的必要性都是容易的，抛弃它却显得不合常规。写点自己的想法。

浙江温州皮鞋湿，下雨进水不会胖。