Subject: Re: TcpAckFrequency test results
From: Frank Swarbrick (Frank.Swarbrick@efirstbank.com)
Date: Mon Aug 18 2008 - 18:40:43 EDT
I would like to get a bit more understanding at what is happening here. I have a Windows XP Pro SP2 workstation, and did the following test: - Connected from my workstation to "TCP/IP for VSE Internal FTPDAEMN 01.05 F 20080714 05.43". - Set Wireshark Network Protocol Analyzer to listen for traffic between my workstation and the VSE FTP server host. - Did a GET of a large file in ASCII mode. My observation is that Windows sends an ACK for every two TCP packets received. This is confirmed by the following statement in Microsoft Knowledge Base issue 328890: "Typically, an acknowledgment is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires. You can adjust the delayed ACK timer by editing the following registry entry." Further, MS says that with this fix: "If you set the value to 1, every packet is acknowledged immediately because there is only one outstanding TCP ACK as a segment is just received. The value of 0 (zero) is not valid and is treated as the default, 2. The only time the ACK number is 0 is when a segment is not received and the host is not going to acknowledge the data." My confusion is that Jeff Barnard states "My Linux systems do not have this problem and have higher transfer rates too." My understanding is that delayed ACKs are common on most (all?) TCP/IP platforms. So I am puzzled as to why this Windows option is necessary. And in fact, I don't understand why it is causing the issue it appears to be causing. First, here is my understanding of how a delayed ACK works. Delayed ACK: This says that a receiver should delay sending an ack for a short period of time in anticipation of the receiver's application generating a response. If the receiver's application generates a response quickly enough then the ACK can be piggybacked on the response. In other words, instead of the receiver doing ACK followed almost immediately by ACK with data, it will just send ACK with data. In a 'sink stream' (I just made up that name) protocol such as FTP where there is only the TCP level ack, with no application level ACK, I don't see why a delayed ACK would cause problems (as longer as the sender TCP is not waiting for the ACK!). It sends the ack for both packets as soon as it receives a second packet, even if the receiving application has no data to send. It is my understanding the the BSI stack does not have this wait, other than perhaps some implementation of the Nagle Algorithm (see below). So why is this delayed ACK causing a problem? The sender should just keep sending, not caring about acks. It should only stop sending of the receiver has closed down the receive window. Nagle says: If new data is to be sent and there is still unacknowledged data on this connection, hold off sending the data until either 1) there is now enough data to fill an entire segment (MSS), or 2) we receive the ACK of the previously sent data. Here's an interesting page that talks about an issue with Delayed ACKs and Nagle: http://www.stuartcheshire.org/papers/NagleDelayedAck/ This example is for a "request/response" protocol, however, in that the sender waits for the receiving application to send an application level response and not just the TCP level ack. I don't believe(!) that FTP should suffer from this. So what am I missing? Why does this fix to Windows "solve" this issue, and why is it apparently not an issue at all on Linux? Frank
This archive was generated by hypermail 2b25 : Fri Sep 05 2008 - 22:05:07 EDT