在DropboxEdge网络上评估BBRv2

最新推荐文章于 2025-02-27 09:14:34 发布

LiveVideoStack_

最新推荐文章于 2025-02-27 09:14:34 发布

阅读量1.9k

点赞数

本文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/103856209

版权

文 / Alexey Ivanov

译 / 元宝

原文

https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/

剧透警告：BBRv2比BBRv1慢，但这是一件好事。

BBRv1拥塞控制

自从“瓶颈带宽和双向”(BBR)拥塞控制技术发布以来，时间已经过去三年了。现如今，它已经被认为可以用在生产环境当中了，并且已经被添加到Linux、FreeBSD和Chrome(作为QUIC的一部分)中。在2017年发布的博客文章“优化web服务器以实现高吞吐量和低延迟”中，我们评估了BBRv1在我们的edge网络上的拥塞控制的效果，结果显示它非常棒:

在2017年BBR实验期间桌面客户端的下载带宽

自从那以后，BBRv1已经被部署到DropboxEdge网络上，我们也已经习惯了它本身存在的一些缺点。其中有一些问题最终是得到了解决的，比如Wi-Fi用户的网速明显变慢的问题。其他的权衡则都完全属于概念性的：BBRv1对基于丢失的拥塞控制的不公平性(例如CUBIC、化合物)，BBRv1流之间的RTT不公平性，以及(几乎)完全不考虑数据包的丢失:

最初的BBRv1部署：某些设备的数据包丢失率>6%

当然，BBR开发人员(和IETF ICCRG)也非常清楚这些问题，并且积极地致力于寻求解决方案。确定了下列问题:

Reno/CUBIC流的低吞吐量与批量BBR流共享瓶颈值
不可知的损失；当瓶颈值< 1.5*BDP时，会有很高的丢包率
与ECN无关
高聚合度路径(例如wifi)的吞吐量较低
由于PROBE_RTT中的cwnd较低，从而导致吞吐量的变化

来看看BBR版本2

BBRv2的目标是解决第一个版本中存在的一些主要缺点，从对数据包丢失的不关心到没有足够的空间让新的流进入。此外，它还使用聚合/运行中的参数增强了网络建模，并增加了对ECN(显式拥塞通知)的实验支持。

随着BBRv2的即将发布，我们决定在DropboxEdge Network上试用一下，看看它是如何处理我们的工作负载的。但是在我们获得实验结果(和一些漂亮的图片)之前，让我们先看看免责声明和相关测试的设置。

免责声明

非低延迟的实验

这个实验针对的是高吞吐量的工作负载，而不是延迟敏感的工作负载。文中提到的所有TCP连接和nginx日志都经过了至少1Mb的数据传输过滤。

最后，我们可能会决定在数据中心内部部署BBRv2(甚至可能使用ECN支持)来支持RPC通信，但这不在本文的讨论范围内。

这不是一个单连接测试

这个实验是在单个PoP(存在点)中进行的，但是同时也是在数百万个连接的机器上执行的，因此不涉及单连接故障排除、tcptrace向下钻取或者tcpdump。接下来是摘要统计、Jupyter notebooks、pandas和seaborn。

尽管seaborn可以帮助创建漂亮的图形，但我在这方面还是失败了，因此对于糟糕的图形质量我预先说声抱歉。OTOH，至少不是xkcd样式=)

这不是实验室测试

这是在我们的edge网络上进行的一个真实实验。如果你想在实验室环境中测试BRRv2(或任何其他拥塞控制)，我们建议使用github.com/google/transperf，它允许“在包括RTT在内的各种模拟网络场景(使用netem)中测试TCP的性能、瓶颈带宽，以及随时间而变化的监管速率”，例如: