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

[Sebastian Moeller]

Hi Bob,

I think I agree, I also agree with the goal of keeping queues small to non-existent, all I am saying is that this is fine as a goal, but unrealistic as a reachable end-point. Queues in the network serve a purpose (actually multiple) and are not pure bloat. The trick is to keep the good properties while minimizing the bad. The way I put it it is:
over-sized and under0managed buffers/queues are bad, the solution is not to get rid of queues but to size them better and more importantly manage them better. Which will result in overall less queue delay, but critically not zero queue delay.

Regards
	Sebastian


> On Oct 20, 2022, at 21:04, Bob McMahon <bob.mcmahon at broadcom.com> wrote:
> 
> Intel has a good analogous video on this with their CPU video here going over branches and failed predictions. And to Stuart's point, the longer pipelines make the forks worse in the amount of in-process bytes that need to be thrown away. Interactivity, in my opinion, suggests shrinking the pipeline because, with networks, there is no quick way to throw away stale data rather every forwarding device continues forward with invalid data. That's bad for the network too, spending resources on something that's no longer valid. We in the test & measurement community never measure this.
> 
> There have been a few requests that iperf 2 measure the "bytes thrown away" per a fork (user moves a video pointer, etc.) I haven't come up with a good test yet. I'm still trying to get basic awareness about existing latency, OWD and responsiveness metrics. I do think measuring the amount of resources spent on stale data is sorta like food waste, few really pay attention to it.
> 
> Bob
> 
> FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested. 
> 
> --tcp-write-prefetch n[kmKM]
> Set TCP_NOTSENT_LOWAT on the socket and use event based writes per select() on the socket.
> 
> 
> On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire via Make-wifi-fast <make-wifi-fast at lists.bufferbloat.net> 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.
> 
> 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
> 
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> 
> This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.