Hacker News Reader

Comment by Animats | Hacker News Reader

You can't turn off delayed ACKs and make them stay off, which is a related problem. The Linux API for that is very strange. It only applies for a short period.

Delayed ACKs and the Nagle algorithm should never be on at the same time. The trouble is, they're controlled at opposite ends of the connection. You can turn off the Nagle algorithm at your end, but you want to turn off delayed ACKs at the other end. That's the practical problem.

Still, what's the use case for having multiple tiny messages in flight during one RTT? Games usually send their interactive traffic over UDP. If you have delayed ACKs off, you should never have a propagation delay of more than one RTT. It's that fixed timer in delayed ACKS, set to a value that made sense for keyboard echo, that can cause delays of more than one RTT.

View on HN

I find it hilarious that people want to turn off your algorithm because most people don’t know delayed ACKs is the “real problem”.

I’d much rather see delayed ACKs disabled as the new default vs. your algorithm being disabled by default.

I’ve seen too many applications not filling packets and sending tons of tiny packets. They’d benefit from your algorithm, even with delayed ACKs on… but people also confuse latency with throughput all the time (sometimes you want/need one more than the other — and languages like Go not giving programmers this ability to decide is frustrating, mainly because for awhile, those programs were the biggest offenders)…

I digress… I do find this whole thing rather amusing.

Delayed ACKs are not the "real problem". For the last 10 years I haven't encountered a single environment where Nagle's algorithm would be a net win. No heuristics, no fancy auto-sensing. It should be off by default.

If you're working in distributed systems, fintech, mobile network optimization, broadcasting, the first thing you should do is switch off Nagle's algorithm. Animats should focus on Second Life and stop holding on to what's now a very bad default.

See, this is why we can't have real conversations about this problem, because most people don't even understand what they are saying and just spout off dogma.

1. Just because you haven't "encountered a single environment" doesn't mean you haven't been in one or that you'd even know what to look for to know if you were in one where it would be a net win.

2. "If you're working in distributed systems," you likely have very fat, fast, and reliable pipes between your services. Nagle's algorithm is probably a Bad Thing[tm] in those situations. If you have a lot of Wi-Fi interference or dropped packets, Nagle's algorithm can be the difference between 50bps and 1mbps (assuming your application isn't filling packets), except that Delayed Acks prevents you from realizing all that.

There's no "one size fits all" solution, but you have control over Nagle's algorithm, you do not have control over Delayed Acks.

It is not, in general, a net win. It is a preventative measure against things getting really bad.

My other work back then, on fair queuing, followed the same line - keep things from getting really bad just because something was slightly overloaded.

When I was working on this, funding was from DARPA, Defense Communications Agency, and such. They wanted networks to keep working under bad conditions. Maximum price/performance was far less important. The price of getting the last 10% in performance is usually complexity and often fragility.

I kind of love that this continues to haunt you :).

For anyone who doesn't know, HN user Animats is John Nagle, eponym of Nagle's algorithm.

My main mental association with that algorithm is always being asked about it in "make menuconfig" when I used to compile my own Linux kernels. One of relatively few networking concepts I can think of that's named after a person (along with Van Jacobson header compression).

I called it "tinygram prevention".

> The trouble is, they're controlled at opposite ends of the connection. You can turn off the Nagle algorithm at your end, but you want to turn off delayed ACKs at the other end. That's the practical problem.

For an extant case of this practical problem chosen at random, I'd be curious to know-- what's the likelihood that it's just openssh on both ends of the connection?

Do you have any sense regarding how helpful tcp_autocorking on Linux is (or isn't)?

Reply on news.ycombinator.com