Why there's a TCP ACK for every second segment

[badalam_nt]

I performed a DL FTP and observed that for every second DL FTP-DATA received from the FTP server, my PC sent a TCP ACK.

FYI, Window Size was all the time 65535.

So, it means that this windows size is not taken into consideration, as my Windows PC always constantly acknowledges every second FTP-DATA received from the server.

Server -> PC: FTP_DATA: 1460bytes (SEQ=x)

Server -> PC: FTP-DATA: 1460bytes (SEQ=X+1460)

PC -> Server: TCP ACK (ACK=x+2920)

Has anyone already observed the same behaviour ?

And is there any solution/workaround for this ?

[#2]

Some servers have a broken behavior, and announce wrong window sizes for themselves. While the bandwidth delay product gives the theoretical value for the TCP window size that is not always the best value. Problems come because the OS's TCP implementation has bugs and/or the network has deficiencies. Usually try values 10% above and below the calculated TCP window size. If one of those is better, try values above and below that, repeating until the maximum bandwidth is reached. Remember there will be some variability in bandwidth due to other competing network traffic. In some cases, OS and network problems may be so bad that deliberately setting the TCP window size low will increase performance because it masks the other problems.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/tcpwslfn.html

[badalam_nt]

There is no problem with the servers.

The behaviour is related Windows XP TCP/IP stack.

See here the details from Microsoft support center:

http://support.microsoft.com/kb/328890

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 side is greater than 200ms).

Now there is a Registry entry mentioned there (which is by the way not present in the registry!!!), called TcpAckFrequency, which is by default set to 2.

I created this entry in the registry, 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 most 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.

By looking at RFC 1122 I observed that Delayed ACK feature presented there is implemented by Microsoft in accordance to what's in that RFC.

So TCP ACK after each 2nd segment apparently is according to the RFC1122.

But using a Linux OS in the client PC, the behaviour of FTP is not as in RFC1122, 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.

What's the right behaviour of a TCP session ?

If to follow RFC1122 then Windows Size is useless. 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" book of Andrew Tanenbaum.

Is this RFC superseding the other TCP mechanisms? Or it is an obsolete RFC?

I'm really puzzled.

Could anyone clarify what should be the normal/reference behavior of TCP ?