本报告分为两部分，一部分是只有BBR的在工作时，它的网络性能。一种是BBR与Cubic竞争时，它的网络性能。
本报告为初步报告，主要论述已发表文章[Experimental Evaluation of BBR Congestion Control, ICNP2017]对BBR的测评和分析。
由于下面我们要大量的在large buffer与small buffer下进行对比测试，说明一下：
buffer指的是网络转发设备（路由器、交换机）的队列大小，large buffer指代大小为8BDP的队列, small buffer指代大小为0.8BDP（不足1BDP）的队列。
1 仅有BBR flow的网络——RTT相同
虽然网络中不可能变为全为BBR的环境，但是探讨BBR内部流相互竞争仍然很有意义。
因为从这些不同的实验变量中，我们可以看到影响BBR表现的关键参数。可以看到，buffer的大小与RTT对于BBR flow的性能表现有着非常强的影响。
首先观察多BBR竞争时的RTT表现，可以看到：在全部都是BBR的flows的情况下， RTT_min能够正确的测量出来。
不过在真正工作起来后，TCP的RTT_use通常是2倍的RTT_min。这是因为在large buffer的场景下，BBR倾向于填满其inflight cap （= 2BDP）。
这个参数是被bbr_cwnd_gain来设置，其限制发送的窗口大小，从而限制inflight packets。
下面试BBR的goodput的波动，goodput包含了retransmissions的流量。当然，实际应用中我们更关注througput，并不包含retransmission traffic。
这里展示了6条流，分别是从: 0 s, 23 s, 31 s, 38 s, 42 s, 47 s开始发送。总的来看，BBR的fairness是很随机的，而且到达稳定后，不同流的差别比较大。
值得注意的是，多个BBR的flow在实际运行中,并不是完全地按照其物理带宽来发送，尤其是在buffer比较小的时候。其发送的总带宽是大于真正的物理带宽的。
当然，我们也可以理解这种策略：假如是小于实际物理带宽，那么与其他策略竞争时，其可用带宽就会被其他流抢占进而导致其throughput越来越小。
不过考虑到BBR没有fast recovery的阶段，不会减小窗口，这点就比较恐怖了：大家都不谦让，导致链路overload和更高的丢包率。上个图感受一下：
3个接口发送6个flow(two flow via one if.)，看total throughput，在small buffer的情况下基本达到了1.1的负载。
同样条件下的Cubic，简直业界良心啊。
2 RTT不同的BBR flows
从实验中可以看出，在buffer大的时候，不同RTT间明显是不公平的，更高RTT的throughput越高。
而在buffer小的时候，不同RTT的flows是公平的竞争。
1、2结果的分析小节
那么为什么buffer对BBR的影响这么大呢？为啥在多个BBR共同工作时，不能按照其真正的带宽和RTT来工作呢？
文章给的解释：由于BBR是按照时序来设置其发送速率的，在多个流时序不同步的情况下，其带宽容易被高估（例如A在1.25x探测phase时，B在0.75x的排空phase，而且带宽总是取窗口最大值）。
在带宽高估的情况下，BBR操作的时刻就不是在最正确、最合理的点了。 这里的操作指发送窗口限制发包数的时间点。
理想的、单流的BBR操作点：
但是实际在带宽被高估的情况下：
解释一下上图，在Buffer Size大的情况下，BBR基于Inflight Cap的操作先于Cubic基于丢包的操作。
在Buffer Size小的情况下，BBR的操作略慢于Cubic。所以在small buffer的情况下，BBR会有明显的overload。
同样，在large buffer的情况下，不同RTT导致其BDP不同，因此大RTT的Inflight Cap会多于小RTT的，从而占据更多带宽。
3 BBR与Cubic的对比
相对来说，在buffer比较小的时候，BBR更加有优势（从throughput的对比可以初步了解一下）。
而且BBR有一个很明显的优势，它的RTT不管在large buffer和small buffer的情况下，都比较小。而Cubic只有在small buffer的情况下，RTT才会变的比较接近BBR的水平。
先上一组TCP的RTT对比图：
当然，这部分是分别测的全BBR的环境和全Cubic的环境，并没有测试两者共同工作时的RTT。
按照常理推断，由于两者处在同样的网络环境下（队列相同，链路相同），所以其RTT应该是相同的。
虽然这个猜测很让人沮丧，但是也有可能出现亮点的地方，比如在传输大小为几十K的小页面时，RTT的表现。
在试验床测评BBR时，会补充这方面的实验。
那看一下两者在全为相同算法的环境下的丢包表现：
BBR可以说是非常“社会”了，不管是在large buffer还是small buffer情况下，它的重传率（丢包率）都非常高。
依靠其产生的高丢包率，基本可以碾压其他依靠丢包来调控窗口的算法了。
下面看一下Cubic与BBR两者竞争时的表现，结果不出意外：
BBR在large buffer的时候就占优，small buffer的时候尤其“狠”。
与Cubic对比的小结
文章总结了4种场景下BBR的表现，并与Cubic做了对比。从结果来看，BBR的表现特性很明显，带宽占用率高，无视丢包，竞争有优势。
但是也要注意到，实验中几点的不足之处：
a 和Cubic做实验时，每次都是先开BBR流，后开Cubic流。如果是先开Cubic，后开BBR呢？
b 没有做多个BBR流与单个Cubic流，多个Cubic流与单个BBR流的对比。
c 在延迟更小，带宽更高的情况下呢？延迟在10ms以内的情况下，谁的表现更好呢？
受到的启发
综合以上的分析，我们可以发现单个BBR工作时，很有效、很合理、很正确。多个BBR一起工作时，带宽占多、RTT也会变长、丢包超级多。
BBR为啥能在竞争时表现强势？就是它会倾向于多占带宽，同时丢包不减窗口。
我们的对策是什么：boost实际上在丢包发生时采取了很强的策略：随机丢包不减窗口，拥塞丢包减窗口到带宽大小。从直觉出发，也不比BBR差。
那么在丢包时不减窗口真的好嘛？大量的重传报文真的没有问题，会带来哪些负面影响？Boost与BBR竞争起来会吃亏吗？这些都是可以探究的工作。
针对前两个问题，进一步的工作是深入剖析Linux的TCP重传机制。在之前的wiki已经理清其函数调用关系，那么每次调用的开销是什么？是否真正能执行？意外情况会有哪些？这些需要进一步的补充。
针对第三个问题，在试验床做boost与BBR的测评，可以给出初步的答案。