【计网实验——prj7】数据包队列管理实验
实验要求
1. 重现BufferBloat问题
- h1(发送方)在对h2进行iperf的同时,测量h1的拥塞窗口值(cwnd)、r1-eth1的队列长度(qlen)、h1与h2间的往返延迟(rtt);
- 变化r1-eth1的队列大小,考察其对iperf吞吐率和上述三个指标的影响;
2. 解决BufferBloat问题
- 根据附件材料中提供的脚本,重现如下实验结果:
数据处理及结果
1. 重现BufferBloat问题
用jupyter notebook编写的数据处理脚本位于文件plot_reproduce_result.ipynb
,取最大队列长度分别为10,50,100,运行reproduce_bufferbloat.py
文件,用该脚本对实验结果进行作图得到的结果如下:
CWND
上图为拥塞窗口大小随时间变化的曲线。测试刚开始时,队列大小为 100 的拥塞窗口迅速增长达到 600 的峰值,队列大小为 50 的拥塞窗口迅速增长达到 300 的峰值。可见该实验环境下,拥塞窗⼝峰值大小为队列大小的六倍。
接着拥塞窗口迅速回落到队列大小⼀致的水平,接着再次增长。拥塞窗口随收包增长,随丢包下降。另外可以看到大队列后续的波动较小队列不明显。
QLEN
上图为即时队列长度随时间变化的曲线。测试刚开始时队列快速上升达到峰值,当队列满时,直接丢弃新接收的包,由于发送速率骤降,使得队列长度度降低至最大队列长度的40%左右。随后⼀直这样循环下去。
RTT
上图为RTT随时间变化的曲线。测试刚开始时,由于接收队列的快速增长,网络延时急剧增加,随后也随着队列缩短而减少。之后的时间内,延时随着队列长度的变化而变化,波动明显。另外可以看到大队列后续的波动频率比小队列低,这与队列长度直接相关。
iperf吞吐率
以上是iperf带宽随时间变化的曲线图。可以看出,三种队列长度的带宽均值基本集中在10Mb/s左右,而队列长度越长,带宽为0的时间也越长,同时其带宽峰值也越高。
总结分析
接收队列的长度受到拥塞窗口的影响,因其长度取决于发送方的发包速率,而发包速率又同时受到滑动窗口和拥塞窗口的制约。因此,当拥塞窗口较大时,可以实现更高的发送速率,接收队列的增长也会随之加快。但是从实验结果中可以看到随着拥塞窗口增大,接收队列增速反而减缓,这可能是因为时延增大引起的。
2. 解决BufferBloat问题
上图中体现了RED,tail drop,CoDel三种算法来解决BufferBloat问题得到的RTT随时间变化的曲线。
可以看出,tail drop的队列延时远高于RED和CoDel。其中CoDel的性能表现最佳。
此外,可以发现tail drop曲线⼀直出现“尖端”情况,和ppt中稳定的⼀段峰值不同,这是因为Mininet环境下仿真环境的差异导致的。在Mininet中,maxq参数实际上是⼀个模拟延迟和丢包的批处理大小,与真实的队列大小有区别,只是近似仿真。因此结果存在一定差异。
调研思考题
BBR
传统的TCP拥塞算法是对带宽实际情况无感知的,它们都是基于一个“数学上收敛的模型”,即AIMD模型运作的,在AI过程中,基本上都是盲目的探测,而MD过程又是过激地降速,这个过程往往会造成很多可用带宽的消耗或者说浪费,一方面丢包作为拥塞信号,重传数据包会消耗部分本来可以传输新数据的带宽,另一方面,在结束了MD过程后,一个新的缓慢AI的过程只有在丢包前夕的那一刻才能有效利用所有带宽,其余时刻都是谨慎又盲目的上探过程,剩余的空闲带宽便无法被利用。这便是传统拥塞算法的症结之根本。
由于这个症结的存在,排队现象是不可避免的!实际上,传统的TCP拥塞算法误用了节点的队列缓存。队列的存在会让传统的TCP拥塞算法误认为是剩余可用带宽,它们并不能意识到队列的存在,所以即便它们都是收敛的流量,CoDel算法也无法“匡正”它们的“错觉”。因此,在传统TCP拥塞算法上部署CoDel算法,依然会出现锯齿状的全局同步现象,事实上,这种现象是可以消除的,CoDel的本意也是在于消除这种现象。
BBR根治了传统TCP拥塞算法的症结。
BBR采集了时间窗口(用于老化数据样本)的历史中最大带宽,以及最小的RTT,并且在另一个时间窗口内“坚持使用该最小RTT”,这就意味着在一个时间窗口内,BBR估算的BDP是不变的,BBR由于采集到了真实的带宽和RTT数据并基于此数据调节发送速率,这便不再需要盲目探测的过程了。BBR采集到的最小RTT便是不排队的RTT,因此在正常情况下,队列缓存不会被使用,几乎不会触发丢包。这使得BBR算法在处理BufferBloat问题上取得了比传统拥塞控制算法更好的效果。
HPCC
HPCC是对现有的拥塞控制的⼀种替代方案。它可让网络中的报文稳定的、以微秒级的延迟传输。当前主流的拥塞控制算法主要依赖于端的信息(如丢包信息,RTT)做拥塞控制,而HPCC则运用了网络设备提供的细粒度负载信息而设计了全新的拥塞控制算法来其解决Bufferbloat问题。
相比于传统的在端上调节流量,以维持网络最佳平衡状态的拥塞控制方法,HPCC的核心理念是利用精确链路负载信息直接计算合适的发送速率,而不是像现有的 TCP 和RDMA 拥塞控制算法那样,通过慢启动等方法,迭代探索合适的速率;HPCC 速率更新由数据包的ACK 驱动,而不是像 DCQCN 那样靠定时器驱动。