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

[David P. Reed]

What standard puts timestamps in each TCP packet?  What standard says 
that they can be viewed as meaningful by a receiver?  Or is this TCP as 
it might have been but isn't?  Timestamps are options in IP, but options 
in IP are not used by TCP that I know of as information bearing elements 
- they aren't even guaranteed to be preserved end-to-end (they are not 
part of the "virtual header" that is end-to-end checksummed).

Lloyd Wood wrote:
> At Wednesday 31/01/2007 16:02 -0500, Sushant Rewaskar wrote:
>   
>> Hi,
>> 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?
>
> L.
>
>
>
>
>   
>> (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
>> www.cs.unc.edu/~rewaskar 
>>
>>
>> -----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
>> congested.
>>
>>
>> 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.
>>
>> Cheers,
>> Lachlan
>>
>> -- 
>> 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
>>     
>
>
>