I am trying to determine if the Delayed ACK timer starts at the receipt of a packet or is started at boot up of PC. I am reading TCP/IP Illustrated vol1 & 2 and reading Microsoft artilces, books by Joesph Davies and RFCs and currently not sure how Delayed ACK really works. TCP/IP Illustrated explains that the 200ms timer is 'started' at PC boot up, when a packet arrives requiring an ACK the a 'flag' is set, when the timer reaches zero a ACK will be sent. So depending on when the data packet arrives the ACK could be sent anywhere from 200 - 0ms. But of course this is old information so not sure if still correct. Microsoft seems to say that the Delayed ACK timer is set/started at 200ms when a packet arrives with data therefore needing an ACK and ACK would be sent if timer reaches zero, if the other options are not met. I think only one can be true or would it depend on implementation? Cheers Jim

Whatever I know about Delayed ACK You are correct , the Delayed ACK timer starts at the receipt of a packet. In a TCP Connection , when a TCP peer receives a TCP segment, the acknowledgment of the segment is not sent immediately. The sending of the ACK can be delayed by the peer. There may be reasons for that There may be a possibility that a single ACK can be used to acknowledge the receipt of multiple TCP segments. Or if the TCP is doing a general connection maintenance then also the ACK can be delayed.