Re: [aqm] [tcpm] TCP ACK Suppression

[David Lang <[e-mail]>]

On Mon, 12 Oct 2015, Greg White wrote:

>> My contention is that since this is already happening, consolidating the ACK 
>> packets into stretched ACKs doesn't make this any worse, and it saves network 
>> bandwidth (and decreases latency to the extent that data is acked faster than 
>> waiting for the entire chain or original ACKs to get through, especially if 
>> that would take multiple transmit windows). As a result, thinning the ACKs is 
>> kinder to the network.
>
> I agree, *iff* they are not DupACKs signalling packet loss.  Do existing and 
> future cable modems take that subtle distinction into account?
>
> I presume that they are not discarding DupACKs or corrupting SACK in some way 
> (the whole point of specialized ACK handling is to ensure good TCP performance 
> after all), but since the algorithms are proprietary, for existing cable 
> modems I don't know.  I will contact the developers as well as run some tests 
> on a few modems to get a better idea (and maybe Mikael already has some data 
> from his recent testing he could share?).  For future modems, I can add an 
> explicit reference to RFC3449 in the DOCSIS 3.1 spec just in case implementers 
> aren't aware for some reason.

It should also say that AQM is needed on the downstream side to protect against 
transmit bursts.



The suggestion was posted early in this thread (but not in someting I can 
quickly find) that to harden the connection against the aggregate ACK being 
lost, it should be sent again in a separate transmit window.

I latched onto that and think the right thing to do is to duplicate the 
aggregate ACK that's created and put it at the beginning of the queue that 
remains after the current transmit window.

If there are more ACKs in the next transmit window, it will get aggregated into 
them and not cause any additional traffic.

If there are not any more ACKs in the next transmit window, and the first ACK 
was lost, it will replace it with the minimum of delay

If there are not any more ACKs in the next transmit window, and the first ACK 
was not lost, we are now transmitting a duplicate ACK, which may be interpreted 
as a signal to speed up tranmission (depending on the exact timing of the 
arrivials of these two ACKs). While this is not good, we already need to be 
protected from transmit bursts, so this is just another possible cause for such 
bursts.

David Lang