Network Neutrality is back! Let´s make the technical aspects heard this time!
 help / color / mirror / Atom feed
From: Jack Haverty <jack@3kitty.org>
To: nnagain@lists.bufferbloat.net
Subject: [NNagain] Internet Education for Non-technorati?
Date: Wed, 11 Oct 2023 10:31:03 -0700	[thread overview]
Message-ID: <cabb8f4c-c397-4853-b949-31c1b2800be6@3kitty.org> (raw)

A few days ago I made some comments about the idea of "educating" the 
lawyers, politicians, and other smart, but not necessarily technically 
adept, decision makers.  Today I saw a news story about a recent FCC 
action, to mandate "nutrition labels" on Internet services offered by ISPs:

https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/

This struck me as anecdotal, but a good example of the need for 
education.  Although it's tempting and natural to look at existing 
infrastructures as models for regulating a new one, IMHO the Internet 
does not work like the Food/Agriculture infrastructure does.

For example, the new mandates require ISPs to "label" their products 
with "nutritional" data including "typical" latency, upload, and 
download speeds.   They have until April 2024 to figure it out. I've 
never encountered an ISP who could answer such questions - even the ones 
I was involved in managing.  Marketing can of course create an answer, 
since "typical" is such a vague term.  Figuring out how to attach the 
physical label to their service product may be a problem.

Such labels may not be very helpful to the end user struggling to find 
an ISP that delivers the service needed for some interactive use (audio 
or video conferencing, gaming, home automation, etc.)

Performance on the Internet depends on where the two endpoints are, the 
physical path to get from one to the other, as well as the hardware, 
software, current load, and other aspects of each endpoint, all outside 
the ISPs' control or vision.   Since the two endpoints can be on 
different ISPs, perhaps requiring one or more additional internediate 
ISPs, specifying a "typical" performance from all Points A to all Points 
B is even more challenging.

Switching to the transportation analogy, one might ask your local bus or 
rail company what their typical time is to get from one city to 
another.   If the two cities involved happen to be on their rail or bus 
network, perhaps you can get an answer, but it will still depend on 
where the two endpoints are.  If one or both cities are not on their 
rail network, the travel time might have to include use of other 
"networks" - bus, rental car, airplane, ship, etc.   How long does it 
typically take for you to get from any city on the planet to any other 
city on the planet?

IMHO, rules and regulations for the Internet need to reflect how the 
Internet actually works.  That's why I suggested a focus on education 
for the decision makers.

Jack Haverty


             reply	other threads:[~2023-10-11 17:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11 17:31 Jack Haverty [this message]
2023-10-11 17:38 ` David Bray, PhD
2023-10-11 18:06   ` Dave Taht
2023-10-11 18:18     ` rjmcmahon
2023-10-11 18:35       ` Dick Roy
2023-10-11 18:49         ` rjmcmahon
2023-10-11 20:42           ` Dick Roy
2023-10-11 20:59           ` Sebastian Moeller
2023-10-11 18:19     ` David Bray, PhD
2023-10-11 18:23       ` David Bray, PhD
2023-10-11 20:49     ` Sebastian Moeller
2023-10-11 19:23   ` David Lang
2023-10-11 20:06     ` rjmcmahon
2023-10-11 22:58       ` David Lang
2023-10-12 15:55         ` Robert McMahon
2023-10-12 16:04           ` rjmcmahon
2023-10-12 16:49             ` David Lang
2023-10-12 17:30             ` Dave Taht
2023-10-12 18:17               ` rjmcmahon
2023-10-12 20:14                 ` David Lang
2023-10-13  4:31                   ` rjmcmahon
2023-10-13  8:34                     ` David Lang
2023-10-13 15:55                       ` Robert McMahon
2023-10-13  8:38                     ` Sebastian Moeller
2023-10-13 17:35                       ` rjmcmahon
2023-10-13  6:35           ` Sebastian Moeller
2023-10-13 17:20             ` rjmcmahon
2023-10-14 10:41               ` Sebastian Moeller
2023-10-14 19:59                 ` rjmcmahon
2023-10-19  0:40                   ` David Lang
2023-10-19  2:02                     ` Robert McMahon
2023-10-19  2:05                       ` David Lang
2023-10-19  2:12                         ` Robert McMahon
2023-10-19  2:25                           ` David Lang
2023-10-19  3:13                             ` rjmcmahon
2023-10-11 20:42 ` Sebastian Moeller
2023-10-12 19:52 ` Hal Murray
2023-10-13 18:47   ` Jack Haverty
2023-10-13 20:50     ` rjmcmahon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cabb8f4c-c397-4853-b949-31c1b2800be6@3kitty.org \
    --to=jack@3kitty.org \
    --cc=nnagain@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox