Hacker News Reader

Comment by punnerud | Hacker News Reader

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

View on HN

See also this thread straight from the horse’s mouth, with some additional technical considerations: https://news.ycombinator.com/item?id=9048947

Not 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)

See also another amusing exchange: https://news.ycombinator.com/item?id=21088736

Ha, I've been here for years and never knew that Animats was John Nagle. cool!

The Stack Overflow answer was "straight from the horse's mouth" too, doubters here at https://news.ycombinator.com/item?id=24799256 notwithstanding. (-:

So 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?

I 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.

Yes, 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.

I wouldn't be sure that this is authentic, i.e. actually from John Nagle.

It 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.

Among 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.

Reply on news.ycombinator.com