Re: [Bloat] On metrics

[dan <dandenson@gmail.com>]

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

On Mar 19, 2023 at 3:00:35 PM, rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:

> Hi All,
>
> It seems getting the metrics right is critical. Our industry can't be
> reporting things that mislead or misassign blame. The medical community
> doesn't treat people for cancer without having a high degree they've
> gotten the diagnostics correct as an example.
>
> An initial metric, per this group, would be geared towards
> responsiveness or the speed of causality. Here, we may need to include
> linear distance, the power required to achieve a responsiveness and to
> take account of Pareto efficiencies, where one device's better
> responsiveness can't make another's worse.
>
> An example per a possible FiWi new & comprehensive metric: A rating
> could be something like 10K responses per second at 1Km terrestrial
> (fiber) cable / 6m radius free space range / 5W total / 0-impact to
> others. If consumers can learn to read nutrition labels they can also
> learn to read these.
>
> Maybe a device produces a scan code qr based upon its e3e measurement
> and the scan code qr loads a page with human interpretable analysis?
> Similar to how we now pull up menus on our mobile phones listing the
> food items and the nutrition information that's available to seat at a
> table. Then, in a perfect world, there is a rating per each link hop or
> better, network jurisdiction. Each jurisdiction could decide if they
> want to participate or not, similar to connecting up an autonomous
> system or not. I think measurements of network jurisdictions without
> prior agreements are unfair. The lack of measurement capability is
> likely enough pressure needed to motivate actions.
>
> Bob
>
> PS. As a side note, and a shameless plug, iperf 2 now supports
> bounceback and a big issue has been clock sync for one way delays (OWD.)
> Per a comment from Jean Tourrhiles
> https://sourceforge.net/p/iperf2/tickets/242/ I added some unsync
> detections in the bounceback measurements. Contact me directly if your
> engineering team needs more information on iperf 2.
>

A food nutrition label is actually a great example of bad information in
consumer hands.  Since adding those, Americans weights have ballooned.  I’m
not saying they are in direct correlation, but that information has
definitely not caused an improvement in health by any measure at all.
Definitely not a model to pursue.

There needs to be a clear distinction between what’s valuable to the
consumer and what’s valuable to the ISP to improve services. These are
dramatically different pieces of data.   For the consumer, information that
directions their choice of product is important.  Details about various
points in the process are useless to them.  How many hops has no value to
them, only the latenc, jitter, throughput, and probably some rating on slow
start or other things that are part of the ISP equation but entirely for
the purpose of making better choices for their needs.  10k responses in x
seconds is meaningless to a consumer.  I have never, and I’m not
exaggerating, EVER had a home user or IT guy or point person for an MSP
ever ask about packet rates or any of the stats that keep getting brought
up.  This is a solution looking for a problem.

Consumers really need things like published performance specs so they can
assemble their needs like an a la carte menu.  What do you do, what’s
important to you, what details support that need, and they need that in a
simple way.   Like a little app that says “how many 1080p TVs or 4K TVs,
how many gaming consoles, do you take zoom calls or VoIP/phone calls.  Do
you send large emails, videos, or pictures.”

Put another way, all the specs are like telling a soccer mom the torque
curve of their minivan.

If ‘we’ the industry make a nutrition type label that has numbers on it
that are not useful in the context of a consumer decision making process in
a direct x gives you y way, it creates data that will get misinterpreted.

These stats should be made available for the providers pushing data so that
they can make sure they are meeting the human readable and useful data.  I
care about the AS path and the latency on my upstream services to various
providers, I can try to make better choices on buying lumen or hurricane
and how I will route those things because I understand how they affect the
service.  Those are really useful numbers for me and any ISP that wants to
have higher “A+ for gaming because latency and jitter are low and bandwidth
is adequate” ratings.

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