[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