TCP SWS avoidance

Communication is interaction, so the responsibility for a communication problem is often shared between the communicating parts (although not always equally shared...).

The Silly Window Syndrome makes no exception to this general rule:

"In brief, SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data." (RFC 1122)

Therefore, countermeasures for SWS avoidance are to be taken at both sides, and RFC 1122 recommends the Clark's solution for the receiver, and the Nagle algorithm for the sender. In a few words, they consist in respectively waiting to have enough space before advertising an increase of the receive window, and in waiting to have enough data before sending a segment.

These are the effects on the test I presented in the last post, when repeated with the above solutions enabled (click to enlarge):

The flow graph on the left is the same as the last post, where no countermeasure is taken and SWS occurs. The capture file of this test can be downloaded here.

The flow graph in the middle shows the effects of Clark's solution: the window is updated only when there is enough space for a smart update - in this case half of the receive buffer - and the sender immediately makes use of it (capture file here).

The flow graph on the right shows the effect when also the sender takes action against SWS, by waiting to have enough data to send a full segment, according to Nagle's algorithm (capture file here).

TCP Silly Window Syndrome

While playing with my TCP implementation, I deliberately provoked a "Silly Window Syndrome" (SWS), just to see how it looks like.

To do so, I established a TCP connection between two endpoints A and B, both with the SWS-avoidance countermeaures disabled, and then I made the application at A rapidly issue 5 "send" calls of 1000 bytes each, and the application at B retrieve the received data at the rate of 100 bytes each 200 ms (fast producer vs. slow consumer). The TCP B had a receive buffer of 2400 bytes, and to see things more clearly I disabled the delayed ack and made A send data with the PSH flag unset.

Here is what happened when I ran the test (click on the thumbnails to enlarge, and here for the capture file):

          

The first segments soon filled the receive window, closing it (packets #8 and #9). After that, as soon as the receiver-side application consumed 100 bytes, the window was re-opened with this "silly" low value (#10) and this caused the sender to issue a small segment (#11) that filled the window again. The sequence of re-opening / small segment / closing was then repeated on and on, until all the data was transferred.

And this is the so-called "Silly Window Syndrome".

When it occurs, data is transferred in many small packets instead of few full-sized packets, resulting in an inefficient (possibly disastrous) use of the network.

TCP Packet Mood

In these weeks I am working at the good old Transmission Control Protocol (TCP)  and I find it a very formative activity, despite the age of the protocol.

Among the several enhancements added to it during the last thirty years, this one is particularly interesting: the option to denote Packet Mood (RFC 5841), which was proposed exactly one year ago "in an attempt to anthropomorphize the bit streams on countless physical layer networks throughout the world" (put it shortly, it adds the capability to express feelings on a per-packet basis).


What makes this feature interesting (at least in my opinion) is that the authors of the RFC forecast the creation of "a new technical job class of network psychologists". Since I do like new jobs ;-), I decided to give my humble contribution, and to implement the Packet Mood option in my TCP.

From the first tests it seems to work fine, and fortunately I found out that Wireshark supports it too (thanks, guys!). You can see an example of an emotional TCP connection in the snapshot below (click on the thumbnail to enlarge)...

... and download the pcap capture file by clicking here.