From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4F7853B29E for ; Sat, 25 Jul 2020 13:18:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595697529; bh=xSHc8dDnLeYJkEw7ycfw8IJ+SSFvcUriHHsg97tYALA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jB33zTHjsIjx7aafNputPZ44xDEoIj1eaCK+QwoMuk751cj2K1YDpZ67tUDH+Vedg ORLSEM2KOGDEDDaHz7wHndRQ4taQCiuyND287pF89UL2sr2Hjyvuox5Hj2siMT4ED/ zPoU9/EdNYFI2akd3vf4lA0vg2cJjL3RiSe2CFOI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.42.229] ([77.6.52.50]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MXGvG-1kIXkl12Uw-00Ygxg; Sat, 25 Jul 2020 19:18:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Sebastian Moeller In-Reply-To: <0CCA78BD-201C-4668-A013-24A3F6F4EC87@darbyshire-bryant.me.uk> Date: Sat, 25 Jul 2020 19:18:48 +0200 Cc: Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <4E86E73D-2ACE-4952-8A2A-B8DAAD4CD262@gmx.de> References: <0CCA78BD-201C-4668-A013-24A3F6F4EC87@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:X1HVBjebDBMyUh86TjVgBf7KCa8sU/SyDqvB1gbFpqkm57NIouu G1Llqs5F7DoiRkXIVngU4sfc3vAoiU137eHRpHY0Zmyc6liXx5Me/Hs4/mhlf3MWXtm5lOx HqjmfCxYJ9GjvAVSu/Vw4EQGgx+VuatTyRd5I9V1UTJBuYLfQU2RpNiNwK2+Ds70cFkbt65 2GqOMTPos5kXpF0u+whqg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:FkZ/qo6IYk0=:qQzKVZddGiXX8yfOy0ni4f 3E1VSGkr2UGwRPGhgEv0c43DN2fjd0k0S4MOMBWYG1p0gbTXytUV1RpL9a0YCabdNzNKWccW3 VsJJxaY3+7BJoObNZgdGMya5OlRd3HmxqW2IJxQr/b/zVVNDepNba6rSybLMHaVBhESAXbor0 Ae0dAYquigY1JTG5K3fqN8ff9eE3V5IoDoYYAD63QLUa6f8noMfg92I1lQNqTw5abPiR+FYza 7gNygrgi5nfGV3BBBnYC6uRbXe4m//xcvTKrf4eU2nAtvO5XzeT4WXO4zSgF84sFO6f1NIJoy a2GMZHyxZT9Vd5aTTB/d2grCKKBLUUyS9nNgrRemEtv5V7IxRcHDvOyTkyPItY90gH2kL6oQN uJT0kaunwz7uWNvAedSQzIAW973Nl6rcGxIIv0BrbDfj1WBOG92U5AvXBNTLTa0KZdquypkV8 a2RCGEscLSs+L1ctOyrgLWRGaTTx10Hp5BcfVyMJw4FOWIrUfjQhGBC3xuR0qfCp4mzj+skGg bRrdXA0LT+VqhURhN+VSH/NRwyUm4cMGobYoevd/13K4JmG6Y7Ox7UtPBOjy1su/d1AqZNAUA sThrZqrXCEKrB+/ar78o03QxHLw8pBmbg9cpy3xZBdcvn/Pv3rH6eLYmPm+hbYJcULOA5LRvO Se+4uJ3wvq4SrAMzNXQrD/QZ9O7YRRyL1IWTKUuKwhjXoccix53ygGu10t0wPSvXswQ1vfQUC Wbl+aQ+Lnm/3V/uGX3Mc7hkKjPb+61jjRgRsqZ/LJ3WJEliknGgI2x655QAiC0H6JQeBqEvK/ ICkz5Q/wfoKXtYK8o1AdOodK/0fC16Q+d6rIgfcsQ+S3EVyS+4Ocfp8wDWyyfj3Jr8seIj+Qx TI3mUwLQThFPLQbEdaOOv0vdY24UJF7ydKE2qYIQ6BBdQlfajrKJsRgznJI5UsCKpIj1tKu6h 8LoSuVFQ4GxRAvUsYA64PVx0EuJjPTgGSM78rmjKo1KxwqfeVHy/9nyNQYm9gTlypTu+MxsWR tCFfhdOgp3DRiJRUaMQ0q7SScl6s6acugPiVPFPGBPv4kV9U4xRw4LqtOUNnHOQiR5ulI8kvB 94AJUbiKVmk1jnr1cPKvVs+TeX9mzSgwSNqpLTftG2Gd7EkmzV0uOIztOslR9D0VTrL1SUpVQ T+LGdH6b1oeXZN1J5jkN0JJVD/By2laW3kiG6c5mf4JeNgH+MLGJ2sc2yiwC0bYuHcL2lDPfs nz4qeuWO+Lh4ZbiqY Subject: Re: [Cake] diffserv3 vs diffserv4 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 17:18:51 -0000 Hi Kevin, > On Jul 25, 2020, at 12:12, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 24 Jul 2020, at 18:42, Kevin Darbyshire-Bryant = wrote: >>=20 >>=20 >> The move from diffserv4 to diffserv5 WAS about de-prioritization. >=20 > It was also about minimum bandwidth allocations: >=20 > LE: 1/64th That is 6 binary orders of magnitude, on a slow link, LE is effectively = starved and there will be no real forward progress. For real scavenger = services this might well be a sane policy, but this requires the very = selective with assigning flows to this tin ;) > BK: 1/16th > BE: 1/1 > VI: 1/2 > VO: 1/4 So I see 1/64 + 1/16 + 1/1 + 1/2 + 1/4 =3D 1.828125 which seems = excessive for actually guaranteed minimums. I was under the naive? = impression the minima should add up to <=3D 1, no? >=20 > So worst case, best effort should get 11/64ths in the extreme case of = all other tins in use. This seems only true, if on overload the lowest prioritiers = tiers get their allotment first, no? I am confused... but I am also confused by cake's output: " Bulk Best Effort Voice thresh 3062Kbit 49Mbit 12250Kbit" as far as I can tell, Bulk's 3062Kbit must be the minimum, while BE and = Voice give their maxima... That, or I am missing something important... (I wonder whether it would not be clearer to give both min and max for = each tin, then again I probably missing all the deyails of the actual = implementation...) Best Regards Sebastian >=20 > Cheers, >=20 > Kevin D-B >=20 > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake