New FCC Broadband Standards Should Consider Latency

I&#x27;ve had Starlink since early beta days and am watching connection metrics very closely. Latency measurement is so much more useful than throughput. So is packet loss. FWIW I&#x27;ve averaged 0.6% packet loss, 38ms latency, and 130&#x2F;20 MBit&#x2F;s in Grass Valley, CA over the last month<p>But averages obscure what&#x27;s really important. The biggest indicator of Starlink congestion problems has been how packet loss increases in evenings. Average latency is interesting but much more interesting is the variance of latency or jitter. A steady 50ms is better than a connection varying 20-80ms all the time. As for bandwidth what I&#x27;ve found most useful is a measure of &quot;hours under 20 Mbps download&quot; (1 or 2 a day on my Starlink).<p>IRTT is a fantastic tool for measuring latency and packet loss. Way better than simple pings. The hassle is you have to run a server too; I have one in the same datacenter as the Starlink terrestrial POP.

When working remotely, latency matters because it&#x27;s so awkward in video meetings when you&#x27;re 1&#x2F;4 second behind everyone else.<p>But something else that matters (possibly not so much in the US, but definitely in many other countries) is mini internet &#x27;brown outs&#x27;, where there&#x27;s a sudden internet drop out for just a few seconds. I don&#x27;t know what statistic would be good for measuring that. But when it happens during a meeting it&#x27;s quite annoying and noticeable. In some parts of the world they seem to occur about once an hour, although YMMV.

A full Nutrition Facts label would be nice. Downstream AND Upstream, latency numbers to headend and nearest IXP, availability numbers, then price stability between day 0 and 3-5 years.

This. Viasat is not viable for Zoom so it&#x27;s not viable as a modern broadband connection. It&#x27;s that simple as I see it. If you can&#x27;t do the stuff most people do with broadband regularly it&#x27;s not broadband.

&gt; The comment submitted by Dave Taht, chief science officer of LibreQoS, argues that today’s applications are not typically bandwidth-limited, but are instead significantly limited by working latency.<p>(for reference, Taht&#x27;s comment is indirectly linked from the submission; <a href="https:&#x2F;&#x2F;www.fcc.gov&#x2F;ecfs&#x2F;document&#x2F;12010651418616&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;www.fcc.gov&#x2F;ecfs&#x2F;document&#x2F;12010651418616&#x2F;1</a> which has much more detailed technical discussion.)<p>Dave Taht... that&#x27;s the guy behind a lot of the bufferbloat work over the past decade or so (and seems to be the submitter?), right?<p>In my experience, predictable latency is more important than low latency. 50ms RTT can be fine for a video call; it&#x27;s not fine if it spikes up to 500ms sporadically. Protocol work like QUIC that can reduce per-connection startup overhead definitely helps in this regard.<p>On the other hand, if you have a highly interactive use case like SSH where every single keystroke must roundtrip between you and a server, that 50ms RTT is very visible.<p>I think talking about absolute latency might be misguided in that it depends partially on the other end you&#x27;re talking to. If I&#x27;m in the eastern US and communicating to a server in India, there&#x27;s no way I&#x27;m getting &lt; 100ms RTT (I&#x27;d be happy if I could get 200ms). On the other hand, if you&#x27;re using legacy satellite internet like Viasat you might have 600ms latency talking to a server in the same city. (Starlink does better, but it still imposes sizable fixed latency costs on the order of 10s of ms.)<p>If I had to come up with latency metrics, I might initially suggest &quot;&lt; 20ms within the same city; loaded latency must not impose a penalty greater than 40ms&quot; (I&#x27;d love for these numbers to be lower, but they&#x27;re already very ambitious for Starlink due to physical characteristics of the satellite constellation).<p>edit: of course, in retrospect, that&#x27;s my urban bias coming through -- what if you don&#x27;t live in a city? or consider Hawaii -- is it good enough to just consider latency to Honolulu? Or do you want latency to www.google.com (the nearest frontends are in Los Angeles)?

Latency to where? To your ISP&#x27;s edge? To the nearest IXP? To Google, Cloudflare, Netflix, or AWS? To any destination on the Internet? Latency is an end-to-end metric which will almost always involve path components beyond the control of your ISP - can and should they be held responsible for those paths?

Except in some specific cases (like when your job is to regularly download and upload huge files) latency is even more important than bandwidth. Even fairly low bandwidth under 10 Mbps is enough for the majority of real-life office job cases and it feels this way if the latency and jitter are low yet high latency&#x2F;jitter can make even a 100+ Mbps connection unbearable. It&#x27;s low latency that makes Internet feel fast. ISPs should advertise latency and jitter levels alongside bandwidth and that&#x27;s the most important numbers customers should look at.<p>I usually explain this to non-techies by inviting them to imagine they own a train full of 1TB drives. This way they can move a million terabytes to a neighbor town in an hour. Naïvely this translates to 277.8 Tbps which seems super fast but there is a catch :-)

If latency doesn’t matter, can I create a service that cross-ships 1TB HDDs overnight and call it broadband?

Broadband funds helped deploy fiber here. Pings to 1.1.1.1 are ~2ms.<p>I love considering latency now.<p>edit: Cable is still hooked up and it&#x27;s 17ms-20ms. Not awful.<p>LTE: GSMA is 25ms-33ms, GSMT is 25ms-51ms.<p>I don&#x27;t have satellite, DSL, IDSN or dial up to compare.

I often get spikes of delay showing up in <a href="https:&#x2F;&#x2F;test.vsee.com&#x2F;network&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;test.vsee.com&#x2F;network&#x2F;index.html</a> while on conference calls. Those correspond to periods in which speakers &quot;sound like aliens&quot;, &quot;have fallen down a well&quot; or simply freeze up.<p>Having a standard that ignores that is less than useful. It&#x27;s the standards body showing disrespect for the people it&#x27;s supposedly creating the standard _for_.

Web pages are increasingly bulky. A 3 MB page will take 1 second to load at 25 Mbps, so latency is often not the primary bottleneck.<p>Part of the problem may be that companies who own network infrastructure, and get paid for data usage, are also the ones that are the largest content providers.<p>This also comes with an electricity cost. We regulate efficiency for refrigerators, it might be time to add some sane limits to the largest content providers, which will also improve connectivity for those stuck with 2 Mbps.

&gt; Up for consideration by the FCC on March 14, the draft report would increase the current national broadband speed definition of 25 * 3 Megabits per second (Mbps) established in 2015, raising it to 100 * 20 Mbps.<p>What is this &quot;25 * 3&quot; and &quot;100 * 20&quot; notation? The next sentence just goes on to say &quot;1 Gigabit&quot; and &quot;500 Mbps&quot; directly.

“Gil Tenne - How not to measure latency” some of the best infotainment on YouTube. Sorry no time to find exact link. There are many.

I never had a latency problem in the US but then again I never had to use satellite... But if I did, there wouldn&#x27;t be any other options anyways.

I never considered restrictions on running servers and the poor upload speeds &quot;broadband&quot;, but apparently everyone does. So here we are.

Most web page latency problems are not network problems. They&#x27;re the pages that load too many crap items. Look at the browser&#x27;s display of network transactions. Pages with little content are making over a hundred transactions. Does anyone really <i>need</i> 34 trackers? But it takes a lot of round-trips to load all that crap.<p>For a while, Google was penalizing slow-loading pages, but that got tied into AMP, which everybody hated.<p>It only takes 25 Mbps to stream 4K TV, after all.

That&#x27;s a pretty good DALL-E header image.