From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 108203B2A4; Thu, 20 Oct 2022 15:33:49 -0400 (EDT) Received: by mail-wr1-x433.google.com with SMTP id f11so658927wrm.6; Thu, 20 Oct 2022 12:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jEU3Ym6fBjwApps2r3we0HnKYwBgNuNUoH67T0QGILI=; b=Vn3x1lD2QQoQ8h7DcHsmIUMpG0bmr7KYLaXBQ9CkPc4q5GTzB3mzkgoz2rPwSCs++4 ahWzCTrkhL2OriUmPAyaWA9DcqT+Q3ttfZvQVKkplTbtoSLz5d/6nMUGX5VeR11zg2bi QOdMDE2Kd0VYD7TGm1ya412ZjOEUrrgebvw1muv4sOmhqEKMgAUkIVswVc9r2krgQc01 GJZ5viTyIuc+kOwJTmsH4J6Qm/1WRBwf9zUnISR6nEQbOU8P3D71Pr7pPqoMFGV1C0t1 kY1b7OHHItPLoZ85wJvdN12XpD4NvTcvT4PZ+lbJSZ8a+DNQn84ncuIJsqVO5BYUq3qP f+kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jEU3Ym6fBjwApps2r3we0HnKYwBgNuNUoH67T0QGILI=; b=OK8w34jYxF/z9iHK9zSGbh5NMtBVbIkTAcTze7KRZqqe6+aVlgQCI8BXyQiqYQdIGP aB3XVNUYxIgLNBXB5/h8DlUQ3S7oNuMk9aRZsAMYQ9TYnt+ogCWQz1lFUijQMnsgMABy JgwciTYgx5n7QcUHyjJyendX83EDx84DjHBMnAX8tjbaGwTk7iGB8eyoNJITtCh2282C dy4mwmQ71Xlcs0t4QLyAAQaFyB/SQCGcaJZuHOmPn5rik1SCmFyrWBXfoKkQsk5bVpXP FHFxs6z0XH6EjvtVWEwykSd5pcC5tZE3Cs2ihxaEAtCctMx4FFiHonXyoh/I/XoSXWC/ 3tVw== X-Gm-Message-State: ACrzQf3FbxQpYUfCWJKvKq+r5T9QjAq9RrML8HLDhZJPDNicndzMVpdR kdXWVm9JD9HxDB5gs3nbPnIH0UGtmaLQw4HnWn8= X-Google-Smtp-Source: AMsMyM7bwIlZWUd5wmp8hwD9g5uyMPB0e/7ZGi7bLwWH0RbHpJLhDpz5P0Qj4kMmtLIOUs4beCsxfa7LFdct3M2WbaE= X-Received: by 2002:a5d:64c3:0:b0:22e:57e7:6230 with SMTP id f3-20020a5d64c3000000b0022e57e76230mr9889071wri.482.1666294427914; Thu, 20 Oct 2022 12:33:47 -0700 (PDT) MIME-Version: 1.0 References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> In-Reply-To: <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> From: Dave Taht Date: Thu, 20 Oct 2022 12:33:09 -0700 Message-ID: To: Stuart Cheshire Cc: Sebastian Moeller , Rpm , Make-Wifi-fast , Cake List , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 19:33:49 -0000 On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire wrote= : > > On 20 Oct 2022, at 02:36, Sebastian Moeller wrote: > > > Hi Stuart, > > > > [SM] That seems to be somewhat optimistic. We have been there before, s= hort of mandating actually-working oracle schedulers on all end-points, int= ermediate 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 curr= ent 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 fast= er than the network carry them. One packet giving the current game player p= osition is better than a backlog of ten previous stale ones waiting to go o= ut. Sending packets faster than the network can carry them does not get the= m 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 s= creen *now* is better than having a backlog of ten previous stale frames si= tting in buffers somewhere on their way to the destination. Stale data is n= ot inevitable. Applications don=E2=80=99t need to have stale data if they a= void 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: > > > > Stuart Cheshire > --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC