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).