From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E424D3B2A4 for ; Mon, 24 May 2021 17:13:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61C4538A2A; Mon, 24 May 2021 17:23:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A1T-SChQH6oW; Mon, 24 May 2021 17:23:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ED94838A20; Mon, 24 May 2021 17:23:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A78B483A; Mon, 24 May 2021 17:13:40 -0400 (EDT) From: Michael Richardson To: Jonathan Morton , "Livingood\, Jason" , "bloat\@lists.bufferbloat.net" In-Reply-To: <9CDBF19A-C131-4497-9456-285343F93787@gmail.com> References: <8CA408F6-C8FA-4AAF-908A-B52BDC5030FF@cable.comcast.com> <9CDBF19A-C131-4497-9456-285343F93787@gmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] AQM & Net Neutrality 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: Mon, 24 May 2021 21:13:42 -0000 --=-=-= Content-Type: text/plain Jonathan Morton wrote: > I'm pleased to help with education in this area. The short and > simplistic answer would be that AQM treats all traffic going through it > equally; the non-interactive traffic *also* sees a reduction in > latency; though many people won't viscerally notice this, they can > observe it if they look closely. More importantly, it's not necessary > for traffic to make any sort of business or authentication arrangement > in order to benefit from AQM, only comply with existing, > well-established specifications as they already do. > If the traffic supports ECN, the AQM can use that instead of packet > drops for signalling, which tends to actually *reduce* packet loss in > bulk transfers, compared to simply bouncing off the tail end of a dumb > FIFO. Reduced latency would already make recovering from these losses > easier for the transport, but eliminating them entirely means that the > application receives a completely smooth delivery, with no sudden > pauses and jumps caused by the recovery process. So it seems that it be fair to say that by reducing the latency, and finding a more reasonable bandwidth*delay value, the AQM allows non-interactive traffic to make do with less buffering. This improves memory utilitization on the receiver (the viewer), but perhaps more importantly, might it also improve memory ultilization on the sender by allowing sent data to be purged faster. Could this reduce the cost of OTT streaming services? Maybe the savings is insignificant for a small service, but could it be substantial for larger services? (there is a media spin to avoid here) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCsFwQACgkQgItw+93Q 3WXZCAf/Xb3QQQrvjGDQrK67R3TBL0tm72FezcmBi7ICKFftdyGz2NMKgEyIT22D ri38HRVxhJM7+ufEQHMOtbnWBwxDwngg6+k9pbOQ0M3as4LBaXcTBLX/K/UK0HOw WSksq8wrnAnf5usnQ2OzgKxPGoBXVrLzfuO3oDuvILn6Ymkeohz/41r7xLrshh93 OTJTGlQCC8ItVlj8GikCN79Y407aQciZeEhnbXDAzo7SVS4jZK+YY9J0FIkc6eHq IXxMHtRPhDyk69UkBYO3ywwzYnWL6XVFJs2UBC78f/TFFVWP2y+XaV9nRVxRG+Et YV40WpsTFNOKrN2r9XzBUCz1VGne/w== =/sg0 -----END PGP SIGNATURE----- --=-=-=--