But a year in, isn't it time to move on from "This is a bad problem!!!!" and anecdotes about the author's home network and kids, to big-picture insight and solutions?
First, it would be great to have some experimental data showing improvement of the problem. i.e, show, on a home network or cell network, how forcing some packets to be dropped would change latencies/RTT.
Second, some insight as to why AQM is (1) hard and (2) not deployed would be useful. Is it really just that it's a burden on ISP's? You'd think if it helped their customers they'd put engineering resources on it.
I've heard that it's partially a prisoner's dilemma - if you turn AQM/RED off and others on the same pipe use it, you get better performance. And packet drops can't be manipulated like this, so TCP uses the measure that's harder to fake. True?
Third, a working implementation of useful AQM would be nice. It's a year or so from initial report, and I get that it's hard, but all we've gotten in this article is "hold onto your pants, Van Jacobsen is working on it".
I think the main problem is the disconnect - either bufferbloat is a terrible disaster, in which every available TCP architect should care about it and be working on it (and they're not), or it's a less general problem with workarounds and engineers and academics can afford to spend a year or more tinkering with solutions (where we're at). In my reading all these articles by jg have this cognitive dissonance.
To improve: stop talking about history, and talk about how to solve this.