Does the Delayed ACK feature make useless the TCP Window Size?
First of all I performed several FTP downloads, with Wireshark tool capturing what's going on during the FTP session. I observed that for every 2nd DL FTP-DATA received from the FTP server, my WindowsXP client sent a TCP ACK. Throughout the entire FTP session, Window Size was all the time 65535, for both the client and the server.
So, it means that this windows size is not taken into consideration, as my Windows PC constantly acknowledges every 2nd FTP-DATA received from the FTP server.
Here's an excerpt from the trace (which repeats all the time):
Server -> PC: FTP_DATA: 1460bytes (SEQ=x)
Server -> PC: FTP-DATA: 1460bytes (SEQ=x+1460)
PC -> Server: TCP ACK (ACK=x+2920)
And I read as well RFC1122, regarding the Delayed ACK feature.
There it is clearly mentioned that at least each 2nd segment is acknowledged (it may happen that also each segment to be acknowledged in case the time interval between 2 consecutive segments that arrive at the receiver's side is greater than 200ms).
This RFC apparently is contradictory to what is described in the "Computer Networks Ed4" book of Andrew Tanenbaum.
Also I searched for support on Microsoft support centre and here's what I found:
As mentioned there, there is a Registry entry (which is by the way not present in the registry!!!), called TcpAckFrequency, which is by default set to 2, explaining so what I observed during the FTP session.
Because this entry was not i the registry, I thought to create myself this entry in the registry, so I did it, then I set it to 30, restarted the PC and started a new FTP download.
I observed an unpredictable and random behaviour:
- in the first 20seconds, the PC sent TCP ACK either for each 2nd segment or for every 3rd segment. After that I observed TCP ACK for each 13 segments, for 14 segments, for 17 segments, for 18 segments, and 3 times for each 30 segments. But quite often a TCP ACK came after each 13 segments.
All the time during FTP download I observed that Windows Size was constantly set to 65535, for both parties, client and server.
I removed the entry and come back to the normal Windows XP behaviour (which is at least predictable and deterministic).
So Delayed ACK feature presented in RFC1122 is implemented by Microsoft in accordance to what's in that RFC, TCP ACK being sent normally after each 2nd segment.
But after using a Linux OS in the client PC, I observed that the behaviour of FTP is not as in RFC1122, Linux taking into consideration Windows Size. There could be seen in the trace as well the TCP slow start mechanism with that increase exponentially and then linearly of the Window Size etc.
So what's the right behaviour of a TCP session ?
If to follow RFC1122 then my understanding is that TCP Windows Size is useless. And Microsoft is inline with RFC112.
But Linux is then not inline with RFC1122. It is inline with what I expect from TCP, with Windows Size adjustments, updates, with variation in number of acknowledged segments, with slow start mechanism etc, as described in "Computer Networks Ed.4" book.
At this moment I'm really puzzled regarding what should be the normal/reference behavior of TCP.
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!