上周随意发的一篇朋友圈，引出本文：
但凡有信道仲裁的地方就不能用self–clock，这就跟我之前说的很多vpn是半双工处理一样，这是wifi，xG的根本问题，用pacing代替burst，这是创举
自时钟和channel仲裁的冲突，（同一个链路，交替突发，自时钟相互影响。与我之前说的收发在同一个线程类似）
bbr弃用自时钟，保持pacing，ack只是用来测量带宽
长rtt打开窗口慢将不再是问题，因为不再需要所谓“打开窗口”了。
"pacing_rate is BBR’s primary control parameter." 这句话是什么意思？
如果pacing_rate曾经不是primary parameter，谁是？
自1986年起，人们开始以cwnd为primary control parameter，直到BBR将primary control parameter改成了pacing rate，算是开启了一个新篇章。这是一个划时代的创举。Why？
任何改变的促因都是为了解决特定的问题。过去30年，基于cwnd的拥塞控制一直运行良好，直到进入移动互联网时代，事情起了变化。
在移动互联网时代，云计算以及内容提供商开始寒武纪大爆发，这显然是移动终端下日益丰富的需求决定的，从此各地IDC就成了成G上T的数据的始发站流向越来越多的终端，在IDC侧，大致的图景看起来是这样子的：
注意，IDC直接进backbone，这附近带宽资源非常充足(各方资金都非常充足)，一般很难发生拥塞。
花开两朵，各表一枝。
2010年前后，移动互联网开始蓬勃发展，无线网络在 最后一公里 引入复杂性。信道串扰，信号衰减，信道仲裁等因素造成了非常多的非拥塞丢包以及其它方面的度量抖动，这些复杂性因素在简单的有线网络中都是不曾存在的。
因此，最后一公里便展现出另一番景象。
在大量移动终端存在的情况下，无论是WIFI，3G/4G/5G，注意到它们的共享介质特征，情况大概是下面的样子：
以WIFI为例，信道仲裁(channel arbitration)，CSMA/CA等等处理共享介质的协议是有线网络中根本没有的，因为有线网络是全双工的，网卡的发送模块和接收模块各自接了一根独立的线，可以实现同时的发送和接收，但无线网络是共享介质的，几乎无法在信号不冲突的前提下同时发送和接收。
换句话说，WIFI网络是一个半双工网络。
我们看一下半双工网络是如何把数据流 整形 成burst突发流，进而降低带宽利用率并加重bufferbloat的。
在半双工网络中，Jacobson管道变得和理想情况有点不同。
在半双工路径上，以TCP为例，由于数据流和ACK流两个方向交替传输，显然数据流不可能再保持背靠背连续。随之的ACK流也会被整形成断断续续的：
传统的TCP拥塞控制是通过ACK时钟保证数据包守恒来起作用的， ACK的到来促使下一个数据段的发送，同时根据拥塞控制算法增减发送窗口 ，如果ACK流是断断续续的burst形式到达，那么数据流显然也会变成断断续续的burst形式发送：
这种间隔性的burst突发一方面降低了网络带宽的利用率，我们可以看到周期性的带宽空闲，即便是理论上一半的带宽空闲，考虑到多流共享链路buffer，也丝毫没有降低链路buffer的压力。另一方面，由于半双工分时处理两个方向，每一个方向便失去了一半的处理时间，但每条流的发送窗口却没有因此而减半，这反过来会造成buffer的积压，最终加重bufferbloat。
既然半双工是个不可改变的现实，将一个RTT内等同于burst突发量的数据更加平滑地以pacing发送，便可以极大减轻链路buffer的压力，从而减轻或者治愈bufferbloat。
为什么pacing就能减轻甚至治愈bufferbloat？因为pacing rate就是采集到的BltBW啊，采用这个rate发送是刚刚好的，我们知道，如果塞buffer了，BltBW是不会增加的，塞再多也不会，这就是用在BltBW基础上微调的pacing rate替代cwnd用于新的拥塞控制的核心原因。
但为什么长达30年的时间里人们都没有过问bufferbloat带来的问题？
可以想见，只有进入了移动互联网时代，各类App的交互体验才让人们得以关注时延而不仅仅是带宽。曾经你在桌面电脑上下载一部电影可能只需要网速足够快即可无关抖动，而在手机上看视频，你可能更加关注流畅性。
bufferbloat，这背后到底发生了什么？同样的问题，为什么近30年的时间人们没有注意到半双工的问题，为什么偏偏在带宽如此丰盈的如今盯上了WIFI，4G/5G？难道就因为有线网络在收发两个方向各自接有一根线吗？
其实不光WIFI等无线网络会有半双工问题，事实上，无线网络的半双工已经非常高效了，分时复用可以快到不值得一提。在一条端到端链路上，半双工可能存在任何一个地方，从而把连续的数据流切割成一段一段的，最终降低网络利用率的同时却没有减轻bufferbloat，一台低端的交换机，一个不负责任的软件代理，均可能用同一个进程(硬件的或软件的)同时处理两个方向的接收逻辑和发送逻辑。难道这就是原罪吗？并不是。
最终还是要说回bufferbloat。bufferbloat是一个可感知的结果，因为过往30年不那么丰富的有线网络App隐藏了bufferbloat带来的延迟和带宽抖动，如今被移动互联网暴露了出来，仅此而已， 问题一直存在，只有问题的结果被感知了，人们才会关注。
是传统基于cwnd的拥塞控制算法导致了大部分问题的发生。你可以简单认为它们 近似盲目地增加cwnd只为了触发一次可捕获的buffers overflow信号。 没错，buffers overflow就是拥塞控制的收敛点，而拥塞控制靠收敛点的存在而有意义。
bufferbloat是TCP AIMD固有的结果，详见：
https://blog.csdn.net/dog250/article/details/114157475
事实上，如果大家都实测自己的BltBW，按照各自的BltBW发送数据不就可以天然避免拥塞了吗？以pacing rate为基础的拥塞控制根本不需要cwnd，理论上发送端可以按照这个测量所得的pacing rate持续发送数据，ACK的作用不再作为时钟触发数据的发送，而仅仅用来测量BltBW。BBR出现了。
那么问题来了，BBR的收敛点在哪？
关于BBR的收敛点，详见：https://blog.csdn.net/dog250/article/details/113783209
pacing_rate is BBR’s primary control parameter. 此话的含义是 BBR开辟了新纪元 它的意义在于 BBR丢弃了以ACK时钟(self-clock)为依托，以控制论为基础的基于cwnd的拥塞控制策略 ，丢掉了ACK时钟，才能带来新东西，所谓的有破有立。
临近本文末尾，我想谈一谈弱网。
什么是弱网？我理解就是如今无所不在的无线网络。这似乎和常识相悖。
1990年代直到整个2010年之前，网速那么低，人们都不曾谈到弱网这个词，如今网速动辄上Gbps，至少也是几百Mbps，大家却大谈特谈弱网，发生了什么？
何为 “弱” ，其实弱不在网速。如今的4G/5G网速可以吊打2010年之前的所有家庭宽带。其实弱在复杂性和稳定性。无线网络远比有线网络复杂得多，这种复杂性无时无刻不在影响着网络的吞吐率，丢包率，抖动以及带宽利用率等，此外无线网络所特有的带外管理流量(error detect/sync…)也会占掉不少带宽。在有线网络中，所有这一切都是可控的，带外管理流量几乎是不必要的，带宽虽慢但却是相对稳定的，然而在移动网络中，伴随着终端的移动速率，接入终端量级，甚至天气情况，相对地理位置，这一切都不再可控。
显然，在上述意义的弱网环境中，一条流无法获得稳定的ACK时钟，那么基于ACK时钟假设的拥塞控制算法将无法达到最佳的效果，那么如果不再依赖ACK时钟，是不是更合适呢？这无疑是一种很正常的思路。
在56Kbps时代，你可以相对稳定地获得一个上限为56Kbps的吞吐率，所谓的稳定更多的指的是一条TCP流可以获得稳定的ACK时钟，因此AIMD运营良好。现在的问题是，即便物理带宽已经到了上百Mbps乃至上Gbps，只要ACK时钟无法保证稳定，基于AIMD的旧有拥塞控制算法便无法正常工作，让本来就长期存在的低带宽利用率问题雪上加霜。这就是BBR产生的时代背景。
持续到现在，BBR一直在持续迭代，在不久前，BBRv2前夕，针对无线环境ack aggregation导致的空窗停摆是一个重要的痛点，令人欣慰的是，BBR采用tcptrace斜率估算的方式在ACK断流的情况下依然可以进行数据的pacing发送，这背后不正是说明了BBR脱离了ACK时钟也能运行良好吗？离开了ACK时钟，基于cwnd的AIMD便无法运行，这是什么呢？
这就是 "pacing_rate is BBR’s primary control parameter." 的意义。
浙江温州皮鞋湿，下雨进水不会胖。