dtaht

12 ms·

31.
by dtaht 3y ago
I had hoped this talk would stir more discussion than it has so far. I don´t know. That 45% figure for quic was news to me.
32.
by dtaht 3y ago
Don´t give up. Ask for RFC7567 everywhere.
33.
by dtaht 3y ago
+10!
34.
by dtaht 3y ago
Mosh, over wifi, is a sanity saver.
35.
by dtaht 3y ago
This is where things stood in 2014. An update a decade later would be nice. https://arxiv.org/pdf/1505.03449.pdf
36.
by dtaht 3y ago
Geoff´s talk was really good. I hope discussion starts over there: https://news.ycombinator.com/item?id=39561073
37.
by dtaht 3y ago
I did slide towards mentioning QUIC there in that that first time crypto cost is gone there too. (I rather like quic), but yes, crypto costs. The web got a lot slower when it went to https, I noticed. A highly interactive site like HN is in
38.
by dtaht 3y ago
See: https://www.taranawireless.com/
39.
Apnic Geoff Huston: The rise and rise of CDNs [video](youtube.com)
4 points by dtaht 3y ago|4 comments
40.
by dtaht 3y ago
I am a big believer in passive monitoring (see libreqos). Measuring packet loss is a PITA because it is the absence of information. While you can infer it from protocols like TCP, QUIC and VOIP protocols make loss only visible to the end-po
41.
by dtaht 3y ago
People are very sensitive to glitches. We should start counting those up and reporting on those.
42.
by dtaht 3y ago
Some packet loss (or ECN marking) is NEEDED to get good congestion control. Certainly random packet loss is a PITA.
43.
by dtaht 3y ago
Glad you use irtt! More should! The bufferbloat project does maintain a few public IRTT servers around the world: https://blog.cerowrt.org/post/flent_fleet/ It would be great to add more to the pool.
44.
by dtaht 3y ago
On top of everything else I do, I run a pretty good email discussion list for starlink stuff, over here: https://lists.bufferbloat.net/pipermail/starlink/
45.
by dtaht 3y ago
In general, using an empty channel, less wide, has more range, and with less interference So I would vastly prefer that in contended scenarios - an apartment building for example - that the actual channel width provisioned to be not be much
46.
by dtaht 3y ago
I have proposed "Glitches per minute" where there is a perceptible glitch while videoconferencing + some other load. The poster child for this is Starlink, which glitches 4 times a minute....
47.
by dtaht 3y ago
The biggest thing that makes me nuts about our speedtest regimes is that we test upload and download separately, rather than at the same time. People have 16+ wifi devices on their networks today. There IS upstream traffic going on at the s
48.
by dtaht 3y ago
Pretty close. A typical fiber latency to a CDN in-city is actually closer to 2ms. It takes 5 round trips to negotiate a TCP SSL connection (I will exclude the cost of generating the crypto), so 10ms later you start getting bursts of content
49.
by dtaht 3y ago
yes!
50.
by dtaht 3y ago
I did have a talk with him about tcp slow start after this.... too many people in his world think tcp is a function call.
51.
by dtaht 3y ago
I have tried to point out MANY times that the DEFAULT behavior of the TCP slow start algorithm is to saturate the link - however briefly - get a drop, and then back off. I try to do it with some humor using jugglers here - and get so far as
52.
by dtaht 3y ago
Thx for the laugh! No FCC regs demand sub 100ms latency, so unless you are taking a really big 24 hour average, that idea won't work. However the technology exists to aim for 20ms - even 4ms - of both idle and working latency today, an
53.
by dtaht 3y ago
I would definately argue for physical latency to the isp's edge, and to several of the nearest CDNs. What is google doing with 8.8.8.9? Could they stick a quic server there for speedtest like metrics? A third thing, which would drive m
54.
by dtaht 3y ago
Consistently low latency is great. Not just with bufferbloat but with physical latency. A lot of city-based fiber dwellers think that just running fiber out to rural areas actually improves performance more than it does. Moving data and int
55.
New FCC Broadband Standards Should Consider Latency(broadbandbreakfast.com)
226 points by dtaht 3y ago|139 comments
56.
by dtaht 3y ago
someone should update talk to ipv6.
57.
by dtaht 3y ago
Although I am being snarky as heck in this blog post, I am genuinely curious as to what, for example, people project as consumer bandwidth growth in 2024. Will we see more bittorrent used more, for example? How often will new AI models be r
58.
Dave Taht´s 2024 predictions for the Tech Industry(blog.cerowrt.org)
1 points by dtaht 3y ago|1 comments
59.
Dr. Starlink tests the gen3 and gen4 dishy in Ukraine(olegkutkov.me)
9 points by dtaht 3y ago|3 comments
60.
by dtaht 3y ago
I am bugged that the BEAD programs do not seem to grok that we are indeed out of IPv4 space, and that the federal government is sitting on 10? 11 idle /8s.

More ›