https://en.wikipedia.org/wiki/Dave_T%C3%A4ht
https://lists.bufferbloat.net/pipermail/bloat/2025-April/018...
replies(1):
He also noted that GL INET devices have the LibreQos pre installed and recommended those routers.
Pace, Dave.
Edit: copying over Vint Cerf's message that was posted on the bufferbloat mail list. I believe that's a public mail list so hopefully Vint doesn't mind:
OMG - that is truly terrible news! I could not say better than Frank already has how much Dave's work has helped to improve our experience of the Internet. I can't think of anyone more dedicated to the proposition that performance counts and should be pursued with determination and vigor. I've known Dave for many years and greatly valued his counsel and technical skills - to say nothing of his healthy sense of humor. I will miss him but will be always grateful to have known him.
dang, could we get a black bar?
It goes deep into his fq_codel work and why it was such a game-changer. It's an informal setting so his personality shines through - seems like we didn't just lose a great technologist, but also a heck of a human.
https://media.freifunk.net/v/lightning-talk-starlink
Rest in peace my friend.
I never met him, but from what I saw on the relevant mailing lists, Dave was at the center of it all. Rest in peace.
To fix it, I had a box that was set to limit 90% of the traffic to the advertised cable services uplink speed and moved small packets (TCP ACKS) to the head of the line. Then once the upstream limit had been reached packets were dropped.
It's quite a bit easier now, but wondershaper really made the internet that much better back then.
The problem with these terrible CPEs is that their buffers are generally much too large, but just making them smaller isn't trivial either – the "correct" size, as suggested by queueing theory, is equal to the product of bandwidth and end-to-end latency, but the latter is impossible to know to a router and varies from connection to connection!
The key insight of CoDeL is that transient queues are good (because they avoid packets dropped due to transient congestion), but standing ones are bad (because they avoid nothing and just increase latency). I believe it's now fortunately mandatory in newer DOCSIS CPEs (but I have a lot of faith in CPE manufacturers to somehow still botch it).
[1] In fact, negligible packet loss for reasons other than congestion is a critical assumption for at most older TCP congestion control algorithms!
https://blog.apnic.net/2024/05/17/a-transport-protocols-view... is the best resource on its channel properties I've seen so far, but it's all empirical.
https://libreqos.io/ https://understandinglatency.com/ https://www.linkedin.com/in/dtaht https://www.patreon.com/dtaht https://www.facebook.com/dtaht/ https://www.youtube.com/@davetaht4989 https://twitter.net/mtaht https://github.com/dtaht http://www.taht.net/ http://www.taht.net/~d/ http://www.taht.net/~mtaht/ http://www.teklibre.net/ http://www.teklibre.net/~d/ http://www.teklibre.net/~mtaht/
> I had to deal with that analogy a lot in high school, and I got used to it. It is, indeed, a rather popular food in schools. My problem with people using TAYT is that they end up misspelling it as Tate. Actually my name in the USA is usually pronounced "Tot", or better, T"ah"T, but while doing i18n testing in the mid-90s, and I discovered that the correct spelling (in Estonia) was with the ä. I gleefully adopted that, so I could break all of our protocols and web tools prior to the worldwide acceptance of UTF-8, and also because I was a death metal fan. Using the umlaut also makes it impossible for an automated spellchecker to respell it as "That", however no alternative has really worked. For a while there, the IRS thought I was three different people....
> The word, in Estonian, means "Star or planet", and as the Estonians did not know what an asteroid was, I have taken it to mean "Star or planet?".
While not saying anything about roots directly, I'm guessing it has to have been the reason behind him adopting the Estonian spelling of it. Maybe from grandparents or great-grantparents. Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
He contributed to GNU Emacs Org-Mode with gnugol: https://list.orgmode.org/4D210A00.9070901@teklibre.org/
I interacted with him directly only once, while working on a [buffering-related issue in Open connect](https://gitlab.com/openconnect/openconnect/-/issues/582#note...).
Like many others, I was inspired by his great attention to detail, his diligence, and his curiosity, which served as a fantastic example for many people working on tricky and important issues in networking and other technologies.
Those will be some big shoes to fill.
This is a sad day. There's no doubt that his efforts benefitted very many people, without their knowledge.
[1] https://blog.tohojo.dk/2025/04/remembering-dave-t%C3%A4ht.ht...
Seeing his name on HN, especially in this context, threw me off a little. RIP Dave.
What - if any - are the barriers to implementing FQ-Codel or a similar scheme in forwarding ASICs? To my mind with limited knowledge managing all those separate queues sounds like it could be challenging in hardware.
> Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
Asteroids have been called "falling stars" in most languages for ages, nor would "asteroid" work well as a name. Nothing to do with anyone's knowledge of astronomy really.
(How do we make sure that there's no benefit to someone if they get the idea of trying to make it happen?)
One could tell it was the cable modem buffering quite easily by watching ping times to an external ip. When the buffer got full. Pings which should have been dropped came in maybe 4, 5, or 6 seconds later.
Only by eliminating the buffer entirely in the cable company provided cable modem allowed TCP congestion algorithms to work correctly. UDP may suffer, sure, but I didn't really care about UDP packets back then. I cared more about browsing and downloads.