Re: [aqm] TCP ACK Suppression

["Bless, Roland (TM)" <[e-mail]>]

Hi,

Am 07.10.2015 um 17:57 schrieb Richard Scheffenegger:
> [as individual]
> 
> Hi Mikael,
> 
> ACK thinning will interfere with the ACK clock of the sender; a good
> recipie to require much more buffering at the bottlneck hop of that
> session (since the sender will start bursting out TCP data packets at
> it's line rate, rather than the bottleneck link rate).

Yes, however, if I understood Mikael correctly, the 100 ACKs are waiting
to be transmitted anyway, so the cable modem link isn't able to provide
feedback at a higher rate, i.e., there is a choice of getting 100 ACKs
transmitted as burst (lets say an ACK train) or a single ACK for the
same amount of data. The effect for congestion control is probably the
same (sender sends out a burst) if the link is the only bottleneck and
the single ACK will not  get lost (i.e., you are throwing away lots of
redundancy that may help in case of packet loss affecting the ACK.

> So, if your goal is to have the sender send out TCP data segments at the
> bottleneck rate, you'd not want to ACK too many segments at once...

Since the cable modem link will lead to clumped ACKs the difference
between sending 100 ACKs vs. 1 ACK is probably not that big...
(except w.r.t. reliability).

> Of course, the drawback is your observation, that TCP (over Ethernet)
> typically requires 64 bytes of ACK per 2x 1448 bytes, or about 1:45
> uplink/downlink bandwidth).
> 
> Others have already pointed out some relevant RFCs in this thread too...

Regards,
 Roland