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: 4, Insightful) by MrGuy on Tuesday July 25 2017, @10:09PM (2 children)
I wonder whether this technology would have any impact on the ongoing debate around network neutrality.
As I read this, the sender of data would effectively ask the router "how fast can I send this?" and will throttle its transmission speed in response to that. This seems to make it really easy to throttle traffic - just tell IP's you don't like (or traffic types you don't like) that they have to slow way down.
Adding a "traffic cop" algorithm in the middle that is allowed to tell everyone how fast they can send data, before they send it, seems like it would make it a lot easier to "weight" the traffic you carry in favor of/against certain parties of your choice. That seems like a lot less work than current traffic shaping approaches, which generally rely on inspecting/fingerprinting packets as they go by and pulling some out of line.
I'm not saying this algorithm by nature breaks net neutrality - it just seems like it would make it a lot easier to implement so-called "fast lanes."
(Score: 3, Interesting) by Anonymous Coward on Tuesday July 25 2017, @10:51PM
None at all. There are many TCP congestion control algorithms [wikipedia.org]. TCP BBR just happens to compensate for bufferbloat slightly better than others.
You ascribe too much intelligence to the sender when you say it "asks" the receiver how fast to send. All it's really doing is measuring the available bandwidth and latency. To throttle traffic, all a router needs to do is raise the latency. It doesn't matter which specific congestion control algorithm is used since all of them would be affected.
Oh, impact on the debate. Sure there will be lots of scaremongering like you're doing.
(Score: 3, Interesting) by cafebabe on Wednesday July 26 2017, @09:57AM
Attempting to minimize round trip time is good. Measuring round trip time while blatantly disregarding RFC3390 is bad. As I noted three weeks ago [soylentnews.org]:-
This latest development falls into the same category as Google AMP: a good concept corrupted by commercial concerns [soylentnews.org].
1702845791×2