4 ms·

TCP Silly Window Syndrome

34 points by gazzik 11y ago

mockery 11y ago
Why is this behavior "silly"? It seems to me like it's the correct behavior under the described conditions. (I'm not a networking expert though.) If the server is incapable of handling the amount of data that the client is sending, shouldn't the buffers get smaller and smaller until they reach a size the server can handle reliably? (Assuming other variables like the latency of the connection or server load aren't changing.) If the server really can only handle a byte of data in the time it takes for a round-trip message, then it seems correct for the client to only send it one byte at a time...?
- mockery 11y ago
  (Oh I just realized that there are more pages to the article - the "next article" button caused me to overlook the "next page" button. Perhaps they explain what the problem is on subsequent pages.)
- gazzik 11y ago
  It does make sense to shrink the window size, but the correct way is to shrink down to 0 instead of shrinking gradually. This is explained in the algorithm. Small window sizes = more overhead on the sending host
Animats 11y ago
Silly window syndrome was fixed in TCP around 1983. Unless someone really botches a TCP implementation, it should not be a problem today. The article has a section "Sender SWS Avoidance and Nagle's Algorithm" and claims that they're related. They're not, except that in some sense they're duals. Silly window syndrome occurs when the pipe is almost full and the reading end is making tiny reads. The tinygram problem, which is addressed by Nagle's Algorithm, occurs when the pipe is almost empty and the writing end is making tiny writes. Silly window syndrome is easy to fix, because doing tiny reads from a full pipe doesn't mean the sender has to be informed immediately that there's space for a tiny bit of new data. The receiver doesn't send a window update until there's some serious space available. But tiny writes on an empty pipe come up often in practice, and senders want their tiny data items delivered promptly, so tinygram prevention can't be as heavy-handed. (A long time ago, when TCP was being designed, I used to have to worry about this stuff. John Nagle)
- zurn 11y ago
  Well spotted. But why is this article still on the front page 4+ hours later? Are people disagreeing, ignoring the comments, or appreciating this for historical reasons?

34 points by gazzik 11y ago

Why is this behavior "silly"? It seems to me like it's the correct behavior under the described conditions. (I'm not a networking expert though.) If the server is incapable of handling the amount of data that the client is sending, shouldn't the buffers get smaller and smaller until they reach a size the server can handle reliably? (Assuming other variables like the latency of the connection or server load aren't changing.) If the server really can only handle a byte of data in the time it takes for a round-trip message, then it seems correct for the client to only send it one byte at a time...?

mockery 11y ago
(Oh I just realized that there are more pages to the article - the "next article" button caused me to overlook the "next page" button. Perhaps they explain what the problem is on subsequent pages.)
gazzik 11y ago
It does make sense to shrink the window size, but the correct way is to shrink down to 0 instead of shrinking gradually. This is explained in the algorithm. Small window sizes = more overhead on the sending host

Animats 11y ago

Silly window syndrome was fixed in TCP around 1983. Unless someone really botches a TCP implementation, it should not be a problem today. The article has a section "Sender SWS Avoidance and Nagle's Algorithm" and claims that they're related. They're not, except that in some sense they're duals. Silly window syndrome occurs when the pipe is almost full and the reading end is making tiny reads. The tinygram problem, which is addressed by Nagle's Algorithm, occurs when the pipe is almost empty and the writing end is making tiny writes. Silly window syndrome is easy to fix, because doing tiny reads from a full pipe doesn't mean the sender has to be informed immediately that there's space for a tiny bit of new data. The receiver doesn't send a window update until there's some serious space available. But tiny writes on an empty pipe come up often in practice, and senders want their tiny data items delivered promptly, so tinygram prevention can't be as heavy-handed. (A long time ago, when TCP was being designed, I used to have to worry about this stuff. John Nagle)

zurn 11y ago
Well spotted. But why is this article still on the front page 4+ hours later? Are people disagreeing, ignoring the comments, or appreciating this for historical reasons?