Does the Delayed ACK feature make useless the TCP Window Size?

5 pts.
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.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Not sure I have a complete answer but here are my thoughts.

As you indicated, delayed ACK says that instead of sending an acknowledgment for every packet received, delay the ACK and send it for every 2nd packet but don’t delay it more that 500ms.

Window size sets a limit on the amount of data that can be sent unacknowledged. This is a key distinction between the two, one specifies the number of packets while the other specifies the amount of data. In practice due to mtu limitations tcp/ip packet size will be smaller than the window size or even half the window size of the receiving station. So the delayed ACK will be sent before the number of unacknowledged packets approaches the window size. But, the window size can of course decrease which is an important signal to the transmitting station, particularly if it is reduced to zero. This behavior alone makes window size an essential part of TCP. Also, while current mtu limitations keep packets small compared to a 65535 byte window size, the maximum size of an IP datagram is also 65535 bytes. It’s likely that when writing the RFCs the authors would have to take this into consideration and would create a standard that could support much larger packet sizes than we see in application today and, at least in theory, could fill up a window size in as little as one or two packets.

So I don’t think delayed ACK makes window size useless.

Discuss This Question:  

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: