5 ms·

Recently I ranted at the ISPs and at the network neutrality people. fq_codel (RFC8290) is now nearly ubiquitous in as the default queuing mechanism in most linu

Recently I ranted at the ISPs and at the network neutrality people. fq_codel (RFC8290) is now nearly ubiquitous in as the default queuing mechanism in most linux distributions, and it is long past time more ISPs supplied it in the gear they give customers. http://blog.cerowrt.org/post/net_neutrality_customers/ http://blog.cerowrt.org/post/net_neutrality_customers/ sch_cake (derived from fq_codel with an integral shaper) is about to enter the Linux mainline after years of baking in openwrt. https://lwn.net/SubscriberLink/758353/05c20f25115c852d/ https://lwn.net/SubscriberLink/758353/05c20f25115c852d/ We can end bufferbloat, now, on everything.

pja 8y ago
I enabled sch_cake on my router (an R7800 with Openwrt 18.06 on it) recently. Worked like a charm. Would happily recommend. I imagine the main thing that's holding back ISPs from using it on their consumer routers is the (minimal) configuration the user has to do to set to upload bandwidth limit. If ISP routers were also using decent queuing algorithms and not buffering like crazy then that wouldn't be necessary of course, but it doesn't seem like that's going to change any time soon.
- dtaht99 8y ago
  Well, many isp-born devices are provided with that info by the ISP at connect time, so the hope has always been that during configuration they'd just pass (for example) "bandwidth 10mbit docsis" to the network setup routine. DSL modems also typically get this info at startup.
philjohn 8y ago
The problem is that ISP provided kit is built to a price, so will tend to have a more aenemic processor. Shaping high bandwidth needs CPU cycles, or better yet, hardware offloading. Funnily enough, I've just got a firmware applied to my cable connection with Virgin Media in the UK that mitigates the Puma 6 issue on their provided DOCSIS 3 modem - it's eliminated buffer bloat as well, which is a nice side effect. People are listening, Docsis 3.1 includes active queue management for instance, which goes a long way to preventing the issue.
- StudentStuff 8y ago
  Note that the firmware update doesn't fix the issue (which is Intel failed to put much cache on their chips to save $$), but merely helps to lessen the impact of Intel's shoddy hardware engineering. I would still replace your modem with a non-Intel modem ASAP if you want good performance. This thread covers the issue pretty well: https://www.dslreports.com/forum/r31614833-Equip-Intel-Puma-6-chipset-issue-now-solved https://www.dslreports.com/forum/r31614833-Equip-Intel-Puma-...
  - philjohn 8y ago
    Virgin Media in the UK don't allow third party modems. I've run a lot of tests since the update, and it's definitely on a par now with my old FTTC connection, jiter especially is much improved.
akira2501 8y ago
> We can end bufferbloat, now, on everything. We have been able to for years. htb+sfq has been around forever.
- wtallis 8y ago
  Neither HTB or SFQ includes a CoDel-like AQM component. HTB+SFQ will get you fair sharing of bandwidth shaped at the rate of your choosing, but does nothing to control queue lengths.
  - akira2501 8y ago
    > but does nothing to control queue lengths. For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well. My understanding is that you would want AQM in order to keep your bandwidth utilization closer to the actual wire speed than a simple priority queue would. So, we've had the tools to deal with bufferbloat for a long time, it's just that this mode now just provides slightly better peak performance.
    - wtallis 8y ago
      > For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well. If you have a traffic shaper being fed by a deep, dumb queue, you aren't giving useful back-pressure to TCP until it's too late. You need an AQM that gives either ECN marks or packet drops soon enough that you don't build up or sustain deep queues of packets. That's the core of what bufferbloat is. The queue(s) in front of HTB in your router might not be as stupidly oversized as the queue in your cable or DSL modem, but they're still susceptible to the same problems when there's no AQM component. Some TCPs do a decent job of backing off when latency climbs, before the buffers actually fill and start causing packet drops. But AQM in the router can more directly observe and act on congestion, and works with older TCPs and non-TCP traffic.

pja 8y ago

I enabled sch_cake on my router (an R7800 with Openwrt 18.06 on it) recently. Worked like a charm. Would happily recommend. I imagine the main thing that's holding back ISPs from using it on their consumer routers is the (minimal) configuration the user has to do to set to upload bandwidth limit. If ISP routers were also using decent queuing algorithms and not buffering like crazy then that wouldn't be necessary of course, but it doesn't seem like that's going to change any time soon.

dtaht99 8y ago
Well, many isp-born devices are provided with that info by the ISP at connect time, so the hope has always been that during configuration they'd just pass (for example) "bandwidth 10mbit docsis" to the network setup routine. DSL modems also typically get this info at startup.

philjohn 8y ago

The problem is that ISP provided kit is built to a price, so will tend to have a more aenemic processor. Shaping high bandwidth needs CPU cycles, or better yet, hardware offloading. Funnily enough, I've just got a firmware applied to my cable connection with Virgin Media in the UK that mitigates the Puma 6 issue on their provided DOCSIS 3 modem - it's eliminated buffer bloat as well, which is a nice side effect. People are listening, Docsis 3.1 includes active queue management for instance, which goes a long way to preventing the issue.

StudentStuff 8y ago
Note that the firmware update doesn't fix the issue (which is Intel failed to put much cache on their chips to save $$), but merely helps to lessen the impact of Intel's shoddy hardware engineering. I would still replace your modem with a non-Intel modem ASAP if you want good performance. This thread covers the issue pretty well: https://www.dslreports.com/forum/r31614833-Equip-Intel-Puma-6-chipset-issue-now-solved https://www.dslreports.com/forum/r31614833-Equip-Intel-Puma-...
- philjohn 8y ago
  Virgin Media in the UK don't allow third party modems. I've run a lot of tests since the update, and it's definitely on a par now with my old FTTC connection, jiter especially is much improved.

akira2501 8y ago

> We can end bufferbloat, now, on everything. We have been able to for years. htb+sfq has been around forever.

wtallis 8y ago
Neither HTB or SFQ includes a CoDel-like AQM component. HTB+SFQ will get you fair sharing of bandwidth shaped at the rate of your choosing, but does nothing to control queue lengths.
- akira2501 8y ago
  > but does nothing to control queue lengths. For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well. My understanding is that you would want AQM in order to keep your bandwidth utilization closer to the actual wire speed than a simple priority queue would. So, we've had the tools to deal with bufferbloat for a long time, it's just that this mode now just provides slightly better peak performance.
  - wtallis 8y ago
    > For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well. If you have a traffic shaper being fed by a deep, dumb queue, you aren't giving useful back-pressure to TCP until it's too late. You need an AQM that gives either ECN marks or packet drops soon enough that you don't build up or sustain deep queues of packets. That's the core of what bufferbloat is. The queue(s) in front of HTB in your router might not be as stupidly oversized as the queue in your cable or DSL modem, but they're still susceptible to the same problems when there's no AQM component. Some TCPs do a decent job of backing off when latency climbs, before the buffers actually fill and start causing packet drops. But AQM in the router can more directly observe and act on congestion, and works with older TCPs and non-TCP traffic.