> (...) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. I don't

> (...) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. I don't think people believed network congestion was a buffer allocation problem. I think people believed buffering was a way to mitigate congestion caused by a spike in traffic before allowing connection problems to surface (dropped packets, dropped connections, etc). Buffers are bounded which, by definition, means they can be filled up. Once they are filled up then the same problems that were caused by a congested network without buffering would also be experienced in connections with buffering. It's hard to believe that back then no one noticed that buffers would only take so much data. > Nagel was one of the first people to point out the problem with this. Correct me if I'm wrong, but the problem that was pointed out was instead modes of failure that take place when networks are congested but buffers are still able to take more data. We're talking about failure modes that happen when the network is congested and buffers are not completely filled but they neither can flush their data nor drop packets/connections, thus it's a steady state characterized by a network that in theory is working, but induces high latency. Also, limiting buffers is also not a fix for network congestion problems. It's a way to allow a failure mode (dropped packets) to happen much earlier than another failure mode (long queues with high latency).