Improving application limited tests for BBR

[alexrabi]

As discussed in #1758, the current "application limited" test with BBR is insufficient as it sometimes mistakes busty traffic for path capacity saturation. This can lead to a very poor throughput. Testing the congestion window (bytes_in_flight < cwnd) is not enough as BBR uses the pacing rate as the main control variable, with the congestion window as a "backup". In normal operation, pacing dominates and the bytes in flight remain below the congestion window. Testing on the pacing rate is also imprecise, because pacing is implemented with a leaky bucket. There will be brief period in which the leaky bucket will be full, letting packets go without pacing, only limiting the last packet out of a train -- but that can happen whether the application is "limiting" or not.

We need to come up with a solution to more accurately detect whether we are application limited or not.

[alexrabi]

I'm wondering if it is worth taking a few notes from the bufferbloat community in regards to this. The issue is being able to distinguish "good queues", i.e. queues that "absorb" bursts, but that eventually drain, from "bad queues", i.e. persistent, standing queues. If we are application limited, then the leaky bucket should act more like a good queue, rather than a bad queue.

The CoDel AQM algorithm uses the sojourn times of each packet to track the (local) minimum queue delay that packets experience. As long as the minimum queue delay is below some target threshold for some time interval, the queue is considered a good queue. Perhaps we can do something similar here to help identify application limited scenarios?