How do we know the test bed is working as expected?

Recreating Results


Cyclic Performance of BBR and Cubic

In the paper “Cycle and Divergence of Performance on TCP BBR” by Miyazawa and Sasaki, the authors show that when BBR and TCP are competing on the same bottleneck, their ‘share’ of the bandwidth will not be consistent. Rather, the dominant flows will cycle between cubic and BBR, where first BBR will dominate the flow for 10 seconds as cubic backs off, and then cubic will dominate the flow as is steals bandwidth during BBR’s rtt probe phase. We aim to confirm this in our panaderia environment. This cyclic behavior shown in this paper is depicted here:

here

Read More…

Single flow

A single bbr flow should display a very regular cycle. Every 8 rtt’s (round trip times) bbr should probe the bandwidth by increasing its sending rate, drain any queue that is built, and then return to a steady state. Every 10 seconds, the flow should completely drain the queue by throttling its speed, and then return to a normal sending rate.

Read More…

Multiple Flow Convergence

Given multiple bbr flows competing at the same bottleneck, all of the flows should sync. BBR has a mechanism to drain the queue and check for a lowest round trip time after some amount of seconds since the last time the round trip time changed. With multiple flows, they all should see the change in round trip time at the same time, so they should begin to drain the queue at the same time.

The goodput (throughput seen by the receiver) should looks something like this result published by the BBR team in this paper:

Syncing of Multiple Flows


And our results, which look roughly similar:

Our Results

See below for the configuration details and analysis