A quick read shows that this is hardly novel. If I missed something, please point it out.
The issue is simple: broadband providers/modem manufacturers/... want to advertise the largest download speeds they possibly can. To do this, they add large buffers (such that they can always fill the pipe with bits).
However, they overdo this: by the time you've buffered a second worth of data, new data can't get through the router in a timely fashion. This means that VoIP sucks (one second latency), TCP sucks (it sends a limited amount of data before waiting for ACKs - note the recent "Google floods clients with 12 TCP packets at once" post on HN), and you may get random drops as well.
The solution is to rate-limit your outgoing internet connection to just a little less than the actual rate, and do queue management on a competent device (e.g. any unixish system should do). Prioritize VoIP, Quake, TCP ACKs, etc, and deprioritize BitTorrent/FTP/anything with the appropriate QoS bits set. Google for a guide relevant to your favourite implementation (netfilter/pf/...)
I believe the author is discussing excessive buffering in the local hardware and OS, not the ISP's. He specifically calls out Intel and some Linux drivers as known causes. Additionally, he demonstrates that changing OS buffering parameters corrects the problem in many cases (going from 1-2s latency to 30ms).
The issue is simple: broadband providers/modem manufacturers/... want to advertise the largest download speeds they possibly can. To do this, they add large buffers (such that they can always fill the pipe with bits).
However, they overdo this: by the time you've buffered a second worth of data, new data can't get through the router in a timely fashion. This means that VoIP sucks (one second latency), TCP sucks (it sends a limited amount of data before waiting for ACKs - note the recent "Google floods clients with 12 TCP packets at once" post on HN), and you may get random drops as well.
The solution is to rate-limit your outgoing internet connection to just a little less than the actual rate, and do queue management on a competent device (e.g. any unixish system should do). Prioritize VoIP, Quake, TCP ACKs, etc, and deprioritize BitTorrent/FTP/anything with the appropriate QoS bits set. Google for a guide relevant to your favourite implementation (netfilter/pf/...)