|
|
|
|
|
|
by esseph
312 days ago
|
|
|
You are 100% correct. It is not yet a "solved" problem, but 10-15 years have started to make a dent and get better tools to both observe and act on the problem. This is seen everywhere from the inclusion of CAKE ( https://man7.org/linux/man-pages/man8/tc-cake.8.html ) in some CPE / home router, but the use of fq_codel ( https://man7.org/linux/man-pages/man8/tc-fq_codel.8.html ) in routers along the way. Other ISPs have to go even farther, because "content" might be 80-120ms away, and the ability to be more aggressive or less aggressive in tuning certain parameters can have a large impact on overall customer Quality of Experience. If there are any LEO hops along the way, problems with TCP and delayed signaling as a byproduct can also make throughout tank while latency spikes. DPDK and VPP have contributed to a lot of new networking devices to help observe and act on traffic. Everytime you go from a big pipe to a small pipe (higher data rate to lower data rate) connection you will see this issue at varying levels. |
|
|
By the way, when I wrote in another comment that bufferbloat was solved, I meant it in the same way that IPv4 exhaustion is solved by IPv6. We have the ability to deploy solutions that largely fix things, but whether we do is another matter. You are right to say that the past 10-15 years have started to make a dent in the problem. I had not meant to suggest otherwise.