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

[Douglas Leith]

Perhaps I can add my own question to this.   The discussion so far  
has mostly centered on whether its possible to detect ack losses.   
But say we could measure these ack congestion/losses - what would the  
right thing be to do ?  Should we  treat loss of any packet (ack or  
data) as congestion, or just consider loss of data packets as being  
meangingful ?

This isn't  as abstract a question as it might at first seem.  Most  
delay-based algorithms use two-way delay and so react to queueing of  
acks as well as data packets.  That is, unlike loss based algorithms  
they *do* treat ack and data packets in similar ways for congestion  
control purposes.  Is this a good thing or not ?

Doug


On 4 Feb 2007, at 20:00, end2end-interest-request at postel.org wrote:

> Send end2end-interest mailing list submissions to
> 	end2end-interest at postel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.postel.org/mailman/listinfo/end2end-interest
> or, via email, send a message with subject or body 'help' to
> 	end2end-interest-request at postel.org
>
> You can reach the person managing the list at
> 	end2end-interest-owner at postel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of end2end-interest digest..."
>
>
> Today's Topics:
>
>    1. Re: Stupid Question: Why are missing ACKs not considered as
>       indicator for congestion? (Detlef Bosau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 04 Feb 2007 20:04:37 +0100
> From: Detlef Bosau <detlef.bosau at web.de>
> Subject: Re: [e2e] Stupid Question: Why are missing ACKs not
> 	considered as indicator for congestion?
> To: end2end-interest at postel.org
> Cc: l.andrew at ieee.org
> Message-ID: <45C62E45.4050607 at web.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> end2end-interest mailing list
> end2end-interest at postel.org
> http://mailman.postel.org/mailman/listinfo/end2end-interest
>
>
> End of end2end-interest Digest, Vol 36, Issue 5
> ***********************************************