2018, Vol. 27
2. 中国科学院大学, 北京 100049
2. University of Chinese Academy of Sciences, Beijing 100049, China
随着网络技术的发展, 网络应用场景呈现出多样化和复杂化的特点, 例如数据中心依赖带宽极高延时极低的网络, 监测自然环境的传感器网络带宽十分不稳定, 卫星通信网络则具备高时延特点, 而实际的网络业务可能同时需要多种网络的支撑. 与此同时, 网络核心设备路由器的缓存容量在不断增加, 这意味着路由器可以缓存待转发数据包不断增加, 这也就是典型的BufferBloat问题. 随着终端应用对网络的可靠性和实时性需求的增加, BufferBloat问题已经影响了网络的性能. 上述客观条件为网络协议的设计带来了挑战, 网络协议对不同场景的适用性不同, 在多种实际场景下的性能有较大的差别. 此外, 不同网络场景下带宽利用率和时延的优先级要求不同, 网络协议的适配性成为影响网络协议性能的重要因素.
TCP作为互联网核心协议之一在不断演进, 其最重要的一项功能就是对网络进行拥塞控制. 随着网络应用场景的多样化和复杂化, TCP中早期的拥塞控制机制已经不再适用于当前的网络环境, 影响了网络的性能. 在上述背景下, Google于2016年10月提出了一种基于瓶颈带宽和往返时延测量的拥塞控制协议BBR (Bottleneck Bandwidth and Round-trip propagation time), 旨在提高网络链路利用率和降低网络时延[1], BBR协议已经在Google内部的数据中心广域网B4部署使用, B4分为数据中心内部网络(IDC Network)及骨干网(Backbone Network)[2]. BBR协议在B4中的性能已经得到了验证, 但其应用范围还不够广泛, 仅仅局限在谷歌内部, 适用性还未被重复证明, 其在更为复杂和多样的网络环境中的性能还有待验证. 本文通过对BBR的测量实验, 分析和评估和分析了BBR协议的性能并在此基础上提出了下一步的改进方向.
2 背景及相关工作 2.1 BBR-TCP原理简介BBR是TCP中的拥塞控制机制, 不再把丢包作为拥塞产生的信号, 丢包检测基于RACK[3], 发生丢包后只重传数据包, 不再对发送端速率调整. 网络链路状态检测是基于实时测量的, 相较于基于丢包的反馈, 实时测量能更准确地反馈出链路的状态. 在BBR中, 发送端不断地测量网络的传输速率速率deliveryRate, 具体方法是用短时间内传输的数据量除以传输时间. 发送端维持一个长度为10×RTT时间窗口Win_Max, 在Win_Max内把测量到的deliveryRate最大值近似为网络的瓶颈带宽BtlBW (Bottleneck Bandwidth). 当经过一个Win_Max后, 原BtlBW过期, 重新测量确定BtlBW的值. RTT也在不断测量, 每收到一个数据包就计算该数据包的RTT. 发送端维持一个长度为10 s的时间窗口Win_Min, 发送端把测量到的最小RTT作为网络的传输时间RTprop, 如果在Win_Min内RTprop没有更新, 该RTprop值过期, 然后重新测量确定RTprop; 如果在Win_Min内RTprop未更新, 则重置Win_Min持续时间即Win_Min重新开始计时. 通过上述方式, 发送端测量得到近似的BottleBW和RTT, 这两个值是拥塞控制的关键参数.
BBR协议根据测量到的BottleBW和RTT调整发送端速率sendingRate, 传输过程分为四种状态: STARTUP、Drain、ProbeBW和ProbeRTT, 四种状态分别根据条件触发和退出. BBR通过Pacing方式控制发送速率sendingRate, 增益系数gain作用是调整Pacing, 同时发送窗口的上限设置为带宽时延积与增益系数的乘积, 带宽时延积BDP (Bandwidth Delay Product)是网络的重要参数, 作用是控制网络中数据包的总量, 其值为公式(2)和公式(3).
| $sendingRate = gain*BtlBW$ | (1) |
| $BDP = BtlBW*RTT$ | (2) |
| $Cwnd = gain*BDP$ | (3) |
BBR协议内公平性是通过ProbeRTT状态实现的, 在一个TCP流进入ProbeRTT状态后会减少网络中的数据包, 其他的流会更新RTT同时重置Win_Min窗口, Win_Min开始重新计时, 不同TCP流同步数据传输过程, 从而实现协议内公平性. BBR协议在设计上没有考虑与其他TCP拥塞控制协议的公平性, 协议间公平性评估是本文的研究重点之一.
2.2 相关工作对TCP协议的拥塞控制机制的改进大致可以分为基于丢包的拥塞控制和基于时延的拥塞控制机制[4,5]. 基于丢包的拥塞控制机制相对较多, 典型的有Reno-TCP[6]、BIC-TCP[7]和Cubic-TCP[8]等. 基于时延的拥塞控制机制, 典型的有Vegas-TCP[9]、FAST-TCP[10]等.
Reno是一种基于丢包反馈的拥塞控制机制, Reno-TCP 是目前使用最广泛的TCP拥塞控制版本. Reno协议基于丢包反馈机制和AIMD的速率调整算法适用于浅队列路由器, 缺点是无法识别错误丢包和拥塞丢包, 在丢包率高的链路上带宽利用率不高.
BIC-TCP是基于二分搜索思想的拥塞控制机制. BIC-TCP的缺点首先就是抢占性较强, BIC-TCP的增长函数在链路带宽小时延短的情况下比起标准的TCP抢占性强; BIC-TCP窗口控制阶段分为binary search increase, max probing, 然后还有Smax和Smin的区分, 这几个值增加了算法上的实现难度, 同时也对协议性能的分析模型增加了复杂度.
Cubic协议是对BIC的改进, 在设计上简化了BIC-TCP的窗口调整算法, 使用一个三次函数取代BIC-TCP的增长曲线. Cubic最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值, 从而窗口增长完全独立于网络的时延RTT, 从而解决HSTCP存在严重的RTT不公平性[11], 而Cubic的RTT独立性质使得Cubic能够在多条共享瓶颈链路的TCP连接之间保持良好的RTT公平性.
Brakmo和Peterson提出了一种用RTT测量网络状况的拥塞控制算法, 称之为Vegas-TCP. Vegas通过TCP连接中RTT值的改变情况来控制拥塞窗口. Vegas协议用RTT的改变来判断, 所以能较好地预测网络带宽使用情况, 并且对小缓存的适应性较强, 其公平性和效率都较好. 但Vegas存在公平性问题, 在与基于丢包的拥塞控制机制中会处于劣势.
由于BBR-TCP是一种新的协议, 对于BBR-TCP性能评价工作还比较少, 尤其缺乏全面系统的性能评价. 已有的一些对BBR-TCP协议性能评价的工作, 评价场景简单、性能指标不够全面. 例如, Brakmo通过发送连续的RPC的方式在Netem仿真环境下[12], 对BBR性能在Lan和Wan环境下的吞吐率、时延和公平性进行了评估, 但网络参数设置的粒度太大, 缺乏对实验结果的原因的深入分析. 此外, Google提出一种基于UDP的应用层传输协议QUIC[13], 该协议也采用了和BBR类似的Pacing机制.
3 实验设计本文通过Netem对网络环境进行仿真, Netem是一个网络仿真平台[14], 通过配置延时、丢包率和队列长度等参数仿真局域网、广域网和高速长距离网络等网络环境. 同时通过软件发包方式在网络中添加背景流量, 进一步还原了网络场景的真实性. 实验场景包括四台服务器和一台交换机, 其中一台服务器作为数据接收端(Client), TCP配置为默认配置; Server01和Server02部署BBR协议, Server03部署Cubic协议. 服务器与交换机直连, 交换机对网络环境仿真. 实验的网络拓扑如图1. Server和Client采用高配置规格的服务器主机, 网络接口为千兆网卡, 在实验中服务器负载不高, 服务器性能不会成为影响传输性能的瓶颈.
Server端作为数据发送端通过Iperf以TCP流的方式向Client端发送数据, Iperf是一个网络带宽测量工具[15], 能够测量网络实时带宽. 链路带宽默认为1Gbps, 瓶颈链路为交换机和Client之间的链路, 通过改变仿真器配置网络参数, 仿真多种网络环境, 评估BBR协议在不同网络环境下的适用性.
|
图 1 实验拓扑图 |
BBR性能评价实验主要对协议的传输效率、收敛时间和公平性等指标进行评价, 与默认的TCP拥塞控制协议Cubic进行比较. 传输效率主要指网络传输速率和稳定性; 收敛时间在带宽变化的场景下传输速率收敛到可用带宽的时间; 公平性指不同TCP流对带宽的利用率公平性, 包括协议内公平性和协议间公平性.
4 实验结果及分析 4.1 效率分析本文首先对BBR协议的效率进行评价, 在RTT为10 ms, 链路丢包率为1×10–12的场景下, 部署BBR协议的Server01与Client传输数据, 传输时间持续60 s, 部署Cubic协议的Server02也以同样的方式传输60 s的数据. 传输速率的变化如图2, 在实验结果中BBR协议的吞吐率大部分时间稳定在900 Mbps左右, 实验结果中有几个时刻的传输速率明显小于900 Mbps, 原因是BBR每隔10 s进入一次ProbeRTT状态, 该状态中发送端降低发送速率, 因此会出现传输速率周期性降低的现象.
|
图 2 吞吐率随时间变化图 |
Cubic协议的吞吐率在200 Mbps上下波动, 原因是发送端在不断地进行最优发送窗口的探测, 传输速率在最优值上下波动, 而该值远低于物理带宽, 原因是传输速率受到链路丢包率的影响, Cubic协议中拥塞窗口最大值与丢包率p的平方根成反比[15]. 丢包率会限制拥塞窗口的增长, 丢包率过高会导致拥塞窗口收敛到一个较小的值, 从而限制传输速率. 而在操作系统内核对TCP拥塞窗口上限进行了限制, 拥塞窗口的最大值用tcp_wmem参数来表示. Cubic协议中在传输过程中拥塞窗口最大值Cwndmax同时受到丢包率和tcp_wmem影响, 如公式(5).
Cwndmax限制了传输速率, 所以在实验结果中Cubic协议的传输速率较低. BBR协议传输速率高的原因是不进行降窗处理, 所以传输速率不受丢包率的影响.
| $Win_{\max} \propto \sqrt {1/p} $ | (4) |
| $Cwn{d_{\max}} = {\rm Min}\left( {Wi{n_{\max}},tcp\_wmem} \right)$ | (5) |
| $Rat{e_{\rm {cubic}}} = \frac{1}{{RTT}}\sqrt {\frac{\alpha }{2}\frac{{1 + \beta }}{{1 - \beta }}\frac{1}{p}} $ | (6) |
| $Ratebbr = BottleBW * 0.98 * \min (1,\frac{{tcp\_rmem}}{{BDP}})$ | (7) |
| ${T_{\rm {probe}}} = {\rm {log}}_2BW*RTT$ | (8) |
Cubic在稳定状态下传输速率Ratecubic如式(6), 其中α是AIMD模型中控制拥塞窗口线性增长的参数, β是拥塞窗口乘性减小的参数, 根据实验中的操作系统内核版本1, α的值为1, β的值为0.8, 带入式(7)可得Ratecubic≈212 Mbps, 基本接近上述实验结果. BBR在稳定状态下传输速率如式(7), 其中0.98含义是发送端有98%的时间完全利用带宽, 而2%的时间处于ProbeRTT状态, ProbeRTT状态下传输速率接近于零. 在RTT为10 ms, BandWidth为1 GMbps的场景下, BDP为1025 KB, 而tcp_rmem初始设置为1000 KB, 根据式(7), 理想状态下Ratebbr≈960 Mbps, 上述实验结果低于这个值, 但基本符合实际情况. 上述实验其他条件保持不变, 改变RTT, 分别测量BBR和Cubic传输速率, 实验结果如图3. Cubic的传输效率在随着RTT变大而变低, 原因是Cubic协议的传输速率与RTT成反比, RTT增加传输速率会降低. BBR传输速率在RTT大于20 ms后大幅度下降, 原因是BBR协议的传输速率受到对发送窗口的限制, tcp_rmem的值限制了拥塞窗口的最大值. 根据式(7)在tcp_rmem>BDP的情况下, 传输速率只受瓶颈带宽的影响; 而在tcp_rmem<BDP的情况下, 传输速率受到tcp_rmem的限制. 随着RTT增加, BDP变大, BBR的传输速率受到tcp_rmem影响, 所以当网络的RTT大于20 ms后, 传输速率下降. 为了验证该结论, 把tcp_rmem设置为80 MB, 此时tcp_rmem足够大, 内核不会成为限制传输速率的因素, 在其他条件保持一致的情况下实验结果如图4.
|
图 3 吞吐率随RTT变化图 |
|
图 4 吞吐率对比图 |
随着RTT的变大, BBR协议传输速率稳定在900 Mbps以上, 而Cubic在改变tcp_rmem后传输速率变化不大, 说明内核中TCP窗口的限制不是影响Cubic性能的主要因素, 丢包率是影响Cubic性能的主要因素, 进一步验证了上文的结论.
上述分析中可知BBR协议性能受链路丢包率影响不大, 而Cubic协议性能受丢包率影响较大, 为了评价对丢包率对协议性能的影响, 在不同丢包率的链路上对BBR和Cubic性能进行了测试, 为了评价不同的网络类型下丢包率对BBR和Cubic的影响, 分别设置RTT为10 ms、20 ms和50 ms进行了实验, 实验结果如图5. 从实验结果可以得出BBR对丢包率不敏感, 丢包率变化对传输速率影响不大, 而Cubic对丢包率比较敏感, 传输速率随丢包率的增加变化较大, 丢包率为0.1%的链路传输速率几乎为零.
|
图 5 丢包率对协议性能的影响图 |
在传输效率上, BBR协议性较Cubic等基于丢包的拥塞控制协议有了提升, 主要原因是BBR通过自身的机制避免了链路拥塞产生丢包, BBR对丢包不进行降窗处理, 所以BBR的传输速率较高.
4.2 收敛性分析BBR协议通过STARTUP探测到最大的可用带宽, 通过ProbeBW状态感知带宽的变化. 本文对BBR协议的收敛性进行了评价, 可变带宽通过背景流量的改变实现, 背景流量为带宽抢占性很强的UDP流量. 首先对BBR协议在UDP背景流量下进行了收敛性测试. 首先启动BBR-TCP连接, 5 s过后背景流量出现, 背景流量持续10 s. 实验结果如图6, BBR在2 s内完成了收敛, 原因是BBR采用乘性增长方式探测可用带宽, 因此收敛速度较快.
本文对BBR协议在可变带宽下的收敛性进行了实验分析, 实验结果如图7. 瓶颈链路带宽的变化如图中所示, 实验结果中BBR协议的收敛时间小于1s. 通过对实验结果分析可知, BBR协议保证了协议的快速收敛, 协议的收敛性较好.
4.3 公平性分析协议公平性是指不同TCP流对带宽的占用率的公平性, 是衡量协议性能的重要方面, 本文对BBR协议的公平性进行了评估, 包括基本公平性、大小流公平性、RTT公平性、协议间公平性. 基本公平性指条件完全相同情况下不同TCP流之间的公平性, 在基本公平性评价实验中, 部署了BBR协议的Server01和Server02同时向Client传输60 s数据, 瓶颈带宽为1 Gbps, 实验结果如图8. 两个BBR流的带宽占用率基本相同, 但是总的带宽利用率稳定在750 Mbps左右, 利用率不高, 原因是两个BBR流竞争瓶颈带宽会导致RTT变大, 从而导致发送端降低发送速率.
|
图 6 背景流量下的收敛性 |
|
图 7 可变带宽下的收敛性 |
|
图 8 基本公平性 |
实际网络中TCP流是随机启动的, 本文设计了对随机启动BBR流测试实验. 在实验中一个BBR流先启动, 5 s后启动另一个BBR流, 每个流持续60 s. 实验结果如图9, 两个BBR流的传输速率图像基本对称, 平均传输速率非常接近, 两个先后启动的BBR流公平性较好, 但还是存在总体带宽利用率不高的问题. 大小流公平性是值持续时间长的TCP流和持续时间短的TCP流之间的公平性. 本文设计了评估大小流公平性的实验, 其中大流持续60 s, 小流持续10 s, 实验结果如图10. 实验结果表明小流的传输速率稳定在400 Mbps, 小流的性能没有受到太大影响.
|
图 9 动态基本公平性 |
|
图 10 大小流公平性 |
RTT公平性指不同RTT的TCP流之间的公平性, BBR协议在设计上有类似慢启动的STARTUP状态, 带宽的探测时间Tprobe与RTT成正比, 如式(8). BBR流的带宽探测速度与RTT成反比, RTT小的TCP流探测速度快, 带宽抢占性强, 所以RTT小的BBR流会占据较多带宽. 本文对RTT公平性进行了评估实验, 实验中同时启动Server01和Server02与Client建立TCP连接, 两个TCP流记为Flow 1和Flow 2. Flow 1的RTT为10 ms, Flow 2的RTT为20 ms, Flow 1传输速率稳定在600 Mbps, Flow 2传输速率稳定在300 Mbps, 符合上述带宽探测速率与RTT成反比的结论. 为了进一步验证BBR的公平性, 把Flow 1的RTT固定为10 ms, 改变Flow 2的RTT, 其他条件保持不变然后进行实验, 实验结果如图11, 随着Flow 2的RTT增加, Flow 1和Flow 2的性能差距在变大, 进一步验证了对BBR协议中RTT公平性分析.
|
图 11 RTT公平性扩展测试 |
协议间公平性是指不同协议间的公平性, 本文中主要是对BBR与Cubic之间的公平性进行评价. 评价实验分别在RTT为50 ms的环境下, 部署BBR的Server01和部署Cubic协议的Server03同时与Client建立TCP连接, 两个流分别为Flow 1和Flow 2, 测试两个流的传输速率, 实验结果如图12. 在RTT为50 ms的场景下BBR流占据了大部分带宽. 随着RTT的增加, Cubic占用的带宽会逐渐增加, 原因是RTT增加BDP变大, 内核开始限制BBR的传输速率, Cubic的传输速率开始增加, 但Cubic在与BBR的竞争中处于劣势.
通过对BBR公平性评估, 可以看出BBR协议在RTT公平性和协议间公平性上还存在改进空间.
5 BBR-TCP协议改进思路BBR协议作为一种基于测试的拥塞控制机制在效率方面有了较大的提升, 但在收敛时间和公平性方面还有进一步优化的空间. 基于本文对BBR的评估, 我们提出了对BBR协议如下的改进思路: (1) 协议在收敛速度上的优化, 由于ProbeBW状态中pacing_ gain=1的phase持续6个RTT, 这将导致BBR在带宽探测阶段收敛速度偏慢并且可能出现新增加的可用带宽被其他TCP流占用的情况, 在下一把的工作中可以通过减少pacing_gain为1的phase数量或者增加pacing_gain的值对收敛速度进行优化; (2) TCP窗口限制优化, 在本文中提到了TCP窗口限制了BBR的性能, 由于BBR对传输效率的大幅度提升, TCP窗口上限成为了现在BBR协议的因素, 可以考虑适当扩大TCP窗口的上限但同时也要兼顾整个网络的负载量和公平性, 因此下一步可以通过扩大TCP窗口的方式对BBR协议效率进行优化; (3) BBR协议的RTT公平性和协议间公平性优化, BBR中带宽的探测过程与RTT成反比, 下一步可以通过借鉴Cubic中带宽探测与RTT无关的优点对RTT公平性进行优化; BBR协议在与Cubic的竞争中处于绝对优势, 原因是Cubic在丢包后降低发送速率而BBR不进行速率调整, 下一步可以考虑通过降低BBR带宽占用率的方式对公平性进行改进.
|
图 12 公平性实时测试 |
6 总结
本文基于仿真实验对BBR-TCP协议的性能进行了比较全面的分析和评估, 包括协议传输效率评价、收敛性评价和公平性评价, 分析了BBR-TCP协议较其他传输协议传输效率提升的关键原因, 对其传输速率在不同场景下的性能进行了实验评估. 在协议公平性方面, 分析了BBR的协议内公平性和协议间公平性存在的问题, 然后通过实验的方式进行了评估. BBR协议内公平性较好, 但与其他拥塞控制协议如Cubic协议对比时会引发协议间公平性问题. 此外, BBR协议也存在RTT公平性较差的问题. 在实验评估的基础上, 本文最后对BBR-TCP协议进一步改进提出了方向.
| [1] |
Cardwell N, Cheng YC. BBR: Congestion-based congestion control. ACM Queue, 2016, 14(5): 20-53. |
| [2] |
Jain S, Kumar A. B4: experience with a globally-deployed software defined WAN. Proceedings of the 2013 ACM SIGCOMM Workshop on Future Human–centric Multimedia Networking. Hong Kong, China. 2013. 3–14.
|
| [3] |
Cheng YC, Cardwell N. RACK: A time-based fast loss detection algorithm for TCP. Proceedings of the IETF 98. Chicago, IL, USA. 2017.
|
| [4] |
任勇毛, 唐海娜, 李俊, 等. 高速长距离网络传输协议. 软件学报, 2010, 21(7): 1576-1588. |
| [5] |
王国栋, 任勇毛, 李俊. TCP改进协议在高速长距离网络中的性能研究. 通信学报, 2014, 35(4): 81-90. DOI:10.3969/j.issn.1000-436x.2014.04.010 |
| [6] |
Jacobson V. Congestion avoidance and control. Proceedings of the SIGCOMM’88 Symposium. 1988. 314–32.
|
| [7] |
Xu LS, Harfoush K, Rhee I. Binary increase congestion control for fast long distance networks. Proceedings of the 23rd Annual Joint Conference on Computer and Communications Societies. Hong Kong, China. 2004. [doi: 10.1109/INFCOM.2004.1354672]
|
| [8] |
Xu LS, Rhee I. CUBIC: A new TCP-friendly high-speed TCP variant. ACM SIGOPS Operating System Review, 2005, 42(5): 64-74. DOI:10.1145/1400097.1400105 |
| [9] |
Brakmo L, O’Malley S. TCP vegas: New techniques for congestion detection and avoidance. Conference on Communications Architectures, 1994, 24(4): 24-35. |
| [10] |
Cheng J, Wei D, Low SH. FAST TCP: From theory to experiments. IEEE Network the Magazine of Global Internetworking, 2005, 19(1): 4-11. DOI:10.1109/MNET.2005.1383434 |
| [11] |
Floyd S. High Speed TCP for Large Congestion Windows. RFC 3649 , December 2003.
|
| [12] |
Brakmo L. BBR Evaluation, 2016. https://drive.google. com/file/d/0B4YZ_0yTgbJEa21CbUVLWFdrX2c/view.
|
| [13] |
Wilk A, Iyengar J. QUIC: A UDP-based secure and reliable transport for HTTP/2. IETF93: Prague, July 16, 2016.
|
| [14] |
Netem. https://wiki.linuxfoundation.org/networking/netem.
|
| [15] |
Iperf. https://iperf.fr/.
|