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

Detlef Bosau detlef.bosau at web.de
Sun Feb 4 11:04:37 PST 2007


Hi Lachlan,

Lachlan Andrew wrote:
>
> Because ACKs are cumulative, we don't know that separate ACKs were
> sent for each packet.
>

it is interesting to see that this discussion goes into the direction 
"we have no mechanism to do so" or "we have a mechanism to do so".

I think we have two issues here:
1. Is ACK drop an indicator for something? One contributor in this 
thread wrote something like: yes it is, but it´s not yet clear for what.
2. If ACK drops indicate anything, how can we detect them?

However, for my own work the discussion turned into a different 
direction. At the moment, I´m working on a ACK pacing / ACK spacing 
approach. And there it is in fact a problem that ACKs are cumulative. 
When we do ACK spacing / spacing and our ACK packets are nicely spaced 
on their travel to a TCP sender, this helps nothing when there are  
large gaps in the ACK flow, i.e. although there is a number of 
consecutive ACK packets which acknowledge one MSS worth of data each - 
and then the next ACK packet acknowledges 100*MSS worth of data in one 
step. This would result in a large bunch of data sent by the TCP sender 
and most likely in congestion drops.

In addition, ACK pacing or spacing respectiveley has to consider the 
rate of the ACK _numbers_ and not only the ACK packets without taking
into account which sequence numbers are acknowledged. Otherwise an ACK 
pacing / spacing algorithm could be easily undermined by
ACK drops.

Basically, this is the rationale I was looking for :-)

I found two drafts particularly helpful on that one:

@misc{spacingdraft,
        author = "C.~Partridge",
        title = "{ACK} Spacing for High Delay-Bandwidth Paths
                 with Insufficient Buffering",
        year = "1997",
        month = "July",
        howpublished = "IRTF End to End Research Group  Draft"
}
 
and

http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-00d.txt

(many thanks to Sally for mailing this link to me).


Detlef






More information about the end2end-interest mailing list