Ask HN: Why isn't VoIP better?

This is a consequence of how congestion is signaled in IP networks: by dropping packets. If the ISP is the bottleneck (it almost always is, due to throttling in both directions), it signals this to upstream equipment (i.e. the source of the packets) by dropping packets. They aren't sent back to some random router to be queued up.

Bufferbloat comes in because the ISP is trying to make use experience a little less crappy by hanging on to bursts of packets which would otherwise be dropped, with the intent of forwarding them on at the throttled rate. The consumer's router does not do this because it has no way of knowing this is happening. (But see below.) This is fine, except ISPs make their buffers HUGE.

There are two ways around this: one is, as you suggested, to use fq_codel, which monitors flows to infer packet buffering or loss at the ISP. So then, it is able to avoid sending packets which would be buffered or dropped by the ISP. The other is, as I suggested, to make your router the one dropping and buffering packets, which it normally does NOT do. It has no reason to: the links to the modem and the client are typically much faster than what the ISP throttles to, and those links are all it can see. (Though it's not unlikely that the user has subscribed to a higher speed than their wireless can handle, in which case inbound traffic is queued on the router, NOT outbound traffic.)

Yes, if your router is underpowered and you have a high-speed connection through the ISP, then your router could become a bottleneck and show bufferbloat. That is almost never the case, and when it is, it can happen in both directions.

The GP has "a way out", it is exactly to perform the steps I indicated. fq-codel is nice to have but NOT necessary.

Their paper tells how they've reduced bufferbloat as well as increasing "airtime fairness" in the Wi-Fi stack. The paper, "Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi", is now available as a preprint at: https://arxiv.org/abs/1703.00064 The conclusion of the paper states:

"We have developed a novel two-part solution to two large performance problems affecting WiFi: Bufferbloat and the 802.11 performance anomaly.

"The solution consists of a new integrated queueing scheme tailored specifically to eliminating bufferbloat in WiFi, which reduces latency under load by an order of magnitude. Leveraging the queueing structure, we have developed a deficit based airtime fairness scheduler that works at the access point with no client modifications, and achieves close to perfect fairness in all the evaluated scenarios, increasing total throughput by up to a factor of 5.

"Our solution reduces implementation complexity and increases accuracy compared to previous work, and has been accepted into the mainline Linux kernel, making it deployable on billions of Linux-based devices."

Fun reading! Oh, and it's available in LEDE today.

Your router at home needs to have the same logic: it needs to control the buffering of data being sent toward the ISP. fq_codel/cake actually measures the time packets dwell in the queues (their "sojourn time") and drops/marks with ECN some of the packets of flows that build up a queue.

A cool feature of fq_codel/cake qdisc in LEDE is that it can control bloat in both directions. It imposes a bottleneck that's slightly (a few percent) below the actual ISP download link speed so that traffic queues up within your home router (instead of at the DSLAM/head end). Consequently, it can do the fq_codel/cake algorithm on the download (as well as the upload) direction, keeping your link unbloated at a very small loss of link speed.

For example, my home network has a 100 Mbit bidirectional Ethernet connection between my router and my modem, and my modem has a 152 Mbps downlink (4 bonded DOCSIS channels) and an 81 Mbps uplink (3 bonded DOCSIS channels).

Neither of those is the bottleneck, because my ISP throttles my connection entirely on their router to 3.5 Mbps downstream, 1 Mbps upstream. I, like most in the US, cannot afford a 100+ Mbps home connection.

What you said would hold true IF, say, I had a gigabit connection (but still used a 100 Mbps Ethernet link). Then, yes, upstream traffic would build up in the upstream queue on my own router or modem. But that's not the case, and neither my modem nor router see anywhere near the 100+ Mbps of traffic needed to saturate the link.

If you do not understand this, I suggest looking at the queue depth on an actual router, with all traffic shaping turned off, while running a speedtest. You will see the interface queues in both directions be completely empty.

Here's a picture, since you seem to be ignoring my words:

     150 Mbps WiFi
           |
      home router
           |
    100 Mbps Ethernet
           |
         modem
           |
    152/81 Mbps DOCSIS
           |
    +-ISP router-----------------+
    |      |  

     150 Mbps WiFi
           |
      home router
           |
    100 Mbps Ethernet
           |
         modem
           |