From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 BAEA93B29E for ; Sat, 25 Jul 2020 16:04:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595707481; bh=whp0CG/kDYz/GOWQyBhNfRwyOagvXektSUkMhTe1wwc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=bc6zKsMtxRjeh8+ftHmdd13SlTgwF2Eul06lcInpKBwnCWcBU4M63KJgOjX3VnzA0 jVlhCT40WiGcDIv9lKJftBfEplYQZJ8N4z4sRqgaL1po9DkoLK9Ws6hghF7Qry6kht ZX19ApOGR/uWyQExl2A/nARK/dt9DOahx6psnyf0= 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 1MHoRK-1k3IZ5144s-00Eygl; Sat, 25 Jul 2020 22:04:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1595705720.093911757@apps.rackspace.com> Date: Sat, 25 Jul 2020 22:04:40 +0200 Cc: Kevin Darbyshire-Bryant , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <1E226B08-B076-4FD5-8DDB-73903F9B86F8@gmx.de> References: <0CCA78BD-201C-4668-A013-24A3F6F4EC87@darbyshire-bryant.me.uk> <1595699283.358416190@apps.rackspace.com> <94003145-2031-454F-8F76-38C153DDFA08@darbyshire-bryant.me.uk> <1595705720.093911757@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:AX2I866xUOKjiA54GL9znWFo0IsZeCKpX0Cl8jQu6pYqFgIweHZ +MKc/RboHrrCS8DtC+eJR3TaooQJCBPYecB7ub1xoKQePDtj6Mcy+SMVJTmo+jNyV+eIV4H 3ikvy4s68m1IpsIBn5zUS52utkHqG9jwdRj4tgfu3ARX4l4NiACYoZuyfAmoJuXqig2uJHQ bzaG1jZ+W05Wh2tz6pkjg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CNO/tpFeGao=:wHxe+/ZziskVfnJGWFjFmn and2UKw1OtoTwpCKvMZ2Wmg2v21rEdst45qOXnNxr4S04W8s9Ns+QDKMjZRsWNgFeGrdmVaqb alzyEHD2x/SDIV7G7ZSdid467v+CNh8lDYe8jBvLuA7ZbUqOAeV7bcfEkFXMAjYVrZJ/y/o7a TUslsrsZbkM1nlAbJQafc8+IZ9O/qZJowVO6wsQWFXYUgkB0C0OvZ94dxiXEYo8BD99OjGZLl 2LBldW3OIcfvJ6qWOhHlbeidGWW0EG/zf9BsHzqcxiwRFDCG13ONqq3vR7DOPsMf3pfJ1ekwg YiFopYk6IhdQ6440UVPn5sB2JAXUibXy1M3det89BGXlpviarJvmYz5Le8K8Ii+z7sPzpts1I pF6+5dYXeL8FjO6PicGzObode6EZew9c/kDzt5lYDDu4ntgYrkE6U5zx+/DT1cmoPVF1Me36e /FQlPBbtknkoY4NgHBl+rzaKZPQ03G1FJ3b7UoxfzAXU+o3xJyoesU+7M7hdmC41CnmZ/wEVC RtGiG2rEJnC5qpJNEMcTPrG5V6RkToPkS/CZctyRunzyoN1FojiHKsm+pQHrLKseZ5mlZtukT ylz+vfOjZ2bGhsygY3SoX3Dn+rLdzEPcOSNsU2EWDOO+Zd5ygAsIPHW4hQ1eIChf3dH9hXjC5 M+lCcbnHUoPB3ufKyuWP/TCjgRsfMNwLKRVFqPbPogV+2VfnFYwEFMGEG8/0gWYknbeoAN34d TaMx1Lq+WJM2V2rbkgdCh5nOzaPz18XpfI9WnwVF5xvOD3qxZRLgbrT+Ws7oZEnFeDPtV7qrp g7Bcd9tiZF+OCyFvuG0DuyzPqrM7EsQMSs3Ji1JnAPliT8Ej3jG7hvRyJtoQsOijv/sDrIOcL 5NpX0OrF/ckYplVwK+YkIj3M5jYFrIp+dg6TD2abFXKdLlYrSVyLxzCguCz4du46rut6vLuvX GlhE8NDJB5pd0v8RQHtogm5/Wkf30jGc4dQqxYlUoLq//UpGEXJiOxkOIi+/IbPCT151pBHH4 SVET5oTMSFh+bk/X9Vdsvqg7qFhrxwb+Ffz1hhOgtyE0/RWWZkRHkD51+kdWlLn8c2zuhQNII YMF4AF+0tCxMMY2qWddJz4hUycSdu9HFNmK1lkRmvpO/Xxe+ljY0+0LgUazpYUVXJTchyizbC LgyhVaq23uRzk20Y3p13RGge4CJWOWQ/jCgR/dbMNpNi9wmZMhuqnWXc6mgK07v2+E+i5Um6S TN4jub+sNEIFjUVZo 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 20:04:46 -0000 Hi David, I believe that folks here, certainly Kevin, have accepted the domain = specificity of diffserv and we are mainly discussion, how many tiers of = differential latency tolerance we desire ;). It goes without saying that = this is all within the "home domain", and the goal is how little/few = priority games we need to play for decent performance under load. Sure, = end2end signaling would be desirable, but as you point out does not = exist in diffserve today and is also not very likely to appear anytime = soon, but in one's home it is still relatively easy to identify a few = special cases, like bit-torrent (don't get in the way of "real" traffic) = or VoIP (quite latency and especially jitter averse, but also typically = of modest rate) that could/should be taken care of.=20 As far as I can tell that is all the cake/sqm's diffserve modes = try to accomplish. DSCPs are simply used, as there exists machinery for = routers/end-hosts OS to selectively set/re-set them and all IP packets = will carry them.=20 Regarding the Bell-haededness, sure I might qualify for that = moniker/abuse*, but the relevant factor, IMHO, is not so much the exact = rate cut-offs of the different priority tiers, but the simple = realization that low latency via prioritization requires relatively low = rates, otherwise "priority" traffic will self congest, so these = thresholds serve to establish a "cost" for using each priority tier.=20 Best Regards Sebastian *) By virtue of intellectual laziness, it is simply often easier for me = to think in rate shares than the alternatives. But hey, I do this as a = hobby, so I cut myself a lot of slack here ;) But I take no offense in = being labeled that. > On Jul 25, 2020, at 21:35, David P. Reed wrote: >=20 > I want to apologize for any implication that you, Mr. = Darbyshire-Bryant, were a "bellhead". AFAIK, you were quoting a staement = from the designers of diffserv4, who apparently still believe in = bandwidth division as a metric. > =20 > But I understand it might be painful to hear my critique of the = diffserv design process. > =20 > Just be aware that it's my problem, not yours. I don't mean to offend = you. I do, however, feel like the folks who did "design" diffserv (and = continue to promote it) completely miss the whole point of why the = Internet is architected the way it is. And since they haven't managed to = respond to a clue-by-4 yet, I'm tired of just pointing out that the idea = doesn't actually achieve any benefits, because no one (literally no one) = has evern done a consistent assignment of end-to-end meaning to the = various diffserv labels after decades of failed testing. > =20 > Since this is a group discussion, and not just a response to you, my = comment was aimed at the general group (which is not dedicated to = bellhead thinking, thank goodness). > =20 > And to be clear, AQM (cake, being an example) is not about bandwidth = allocation. It does focus on latency/queueing-delay, for the most part. > =20 > Hence my concern that diffserv's fundamental misunderstanding of the = responsibility of router queue management might contaminate a very, very = important project. > =20 > =20 > On Saturday, July 25, 2020 1:54pm, "Kevin Darbyshire-Bryant" = said: >=20 > > I didn=E2=80=99t sign up for this abuse. Bellhead eh? Well f**k off! > >=20 > > I=E2=80=99ve had enough - bye. > >=20 > > > On 25 Jul 2020, at 18:48, David P. Reed = wrote: > > > > > > This idea (dividing the link rate capacity, since "bandwidth" is = an incorrect > > term not to be promulgated), is absurd, but typical of "bellhead" = thinking. > > > > > > Per packet latency is the key control variable, even for TCP. = That's because > > capacity/rate is not controllable by routers, but by routing in a = general Internet > > situation. > > > > > > Latency is controlled by queuing delay in a packet network, not = bitrate. And > > in mixed traffic, which after all is why traffic is classified in = the first place, > > by its characteristics and response to increased latency end-to-end, = is the core > > "control" for the internetwork as a whole. > > > > > > So, by promoting thinking about "bandwidth" a whole sequence of > > misformulations of network management is embedded into the thinking = of those > > designing queue management algorithms. > > > > > > And make no mistake, queue management is the ONLY knob other than = sending > > different packets on different routes that one has for routers. > > > > > > I don't know who proposed this fractional division, but it is = clearly a > > bellhead-influenced thinker who thinks all protocols are CBR flows = like in the old > > phone system. > > > > > > But almost no flows in the internet are CBR flows! File transfers = are not, > > streaming TV is not, web ttraffic is not, game traffic is not. Only > > non-statistically multiplexed real-time telephony and *some* video = conferencing is > > CBR. > > > > > > Yet this bizarre idea of dividing "bandwidth" among all categories = of flows > > pops up. Probably from employees of phone companies or phone = equipment suppliers. > > Or folks who went to Uni and were trained in "communications" by = former phone > > engineers. > > > > > > Latency, latency, latency. Queue delay, queue delay, queue delay. = Not link > > speed! Change your brains. > > > > > > It's hard fo fight this bellhead crowd (or the bellheadedness in = your own > > thinking) but think about packets and queues instead. > > > > > > My good friend Len Kleinrock didn't invent "Bandwidth Theory"! He = invented > > Queueing Theory. For a reason. > > > > > > On Saturday, July 25, 2020 6:12am, "Kevin Darbyshire-Bryant" > > said: > > > > > > > _______________________________________________ > > > > Cake mailing list > > > > Cake@lists.bufferbloat.net > > > > https://lists.bufferbloat.net/listinfo/cake > > > > > > > > > > > > > On 24 Jul 2020, at 18:42, Kevin Darbyshire-Bryant > > > > wrote: > > > > > > > > > > > > > > > The move from diffserv4 to diffserv5 WAS about = de-prioritization. > > > > > > > > It was also about minimum bandwidth allocations: > > > > > > > > LE: 1/64th > > > > BK: 1/16th > > > > BE: 1/1 > > > > VI: 1/2 > > > > VO: 1/4 > > > > > > > > So worst case, best effort should get 11/64ths in the extreme = case of > > all other > > > > tins in use. > > > > > > > > Cheers, > > > > > > > > Kevin D-B > > > > > > > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A > > > > > > > > > >=20 > >=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