hckrnws
I didn't know him, but followed his work on bufferbloat closely. I've never seen anyone work so diligently, for so many years, to fix a problem most people will never know even existed. And yet, that work will be felt by almost everyone on the internet. I'm sad knowing he's passed, and thankful to have seen his work. Rest in peace.
https://xkcd.com/2347/ (which is, in my opinion, highest praise in this line of work)
In 2012, he travelled to France and bought me a beer to thank me for my work on Org-Mode, and it was great. He was enthusiastic about this worldwide half-random connections, and insisted on how great it was to be able to connect with everyone in this way... we certainly miss him and that spirit.
He contributed to GNU Emacs Org-Mode with gnugol: https://list.orgmode.org/4D210A00.9070901@teklibre.org/
Learning about Bufferbloat in my undergrad, but more importantly that by running OpenWrt on my €20 home router and simply activating an (at the time) nonstandard queueing policy could make a shared internet connection infinitely more usable, blew my mind.
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.
Cable modems 15 years ago were really terrible. Instead of trusting TCP to do the right thing, the modems buffered the packets. This caused weird slowdowns if the uplink got congested a combination of large upstream packets and TCP acknowledgements. (Think backing up a computer to a server, etc)
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.
Some amount of buffering is inevitable in any packet-switched network, even in a pure Ethernet network with negligible packet loss/corruption, due to the nature of packet switching statistics in general and the TCP congestion control algorithm in particular [1].
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!
Sure, but the problem really was the lack of upstream bandwidth meant to handle the acknowledgements at the time. It's not so much "Should I buffer or should I not?" as it was more about "What is the proper amount to upstream bandwidth to allow people to properly let them use their downstream bandwidth?"
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.
Sorry to hear this. I was at Goto Chicago for one of his talks and he used a bunch of people to model TCP and participated and learned a lot about the protocol. Really nice person and great lecturer.
He also noted that GL INET devices have the LibreQos pre installed and recommended those routers.
I worked with him in the 90's at SCO and we became friends based more upon music than tech.
He was an early adopter of a kludgy midi bass which he insisted I play but we had lots of laughs at how ridiculous it was.
He visited us in NM about ten years ago and voraciously consumed my wife's pumpkin waffles like he had not eaten for days. Which, knowing him, he likely had not.
I called him MTaht since that was his email handle at SCO.
Many other tales to tell but I will stop.
I am shocked at his passing too soon.
Happy travels, amigo!
Dave had a rtalk about Starlink at Wireless Battlemesh in Paris in 2019, we had some beers:
https://media.freifunk.net/v/lightning-talk-starlink
Rest in peace my friend.
I really hope he did find out, or at least had a good theory, on what protocol stack Starlink runs on. The engineering achievement is amazing, but it's sad that it all seems to happen entirely behind closed doors.
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.
I know Dave was still trying to figure out exactly how Starlink worked, and how he could help with its performance characteristics, at least two years after that talk, as he sent me a draft of a document related to that.
The fact that he applied to starlink and they didn't hire him is depressing....
I don't think his personality was compatible with the corporate world.
According to Toke Høiland-Jørgensen's memorial of him[1], he turned down offers from big companies to stay independent.
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...
What a stunning condemnation of the corporate world.
They hired someone from Netflix that studied at his feet
I'm so sorry to hear of his death, and sending my prayers and wishes for peace and healing to his loved ones.
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.
I appreciate and applaud your inclination to sympathy, but I don't think saying words in your head will help him or his family. Perhaps instead you should let his family know directly that you found inspiration in his work - I imagine they would find that quite comforting in their grief.
Oh man! I didn't know him closely, but we'd come into one anothers' orbits on Google+ and he was a great source of technical (and other) knowledge. One result of that is sitting a metre from me as I write this, as he'd turned me on to the Turris Omnia OpenWRT-based router.
Pace, Dave.
I recently listened to a podcast episode he was on: https://castbox.fm/app/castbox/player/id3692892/id372628820
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.
Thank you, this was a great listen.
What sad news. Dave was an incredible human and very dedicated to making the Internet better and faster. What a loss.
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?
High praise indeed.
RIP Dave, he will be sorely missed.
His last name means "star" in Estonian. I was curious if his roots were from Estonia, but could not find any info. In any case, rest in peace Dave.
I was curious about the same thing, and found the following from Dave:
> 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.
The word "täht" itself means "star" (both celestial one or a notable person) or "letter/glyph", not "planet".
> 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.
Dave Täht was my initial motivation to get serious about getting into low level networking more than 8 years ago. Ever since then I’ve had the honor to co-develop various systems on multi terabit ISP routers. I’m really thankful for the insights he provided as I was trying to figure out how to configure WRED hardware blocks in our network ASICs. Men like Dave was one in hundred million if that. May he be forever remembered and his work live on forever.
Sorry to hijack this but your role has me curious.
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.
Some more related links:
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/
There's a reddit account too
Argh, he was the immediately previous person before me to work on the Unicast Extension Project and still a coauthor on all of our reserved address drafts!
Now our lowest-address draft is at 50% deceased coauthors.
Never realised that Dave had so much impact on the networking world until now - he had contacted me out of the blue on linkedin years ago after a blog post about my cable/DSL connection woes - wish I talked to him a little more about it. I can see what people mean about him being present everywhere.
Seeing his name on HN, especially in this context, threw me off a little. RIP Dave.
met him in prague. had his guitar. played a song for me and this other dude hanging out in the smoking area.
have a video of it if there is a good place to send it to.
RIP to a real one.
Looks like others are sharing things like that here:
This would be as good a place as any to share it :)
Youtube then link it everywhere. Here, the Reddit thread that links to here, etc.
Hosted one of his measurement boxes for a while. Nice guy, very committed to researching the problem space.
Dave was ever-present in the areas he had passion for and that presence and unwavering advocacy had many positive outcomes. I'll miss his friendly challenges during future work in this space, they were always enjoyable and valuable even when we had differing approaches.
I wonder how many people will never be able to use his work because their router/other firmware is proprietary, GPL violating or otherwise non-upgradable.
Very very many of the non-upgradable and proprietary routers use Linux under the hood. As long as they aren't stuck on an ancient Linux kernel, they would be able to use fq-codel and CAKE.
I ran into him at a store in El Granada in 2022. He was wearing a USENIX t-shirt and I commented on it. I think he was living on a boat in the harbor at the time, it was a little sad. How did he pass?
I don't know him, or what happened to him. I do wonder, if there are members of the old guard who are feeling like the world is shutting off their options, if there is a way to know that and to help.
Another one. John Thornton, supporter of nonprofit public service journalism. https://www.washingtonpost.com/obituaries/2025/04/02/john-th...
(How do we make sure that there's no benefit to someone if they get the idea of trying to make it happen?)
Reach out, peeps. Carefully.
iam really inspired by his work on FQ-CoDel and CAKE, which has greatly boosted internet performance. His legacy will continue to inspire and benefit the networking community.
Truly hits different when it's someone you know at a personal level.
Inspired by his work on buffer bloat like so many others. Rest in peace.
What killed him?
Crafted by Rajat
Source Code