Re: [LibreQoS] Ack-filtering

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

I just busted a guy laughing at your annotations. Tahhnk you.

There's been a long "misery metrics" thread elsewhere, about how measuring
customer satisfaction was more important than packet loss or bandwidth or
the other statistics we so often try to interpret.

Over here, for example, was this bug:
https://github.com/rchac/LibreQoS/issues/126#issuecomment-1286061009

where the OP applied a change that "saved cpu", but in-observably hurt the
customer experience, until a few days went by,
and they "felt" the change for themselves, and complaints had gone up.

Proactively engaging with users to ask how their subjective experience has
got better or worse, after making a change, is one way to get feedback.
Others include eating your own dogfood, and active measurements like the
flent tests, crusader,
etc.

The ack-filter, should, in general, speed up slow start, which is a good
thing in a fully FQ'd and codeled environement.
It also accelerates additive increase, same benefits.

Downsides include that the TCPs on the other side have to interpolate more.

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]