test quic bbr on ns3

 The network congestion control mechanism is the most important component in computer network. Ever since the Internet has experienced collapse[1], to work out solution to avoid network into congestion becomes quite popular in network research area.
 The main purpose of congestion control algorithm is to probe the maximum available bandwidth while avoiding the network into congestion. And one important property of congestion control is fairness, which guarantees network uses can converge to similar throughout when they share same routing. And the additive increase and multiplicative decrease algorithm can converge to the fairness bandwidth as discussed in [2], which is further developed in [3] and become a classic rule for rate control applied in TCP.
  One of drawback of AIMD law that takes packet loss as congestion signal is that it will occupy much buffer resource since the sender will keep increase its congestion window until the buffer overflow. Due to the excessive buffer in current router equipment, the loss based algorithms tend to fill queue buffer full and cause high latency, which is notorious for buffer bloat[4].
  As early as 1987[2], researchers has realized than an ideal congestion control can achieve the maximum available bandwidth while keep lowest delay at the same time. Of course, the loss based AIMD congestion control law does not reach this optimal control point.

  And BBR[5] was proposed with the goal to achieve such optimal control point. It was first tested on linux TCP stack.
  Recently, Google has developed quic protocol with the purpose to accelerate web. Since TCP is quite an old protocol which can be trace back to a paper published in 1974 and the change and evolution in linux kernel is quite slowly. And the BBR congestion control is implemented in quic also.
 I test the performance of BBR algorithm on ns3. Since the codebase in quic is quite large, I copy some code in quic and make it running on ns3.
 There are 3 flows running on a point to point link (3Mbps, one way delay 100ms, max queue length 300ms).


 And the throughput figure clearly show the fairness property among BBR flows. A bbr flow can samples the minimal RTT again only after entering into ProbeRTT state as shown in delay figure. The goal to achieve maximum available bandwidth and maintain lowest latency at the same time is a direction to be worth further effort.
 In a recent test, I test parameter drain_to_target_(true) in bbr_sender.cc with the same link configuration as previous, and a lower one way transmission delay can be got.


 From this simulation results, BBR algorithm has excellent performance in terms of bandwidth fairness, transmission delay and link resource utility. To design another algorithm that can outperforms BBR is quite hard.
  Performance comparison when BBR and cubic share same links（the congestion control algorithm in flow 3 is cubic）:

one way transmission delay:

[1] Gateway Congestion Control Survey, rfc1254
[2] Analysis of the increase and decrease algorithms for congestion avoidance in computer networks
[3] Congestion Avoidance and Control
[4] Bufferbloat: Dark buffers in the internet
[5] BBR: Congestion-Based Congestion Control