Silly Window Syndrome (SWS) is a problem that can arise in poor implementations of the transmission control protocol (TCP) when the receiver is only able to accept a few bytes at a time or when the sender transmits data in small segments repeatedly. The resulting number of small packets, or tinygrams, on the network can lead to a significant reduction in network performance and can indicate an overloaded server or a sending application that is limiting throughput. 

What Causes Silly Window Syndrome from the Sender Side? 

On the sender's side, silly window syndrome can be caused by an application that only generates very small amounts of data to send at a time. Even if the receiver advertises a large window, the default behavior for TCP would be to send each individual small segment instead of buffering the data as it comes in and sending it in one larger segment. 

What Causes Silly Window Syndrome from the Receiver-Side? 

If the receiver processes data slower than the sender transmits it, eventually the usable window becomes smaller than the maximum segment size (MSS) that the sender is allowed to send. However, since the sender wants to get its data to the receiver as quickly as possible, it immediately sends a smaller packet to match the usable window. As long as the receiver continues to consume data at a slower rate, the usable window, and therefore the transmitted segments, will get smaller and smaller. 

SOLUTIONS TO SWS 

1.      Sends the first segments even it is small 

2.      Wait for acknowledgement from the receiver and accumulate silly window created by receiver. 

Clarks : from the receiver 

1.      Sends ACK as soon as data arrive 

2.      Announce a window size of the zero until: 

Available space in receiver buffer is equal or greater than the maximum segments size or half of the receiver buffer is empty. 

Delay acknowledgement: 

Received segment is not ACK until there is decent amount of free space in receiver buffer. Ack delayed typically for 200ms. 

Nagles delay ACK deadlock: 

This happen when there is no ACK or PSH received by the sender then the transmission became deadlock. 

 

 The first segment is sent regardless of size. 
 Next, if the receiving window and the data to send are at least the maximum segment size (MSS), a full MSS segment is sent. 

 Otherwise, if the sender is still waiting on the receiver to acknowledge previously sent data, the sender buffers its data until it receives an acknowledgment.

 

 

To see how this can happen, let's consider an example that is a variation on the one we’ve been using so far in this section. We'll assume the MSS is 360 and a client/server pair where again, the server's initial receive window is set to this same value, 360. This means the client can send a “full-sized” segment to the server. As long as the server can keep removing the data from the buffer as fast as the client sends it, we should have no problem. (In reality the buffer size would normally be larger than the MSS.)

Now, imagine that instead, the server is bogged down for whatever reason while the client needs to send it a great deal of data. For simplicity, let's say that the server is only able to remove 1 byte of data from the buffer for every 3 it receives. Let's say it also removes 40 additional bytes from the buffer during the time it takes for the next client's segment to arrive. Here's what will happen: