[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?
baruch at ev-en.org
Tue Jan 30 00:01:35 PST 2007
* Detlef Bosau <detlef.bosau at web.de> [070129 23:29]:
> 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?
How would you go about detecting that an ACK was lost?
TCP packet loss is detected by receiving repeating ACKs with the same
sequence number or by packets with SACK information. ACKs might not be
for each TCP packet, delayed-acks can and are being sent all around the
net and they usually acknowledge two or more packets. Linux sometimes
takes its time and was seen to ack 7 packets per ack.
And then there is a (more important) question of why would you consider
an ACK lost to be a congestion event at all. A congestion event means
that we are pushing too much data through the link and we should slow
down, but the ACK packets normally carry no payload so the only
congestion signal should be on the direction that the payload is
flowing. Rarely the protocol has bidirectional data transfers (the
lovely days of bimodem compared to zmodem!) and then congestion is
detect on each direction independently.
There are cases of asymmetric links that might cause trouble, but that
will only serve to slow down the payload direction as well since packets
are released to the network only when acks come back, so a lost ack will
already slow down the rate of the payload, just not by cutting the cwnd
More information about the end2end-interest