| 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?).
struct tcp_bbr_info. User-space applications can use this information as hints for adapting their use of a given connection, e.g. by selecting appropriate audio or video encodings. 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.