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

Dave Taht dave.taht at gmail.com
Thu Oct 20 15:33:09 EDT 2022


On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire <cheshire at apple.com> wrote:
>
> 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.

The core  of what you describe is that transports and applications are
evolving towards being delay aware, which is the primary outcome you
get from  FQ'd environment, be the FQs are physical (VoQs, LAGs,
multiple channels or subcarriers in wireless technologies) or virtual
(fq-codel, cake, fq-pie), so that the only source of congestion is
self-harm.

Everything from BBR to googles' gcc for videoconferencing, to recent
work on swift ( https://research.google/pubs/pub49448/ ) seems to be
pointing this way.

I'm also loving the work on reliable FQ detection for QUIC.
> 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
>


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC


More information about the Cake mailing list