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

[Lloyd Wood]

At Thursday 01/02/2007 11:17 -0500, David P. Reed wrote:
>What standard puts timestamps in each TCP packet?  

RFC1323 does not preclude including the TCP Timestamp option in each packet sent. (And there are cases where disambiguation of segments/ack would be a useful benefit from doing this. How you compute RTO given more sample information and whether that's just diminishing returns for most common use is a separate issue that is open to question.)

The TCP Timestamp option is checksummed by the TCP checksum.


>What standard says that they can be viewed as meaningful by a receiver?  

Well, gee, RFC1323 is only a proposed standard. But attackers will take any hints about internal state that they are given, and they don't pay that much attention to standards.



>Or is this TCP as it might have been but isn't?  Timestamps are options in IP, 

Is IP option 4 even used by anything?


>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
>>>    
>>
>>
>>