TCP Windows are not a buffer

Recently, I read an article that attempted to explain what TCP windows were and how the effected traffic flow for TCP connections. While the author was 90% correct about the practical knowledge, there was a lack of understanding that permeated the article. TCP windows are one of the most complicated things about the protocol, and it's not surprising that there was a fault present.

For this article I'm going to assume that you've got the basics of TCP/IP down. The TCP window can be defined as such: the window is the total amount of bytes of data that can be sent prior to receiving an acknowledgment. What this is, in essence, is the data that is actually on the wire between the transmitter and the receiver. The idea behind the sliding window system is to cleanly implement a mechanism for flow control.

An example in the real world is water in a hose. The transmitter is the faucet, and the receiver is at the other end of the hose. When you turn the water on, it takes a bit of time for the water to get from the faucet to the other end. This, in network terms, is the propagation delay (also called the return trip time, or RTT). Once the hose is on, we see the water representing our data. Most of the data is at the faucet. Some of it has made it out of the hose at the other end. But the water that is still inside the hose is what represents our TCP window. In a network sense, we're doing the same thing with data. We're trying to fill the "hose" of our network with enough data so that the data continues to flow smoothly.

This is not a buffer. Buffers are temporary memory areas for storing data. I would no more describe the objects that a juggler juggles as buffered than I would describe the TCP window as such.

Now, clearly I'm cranky, but we're not done quite yet. The reason this is important is so we can understand the true effect that windows have on data flow. If the window for a given connection is too small, the traffic will studder. The reason being that the transmitter will fill their window and then stop transmitting. The good news is that the window can shift as the connection moves past it's initial start. We can also determine ahead of time what the optimum window size is for a given connection. The formula for this is bandwidth * propagation delay. In this case, the bandwidth here will represent the size of the smallest link between two machines.

Typically the maximum TCP window is 64k -- a number that seems small because it is. What we can do is enable an option called Window Scaling. This will allow us to create windows that go as large as 2 GB. Something that would be useful only over network connections that have very long propagation delays (traveling to Mars anyone?). The window scaling function is advertised at the start of a connection in the SYN packet. Both sides must advertise it in order for it to be an option for this connection. Linux machines, for example, default to advertising this capability.

In short TCP windows are not buffers, and you kids need to get off of my lawn.