[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?

Lloyd Wood L.Wood at surrey.ac.uk
Wed Jan 31 14:41:00 PST 2007

At Wednesday 31/01/2007 16:02 -0500, Sushant Rewaskar wrote:
>I agree with Lachlan. In TCP there is no way to know when an ack is lost as
>it carries no "sequence number" of its own. 

It can - timestamps are used for disambiguation, and they disambiguate the acks. They can act as unique sequence numbers.

(In fact, you wouldn't naively issue a timestamp, and expect the other end to copy and reflect it in an ack, as that's open to a variety of DoS attacks. The sender would have a table of timestamp times, with unique keys for each timestamp, and the sender would send out and look for the key in the timestamp option field. To get a better understanding of these issues you may want to read RFC1323.)

It's possible for the sender to infer that an ack has been lost, based on subsequent receiver behaviour in sending a cumulative ack including packets received that the sender didn't get individual acks for.

Stupid question: why is a missing ack presumed to automatically be due to congestion, rather than link errors along the path?


>(so in fact not only it is not
>done but it cannot be easily done in the current set-up). 
>To get a better understanding of these issues you may want to read the
>string of papers and RFC on Datagram Congestion Control Protocol (DCCP)
>(http://www.read.cs.ucla.edu/dccp/ )  
>Take care,
>Sushant Rewaskar
>UNC Chapel Hill
>-----Original Message-----
>From: end2end-interest-bounces at postel.org
>[mailto:end2end-interest-bounces at postel.org] On Behalf Of Lachlan Andrew
>Sent: Monday, January 29, 2007 5:18 PM
>To: Detlef Bosau
>Cc: end2end-interest at postel.org
>Subject: Re: [e2e] Stupid Question: Why are missing ACKs not considered
>asindicator for congestion?
>Greetings Detlef,
>On 29/01/07, Detlef Bosau <detlef.bosau at web.de> wrote:
>> In TCP, lost / dropped packets are recognised as congestion indicator.
>> We don4t do so with missing ACKs.
>> If a TCP packet is dropped, this is reckognized as congestion
>> indication. Shouldn4t be a dropped ACK packet seen as congestion
>> indication as well?
>Because ACKs are cumulative, we don't know that separate ACKs were
>sent for each packet.
>For example, high-end NICs typically have "interrupt coalescence",
>which delivers a large bunch of packets simultaneously to reduce CPU
>overhead.  A single "fat ACK" is sent which cumulatively acknowledges
>all of these packets.  This happens even when the receiver is not
>Another factor is that ACKs are typically small compared with data
>packets.  The total network throughput is much greater if we throttle
>only the sources contributing most to a given link's congestion,
>namely those sending full data packets over the link.
>Lachlan Andrew  Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

More information about the end2end-interest mailing list