 |
| 4 users recommended this comment. What they said: |
|
rb2k_ Sep 14, 2016 | on: Ask HN: What's your favorite HN post? | context
That time when John Nagle ("Animats") responded to a comment about Nagle's algorithm in TCP https://news.ycombinator.com/item?id=9048947 ( - "If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk." - "Are you John Nagle, or was that a quote?" ) |
|
onekorg Sep 20, 2020 | on: Ask HN: Your Favourite HN Comment? | context
John Nagle commenting on Nagle's algorithm: To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation. > Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay. > The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time. > If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk. > John Nagle |
|
evanelias May 9, 2024 | on: It's always TCP_NODELAY | context
John Nagle has posted insightful comments about the historical background for this many times, for example https://news.ycombinator.com/item?id=9048947 referenced in the article. He's a prolific HN commenter (#11 on the leaderboard) so it can be hard to find everything, but some more comments searchable via https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... or https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... |
|
rdtsc Mar 8, 2024 | on: NASA Unveils Design for Message Heading to Jupiter's Moon… | context
>> [cdelsolar] Are you a literary critic? > [jfengel] I am. (Or at least, adjacent to one, a Shakespeare scholar.) I love this about HN. It gave me "Are you John Nagle, or was that a quote?" classic vibes https://news.ycombinator.com/item?id=9048947 |
To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation.
Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.
The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.
If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.
John Nagle