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

[Jon Crowcroft]

its clear we should devise a schmee for disguising data packets as acks
a they'd 
1/ advance the  congestion window and so on
2/ get highrer priority than data packets

otoh, how do we do this - compression, perhaps? how well would VJ's compressed
tcp./ip headers scale over multiple hops? intersting to thin kabout sratge
recovery ( a la  nat state recovery) too...

also, what would happen if this was typical behaviour? virtual circuit IP?
MPLS on IP? who knows?
In missive <aa7d2c6d0701291418xf8f715eu447b669ae977160b at mail.gmail.com>, "Lachlan Andrew" 
typed:

 >>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 don=B4t do so with missing ACKs.
 >>>
 >>> If a TCP packet is dropped, this is reckognized as congestion
 >>> indication. Shouldn=B4t 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
 >>
 >>--=20
 >>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
 >>

 cheers

   jon