SoylentNews is people
SoylentNews
Google has debuted a new algorithm for traffic congestion control, TCP BBR:
We're excited to announce that Google Cloud Platform (GCP) now features a cutting-edge new congestion control algorithm, TCP BBR, which achieves higher bandwidths and lower latencies for internet traffic. This is the same BBR that powers TCP traffic from google.com and that improved YouTube network throughput by 4 percent on average globally — and by more than 14 percent in some countries.
[...] BBR ("Bottleneck Bandwidth and Round-trip propagation time") is a new congestion control algorithm developed at Google. Congestion control algorithms — running inside every computer, phone or tablet connected to a network — that decide how fast to send data.
How does a congestion control algorithm make this decision? The internet has largely used loss-based congestion control since the late 1980s, relying only on indications of lost packets as the signal to slow down. This worked well for many years, because internet switches' and routers' small buffers were well-matched to the low bandwidth of internet links. As a result, buffers tended to fill up and drop excess packets right at the moment when senders had really begun sending data too fast.
[...] We need an algorithm that responds to actual congestion, rather than packet loss. BBR tackles this with a ground-up rewrite of congestion control. We started from scratch, using a completely new paradigm: to decide how fast to send data over the network, BBR considers how fast the network is delivering data. For a given network connection, it uses recent measurements of the network's delivery rate and round-trip time to build an explicit model that includes both the maximum recent bandwidth available to that connection, and its minimum recent round-trip delay. BBR then uses this model to control both how fast it sends data and the maximum amount of data it's willing to allow in the network at any time.
IETF draft and GitHub.
(Score: 3, Disagree) by BananaPhone on Tuesday July 25 2017, @08:34PM (14 children)
Is there an RFC #?
Didn't think so.
(Score: 4, Informative) by Anonymous Coward on Tuesday July 25 2017, @08:44PM (13 children)
There isn't an RFC yet because it's still a draft. Jeez.
https://tools.ietf.org/html/draft-cardwell-iccrg-bbr-congestion-control-00 [ietf.org]
See? Fully documented and everything.
(Score: 2) by frojack on Tuesday July 25 2017, @11:11PM (6 children)
What do you thing RFC stands for? It was meant for drafts.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Tuesday July 25 2017, @11:32PM (3 children)
Internet Draft is meant for drafts. RFC is meant for standards. "Request For Comments" is an anachronistic name from the days when ARPANET was the exclusive playground of rich old white men.
(Score: 0) by Anonymous Coward on Tuesday July 25 2017, @11:41PM (2 children)
Old? Rich? Steve Cocker was a 24-year-old grad student when he wrote RFC 1 [ietf.org].
(Score: 0, Informative) by Anonymous Coward on Wednesday July 26 2017, @12:17AM (1 child)
|
_______________________|@\
|@ \
*Crocker |@ C
|@ /
~~~~~__________________|@/
~~~~
~~
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @12:34AM
Would you believe Steve Crocker [wikipedia.org] and Joe Cocker [wikipedia.org] were born in the same year.
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @03:53AM (1 child)
No. Drafts are drafts. It only becomes an RFC if there's enough buy-in from others: https://www.rfc-editor.org/pubprocess/ [rfc-editor.org]
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @05:09AM
IETF with its "requests" for "comments" has become as democratically egalitarian as a totalitarian people's republic.
(Score: 2) by driverless on Wednesday July 26 2017, @02:27AM (5 children)
Yeah, but it's just another idea dreamed up by the Google children to make things easier for them. You can always improve performance for you if you don't care about the impact on everyone else, which is all that Google cares about, as long as they can stream their content and ads and whatnot at you with maximum efficiency their job is done. Any number of "TCP tweak" programs for Windows that have the same effect have been around for years to do this.
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @04:13AM (4 children)
You're wrong, of course. This is not some tweak to change the parameters of an existing algorithm. This is a new algorithm. They're completely right that networks are different now: wireless is ubiquitous, bufferbloat is more common than packet loss, and "long fat networks" are everywhere. The time has come for TCP to adapt automatically to variations in latency. TCP can't assume constant latency anymore and use a simplistic congestion model where packet loss indicates congestion. Wired networks still work that way, but wireless networks don't have constant latency and need a more complex algorithm to determine how much latency is within acceptable limits and how much delay indicates congestion.
Even so this new algorithm only improves throughput by at most 14% which says to me that it wasn't tested on enough truly crappy networks. I've seen a much simpler congestion control algorithm, based on the same principles as this one, improve throughput by 100% when latency is sufficiently variable that the minimum round-trip delay is 50% of the average round-trip delay.
(Score: 2) by driverless on Wednesday July 26 2017, @04:35AM (3 children)
No, we're actually talking about the same thing, you've just misunderstood the point I was making, which is that anyone... well OK, many people can come up with a mechanism for improving TCP performance if they don't care how it affects others and if they only apply it to their particular situation, which is something that Google excel at. Windows "TCP tweakers" are probably the best-known example of this approach.
Or, if they're following their usual pattern, anything outside their particular use case. There are endless proposals for new, better, shinier, faster fiddle-with-TCP algorithms, or tweaks to existing algorithms. This is just one of an endless succession of such things. Few of them have ever taken off (large windows, or window tweaks in general, and SACKs, are two examples that did), for one or both reasons that they don't generalise, so they make things better for the proposer and worse for many other users, or that the change to existing infrastructure is so great that there's no obvious way to deploy them. From a quick read of the draft, this looks like it has not just one but both properties.
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @05:04AM (2 children)
I like to set the retransmission timeout so low that the slighted delay causes congestive collapse.
(Score: 2) by driverless on Wednesday July 26 2017, @05:39AM (1 child)
Or turn on super jumbo frames on ethernet, but only for yourself. All the 1500-MTU wimps can just sit back and watch as my freight train frames [dailymail.co.uk] lumber past.
(Score: 0) by Anonymous Coward on Wednesday July 26 2017, @04:36PM
I envy the lucky wimps with their 1500-MTU. I'm extra wimpy cuz I got only 1280-MTU on IPv6.