I agree with with just about everything you said, up to your last paragraph. The economics of actual installations in rural areas don't support that price point.

I am aware of small, private company that's installing fiber to the premise to everyone in their fairly compact rural town. The major (unavoidable) drivers of up-front cost are:

- $35,000-40,000 per mile of road for licensing, pole make-ready, and hanging the fiber
- $1,500 per drop to the premise

This sugars out to a basic 25/25mbps plan (including phone service) at about $100/month. The investors are patient, and are motivated by the desire to get good internet for the town, not a quick payback.

But you're right that 25/25 is completely adequate service. And the comparison should be between $100/month and simply not available.

Elon Musk touts Starlink as a low latency transmission scheme. As a member of the team that has been working to fight bufferbloat (and solved it seven years ago) I would be interested to hear how Starlink plans to avoid queueing too much data in their network.

In New Hampshire, municipalities may only use public funds (e.g., float a bond) to build out service in "unserved/underserved" parts of the town. So an incumbent ISP gets all the profitable parts of the area, and lets the town government pay for the expensive parts. Pretty crafty, eh?

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.

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.)