Hi Kartik, Thanks for the questions.
> Has HTTP/2[1] been discussed on this list?[2] I've been thinking about > bufferbloat as I read the spec, and had a couple of questions that weren't > answered in the FAQ[3]: > > 1. HTTP/2 reduces the number of connections per webpage. Assume for a second > that all players instantaneously adopt HTTP/2 and so reduce their buffer > sizes everywhere. Latencies will improve and there'll be less congestion. Now > back to the real world with people building websites, trying to improve > performance of websites and devices all over the place. Will bufferbloat stay > eradicated, or will the gains be temporary? A Bufferbloat algorithm (fq_codel, or other SQM (smart queue management)) is required to minimize the number of buffers queued at *any* bottleneck in a network. This occurs frequently at the home router/edge of the network, but can appear anywhere. Wherever a queue begins to build up in a network, optimal performance demands some kind of SQM HTTP/2 may well help by requesting fewer connections, but the SQM in the router will still be in effect. If the smaller number of HTTP/2 requests from the browser don't create a queue, then SQM won't even become active. But if the browser traffic does manage to generate a queue, the router's SQM will keep it under control. I want to emphasize that point: SQM doesn't force any fixed allocations of bandwidth, packet rate, etc. It actually measures the queue length (in msec) for each traffic flow. If all the packets are whistling through without any congestion, every sender will get the full rate of the link. SQM only becomes active when there *is* congestion, and it throttles those flows that are sending the most traffic (to preserve the link capacity for the "little flows" that are time sensitive. > 2. More generally, is there any technical way for bufferbloat to stay solved? > Or is it an inevitable tragedy of the commons dynamic that we just have to > live with and make temporary dents in? Yes, it will stay solved. No, there's no tragedy of the commons. (Great question, though.) The SQM algorithm only examines packets within a single router, so multiple routers are essentially independent. There's no central communication required - it's all local to a router. In fact, the "tragedy" of solving bufferbloat is that it needs to be solved *everywhere*. That is to say that *every* router, cell phone, DSLAM, Cable modem (home and head-end), personal computer OS, and other piece of equipment on the planet needs to be updated. This is the hard part. > 3. Has there been discussion of solving bufferbloat at the TCP layer, by > making buffers harder to fill up? I'm thinking of heuristics like disallowing > a single site from using 80% of the buffer, thereby leaving some slack > available for other bursty requirements. I am personally not hopeful for this kind of approach. a) The TCP algorithm in hosts isn't easily made aware of congestion elsewhere in the network, so it can't react to that congestion; b) there aren't a lot of tested proposals (beyond dropping packets) to make things better; c) it suffers from exactly the same problem as solving bufferbloat - it needs to be rolled out in every piece of gear. (We can't even attract the attention of vendors (Apple, Microsoft, most routing gear, etc). to implement the solved algorithms to improve bufferbloat. Sigh.) > I'm sure these questions are quite naive. Pointers to further reading greatly > appreciated. > > Kartik > http://akkartik.name/about > > [1] https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs > > [2] Google search on "site:https://lists.bufferbloat.net"; didn't turn up > anything, and I get "permission denied" when trying to access the > downloadable archives at https://lists.bufferbloat.net/pipermail/bloat. > > [3] https://gettys.wordpress.com/bufferbloat-faq > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
