From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mail.toke.dk (Postfix) with ESMTPS id 04DF9A4D6C7 for ; Thu, 11 Jan 2024 20:26:20 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; secure) header.d=gmx.de header.i=moeller0@gmx.de header.a=rsa-sha256 header.s=s31663417 header.b=ShoyXerd DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1705001179; x=1705605979; i=moeller0@gmx.de; bh=Wpvm2BSL64Zm/AGFn9DLGyR1XKLa0OxU6UdCGhoKK6s=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=ShoyXerdJ//hsjYdaxVZvk0ACUEcz+XcuWR/wLLkmVl+O9iKkT8pHFXs5buHre7+ vVs2k2c0VX8ZZ+EwXkOiZSpfJMuxAVFmTPFXOX+MKqKcZk7UlCM9dFjhUCYUOTBzV zjePLKND12dEijknYDoF0UhSZ1eCb9CnKOYIQH2yJYfAu8ETQFdI0BabRbmyYZumb i9CfttGK2zwNVOt1uJT86dt14BOhfsNl+0FFjQJj4/bMfiCzPv3ERzASoRpbyIC6W A2DGZGy+hH29grDOhyIJhrqXWboXcIHx8G5tP0Tylr6WoA3jMtUZZZdh2FZ8LwPsr I/e9WLBHIAR3KcFu3Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.1.171.156]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4zAs-1qyooQ3oTk-010xcE; Thu, 11 Jan 2024 20:26:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 11 Jan 2024 20:26:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35C07AA3-5C67-44F7-91EB-58AF0FB33725@gmx.de> References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:YdpO8eG9tWuH9VgfmpxPl/wj5Vcd7iERj/Q8jN3G90v0mC0waDp XZdb5ju/mP4QgdBAyHKpv1TkVbM22BAHLunAnBbPj22WmgjGiqLBvqoOHjGa2PaQawkmZ/1 V4Sql6yhYFZIvRIoUah7PVDQ0K/uQFMFIs0ZU1/UdJTEb1NhDEEYrzBplOAtG2v4sr9SBXa jnngkuT3WXGyosuZ3uOaA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:kXSRFnqZrIA=;TCU5PXup8U840Wp2t1PQuUr9YfQ TU3mjJa2reX3Z3wArYSkyBsUgMeiAUoy5TAZ1PqBVW4YvoPptVqS3t7mmnMzRwrKUCAdEtwOK 78c+5f7NOf//QIyVgRTwAFQ7t/s3IoawyiLar5ooHelg0cUQOncu1xogEq9hgoWt+VFrTRyvV Q9pAeYfiIXc8BOc4dHRzPYlSt+ZvXOS2eA7tz+9vSdS1zjQV/dZIh2AexQo7UHWP7P29GHiKs cQQkIGJ0QRUQ5FOtw1JYsA+GQKlKQr7RELtGQdGaESgxuYXDNAM1AKA9xsmBFGnW0m+S9/u6+ G9C4WcwS8bf4c83mULNQpDdKBBdAUj72wmIb0YPdSceMiIc7pPp/7TpYR2xTjCVG1YReisUe6 g5iv0W80DcNcnwl64u3+aEKPVy3TKzhqmIONxixnwZoe2EK4lJOyDVbQfMx8iFrWfIR9OvntP rqLF8ROmuJmMblkA2JuZS8C6jqzL1noiq7ZaHjPeTLViy3zSEl+qZdqeOJL0sb8Vb0IKkMFGx BgN83NVWgWByuIIcRtuUfYy6lHMa+5WN4ZBIu70oSVwi7ZlzKUZ3rwti9ZhwNRpLajRYl9pBL 7adbEQZBCDspGhumDpC6/aOy4orlShsHIOHJKLSrzRG4nBZ6mUCbrh2CXbSdTAHFegP3N0KBV MvyyltsPm7d7UAtangEEpsgI8cEWDaHJ7lcyX2B3wn7jeJYlaCqeDd9OfxSHr5gXXf24JsN/1 z4Z0rNHjO0sxzv0BADShJpUl4Pq06SFlfEU+1jGsPUG/NlKWcFkEtDPGgqJLYiPktNwkUfkM5 OZd111mXeVUwQslAV8Q/ahrs4Dc2xyV+L0i8gk/OEk5/j6MhnPlOa1S7/kz3EXp6sKzZMakD7 Dc42kOluahd6BjwLt4yK8RRdoez+1w16kgIOKqBNFFXmSE3e9aF60bv3O6DRC2pG7E0gqDo9Q p3y+Hw== X-MailFrom: moeller0@gmx.de X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: EREMLYAAYUSKXEOMB7LWOGPMTFU5OIBE X-Message-ID-Hash: EREMLYAAYUSKXEOMB7LWOGPMTFU5OIBE X-Mailman-Approved-At: Thu, 11 Jan 2024 21:17:11 +0100 CC: galene@lists.galene.org, bloat , Rpm X-Mailman-Version: 3.3.9 Precedence: list Subject: [Galene] Re: [Rpm] very good article on webrtc bandwidth estimation List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Dave, > On Jan 11, 2024, at 14:53, Dave Taht via Rpm = wrote: >=20 > This was quite excellent, and did go into a delay based controller a = bit. >=20 > https://www.meetecho.com/blog/bwe-janus/ Yes, excellent article. I noted that the GCC draft contained = this though: The loss-based controller SHOULD run every time feedback from the receiver is received. o If 2-10% of the packets have been lost since the previous report from the receiver, the sender available bandwidth estimate As_hat(i) will be kept unchanged. o If more than 10% of the packets have been lost a new estimate is calculated as As_hat(i) =3D As_hat(i-1)(1-0.5p), where p is the = loss ratio. o As long as less than 2% of the packets have been lost As_hat(i) will be increased as As_hat(i) =3D 1.05(As_hat(i-1)) The loss-based estimate As_hat is compared with the delay-based estimate A_hat. The actual sending rate is set as the minimum between As_hat and A_hat. We motivate the packet loss thresholds by noting that if the transmission channel has a small amount of packet loss due to over- use, that amount will soon increase if the sender does not adjust his bitrate. Therefore we will soon enough reach above the 10% threshold and adjust As_hat(i). However, if the packet loss ratio does not increase, the losses are probably not related to self-inflicted congestion and therefore we should not react on them. Without even a hint of source where in the world 10% random = (non-congestive) packet loss is "normal". (The justification given for = the 10% would just works as badly for any other number < 100%...) Just having had ~0.8% random loss on a link, I am unhappy to report that = single flow tcp throughput was visibly affected (as expected from the = Mathis equation). Taking 2% packet loss as an indicator that one should increase the = sending rate, IMHO should be backed by data, and preferably tons of = it... as should the recommendation to simply soldier on with loss in the = range of 2-10%.... I am not saying there might not be a rational = argument to be made for those values, but that draft certainly did not = make those arguments... Side question: when I do MTRs to DNS servers I typically get 0% random = packet loss, is there any study what level of non-congestive packet loss = is typical for different parts of the internet? >=20 > --=20 > 40 years of net history, a couple songs: > https://www.youtube.com/watch?v=3DD9RGX6QFm5E > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm