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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
He contributed to GNU Emacs Org-Mode with gnugol: https://list.orgmode.org/[email protected]/
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!
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.
He also noted that GL INET devices have the LibreQos pre installed and recommended those routers.
https://media.freifunk.net/v/lightning-talk-starlink
Rest in peace my friend.
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.
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...
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.
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?
RIP Dave, he will be sorely missed.
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.
> 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.
> 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.
https://blog.cerowrt.org/
https://lists.bufferbloat.net/pipermail/bloat/2025-April/018...
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/
Now our lowest-address draft is at 50% deceased coauthors.
Seeing his name on HN, especially in this context, threw me off a little. RIP Dave.
have a video of it if there is a good place to send it to.
RIP to a real one.
https://github.com/LibreQoE/LibreQoS/pull/684
(How do we make sure that there's no benefit to someone if they get the idea of trying to make it happen?)
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.