Loading

关于博客《BBR evaluation at a large CDN》和 《When to use and not use BBR》的理解

《BBR evaluation at a large CDN》

解决的问题

通过在 \(CDN\) (\(Content \ Delivery \ Network\)) 的环境中对 \(BBR\) 算法进行评估,量化其带来的好处以及对网络流量的影响,从而帮助内容提供商选择正确的拥塞控制算法。

方法

使用多个策略对 \(BBR\) 进行评估,先在一个 \(POP\) (\(Points \ of \ Presence\))上进行一个小规模的 \(BBR\) 测试(a large wireless provider, a large wireline provider, PoP-to-PoP and intra-PoP traffic),最后进行了一个全面的 \(POP\) 测试。

该作者使用了两个评测指标,一个是吞吐量,一个是 \(TCP\) 流的完成时间,之所以采用两个评估指标,是由于在发送目标数据大小很小的时候,再去用吞吐量去评估,可能不够精确,存在很多噪声。因此,作者定量当发送数据大小小于3\(MB\) 时候,追踪流的完成时间,是更好的指标;当发送数据大小大于3\(MB\) 时候,使用吞吐量进行衡量。

A large wireless provider
img

在无线提供商的环境中,启用 \(BBR\) 算法有了一个明显的提高(6%-8%),如上图所示,\(test\) 蓝线代表 \(BBR\)\(control\) 红线代表 \(CUBIC\) 。对于左图,我们可以发现,当在垂直蓝线时刻,激活 \(BBR\) 算法之后,\(BBR\) 算法的吞吐量很明显高于 \(CUBIC\) 算法的吞吐量。对于右图,在当 \(CDF\) (\(cumulative \ distribution \ function\))概率相同的时候,即同一纵坐标时,\(BBR\) 算法的吞吐大于 \(CUBIC\) 算法的吞吐量。

不过作者认为,由于无线环境中,丢包率较高,因此并不能确定该包的丢失是由于拥塞所引起的,从而对 \(BBR\) 算法的实验结果也有一定的质疑。

A large wireline provider
img

作者在有线环境中,根据不同发送数据的大小下所完成传输的时间对 \(BBR\) 做了评估,如上图所示,我们可以看见 \(BBR\) 在发送同等大小的数据时,抖动很小,并且完成的时间相比于 $CUBIC $ 算法也更短。不过,也会存在和 \(CUBIC\) 算法类似的抖动。总体而言,\(BBR\) 的性能是很好的。

不过作者认为,\(BBR\) 算法的增益,是从 \(POP-to-Client\) 的聚合视图所得出来的,无法确定该算法是否对所有的\(TCP\) 流都有增益。因此,进行了更加细化的评估。

PoP-to-PoP and intra-PoP traffic
img

作者更为细致的在 \(poP-to-poP \ and \ intra-poP\) 中使用 \(BBR\) 算法进行了实验评估,从上图我们可以发现,当在垂直蓝线时刻处激活 \(BBR\) 算法后,\(BBR\) 的吞吐量远不如 \(CUBIC\) 算法的吞吐量。

为什么在\(POP-to-Client\)\(poP-to-poP \ and \ intra-poP\) 中,\(BBR\) 算法的性能会有如此大的差异呢?

作者后面通过服务器日志发现,\(BBR\) 在较高 \(RTT\) 和 重传率下会有很好的性能表现,而 \(poP-to-poP \ and \ intra-poP\) 中,由于是低 \(RTT\) 和低 重传率,因而比较适合 \(CUBIC\)

Full PoP test
img

作者最后进行了一次完整的 \(PoP\) 测试,使用了两个 \(ASes\) (\(Autonomous \ Systems\)),如上右图所示,两个网络的 \(RTT\) 都比较高,其中 \(ASN1\) 的重传率较高,\(ASN2\) 的重传率较低。从上图左边两幅 关于\(throughput\)\(CDF\) 可知,在关于 \(ASN1\)\(CDF\) 图中,\(BBR\) 的性能较好,而在关于 \(ASN2\)\(CDF\) 图中,\(CUBIC\) 的性能较好。因此,可以发现,即便在 \(RTT\) 较高的环境中,\(BBR\)也只适用于 重传率较高的情况下,才能有较好的性能表现。

接下来作者想要评测在\(ASN1\)\(BBR\) 是否对于所有的连接都有吞吐量的提升。

img

从上图分析可知,\(BBR\) 算法也只有刚开始的时候,性能优于 $CUBIC $ 算法。

结果分析

作者认为原因还是归根于 \(BBR\) 的公平性问题上。

  1. \(CUBIC\)\(BBR\)

    在一个高缓存的情况下,中间设备(路由器等)可能会存在排队的情况,而 \(BBR\) 的的估计的\(RTT\) 可能会增加。而 \(CUBIC\) 则是基于丢包来判断拥塞,因此会倾向于填满缓存,导致 \(CUBIC\)能够抢占更多的带宽,从而表现较好。而在一个浅缓存的情况下,缓存容易被填满,导致缓存溢出,从而容易丢包,\(CUBIC\) 算法会轻易去降低自己的拥塞窗口,因此 \(BBR\) 能够获得更多带宽。

  2. \(BBR\)\(BBR\)

    当两个不同 \(RTT\) 的 流竞争共享带宽时,\(RTT\) 较高的流可能会估量得到更高的最小 \(RTprop\),因此会获得更大的 \(BDP\),从而占有更多的带宽份额。

在实验室中去复现结果

img

作者在虚拟机上搭建了测试平台环境,在边缘服务器上去模拟不同流量类别(Client、P2P、Intra-PoP)的方法。

img

作者重现了 \(BBR\) 在不同类别下的行为表现,在 \(client-smallbw\) 情况下 \(BBR\) 流完成的时间比 \(CUBIC\) 流所完成的时间更短;由于 \(client\) 环境为 较高延迟,丢包率较高,因此 \(BBR\) 性能表现更好。

所以在\(CDN\) 上进行 \(BBR\) 的任何部署都必须意识到它可能对混合流类型产生更广泛的影响。

结论

\(BBR\)\(poP-to-poP \ and \ intra-poP\) 这种低重传率的环境下,会存在降低吞吐量的风险。但是在客户端表现良好,所以可以从 \(wireless \ providers\) 开始去启用 \(BBR\) 拥塞控制算法,因为无线环境中存在浅缓存和丢包率较高的情况,所以\(BBR\) 算法会很有优势。

首先CUBIC与BBR共存于共享链路,在瓶颈带宽被占满之后,CUBIC会继续发包填充队列,造成BBR被动排队。由于BBR的被动排队,所以rtt也会显著上升。但是这在短时间内不会影响BBR的发包,因为BBR的测量RTT的是10秒内的最小RTT。也就是说,只要BBR能够坚持10s不划走,CUBIC一旦丢包就会出现乘性减窗。BBR在回复到干净状态的同时也可以迅速占据空闲的带宽,从而达到压制CUBIC的效果。而相反在另一种情况,如果队列足够深,rtt足够长,足以让CUBIC填充10s还不满时,CUBIC丢包前BBR就退到4个包发送速度了,这反而说CUBIC压制了BBR。

所以这里可以顺理成章地得出结论结论是,浅队列时,CUBIC受BBR的影响比较小,深队列时,BBR会受到CUBIC的影响。

《When to use and not use BBR》

这一篇博客主要也是分析了 \(BBR\) 地公平性问题,同样认为 \(BBR\) 算法比较适用于浅缓存,重传率较高地情况下,不过作者对丢包率做了定量分析。

image-20200924143144110

当丢包率超过20%的时候,\(BBR\)算法的吞吐量有一个断崖式的下跌,而右边的图说明了这个断崖点是与 \(pacing\_gain\)有密切关系的,所以作者认为\(BBR\) 的性能对参数是非常敏感的,可以使用参数的自动调整,以应对不同的网络环境。

原文

《When to use and not use BBR》

《BBR evaluation at a large CDN》

posted @ 2020-10-20 17:57  Rookie丶flying  阅读(271)  评论(0编辑  收藏  举报