4 ms·

Does Nagle's algorithm actually make sense on the modern web? I've always seen it as an artefact from a bygone era that is more likely to cause performance iss

Does Nagle's algorithm actually make sense on the modern web? I've always seen it as an artefact from a bygone era that is more likely to cause performance issues than solve them today. But that's just my intuition and it may be dead wrong.

axaxs 6y ago
Modern web as in...? Tinygram prevention is a TCP level actor, with no regard to whether it's sending db queries or webpages. With the prevalence of "smart" appliances and ever coming IOT, I'd argue it's more important than ever. I don't trust most vendors to get it anything close to optimal otherwise.
- reitzensteinm 6y ago
  Packet sizes are increasing [1], which makes it more likely you'll go over the threshold quickly. It used to be far more common to write a hand written protocol to a TCP stream directly. Now the shitty IOT stuff is more likely to be throwing massive JSON packets down the wire. The original motivation (as I understand it, and recognizing I may well get corrected by John who is in this thread) were situations like a remote terminal where you'd be writing single bytes to a TCP stream. I just don't think much software is written that way any more, and if it is, it's probably latency sensitive. And 200ms is an eternity to wait if you happen to build a tiny packet for real time situations and this trips you up. I write multiplayer games for a living, and you're not always in control of the connection that you're passing data through. Usually, but not always. If Nagle is enabled you literally have to write padding data to the stream to make sure your packet is being sent like this poor soul [2]. Like I say, I'm happy to learn I'm wrong. Given the downvotes, people certainly seem to think I am, and I'm happy to believe they're experienced network engineers dumbfounded at my naïve stupidity. [1] Eg here's a ten year trend, and it's been thirty years since Nagle's introduction: https://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml https://www.caida.org/research/traffic-analysis/pkt_size_dis... [2] https://stackoverflow.com/questions/19560163/sending-filler-data-on-websocket https://stackoverflow.com/questions/19560163/sending-filler-...
- magicalhippo 6y ago
  > With the prevalence of "smart" appliances and ever coming IOT Someone was recently complaining that their Arduino project was gobbling up mobile data. They had used an Ethernet shield coupled to some 4G network something. After a bit of back and forth the culprit was found: it was sending one byte packets. The standard Arduino is extremely memory limited, so a typical trick is to use the Flash memory to store string constants, and then use those when writing to devices etc. The library code has some nice wrappers which makes things like sending a Flash string constant to some output stream like a serial port or say Ethernet shield fairly seamless. However for reasons[1], the Flash variant of the "send constant string" call does this by reading and sending one character at a time. And the Ethernet library (memory constrained) or Shield did no extra buffering, so it sent minimum one packet per call... [1]: IIRC the Arduino Flash is 16 bit and the characters in the string are stored zero-expanded, so it can just memcpy but has to strip away the top byte.
buckminster 6y ago
Nagle says yes, but he'd get rid of delayed ACK: https://news.ycombinator.com/item?id=9050645 https://news.ycombinator.com/item?id=9050645
- susam 6y ago
  Here is yet another post from 2006 where John Nagle talks about the bad interaction between Nagle's algorithm and delayed ACK: https://developers.slashdot.org/comments.pl?sid=174457&cid=14515105 https://developers.slashdot.org/comments.pl?sid=174457&cid=1...
toast0 6y ago
Nagle is fine for web, as long as you flush when you reach the end of your request/response. And at strategic places like end of headers, end of html head, etc, if you know the content isn't directly forthcoming. A lot of HTTP software writes things to sockets in small chunks though, especially headers and what not. I've seen some things with chunked encoded posts; I don't think it was visible at the TCP level, but I would get three TLS application data segments, one for $SIZE\r\n, one for the size worth of data, and one for the trailing \r\n. Ugh.
- reitzensteinm 6y ago
  But it's there, as I understand it, mainly to combine multiple logical packets over a short human sized time scale. By its nature it also prevents fragmenting poorly written logical packets. But you could also do this as a separate level of protection. Say a 5ms delay on any write without a flush, any further write resets the delay, up until a maximum of 20ms. This would seem to reign in the worst of the behavior - developers not realizing they're sending multiple packets - without adding a large delay to developers using the system properly but not flushing. And since the penalty is much less, it would be less likely to be turned off aggressively, see the Go example in sibling comments. If the goal is to hand training wheels to developers of shitty apps, it's pretty important they actually use them.

axaxs 6y ago

Modern web as in...? Tinygram prevention is a TCP level actor, with no regard to whether it's sending db queries or webpages. With the prevalence of "smart" appliances and ever coming IOT, I'd argue it's more important than ever. I don't trust most vendors to get it anything close to optimal otherwise.

reitzensteinm 6y ago
Packet sizes are increasing [1], which makes it more likely you'll go over the threshold quickly. It used to be far more common to write a hand written protocol to a TCP stream directly. Now the shitty IOT stuff is more likely to be throwing massive JSON packets down the wire. The original motivation (as I understand it, and recognizing I may well get corrected by John who is in this thread) were situations like a remote terminal where you'd be writing single bytes to a TCP stream. I just don't think much software is written that way any more, and if it is, it's probably latency sensitive. And 200ms is an eternity to wait if you happen to build a tiny packet for real time situations and this trips you up. I write multiplayer games for a living, and you're not always in control of the connection that you're passing data through. Usually, but not always. If Nagle is enabled you literally have to write padding data to the stream to make sure your packet is being sent like this poor soul [2]. Like I say, I'm happy to learn I'm wrong. Given the downvotes, people certainly seem to think I am, and I'm happy to believe they're experienced network engineers dumbfounded at my naïve stupidity. [1] Eg here's a ten year trend, and it's been thirty years since Nagle's introduction: https://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml https://www.caida.org/research/traffic-analysis/pkt_size_dis... [2] https://stackoverflow.com/questions/19560163/sending-filler-data-on-websocket https://stackoverflow.com/questions/19560163/sending-filler-...
magicalhippo 6y ago
> With the prevalence of "smart" appliances and ever coming IOT Someone was recently complaining that their Arduino project was gobbling up mobile data. They had used an Ethernet shield coupled to some 4G network something. After a bit of back and forth the culprit was found: it was sending one byte packets. The standard Arduino is extremely memory limited, so a typical trick is to use the Flash memory to store string constants, and then use those when writing to devices etc. The library code has some nice wrappers which makes things like sending a Flash string constant to some output stream like a serial port or say Ethernet shield fairly seamless. However for reasons[1], the Flash variant of the "send constant string" call does this by reading and sending one character at a time. And the Ethernet library (memory constrained) or Shield did no extra buffering, so it sent minimum one packet per call... [1]: IIRC the Arduino Flash is 16 bit and the characters in the string are stored zero-expanded, so it can just memcpy but has to strip away the top byte.

buckminster 6y ago

Nagle says yes, but he'd get rid of delayed ACK: https://news.ycombinator.com/item?id=9050645 https://news.ycombinator.com/item?id=9050645

susam 6y ago
Here is yet another post from 2006 where John Nagle talks about the bad interaction between Nagle's algorithm and delayed ACK: https://developers.slashdot.org/comments.pl?sid=174457&cid=14515105 https://developers.slashdot.org/comments.pl?sid=174457&cid=1...

toast0 6y ago

Nagle is fine for web, as long as you flush when you reach the end of your request/response. And at strategic places like end of headers, end of html head, etc, if you know the content isn't directly forthcoming. A lot of HTTP software writes things to sockets in small chunks though, especially headers and what not. I've seen some things with chunked encoded posts; I don't think it was visible at the TCP level, but I would get three TLS application data segments, one for $SIZE\r\n, one for the size worth of data, and one for the trailing \r\n. Ugh.

reitzensteinm 6y ago
But it's there, as I understand it, mainly to combine multiple logical packets over a short human sized time scale. By its nature it also prevents fragmenting poorly written logical packets. But you could also do this as a separate level of protection. Say a 5ms delay on any write without a flush, any further write resets the delay, up until a maximum of 20ms. This would seem to reign in the worst of the behavior - developers not realizing they're sending multiple packets - without adding a large delay to developers using the system properly but not flushing. And since the penalty is much less, it would be less likely to be turned off aggressively, see the Go example in sibling comments. If the goal is to hand training wheels to developers of shitty apps, it's pretty important they actually use them.