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 --]
next prev parent 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