[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