From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp115.iad3a.emailsrvr.com (smtp115.iad3a.emailsrvr.com [173.203.187.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C09A93B29E for ; Mon, 22 Mar 2021 20:50:50 -0400 (EDT) Received: from app54.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 56D7B2237D; Mon, 22 Mar 2021 20:50:50 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app54.wa-webapps.iad3a (Postfix) with ESMTP id 43DD3E18CB; Mon, 22 Mar 2021 20:50:50 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 22 Mar 2021 20:50:50 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 22 Mar 2021 20:50:50 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: mykola.i.beshlei@lpnu.ua, m.seliuchenko@gmail.com, halink@ukr.net, elhadi.shakshuki@acadiau.ca, ansar.yasar@uhasselt.be, natalia.kryvinska@univie.ac.at, "cerowrt-devel" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210322205050000000_97083" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.10.161 Message-ID: <1616460650.275121342@apps.rackspace.com> X-Mailer: webmail/18.1.23-RC X-Classification-ID: d26f7a8e-4920-4f3e-a924-d78c4908a024-1-1 Subject: Re: [Cerowrt-devel] smart queue management conflict X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 00:50:50 -0000 ------=_20210322205050000000_97083 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI know I am seen as too outspoken on these things, but this paper was fr= ank nonsense! I mean, starting from the idea that sensor and actuator devic= es use a small bit rate averaged over a 24 hour period means that they shou= ld be assigned a "narrowband channel" (which would be fine if real sensors = are Constant Bit Rate sources that required isochronous bit-level synchroni= zation with extremely narrow jitter bounds.=0A =0ABut real sensors and actu= ators in real machine-to-machine automation systems in real life are not AT= ALL like that.=0A =0AIn fact many such sensors and actuators are cheap vid= eo sources with pattern recognition on them (these cost < $7 in quantiy 1 t= oday with fully encrypted WiFi connectivity supporting both IPv4 and IPv6).= =0A =0ASo, as they say, WTF are these LTE affiliated researchers smoking?= =0A =0AThe whole revolution of "packet networking" (from the very beginning= ) was not about creating "sessions" that have nailed-up constant bit rates.= =0A =0ALet's say I have a sensor on my dog's collar, or on a fork lift in a= warehouse? Do these researchers honestly think that each sensor will make = a *phone call* over the LTE fabric and continue that phone call for all the= time the device is powered on? Is the cost going to be proportional to the= delivered bit-rate? In "message units" for each 3 minutes of call time?=0A= =0AAnd then there's the term "end-to-end queue management". What that seem= s to mean is that the "call" is tracked at every intermediate multiplexing/= switching point in the network, fully allocating "reliable bits".=0A =0AAnd= QoS? I know, in telephony circles (LTE) QoS is measured by the number ret= ransmissions of individual bits, and the whole point is never to drop any b= it once it is transmitted from the source, so the source doesn't need to re= member the bit so it can be retransmitted upon the receiver's request.=0A = =0AThey do still teach this concept of communications in engineering school= s. In fact, you can still occasionally observe it in electrical engineering= classes on topics that arose before the ARPANET was invented. And I know t= hat many of these engineers infect the telephony profession, where hopefull= y they get promoted into management roles before they actually encounter pa= cket switching.=0A =0ABut really! It's been more than 4 decades since this = whole set of concepts investigated in the paper become obsolescent. Even AT= M is dead with its "circuit-like" use of packets that aren't end-to-end ack= nowledged.=0A =0AI have long suspected that IETF has got itself infected by= this nonsense antiquarian view of communications.=0A =0ANote: service qual= ity (properly redefined for packet switching networks with freedom to use a= rbitrary redundant paths, and without pre-allocation) is important. But whe= n most engineers use QoS, they are talking about a meaningless issue around= creating a near-isochronous path that does not ever retransmit any bit onc= e it enters the physical network "owned" by a single company (or oligopoy) = from end-to-end.=0A =0APlease let us hope that IoT (whatever it is in fact)= isn't being defined by the community that thinks this paper is working on = an interesting problem.=0A =0AOn Monday, March 22, 2021 1:28am, "Dave Taht"= said:=0A=0A=0A=0A> see: https://www.mdpi.com/1424-82= 20/20/8/2324=0A> =0A> I do kind of wish the authors hadn't overloaded our t= erm "smart queue=0A> management" (SQM) with their interpretation in "End-to= -End QoS =E2=80=9CSmart=0A> Queue=E2=80=9D Management" (=0A> https://www.bu= fferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/=0A> )=0A> =0A> = It's not trademarked but, well, read the paper for some insight into lte-th= ink.=0A> =0A> =0A> --=0A> "For a successful technology, reality must take p= recedence over public=0A> relations, for Mother Nature cannot be fooled" - = Richard Feynman=0A> =0A> dave@taht.net CTO, TekLibre, LLC = Tel: 1-831-435-0729=0A> _______________________________________________=0A>= Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> htt= ps://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20210322205050000000_97083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I know I am seen as to= o outspoken on these things, but this paper was frank nonsense! I mean, sta= rting from the idea that sensor and actuator devices use a small bit rate a= veraged over a 24 hour period means that they should be assigned a "narrowb= and channel" (which would be fine if real sensors are Constant Bit Rate sou= rces that required isochronous bit-level synchronization with extremely nar= row jitter bounds.

=0A

 

=0A

But real sensors and actuators in real machine-to-machine automation s= ystems in real life are not AT ALL like that.

=0A

&n= bsp;

=0A

In fact many such sensors and actuators are= cheap video sources with pattern recognition on them (these cost < $7 i= n quantiy 1 today with fully encrypted WiFi connectivity supporting both IP= v4 and IPv6).

=0A

 

=0A

= So, as they say, WTF are these LTE affiliated researchers smoking?

=0A 

=0A

The whole revolution o= f "packet networking" (from the very beginning) was not about creating "ses= sions" that have nailed-up constant bit rates.

=0A

&= nbsp;

=0A

Let's say I have a sensor on my dog's coll= ar, or on a fork lift in a warehouse? Do these researchers honestly think t= hat each sensor will make a *phone call* over the LTE fabric and continue t= hat phone call for all the time the device is powered on? Is the cost going= to be proportional to the delivered bit-rate? In "message units" for each = 3 minutes of call time?

=0A

 

=0A

And then there's the term "end-to-end queue management". What tha= t seems to mean is that the "call" is tracked at every intermediate multipl= exing/switching point in the network, fully allocating "reliable bits".

= =0A

 

=0A

And QoS?  I = know, in telephony circles (LTE) QoS is measured by the number retransmissi= ons of individual bits, and the whole point is never to drop any bit once i= t is transmitted from the source, so the source doesn't need to remember th= e bit so it can be retransmitted upon the receiver's request.

=0A

 

=0A

They do still teach this co= ncept of communications in engineering schools. In fact, you can still occa= sionally observe it in electrical engineering classes on topics that arose = before the ARPANET was invented. And I know that many of these engineers in= fect the telephony profession, where hopefully they get promoted into manag= ement roles before they actually encounter packet switching.

=0A

 

=0A

But really! It's been more t= han 4 decades since this whole set of concepts investigated in the paper be= come obsolescent. Even ATM is dead with its "circuit-like" use of packets t= hat aren't end-to-end acknowledged.

=0A

 

= =0A

I have long suspected that IETF has got itself infe= cted by this nonsense antiquarian view of communications.

=0A

 

=0A

Note: service quality (properly= redefined for packet switching networks with freedom to use arbitrary redu= ndant paths, and without pre-allocation) is important. But when most engine= ers use QoS, they are talking about a meaningless issue around creating a n= ear-isochronous path that does not ever retransmit any bit once it enters t= he physical network "owned" by a single company (or oligopoy) from end-to-e= nd.

=0A

 

=0A

Please let= us hope that IoT (whatever it is in fact) isn't being defined by the commu= nity that thinks this paper is working on an interesting problem.

=0A

 

=0A

On Monday, March 22, 20= 21 1:28am, "Dave Taht" <dave.taht@gmail.com> said:

=0A=
=0A

> see: https://= www.mdpi.com/1424-8220/20/8/2324
>
> I do kind of wish the= authors hadn't overloaded our term "smart queue
> management" (SQM= ) with their interpretation in "End-to-End QoS =E2=80=9CSmart
> Que= ue=E2=80=9D Management" (
> https://www.bufferbloat.net/projects/ce= rowrt/wiki/Smart_Queue_Management/
> )
>
> It's no= t trademarked but, well, read the paper for some insight into lte-think.>
>
> --
> "For a successful technology, re= ality must take precedence over public
> relations, for Mother Natu= re cannot be fooled" - Richard Feynman
>
> dave@taht.net &= lt;Dave T=C3=A4ht> CTO, TekLibre, LLC Tel: 1-831-435-0729
> ____= ___________________________________________
> Cerowrt-devel mailing= list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists= .bufferbloat.net/listinfo/cerowrt-devel
>

=0A
------=_20210322205050000000_97083--