内容类网站如何 流量,应用公园是免费的吗,网站app怎么制作,国家高新技术企业公示前面提到 pacing 替代 burst 是大势所趋#xff0c;核心原因就是摩尔定律逐渐失效#xff0c;主机带宽追平交换带宽#xff0c;交换机不再能轻易吸收掉主机突发#xff0c;且随着视频类流量激增#xff0c;又不能以大 buffer 做带宽后备。因此#xff0c;主机必须 pacing…前面提到 pacing 替代 burst 是大势所趋核心原因就是摩尔定律逐渐失效主机带宽追平交换带宽交换机不再能轻易吸收掉主机突发且随着视频类流量激增又不能以大 buffer 做带宽后备。因此主机必须 pacing。
再看一下到底什么是 bufferbloat。bufferbloat 不是一个瞬时行为而是持续行为。举个例子就能明白。为什么中国大河流域大湖少因为中国地形东西落差太大百川东到海势能足够吞吐就够大足以抹平任何堰塞
对任何流体特别是大突发流体buffer 一旦填充除非上游主动排空buffer 很难排空只要有填充态 buffer 就必然增加时延。一般倾向是buffer 无论多大若不加干涉总会被填满。不加干涉的流体本质就是 capacity-seeking不信你自己挖一个水平的渠道中间某些地方加宽一点然后从一端灌水观察一下。
aimd 只能事后解决 bufferbloat 后的可用性收敛问题解决不了 bufferbloat 本身即使在大流量下统计意义上所需 buffer 数量也和流数量的 1/2 次方成正比而且还要配合复杂的 red aqm 等技术。
所以解决 bufferbloat 要么下游加大带宽要么上游减少突发。端到端标准建议是后者即从主机开始就 pacing而 bbr 是一个 “如何计算主机 pacing rate” 的一个实例。至于加大带宽端到端无力干涉未来可能会是链路并行化而这必然导向多路径但这是后话本文不谈。
说到底主机似乎必须 pacing。但这引入另一个关于 bbr 的问题
端到端的全链路是 n 跳而非 1 跳链路而主机 pacing 只能影响第一跳 buffer 状态但 bbr pacing 计算则基于全链路 bottleneck 带宽。
很简单的一个 use case如果共享第一跳 a 的流 1 的 bottleneck bw 大于 流 2 的 bottleneck bw它们都在 a 获得 bottleneck bw而流 2 和流 3 共享最后一跳 b
除非所有 bbr 一起 probe否则 bbr 的状态机非常脆弱它不是稳定的。bbr probe 效果并非如论文所说为探测空闲资源现实中在多流共享全链路场景不得已的行为系统本身不稳定bbr 需要不停 probe 扶正而计算的代价非常大这也不是算不算的准的问题而是不得不计算胡乱写一个 probe gain 系数都 ok但必须做。
主机 pacing 的问题在于一旦堆积 bufferpacing rate 越小 buffer 占比越低结果是获得带宽越小。交换机要考虑多流带宽复用让交换机根据 buffer 状态和排队规则分配带宽才是正解因为主机计算的 pacing rate 到了交换机并不算数交换机根本无视这个 pacing rate它是无效的。
为什么我说每条流跟踪 max(bw / rtt)-b 和 minrtt 并基于此控制自己的 inflight 是对的
b * minrtt 意味着不主动堆 bufferb 不一定最大但 b / rtt 一定最优inflight (minrtt / rtt) * beta 增加固定余量动态发现带宽变化这 buffer 堆积算是动态自适应的代价(minrtt / rtt) 修正 minrtt 本身的 buffer 堆积因为 minrtt 本身也是统计最小值不意味着不排队。
理论上所有流的 (minrtt / rtt) * beta 就是整个网络中所有 buffer 的和至于每条流的 bdp 余量到底堆积在哪由整个网络的当前状态决定这个状态是个统计状态本质上是概率问题上述三点保证全网收敛但千万别精确计算。
去掉 bbr 不合理的假设就都合理了也变简单了。bbr 的问题在于试图在统计环境中通过计算描述一个确定状态相当于控制风力和风向时计算每个空气分子动量显然只需要控制单位面积的空气分子总量和外力方向就可以了。
那主机可以不 pacing 吗显然不可以为了降低第一跳突发减少第一跳 bufferbloat所有主机固定 pacing 也不是不行比如 500mbps pacing而不是以主机能力突发。至于后面的跳主机控制不了只能交换机做。如果交换机为提高出口能效塞住出口 10msbuffer 占有率达到一定量再批量发送拦了一座大坝那就谁也没办法。
浙江温州皮鞋湿下雨进水不会胖。
