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: Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!
Date: Tue, 27 Feb 2024 15:17:13 -0800	[thread overview]
Message-ID: <71063fa7-ba1b-4da8-8252-73b1ff2dd29e@3kitty.org> (raw)
In-Reply-To: <69133641c96091ed047e6bf11a2ff5d7@rjmcmahon.com>


[-- Attachment #1.1.1.1: Type: text/plain, Size: 3327 bytes --]

Has any ISP or regulatory body set a standard for latency necessary to 
support interactive uses?

It seems to me that a 2+ second delay is way too high, and even if it 
happens only occasionally, users may set up their systems to assume it 
may happen and compensate for it by ading their own buffering at the 
endpoints and thereby reduce embarassing glitches. Maybe this explains 
those long awkward pauses you commonly see when TV interviewers are 
trying to have a conversation with someone at a remote site via Zoom, 
Skype, et al.

In the early Internet days we assumed there would be a need for multiple 
types of service, such as a "bulk transfer" and "interactive", similar 
to analogs in the non-electronic transport systems (e.g., Air Freight 
versus Container Ship).   The "Type Of Service" field was put in the IP 
header as a placeholder for such mechanisms to be added to networks in 
the future,

Of course if network capacity is truly unlimited there would be no need 
now to provide different types of service.   But these latency numbers 
suggest that users' traffic demands are still sometimes exceeding 
network capacities.  Some of the network traffic is associated with 
interactive uses, and other traffic is doing tasks such as backups to 
some cloud.  Treating them uniformly seems like bad engineering as well 
as bad policy.

I'm still not sure whether or not "network neutrality" regulations would 
preclude offering different types of service, if the technical 
mechanisms even implement such functionality.

Jack

On 2/27/24 14:00, rjmcmahon via Nnagain wrote:
>> Interesting blog post on the latency part at
>> https://broadbandbreakfast.com/untitled-12/.
>>
>> Looking at the FCC draft report, page 73, Figure 24 – I find it sort
>> of ridiculous that the table describes things as “Low Latency
>> Service” available or not. That is because they seem to really
>> misunderstand the notion of working latency. The table instead seems
>> to classify any network with idle latency <100 ms to be low latency
>> – which as Dave and others close to bufferbloat know is silly. Lots
>> of these networks that are in this report classified as low latency
>> would in fact have working latencies of 100s to 1,000s of milliseconds
>> – far from low latency.
>>
>> I looked at FCC MBA platform data from the last 6 months and here are
>> the latency under load stats, 99th percentile for a selection of ten
>> ISPs:
>> ISP A  2470 ms
>>
>> ISP B  2296 ms
>>
>> ISP C 2281 ms
>>
>> ISP D 2203 ms
>>
>> ISP E  2070 ms
>>
>> ISP F  1716 ms
>>
>> ISP G 1468 ms
>>
>> ISP H 965 ms
>>
>> ISP I   909 ms
>>
>> ISP J   896 ms
>>
>> Jason
>
> It does seem like there is a lot of confusion around idle latency vs 
> working latency. Another common error is to conflate round trip time 
> as two "one way delays." OWD & RTT are different metrics and both have 
> utility. (all of this, including working-loads, is supported in iperf 
> 2 - https://iperf2.sourceforge.io/iperf-manpage.html - so there is 
> free tooling out there that can help.)
>
> Bob
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain


[-- Attachment #1.1.1.2: Type: text/html, Size: 5035 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

  reply	other threads:[~2024-02-27 23:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 21:06 Livingood, Jason
2024-02-27 22:00 ` rjmcmahon
2024-02-27 23:17   ` Jack Haverty [this message]
2024-02-27 23:41     ` Jeremy Austin
  -- strict thread matches above, loose matches on Subject: below --
2024-02-26 15:06 Dave Taht
2024-02-26 19:24 ` Jack Haverty

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=71063fa7-ba1b-4da8-8252-73b1ff2dd29e@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