From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.rno.apple.com [17.179.253.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9FD293B2A4; Thu, 20 Oct 2022 14:32:51 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 29KIVflN027749; Thu, 20 Oct 2022 11:32:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=+c3wio5KyAAYGT8bhG1cs2rCo3Uo97Og8CFePr9njR4=; b=cPeCbcTc1w7KO2jDjWn/H24/v0i7d/Sgm1W1WECR6ZrRNLK6tU/eYzjsuP0mQmyswPsq sZOyg0EfkoT2JKa0PRws4gCT7NTzA3Lzi45gz/+P/wcgDAm+jlikNoe22oOdCXzbfJBc 59Qc/oPTSU06P0JS5EYxzfb9GXy9ZZHANMEO3KjxBC3uw5+iyiwPGdbkgHhx0Dbw9zpb kuhhOjovZiqeNvQ7fnoiFODGpUJsdAiyNLj7YvoOKHHW1+objtPwfPPnncBtNKpmBNku VV0jIDc4wD+00jY3uCKXnxCCme9FxNvg1Q79tuEcCE3V7eYMWHvXYKL/PPGJhWHvf5MO YA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3k8380gtus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 20 Oct 2022 11:32:47 -0700 Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RK200DWWE6NKI70@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 20 Oct 2022 11:32:47 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RK200Z00DMFUE00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Thu, 20 Oct 2022 11:32:47 -0700 (PDT) X-Va-A: X-Va-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-Va-E-CD: 05fe825c938c59b2f2fa3a8ec45389e8 X-Va-R-CD: 8d771ce1c9635e4f9e230061af075a72 X-Va-CD: 0 X-Va-ID: 889a81a7-7c0d-4732-9dfb-f7a5c05e2a19 X-V-A: X-V-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-V-E-CD: 05fe825c938c59b2f2fa3a8ec45389e8 X-V-R-CD: 8d771ce1c9635e4f9e230061af075a72 X-V-CD: 0 X-V-ID: ccb140f1-72fe-4562-89c2-f2b4cabe82a0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545, 18.0.895 definitions=2022-10-20_09:2022-10-20, 2022-10-20 signatures=0 Received: from [17.11.114.31] (unknown [17.11.114.31]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RK200J9DE6M9N00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Thu, 20 Oct 2022 11:32:47 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Stuart Cheshire In-reply-to: <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> Date: Thu, 20 Oct 2022 11:32:46 -0700 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Rpm , Make-Wifi-fast , Cake List , bloat Content-transfer-encoding: quoted-printable Message-id: <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545, 18.0.895 definitions=2022-10-20_09:2022-10-20, 2022-10-20 signatures=0 Subject: Re: [Bloat] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2022 18:32:51 -0000 On 20 Oct 2022, at 02:36, Sebastian Moeller wrote: > Hi Stuart, >=20 > [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=E2=80=99m 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=E2=80=99t 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: Stuart Cheshire