Google Fixes A Longstanding, Important TCP Bug In The Linux Kernel

[yoshi314]

If these issues are longstanding bugs in the kernel then I don't think Linux is serious OS. It's probably better that it's at 1%.

the only difference from proprietary competitors is that those are being closed in the open. if a proprietary vendor finds an embarassing bug, they fix it and sweep it under the rug. unless they can make a marketing spin on it.

[milkylainen]

Reading the title you would indeed think this was high profile. A longstanding TCP bug...
Yeah.. In the cubic congestion control module.
That's why congestion control is modular to begin with.
Because congestion control is a behavior ridden booby trap field.

[Delgarde]

BTW, why are you people feeding the troll?

Boredom, I assume. Arguing with trolls isn't very productive, but it can be a fun way to waste some downtime...

[Remdul]

Hmm. This bug reminds me of another (inherent?) flaw in the typical Berkeley socket implementation. When you close the socket, all pending outgoing data is immediately destroyed, and nothing is send (the expected behavior appears undocumented). This requires the client application to wait for the network stack (networking hardware mostly?) to finish up, wasting lots of CPU cycles. My guess is that Google & co have custom socket implementations or hardware that have this fixed (or worked around), but for your typical client application (read: everything not in a datacenter), you have to wait until it burps. An enormous amount of energy must be wasted worldwide on those pointless CPU cycles.

What I learned is that the technology that powers the internet is extremely fragile, outdated, and quite frankly, in very very poor state. OpenSSL/Heartbleed was just the tip of the iceberg. IMO, it's a miracle that things just work at all.

[thunderbird32]

Zork> Pick up sword.
Zork> Kill troll with sword
The troll is disarmed by a subtle feint past his guard.
The unarmed troll cannot defend himself: He dies.
Almost as soon as the troll breathes his last breath, a cloud of sinister black fog envelops him, and when the fog lifts, the carcass has disappeared.
Your sword is no longer glowing.

"'Your sword's blowing glue'. Wait let me try that again, 'Your sword's glowing blue'."

[pal666]

If these issues are longstanding bugs in the kernel then I don't think Linux is serious OS. It's probably better that it's at 1%.

moron, linux has larger installed base than all others combined. its only weak spot is desktop pcs, which are not the largest traffic source

[SystemCrasher]

Well, I noticed some strange "oscillations" in TCP traffic, too. And I suspect this could at least partially mitigate it. Though calling it "important" is overrated: it only happens in very specific circumstances and does not affects most of users most of time. So after fix, most people would not see anything changed at all...

[YoungManKlaus]

On web servers - where this is actually relevant - that share is more like 70%. More than twice that of Windows.

You also forgot that teeny tiny thing called Android, so also for consumers Linux market share is more around 50% (wild guess form me) across their major internet devices.

[Ardje]

Besides, from the description it seems that the issue goes away once the first congestion is detected and acted upon accordingly.

Unfortunately no. After "idle" (which is normal in tcp land), it needs to congest again and again, while you actually want to continue the same parameters. Idle might be a 1 second delay or whatever is considered idle. Normal tcp land usually has regular parts of idle. Such as in web browsers, which linger connections for a few seconds.

[droidhacker]

On web servers - where this is actually relevant - that share is more like 70%. More than twice that of Windows.

Not just servers, but also portable devices... where it actually has an even GREATER share than servers (over 80%).
I think that windows has something like ZERO percent share in portable devices.

I actually think that this bug will have more impact on portable devices than servers. Because servers tend to have multiple users, they don't generally have a quiescent period. They stay under load. Portable devices, on the other hand, have the OBJECTIVE of maximizing the quiescent periods in order to improve battery performance. So they'll sit there dormant, until they blast everything all at once. Combine that with a generally SLOWER network, and bad things happen.