Buffer 与 拥塞控制

Buffer 到底是什么？理想 Pacing 情形，不会形成队列，但按照排队理论，统计复用情形，队列必然存在，Buffer 的作用即提供队列，它唯一的意义在于吸收统计突发。

Buffer 仅为吸收突发，如果现代拥塞控制算法想利用 Buffer 溢出来产生 MD(multiplicative-decrease) 信号，这本身就很可笑。

值得注意的是，AIMD 并不依赖 Buffer，没有 Buffer 的存在，AIMD 依旧可以收敛到公平，即使在 范雅各布森 的假设中，Buffer 存在的意义依然是吸收突发，与拥塞控制算法的部署和执行无关。

但现代拥塞控制算法的 AI(additive-increase) 过程总是会填满 Buffer，如果 Buffer 总处在满的状态，还如何吸收突发呢？

被动等待被 AIMD 算法填满，显然偏离了部署 Buffer 的初衷，更现实的做法是主动管理 Buffer，这就是 AQM(active queue management) 被提出的背景。

AQM 必须引入一种机制来限制 Buffer 的使用，保留空闲的 Buffer 才能用于吸收突发。

RED(random early detection) 提出一种方案，一段足够持久的时间段 Buffer 队列长度足以影响应对突发时，概率性丢包以期望发送主机对此作出反应，降低发送量，从而缓解 Buffer 侵占。

RED 的核心在于试图控制 Buffer 队列的长度， 至于它解决了 TCP 全局同步，只是一个副作用。

值得注意的是，“足够久的”时间用来识别 Buffer 侵占是必要的，Buffer 本来就允许瞬间被占用，但它不允许持续被侵占，就像高速公路上的紧急停车带。因此 RED 用移动指数平均(EMA)算法跟踪 Buffer 队列长度，而不关注其瞬时长度。

但去中心化的互联网是面对所有流量的，不能假设 TCP 外的流量会对丢包作出响应，甚至对 TCP 流，也不能假设它们的反应都是正确的。RFC 2914 表达了担忧：

The popularity of the Internet has caused a proliferation in the number of TCP implementations. Some of these may fail to implement the TCP congestion avoidance mechanisms correctly because of poor implementation [RFC2525]. Others may deliberately be implemented with congestion avoidance algorithms that are more aggressive in their use of bandwidth than other TCP implementations; this would allow a vendor to claim to have a “faster TCP”. The logical consequence of such implementations would be a spiral of increasingly aggressive TCP implementations, or increasingly aggressive transport protocols, leading back to the point where there is effectively no congestion avoidance and the Internet is chronically congested.

由于对 AQM 信号不响应或错误响应的非规范流量存在，Buffer 队列长度很难被控制在一个合理范围，Bufferbloat 几乎是常态，为保留吸收更高突发的能力，需要更大的 Buffer，但该能力不得不用更高时延为代价为 Buffer 的误用买单。

另一个极端点看，如果彻底取消 Buffer，额外的排队延时就不存在，但也同时失去了吸收突发的能力，超带宽的突发数据将被丢弃，不确定的退避时间将带来不确定的重传延时，即抖动。

和直觉相反，足够小但不是 0 的 Buffer 才是正确的选择，无论时延还是抖动均被控制在合理的范围。小 Buffer 场景，若大突发到来，让其自然溢出优于付出延时和抖动作为代价。即便配置大 Buffer，额外的 Buffer 也应该且只应该用于吸收突发，而不是溢出后提供 MD 信号，这需要对 AMQ 进行配置，比如 RED 高丢包率阈值要足够低。

更精确应对 Bufferbloat 的方案需要对流量进行甄别分类，给那些不响应 AQM 信号的流量更低优先级或更高丢包率以正视听，以示惩戒，试图用这种方式让发送端被动收敛到 TCP 兼容模式。

但更强的甄别能力本身即消耗更多计算资源，这个矛盾是所有可观测性固有的。同时，在高复用率的连接间做拥塞控制，还将面临另一个难题。

接上篇：新式拥塞控制漫谈 ，当今互联网统计复用率非常高，以至于任何单独流的行为都无法改变网络的统计特征，和早期一条流的延时，丢包率是自身发送速率的函数不同，如今这些指标都近乎链路固有属性。

无心之过的激进流量如果无法从一开始就检测到来自 AQM 的惩罚，它们甚至不知道自己做错了什么，谈何修正自己行为呢？

换句话说，发送端无法在抖动中识别自身的过失。既然自己的行为无法改变全局的统计特征，又如何能从统计波动中识别出哪些与自身相关呢？这又是一个测不准难题。

来看下时延抖动的根因。

时延抖动要么来自统计突发造成的队列长度波动，要么来自于不确定的退避造成的重传时间波动。很不幸，这二者此消彼长。小 Buffer 浅队列固然能有效降低队列长度方差而降低抖动，但同时由于无法应对大突发造成的丢包，重传时延波动会增加，相反，大 Buffer 深队列排队时延波动会增加，但由于不会丢包，也就不存在重传时延。

归根结底还是要配置一个合适的 Buffer。

OK，我们已经理解了 Buffer 和时延，抖动的关系，总结一下：配置一个足够小，但不是 0 的 Buffer。
以上就是 Buffer 在互联网中必不可少的现实原因。

同时，我们也看到，时延和抖动不可避免，唯一能让它们稳定下来的似乎只有好的拥塞控制算法，但端到端原则和网络中立性原则意味着拥塞无法被直接控制，分布式网络的拥塞控制依赖于所有端系统以及网络节点之间合作，而这种被迫的合作背后则是博弈。

周末写篇关于 Buffer 的，这篇文章写的有些散，但还是带感觉的。

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