On 20 Oct 2022, at 02:36, Sebastian Moeller <[email protected]> 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

_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to