Open In App

Silly Window Syndrome

Last Updated : 05 Jul, 2022
Improve
Improve
Like Article
Like
Save
Share
Report

Silly Window Syndrome is a problem that arises due to poor implementation of TCP. It degrades the TCP performance and makes the data transmission extremely inefficient. The problem is called so because: 
 

  1. It causes the sender window size to shrink to a silly value. 
     
  2. The window size shrinks to such an extent that the data being transmitted is smaller than TCP Header. 
     

What are the causes? 
The two major causes of this syndrome are as follows: 
 

  1. Sender window transmitting one byte of data repeatedly. 
     
  2. Receiver window accepting one byte of data repeatedly. 
     

Cause-1: Sender window transmitting one byte of data repeatedly – 
Suppose only one byte of data is generated by an application . The poor implementation of TCP leads to transmit this small segment of data.Every time the application generates a byte of data, the window transmits it. This makes the transmission process slow and inefficient.The problem is solved by Nagle’s algorithm. 

Nagle’s algorithm suggests: 
 

  1. Sender should send only the first byte on receiving one byte data from the application. 
     
  2. Sender should buffer all the rest bytes until the outstanding byte gets acknowledged. 
     
  3. In other words, sender should wait for 1 RTT(Round Trip Time). 
     

After receiving the acknowledgement, sender should send the buffered data in one TCP segment. Then, sender should buffer the data again until the previously sent data gets acknowledged. 

Cause-2: Receiver window accepting one byte of data repeatedly – 
Suppose consider the case when the receiver is unable to process all the incoming data.In such a case, the receiver will advertise a small window size.The process continues and the window size becomes smaller and smaller.A stage arrives when it repeatedly advertises window size of 1 byte.This makes receiving process slow and inefficient.The solution to this problem is Clark’s Solution. 

Clark’s solution suggests: 
 

  1. Receiver should not send a window update for 1 byte. 
     
  2. Receiver should wait until it has a decent amount of space available. 
     
  3. Receiver should then advertise that window size to the sender. 
     

Note: 
 

  1. Nagle’s algorithm is turned off for those applications that require data to be immediately send. Nagle’s algorithm can introduce delay as it sends only one data segment per round trip. 
     
  2. Both Nagle’s as well as Clark’s algorithm can work together.Both are complementary. 
     

Example: 
A fast typist can do 100 words a minute and each word has an average of 6 characters. Demonstrate Nagle’s algorithm by showing the sequence of TCP segment exchanges between a client with input from our fast typist and a server. Indicate how many characters are contained in each segment sent from the client.Assume that the client and server are in the same LAN and the RTT is 20 ms? 

Nagle’s algorithm suggests: 
Sender should wait for 1 RTT before sending the data. The amount of data received from the application layer in 1 RTT should be sent to the receiver. 

Amount of data accumulated in 1 RTT, 
 

= (600 characters / 1 minute) x 20 msec
= (600 characters / 60 sec) x 20 msec
= (10 characters / 103 msec) x 20 msec
= 0.2 characters 

From here, we observe: 
Even if the sender waits for 1 RTT, not even a single character is produced. So, sender will have to wait till it receives at least 1 character. Then, sender sends it in one segment. Thus, one character will be sent per segment. Assuming the TCP header length is 20 bytes, 41 bytes of data will be sent in each segment.
 


Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads