Gettys: Mitigations and Solutions of Bufferbloat

ISPs don't really have an incentive to make their router transmit buffers too large, because customers, especially sophisticated customers, care about latency as well as bandwidth. DNS lookups, the establishment phases of connections, and recovery time after a packet loss are all highly dependent on latency.

If the latency is excessive, the ISP is liable to be perceived as sluggish relative to the competition, no matter what the top line bandwidth is. DSL providers are major offenders here, due to default adoption of high latency forward error correction. Link level acknowledgement and retransmission would probably be much more effective.

Those who cannot remember the past are condemned to repeat it.
- Santayana

Unfortunately, we've managed to forget both the NSFnet collapse, and the solutions that were devised to avoid it's reappearance (e.g. RED, and now I find people are messing with slow start).

Last comment from me tonight: the ISP's have missed this just as much as the equipment vendors, or OS developers, or device driver writers have. We're all in glass houses. Much as we all like good conspiracy theories, I don't believe conspiracy theory in this case.

The rule is that the bottleneck controls buffering behavior, so if you don't like someone else's buffer management policy, you have to throttle your connection.

So say I throttle my upstream, in return for latency. Why in the world would my ISP respond to this by throttling their connection *even more*, throwing away even more throughput in return for *worse* latency? That makes no sense. ISPs, like you say, have been trained to maximize throughput.

Which could still turn out okay, I guess -- if main-stream OSes were to start doing dynamic traffic shaping (i.e., detect bufferbloat and then shape outgoing traffic to maintain latency) and telling their users "hey, so maybe your ISP told you that you got X Mbs but actually you get Y Mbs" then ISPs might start fixing their routers. It would certainly be a lot cheaper for them than any *other* way of increasing (effective) throughput, like laying new cable.

And many endpoints never get updated.

What's the current penetration of Windows XP? Still > 50%. Unless Microsoft decided to bundle TCP changes into security updates, it strikes me as very unlikely updated TCP's will deploy faster than even replacing the offending hardware.

Phones are a different market: they still do get updates frequently (at least smart phones). So there one could imagine it.

But what has worried me about the "mess with TCP" approach is game theory: if modifying it for everyone's benefit disadvantages the user of that device over others, it's going to be a hard sell to deploy. We see the opposite phenomena today with browsers, which have been upping the # of connections used at once. This is bad for the network and other users sharing any link, but beneficial to the end users, so happens anyway.