Well... I disagree that the "modern internet does not suffer from this problem." I have seen it at my house, and at measurements at many other places. (If you're only considering FTTH as "modern", I have still seen bufferbloat there...)
The ISP does have an opportunity to control buffering in two places: at both ends of the bottleneck (which is likely to be your cable/DSL/FTTH/etc.) link between your house and their facility.
a) Their "head end" gear might control queues for traffic going *to* you b) Their Customer Premise Equipment (CPE) also would have the ability to control outgoing queues
If the ISP did both, then no one would have need to coin the term "bufferbloat". But the fact of the matter is that the vast majority of ISPs do *neither*.
Consequently, in late 2016, I believe it's prudent to provide my own solution and use one of the Smart Queue Management solutions (fq_codel, cake) that's available in LEDE/OpenWrt/DD-WRT so that I can get on with useful work.
Buffer bloat can't happen without congestion. Congestion is the real problem and talk of buffer bloat is a bit off-point. Sure, if you combat congestion with very large buffers (and hence significant queuing), you get increased latency due to the queuing. Reasonable increase in latency (say 20%) is not a huge hit on performance. Remember that you're trading that extra latency for lower probability of dropped packets.
You're correct that bufferbloat "only happens" when there's traffic. But I don't think you appreciate the current nature of internet traffic.
With web pages averaging 2 megabytes these days, you're "doing large file transfers" all the time. And if your iPhone kicks off an upload of its pictures, or your child starts watching videos, or your spouse starts their own web browsing/mail session, you're at the mercy of your router's queue management algorithm.
I don't think a "20% increase" in latency is reasonable, given that the Smart Queue Management (fq_codel, and soon cake) that's available in the Linux kernel (not to mention LEDE/OpenWrt/DD-WRT for your home routers) provide a "no-settings" way to limit lag/latency to an increase of only a few msec (or a couple dozen msec on a crummy DSL link).
The router needs to manage the bottleneck link, since that's the place all the data gets queued up (in those buffers that are the topic of interest).
The router is the only device that has visibility into the amount of data that's in transit "to the internet". Your browser doesn't know that your spouse's/kid's iPhone just decided to upload all new images to the cloud. Nor can your gaming system.
Browsers are designed to send the data as fast as possible. Gaming systems are designed to send immediately after you click. It's the responsibility of good networking equipment to regulate all the flows of data so that *everyone* gets good performance.
(And while you *could* spend your life optimizing qos rules, the beauty of fq_codel/cake is that they take one parameter (link speed) and they automate all the rest.)
Slashdot Mirror
Well... I disagree that the "modern internet does not suffer from this problem." I have seen it at my house, and at measurements at many other places. (If you're only considering FTTH as "modern", I have still seen bufferbloat there...)
The ISP does have an opportunity to control buffering in two places: at both ends of the bottleneck (which is likely to be your cable/DSL/FTTH/etc.) link between your house and their facility.
a) Their "head end" gear might control queues for traffic going *to* you
b) Their Customer Premise Equipment (CPE) also would have the ability to control outgoing queues
If the ISP did both, then no one would have need to coin the term "bufferbloat". But the fact of the matter is that the vast majority of ISPs do *neither*.
Consequently, in late 2016, I believe it's prudent to provide my own solution and use one of the Smart Queue Management solutions (fq_codel, cake) that's available in LEDE/OpenWrt/DD-WRT so that I can get on with useful work.
Buffer bloat can't happen without congestion. Congestion is the real problem and talk of buffer bloat is a bit off-point. Sure, if you combat congestion with very large buffers (and hence significant queuing), you get increased latency due to the queuing. Reasonable increase in latency (say 20%) is not a huge hit on performance. Remember that you're trading that extra latency for lower probability of dropped packets.
You're correct that bufferbloat "only happens" when there's traffic. But I don't think you appreciate the current nature of internet traffic.
With web pages averaging 2 megabytes these days, you're "doing large file transfers" all the time. And if your iPhone kicks off an upload of its pictures, or your child starts watching videos, or your spouse starts their own web browsing/mail session, you're at the mercy of your router's queue management algorithm.
I don't think a "20% increase" in latency is reasonable, given that the Smart Queue Management (fq_codel, and soon cake) that's available in the Linux kernel (not to mention LEDE/OpenWrt/DD-WRT for your home routers) provide a "no-settings" way to limit lag/latency to an increase of only a few msec (or a couple dozen msec on a crummy DSL link).
The router needs to manage the bottleneck link, since that's the place all the data gets queued up (in those buffers that are the topic of interest). The router is the only device that has visibility into the amount of data that's in transit "to the internet". Your browser doesn't know that your spouse's/kid's iPhone just decided to upload all new images to the cloud. Nor can your gaming system. Browsers are designed to send the data as fast as possible. Gaming systems are designed to send immediately after you click. It's the responsibility of good networking equipment to regulate all the flows of data so that *everyone* gets good performance. (And while you *could* spend your life optimizing qos rules, the beauty of fq_codel/cake is that they take one parameter (link speed) and they automate all the rest.)