[Bloat] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Stuart Cheshire]

On 20 Oct 2022, at 02:36, Sebastian Moeller <moeller0 at gmx.de> wrote:

> Hi Stuart,
> 
> [SM] That seems to be somewhat optimistic. We have been there before, short of mandating actually-working oracle schedulers on all end-points, intermediate hops will see queues some more and some less transient. So we can strive to minimize queue build-up sure, but can not avoid queues and long queues completely so we need methods to deal with them gracefully.
> Also not many applications are actually helped all that much by letting information get stale in their own buffers as compared to an on-path queue. Think an on-line reaction-time gated game, the need is to distribute current world state to all participating clients ASAP.

I’m afraid you are wrong about this. If an on-line game wants low delay, the only answer is for it to avoid generating position updates faster than the network carry them. One packet giving the current game player position is better than a backlog of ten previous stale ones waiting to go out. Sending packets faster than the network can carry them does not get them to the destination faster; it gets them there slower. The same applies to frames in a screen sharing application. Sending the current state of the screen *now* is better than having a backlog of ten previous stale frames sitting in buffers somewhere on their way to the destination. Stale data is not inevitable. Applications don’t need to have stale data if they avoid generating stale data in the first place.

Please watch this video, which explains it better than I can in a written email:

<https://developer.apple.com/videos/play/wwdc2015/719/?time=892>

Stuart Cheshire