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

Fred Baker fred at cisco.com
Mon Jan 29 14:38:04 PST 2007


missing acks are indeed an indicator of something, but it may not be  
forward path congestion.

In asymmetric circuits, for example, it is often an indicator of  
reverse path congestion. eg, if I have 100 KBPS up and 1000 KBPS  
down, I might use up the 100 KBPS before I use up the 1000 KBPS. Some  
research I read a few years back suggested that in such cases it  
might be interesting to use last-in-first-out queuing on the slower  
speed path, with a view to letting the later-and-more-inclusive ack  
get through first and eat the bypassed ones later, just to keep the  
forward path going. One of the criticisms of FAST TCP is that it is  
susceptible to reverse path congestion.

and in any event, I can think of many networks in which loss is an  
indicator of nothing more than loss. Just say "radio"...

On Jan 29, 2007, at 12:48 PM, Detlef Bosau wrote:

> My apologies for this question, perhaps it´s simple:
>
> In TCP, lost / dropped packets are recognised as congestion indicator.
> We don´t do so with missing ACKs.
>
> Consider the following net:
>
>
>     (downstream:)  T T T T T T T T T
> Sender                                                            
> Receiver
>     (upstream: )      AAAAAAAAAA
>
>
> Then the flow occupies the cumulated capacity of T(CP packets) and A 
> (CK packets).
>
> If CWND grows too large (by probing) and the available path  
> capacity is exceeded, packet drop occurs.
> If a TCP packet is dropped, this is reckognized as congestion  
> indication. Shouldn´t be a dropped ACK packet seen as congestion  
> indication as well?
>
> Perhaps, this question is a bit stupid, but I don´t see the clue  
> here at the moment. Perhaps, someone could help me please?
>
> Thanks!
>
> Detlef
>
>



More information about the end2end-interest mailing list