The LA-120 and the Internet

When I see one of these things, a Digital Equipment Corp LA-120, I think back to 1986 when I was sitting at one connected to a VAX. It was at a competitor to Dictaphone, and was getting into computers. They had before I arrived purchased a VAX 750. Hence the LA-120.

I remember because I was puzzled. We had just upgraded to BSD 4.3 UNIX but something with the internet was kind of wonky. Things seemed to be quite slow. Later, at a Usenix technical conference tutorial, I discovered why. TCP/IP was more aggressive in 4.3 and had crushed the net.

TCP has flow control. The receiver tells the sender how much data it can take. This window gets updated as the receiver consumes the bytes. BSD 4.3 tried to keep the window full. But there are more buffers in the path than the receivers’. Routers have buffers, too.

The issue was that routers were having to toss packets as they had no place to put them. I certainly had not thought of that. Apparently no one else had either.

But we all noticed it. And one intrepid researcher did something about it. His name is Van Jacobson, and he was working at Lawrence Berkeley Labs at the time. He figured out that it was the issue of router buffers getting spilled, but he did more than just learn what it was. He did something about it.

The result is an area of protocol design called congestion avoidance. Turns out, if you keep a close eye on how long it takes to get responses to packets, and you treat all losses as most likely caused by congestion, you can meter how many packets at a time you’re sending out.

Jacabson’s included two solutions, soon making it into all our TCP stacks. One was to start slow. Now, the word slow is relative. It’s not really that slow. But the TCP stack doesn’t start out with sending all the packets mentioned in the TCP windows. It instead starts with a couple, then four, then eight, all designed to give the network a chance to tell the sending TCP where the limit is.

Second, something called a congestion window keeps the number sent adjusted to fill the available bandwidth, but not over fill. It’s always dynamic. New traffic arrives at the limited switch, and some traffic stops, freeing up more bandwidth for your connections. So the congestion window moves around quite a bit.

We actually use this knowledge in our ATA-over-Ethernet initiator code. Our EtherDrive HBA uses these kinds of techniques to manage congestion in switches and ATA-over-Ethernet targets. It’s a bit harder. Our times are in microseconds, not milliseconds, which may be one reason iSCSI is slower than ATA-over-Ethernet. But it works quite well.

But I still remember those hours at the LA-120, typing away on green bar, trying to understand what had gone wrong.