<font face="arial" size="2"><p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">But I understand it might be painful to hear my critique of the diffserv design process.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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).</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Hence my concern that diffserv's fundamental misunderstanding of the responsibility of router queue management might contaminate a very, very important project.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">On Saturday, July 25, 2020 1:54pm, "Kevin Darbyshire-Bryant" <kevin@darbyshire-bryant.me.uk> said:<br /><br /></p>
<div id="SafeStyles1595704947">
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">> I didn’t sign up for this abuse. Bellhead eh? Well f**k off!<br />> <br />> I’ve had enough - bye.<br />> <br />> > On 25 Jul 2020, at 18:48, David P. Reed <dpreed@deepplum.com> wrote:<br />> ><br />> > This idea (dividing the link rate capacity, since "bandwidth" is an incorrect<br />> term not to be promulgated), is absurd, but typical of "bellhead" thinking.<br />> ><br />> > Per packet latency is the key control variable, even for TCP. That's because<br />> capacity/rate is not controllable by routers, but by routing in a general Internet<br />> situation.<br />> ><br />> > Latency is controlled by queuing delay in a packet network, not bitrate. And<br />> in mixed traffic, which after all is why traffic is classified in the first place,<br />> by its characteristics and response to increased latency end-to-end, is the core<br />> "control" for the internetwork as a whole.<br />> ><br />> > So, by promoting thinking about "bandwidth" a whole sequence of<br />> misformulations of network management is embedded into the thinking of those<br />> designing queue management algorithms.<br />> ><br />> > And make no mistake, queue management is the ONLY knob other than sending<br />> different packets on different routes that one has for routers.<br />> ><br />> > I don't know who proposed this fractional division, but it is clearly a<br />> bellhead-influenced thinker who thinks all protocols are CBR flows like in the old<br />> phone system.<br />> ><br />> > But almost no flows in the internet are CBR flows! File transfers are not,<br />> streaming TV is not, web ttraffic is not, game traffic is not. Only<br />> non-statistically multiplexed real-time telephony and *some* video conferencing is<br />> CBR.<br />> ><br />> > Yet this bizarre idea of dividing "bandwidth" among all categories of flows<br />> pops up. Probably from employees of phone companies or phone equipment suppliers.<br />> Or folks who went to Uni and were trained in "communications" by former phone<br />> engineers.<br />> ><br />> > Latency, latency, latency. Queue delay, queue delay, queue delay. Not link<br />> speed! Change your brains.<br />> ><br />> > It's hard fo fight this bellhead crowd (or the bellheadedness in your own<br />> thinking) but think about packets and queues instead.<br />> ><br />> > My good friend Len Kleinrock didn't invent "Bandwidth Theory"! He invented<br />> Queueing Theory. For a reason.<br />> ><br />> > On Saturday, July 25, 2020 6:12am, "Kevin Darbyshire-Bryant"<br />> <kevin@darbyshire-bryant.me.uk> said:<br />> ><br />> > > _______________________________________________<br />> > > Cake mailing list<br />> > > Cake@lists.bufferbloat.net<br />> > > https://lists.bufferbloat.net/listinfo/cake<br />> > ><br />> > ><br />> > > > On 24 Jul 2020, at 18:42, Kevin Darbyshire-Bryant<br />> > > <kevin@darbyshire-bryant.me.uk> wrote:<br />> > > ><br />> > > ><br />> > > > The move from diffserv4 to diffserv5 WAS about de-prioritization.<br />> > ><br />> > > It was also about minimum bandwidth allocations:<br />> > ><br />> > > LE: 1/64th<br />> > > BK: 1/16th<br />> > > BE: 1/1<br />> > > VI: 1/2<br />> > > VO: 1/4<br />> > ><br />> > > So worst case, best effort should get 11/64ths in the extreme case of<br />> all other<br />> > > tins in use.<br />> > ><br />> > > Cheers,<br />> > ><br />> > > Kevin D-B<br />> > ><br />> > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A<br />> > ><br />> > ><br />> <br />> <br />> Cheers,<br />> <br />> Kevin D-B<br />> <br />> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A<br />> <br />> </p>
</div></font>