<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I didn't study the whole report, but I didn't notice any metrics
associated with *variance* of latency or bandwidth. It's common for
vendors to play games ("Lies, damn lies, and statistics!") to make
their metrics look good. A metric of latency that says something
like "99% less than N milliseconds" doesn't necessarily translate
into an acceptable user performance.<br>
<br>
It's also important to look at the specific techniques used for
taking measurements. For example, if a measurement is performed
every fifteen minutes, extrapolating the metric as representative of
all the time between measurements can also lead to a metric
judgement which doesn't reflect the reality of what the user
actually experiences.<br>
<br>
In addition, there's a lot of mechanism between the ISPs' handling
of datagrams and the end-user. The users' experience is affected
by how all of that mechanism interacts as underlying network
behavior changes. When a TCP running in some host decides it needs
to retransmit, or an interactive audio/video session discards
datagrams because they arrive too late to be useful, the user sees
unacceptable performance even though the network operators may think
everything is running fine. Measurements from the end-users'
perspective might indicate performance is quite different from what
measurements at the ISP level suggest.<br>
<br>
Gamers are especially sensitive to variance, but it will also apply
to interactive uses such as might occur in telemedicine or remote
operations. A few years ago I helped a friend do some tests for a
gaming situation and we discovered that the average latency was
reasonably low, but occasionally, perhaps a few times per hour,
latency would increase to 10s of seconds. <br>
<br>
In a game, that often means the player loses. In a remote surgery
it may mean horrendous outcomes. As more functionality is performed
"in the cloud" such situations will become increasingly common.<br>
<br>
Jack Haverty<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/26/24 12:02, rjmcmahon via Nnagain
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3d808d9df1a6929ecfba495e75b4fc1b@rjmcmahon.com">Thanks
for sharing this. I'm trying to find out what are the key metrics
that will be used for this monitoring. I want to make sure iperf 2
can cover the technical, traffic related ones that make sense to a
skilled network operator, including a WiFi BSS manager. I didn't
read all 327 pages though, from what I did read, I didn't see
anything obvious. I assume these types of KPIs may be in reference
docs or something.
<br>
<br>
Thanks in advance for any help on this.
<br>
Bob
<br>
<blockquote type="cite">And...
<br>
<br>
Our bufferbloat.net submittal was cited multiple times! Thank
you all
<br>
for participating in that process!
<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.fcc.gov/public/attachments/DOC-400675A1.pdf">https://docs.fcc.gov/public/attachments/DOC-400675A1.pdf</a>
<br>
<br>
It is a long read, and does still start off on the wrong feet
(IMHO),
<br>
in particular not understanding the difference between idle and
<br>
working latency.
<br>
<br>
It is my hope that by widening awareness of more of the real
problems
<br>
with latency under load to policymakers and other submitters
<br>
downstream from this new FCC document, and more reading what we
had to
<br>
say, that we will begin to make serious progress towards finally
<br>
fixing bufferbloat in the USA.
<br>
<br>
I do keep hoping that somewhere along the way in the future, the
costs
<br>
of IPv4 address exhaustion and the IPv6 transition, will also
get
<br>
raised to the national level. [1]
<br>
<br>
We are still collecting signatures for what the bufferbloat
project
<br>
members wrote, and have 1200 bucks in the kitty for further
articles
<br>
and/or publicity. Thoughts appreciated as to where we can go
next with
<br>
shifting the national debate about bandwidth in a better
direction!
<br>
Next up would be trying to get a meeting, and to do an ex-parte
<br>
filing, I think, and I wish we could do a live demonstration on
<br>
television about it as good as feynman did here:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=raMmRKGkGD4">https://www.youtube.com/watch?v=raMmRKGkGD4</a>
<br>
<br>
Our original posting is here:
<br>
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit">https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit</a>
<br>
<br>
Larry's wonderful post is here:
<br>
<a class="moz-txt-link-freetext" href="https://circleid.com/posts/20231211-its-the-latency-fcc">https://circleid.com/posts/20231211-its-the-latency-fcc</a>
<br>
<br>
[1] How can we get more talking about IPv4 and IPv6, too? Will
we have
<br>
to wait another year?
<br>
<br>
<a class="moz-txt-link-freetext" href="https://hackaday.com/2024/02/14/floss-weekly-episode-769-10-more-internet/">https://hackaday.com/2024/02/14/floss-weekly-episode-769-10-more-internet/</a>
<br>
<br>
--
<br>
<a class="moz-txt-link-freetext" href="https://blog.cerowrt.org/post/2024_predictions/">https://blog.cerowrt.org/post/2024_predictions/</a>
<br>
Dave Täht CSO, LibreQos
<br>
</blockquote>
_______________________________________________
<br>
Nnagain mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Nnagain@lists.bufferbloat.net">Nnagain@lists.bufferbloat.net</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/nnagain">https://lists.bufferbloat.net/listinfo/nnagain</a>
<br>
</blockquote>
<br>
</body>
</html>