| V +---> STARTUP ----+ | | | | V | | DRAIN ----+ | | | | V | +---> PROBE_BW ----+ | ^ | | | | | | | +----+ | | | +---- PROBE_RTT <--+A BBR flow starts in STARTUP, and ramps up its sending rate quickly. When it estimates the pipe is full, it enters DRAIN to drain the queue. In steady state a BBR flow only uses PROBE_BW and PROBE_RTT. A long-lived BBR flow spends the vast majority of its time remaining (repeatedly) in PROBE_BW, fully probing and utilizing the pipe's bandwidth in a fair manner, with a small, bounded queue. If a flow has been continuously sending for the entire min_rtt window, and hasn't seen an RTT sample that matches or decreases its min_rtt estimate for 10 seconds, then it briefly enters PROBE_RTT to cut inflight to a minimum value to re-probe the path's two-way propagation delay (min_rtt). When exiting PROBE_RTT, if we estimated that we reached the full bw of the pipe then we enter PROBE_BW; otherwise we enter STARTUP to try to fill the pipe. merged into the net-next branch, and should therefore be included in an upcoming Linux kernel release (4.9?). Ph.D. thesis. It shares the basic goals of (Google's) BBR TCP, namely to detect bottleneck rate and to avoid bufferbloat. But it uses a delay-based measurement approach rather than direct measurement of the amount of ACKed data per time, and doesn't seem to make use of pacing.