Hacker News Reader

Comment by Animats | Hacker News Reader

This is useful mostly for long-lived connections. As Google moves away from the many-short-connections HTTP model to the persistent connections of HTTP/2, connections live long enough that both bandwidth and delay can be discovered.

This is much better than trying to estimate bandwidth from packet loss.

View on HN

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?

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...

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.

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

> This is much better than trying to estimate bandwidth from packet loss.

This definitely seems like an improvement, however is it possible that this changed could result in one or more additional attack vectors?

In addition, what about the additional resources needed to pull this off; how many fewer persistent connections could be maintained by a single server with the same specs?

There shouldn't be much overhead per stream. The estimators are just a few integers each, which is tiny compared to the TCP socket buffer itself. There could be added cpu overhead from implementing pacing if it isn't done carefully, but my understanding is the Linux pacing is done "right" so that it actually has very little or even negative overhead compared to traditional burst transmissions. (Also, it's generally safe to assume that Google cares more about server scalability than almost anyone else, so they wouldn't use this if it weren't pretty good on that front.)

For those that don't know, someone revealed recently that Animats is John Nagle, who designed https://en.wikipedia.org/wiki/Nagle%27s_algorithm ... so this perhaps one of the most informed possible comments.

It's on his profile comment here on HN. :)

John Nagle revealed recently that Animats is John Nagle.

Reply on news.ycombinator.com