[Cerowrt-devel] smart queue management conflict

[Cerowrt-devel] smart queue management conflict

[Dave Taht]

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 “Smart
Queue” Management"  (
https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/
)

It's not trademarked but, well, read the paper for some insight into lte-think.


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

Re: [Cerowrt-devel] smart queue management conflict

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]


I know I am seen as too outspoken on these things, but this paper was frank nonsense! I mean, starting from the idea that sensor and actuator devices use a small bit rate averaged over a 24 hour period means that they should be assigned a "narrowband channel" (which would be fine if real sensors are Constant Bit Rate sources that required isochronous bit-level synchronization with extremely narrow jitter bounds.
 
But real sensors and actuators in real machine-to-machine automation systems in real life are not AT ALL like that.
 
In fact many such sensors and actuators are cheap video sources with pattern recognition on them (these cost < $7 in quantiy 1 today with fully encrypted WiFi connectivity supporting both IPv4 and IPv6).
 
So, as they say, WTF are these LTE affiliated researchers smoking?
 
The whole revolution of "packet networking" (from the very beginning) was not about creating "sessions" that have nailed-up constant bit rates.
 
Let'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?
 
And then there's the term "end-to-end queue management". What that seems to mean is that the "call" is tracked at every intermediate multiplexing/switching point in the network, fully allocating "reliable bits".
 
And QoS?  I know, in telephony circles (LTE) QoS is measured by the number retransmissions of individual bits, and the whole point is never to drop any bit once it is transmitted from the source, so the source doesn't need to remember the bit so it can be retransmitted upon the receiver's request.
 
They do still teach this concept of communications in engineering schools. In fact, you can still occasionally observe it in electrical engineering classes on topics that arose before the ARPANET was invented. And I know that many of these engineers infect the telephony profession, where hopefully they get promoted into management roles before they actually encounter packet switching.
 
But really! It's been more than 4 decades since this whole set of concepts investigated in the paper become obsolescent. Even ATM is dead with its "circuit-like" use of packets that aren't end-to-end acknowledged.
 
I have long suspected that IETF has got itself infected by this nonsense antiquarian view of communications.
 
Note: service quality (properly redefined for packet switching networks with freedom to use arbitrary redundant paths, and without pre-allocation) is important. But when most engineers use QoS, they are talking about a meaningless issue around creating a near-isochronous path that does not ever retransmit any bit once it enters the physical network "owned" by a single company (or oligopoy) from end-to-end.
 
Please 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.
 
On Monday, March 22, 2021 1:28am, "Dave Taht" <dave.taht@gmail.com> said:



> 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 “Smart
> Queue” Management" (
> https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/
> )
> 
> It's not trademarked but, well, read the paper for some insight into lte-think.
> 
> 
> --
> "For a successful technology, reality must take precedence over public
> relations, for Mother Nature cannot be fooled" - Richard Feynman
> 
> dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 

[-- Attachment #2: Type: text/html, Size: 7086 bytes --]

Re: [Cerowrt-devel] smart queue management conflict

[Valdis Klētnieks]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Mon, 22 Mar 2021 20:50:50 -0400, "David P. Reed" said:
> Let'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?

You turn on almost any media, and get to see ads for Ring doorbells and other
IoT things that don't report to a smart-home-hub on the local home network, but
to someplace where corporate interests can monetize the data. So yes, the
researchers honestly think that's a sustainable model.

I'm still trying to figure out how the <expletive> you monetize data from a
Roomba, unless they're looking at the coverage patterns and using them to
figure out how big your residence is and how much furniture you have, and using
that to estimate income and/or need for new/more furniture...


[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]