No one seems to have seriously looked at the impact of LEDBAT on VoIP or other need-to-see-minimal-delay services. Yes, persistent TCP flows will do worse damage to VoIP, but scavenger protocols are far more likely to be running constantly in the background. 100ms of extra delay is a serious impediment to high-quality VoIP (or interactive video) service.

The initial 25ms proposal would have been mildly annoying, but manageable if it was achieved. 100ms (and the switch has no source I was able to find on the LEDBAT WG archives) is a real problem. I also worry about it being used in non-user-visible/controllable manners, like OS or application background updates, or for background cloud backups, or synchronizing pictures, etc.

And, as mentioned, it doesn't respond well to AQM techniques – it devolves to roughly fair sharing with TCP/etc it appears. If it reacted more strongly to loss (and ECN) than TCP, it might remain a scavenger in an AQM environment, for example.

diffserv is all well and good, but it is not an alternative for 'correct' protocol design (and I realize 'correct' is subjective). We can adjust endpoint protocols; we can't wave a wand and get rid of 100's of millions of WiFi/NAT/routers that no one will ever update the firmware of. Eventually (10 years?) most will have failed and be replaced, but I'd rather not wait until then.

I hope you'll be coming the the IAB/IRTF Congestion Control Workshop right before the next IETF!

But I don’t see ledbat as a panacea: all it takes is one TCP session to ruin your whole day (sharing the same network path through a bottleneck), and by design, it means that any conventional TCP will take precedence over it. So Ledbat has the same problem that delay based TCP algorithms such as TCP Vegas has: flag days in the internet can’t exist, and you can’t get everyone to convert at once.

Deploying home routers and broadband gear with codel will avoid bufferbloat for all versions of TCP; so you don’t face the upgrade of (often impossible to upgade) equipment.

So I don’t think this is an “either/or” situation at all: both help, and both have their place.

Just make sure that ledbat can deal with active AQM, and mark its packets with diffserv, and we’ll all win.

In terms of deployment we already have widespread deployment of utp, and end users would be happy to deploy ledbat for all their TCP connections if only they were given the option, because they’re the ones suffering from the buffer bloat. Codel would have to be deployed by ISPs, who generally aren’t interested in fixing things.

As a solution, ledbat maintains the simple and flexible behavior of internet routers, while codel would make their behavior much more specific and particular, which could cause problems for future innovation. Codel has the benefit that it knows the one way delay, rather than having to subtract out a minimum seen, but ledbat knows what the RTT is.

In terms of future development, it should be possible to switch ledbat to be rate based rather than congestion window based, which would allow buffers to be much smaller than the RTT. (We’re working on that one). It should also be possible to rely almost exclusively on delays and ignore packet loss, which would be very good on mobile networks and wireless, because those have high non-congestive packet loss rates. That would currently break down when the bottleneck is on a very high bitrate connection, although explicit congestion notification should be able to fix that problem.