4 ms·
From John Nagle: "(..) Unfortunately, delayed ACKs went in after I got out of networking in 1986, and this was never fixed. Now it's too late." https://stack
by punnerud 6y ago
From John Nagle:
"(..) Unfortunately, delayed ACKs went in after I got out of networking in 1986, and this was never fixed. Now it's too late."
https://stackoverflow.com/a/16663206/2326672 https://stackoverflow.com/a/16663206/2326672
- oefrha 6y agoSee also this thread straight from the horse’s mouth, with some additional technical considerations: https://news.ycombinator.com/item?id=9048947 https://news.ycombinator.com/item?id=9048947
- punnerud 6y agoNot topic related, but John’s transfer from networking to Autodesk got me interested. I don’t immediately see the good connection between the two, when they where a startup. Would love to see a blog post from John Nagel on this, now that we know the outcome of Autodesk. (I see he is active on HN almost every day)
- ignoramous 6y agoSee also another amusing exchange: https://news.ycombinator.com/item?id=21088736 https://news.ycombinator.com/item?id=21088736
- mercer 6y agoHa, I've been here for years and never knew that Animats was John Nagle. cool!
- JdeBP 6y agoThe Stack Overflow answer was "straight from the horse's mouth" too, doubters here at https://news.ycombinator.com/item?id=24799256 https://news.ycombinator.com/item?id=24799256 notwithstanding. (-:
- pedrocr 6y agoSo the kernel is using a static decision that's really bad sometimes? Would it be too expensive to treat this like a branch predictor and keep some state to have the kernel enable/disable the delayed ACK dynamically depending on how it has won/lost the bet recently?
- eru 6y agoI think that what John Nagle's answers was suggesting: > A delayed ACK is a bet. The TCP implementation is betting that data will be sent shortly and will make it unnecessary to send a lone ACK. Every time a delayed ACK is actually sent, that bet was lost. The TCP spec allows an implementation to lose that bet every time without turning off delayed ACKs. Properly, delayed ACKs should only turn on when a few unnecessary ACKs that could have been piggybacked have been sent in a row, and any time a delayed ACK is actually sent, delayed ACKs should be turned off again. There should have been a counter for this.
- pedrocr 6y agoYes, that's the suggested fix. My question is if treating this like a CPU branch predictor and keeping some state that needs to be updated is too expensive or not. The packet pipeline is very performance sensitive.
- Flowdalic 6y agoI wouldn't be sure that this is authentic, i.e. actually from John Nagle.
- JdeBP 6y agoIt is amusing that you doubt that "John Nagle" on Stack Overflow is M. Nagle, but don't express any doubt that "Animats" here on this WWW site, and indeed this very discussion, is M. Nagle. Surely the reverse stance is the more logical, if one has no idea what "Animats" is. It is odd that some people give more credence to a pseudonym, or in this case a company name, than to using one's own name.
- perl4ever 6y agoAmong people who would pretend to be a given well known person, surely more of them know that person's real name than something that would make a plausible pseudonym. Or in any case, more of them would choose it. And if someone thinks a pseudonym is a particular famous person, they must have a reason, which is unlikely to be weaker than just assuming a normal name is accurate. I'm not up to doing a Bayesian analysis right now, but I feel like one could show it makes more sense to doubt an unverified name.