SecurActive blog

I do not know if you have had the chance to notice this, but here are two tables that show you the phenomenon: a zone populated with Windows clients has got larger RTTout values than one populated with Unix based clients.

RTTout for unix based clients

RTTout for windows based clients

Principles

This may sound odd to you and look like an old “tech” discussion with regards to the better or worse performance of two kinds of operating systems… This is not the case, because this phenomenon can be explained with very clear facts.

Apparently, Microsoft has implemented the RFC 1122 in its TCP/IP stacks: one of the consequences is that some TCP acknowledgments packets will be delayed. As most of the passive measurements of RTT are based on the time interval between a packet (with a non null payload) and its acknowledgment, gross RTT measures will then look much higher than the actual network round latency.

Impact of a delayed ACK on RTT measures

What does the RFC 1122 tell about TCP acknowledgment?

The RFC recommends not to send a ACK for each TCP segment but only each second segment, provided the delay does not exceed 0,5 seconds, for efficiency reasons.

In Section 4.2.3.2 ‘When to send an ACK segment”, the RFC tells the following:

“A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a “delayed ACK” .

A TCP should implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment.

DISCUSSION:

A delayed ACK gives the application an opportunity to update the window and perhaps to send an immediate response. In particular, in the case of character-mode remote login, a delayed ACK can reduce the number of segments sent by the server by a factor of 3 (ACK, window update, and echo character all combined in one segment).

In addition, on some large multi-user hosts, a delayed ACK can substantially reduce protocol processing overhead by reducing the total number of packets to be processed. However, excessive delays on ACK’s can disturb the round-trip timing and packet “clocking” algorithms.”

For more information, please consult: http://www.faqs.org/rfcs/rfc1122.html