Bottleneck Bandwidth and RTT

Re:Bottleneck Bandwidth and RTT by AdamJacobMuller on Saturday September 17, 2016 @01:34AM (#12519293)

Any idea of how to define "long lived" ?

Excluding the HTTP/2 situations, obviously if you're fetching a single small resource (image or something) that takes <1s then that's short, but, where's the line there? Is something >1m long?

[ Parent | on HN ]

Re:Bottleneck Bandwidth and RTT by Animats on Saturday September 17, 2016 @02:36AM (#12519434)

10 seconds in this code.

    static u32 bbr_min_rtt_win_sec = 10; /* min RTT filter window (in sec) */

The code also uses a moving average over 10 round trips. So that's what the filter needs to get a stable estimate. A point in the paper [1] is that this method is said to work well for maintained TCP connections with idle periods. That means HTTP/2 in practice.

It would be interesting to see test data on this for large numbers of real connections. How much do bandwidth and delay vary in practice across ISP links, cable headends, and cellular links?

[1] http://caia.swin.edu.au/cv/dahayes/content/networking2011-cd...

[ Parent | on HN ]

Re:Bottleneck Bandwidth and RTT by apenwarr on Saturday September 17, 2016 @05:05PM (#12522442)

The averaging period says more about how fast they expect min_rtt to change than how long it takes to calculate it. If the rtt is fairly stable, that measurement could be accurate much sooner than 10s.

Super short lived sessions can really only go faster with tricks like increasing the initcwnd. Anything longer than that, I'd expect bbr to work well.

[ Parent | on HN ]

Re:Bottleneck Bandwidth and RTT by colechristensen on Saturday September 17, 2016 @02:36AM (#12519435)

HTTP <2 doesn't bring up and tear down TCP connections for every asset. keep-alive is the default for 1.1 and supported in 1.0

[ Parent | on HN ]