Re: [aqm] ACK Suppression

On Wed, 7 Oct 2015, dpreed@reed.com wrote:

> Date: Wed, 7 Oct 2015 15:52:18 -0400 (EDT)
> From: dpreed@reed.com
> To: aqm@ietf.org
> Subject: Re: [aqm] ACK Suppression
> 
>
> I presume this is not a serious focus of the AQM group. So maybe I'm wasting 
> my time by writing about this.
> 
> Nonetheless I am troubled by the very fact of the discussion taking place, for 
> two reasons:
> 
> 1) TCP ACKs are TCP's business only.  It's not a gateway or router's job to 
> get involved in or to understand end-to-end protocols, *even if* the router 
> thinks it knows exactly what the endpoints' goals are.  And the router cannot 
> know that for every protocol, not even the many higher level protocols on top 
> of TCP, which use TCP quite differently.  The idea that routers can be 
> omniscient, merely by looking at packets and taking the designers' personal 
> prejudices into account, seems ridiculous. TCP endpoints on both ends of a 
> connection can reduce the number of ACKs they send if they want. If ACKs are 
> filling up buffers in intermediate routers, just drop them or mark them to 
> notify that they are contributing to congestion.  The endpoints have to slow 
> down something, and they can slow down ACKs by mutual agreement.
> 
> 2) The hypothetical that there will be a sufficiently long sequence of ACKs 
> for a single end-to-end flow buffered in a single router queue may seem 
> plausible, *until it becomes clear that in the big picture, having so many 
> packets in a queue means that the network is extremely congested by that 
> point*.  In other words, in order for this "optimization" to apply, you would 
> have to operate the network at an unacceptable operating point! It's like 
> saying that when a highway has slowed to a crawl, we can load all the cars 
> going to a particular destination onto single "car carrier" to save gas. Far 
> better to insure that queues are not built up!  The purpose of queueing is to 
> absorb bursts that can't be anticipated, not to build up congestion in order 
> to have enough data to perform a dubious optimization that can best be done at 
> the source of traffic in cooperation with the destination.

Look at Wifi, you have close to 1Gb/s data rates, but it's still half-duplex. So 
while a station/AP is receiving, there can be a substantial number of ack 
packets that queue up while recieving even a 'small' bundle of data packets.

This is normal operation, not 'operate the network at an unacceptable operating 
point'

David Lang