[Bloat] Beyond Bufferbloat: End-to-End Congestion Control Cannot Avoid Latency Spikes

[Toke Høiland-Jørgensen]

Bjørn Ivar Teigen <bjorn at domos.no> writes:

> Hi everyone,
>
> I've recently published a paper on Arxiv which is relevant to the
> Bufferbloat problem. I hope it will be helpful in convincing AQM doubters.
> Discussions at the recent IAB workshop inspired me to write a detailed
> argument for why end-to-end methods cannot avoid latency spikes. I couldn't
> find this argument in the literature.
>
> Here is the Arxiv link: https://arxiv.org/abs/2111.00488

I found this a very approachable paper expressing a phenomenon that
should be no surprise to anyone on this list: when flow rate drops,
latency spikes.

> A direct consequence is that we need AQMs at all points in the internet
> where congestion is likely to happen, even for short periods, to mitigate
> the impact of latency spikes. Here I am assuming we ultimately want an
> Internet without lag-spikes, not just low latency on average.

This was something I was wondering when reading your paper. How will
AQMs help? When the rate drops the AQM may be able to react faster, but
it won't be able to affect the flow xmit rate any faster than your
theoretical "perfect" propagation time...

So in effect, your paper seems to be saying "a flow that saturates the
link cannot avoid latency spikes from self-congestion when the link rate
drops, and the only way we can avoid this interfering with *other* flows
is by using FQ"? Or?

Also, another follow-on question that might be worth looking into is
short flows: Many flows fit entirely in an IW, or at least never exit
slow start. So how does that interact with what you're describing? Is it
possible to quantify this effect?

-Toke