3 ms·

The author of the original RFC 896 from 1984 and namesake of Nagle's algorithm is John Nagle who is an active user here on Hacker News: https://news.ycombinato

• anonymousiam 3y ago
  Thirty years ago when I was doing amateur packet radio, the digipeaters would often get crowded and collisions were frequent. If everyone played nice, the exponential backoff timers would work as expected, but it did not take long for people to learn that they could disable the Nagle algorithm, and/or increase the length of their (AX25) preamble so they would own the channel. Increasing the preamble meant that even if there was a collision, the longer preamble would use up enough time so that the "enemy" packet would be finished before the "evil" packet began to send the important bits, so it would be received properly. Disabling the Nagle algorithm (by hard-coding the backoff timer length to zero) would ensure that the "evil" transmitter would be the first one to key up after a collision. CSMA/CD works pretty well on a shared wire, but not very well on a single radio frequency where you cannot "hear" other people trying to reach the same mountain-top receiver. I'm glad that aspect of congestion is now a thing of the past. (Now that everything (wired) is switched, it's all point-to-point, so the only congestion we get is from insufficient bandwidth on the trunk, and we have ECN for that.)
  • 1letterunixname 3y ago
    Slotted aloha enters the chat to talk about the good ol' days. Unfortunately, there was a collision during TX and they had to start over.
  • Animats 3y ago
    > If everyone played nice, the exponential backoff timers would work as expected, Yes. As I wrote in 1985, in [1], under "Game Theoretic Aspects of Network Congestion" and "Fairness in Packet Switching Systems", about fair queuing, We would like to protect the network from hosts that are not well-behaved. More specifically, we would like, in the presence of both well-behaved and badly-behaved hosts, to insure that well-behaved hosts receive better service than badly-behaved hosts. We have devised a means of achieving this. The goal of fair queuing is not to improve network performance overall. The goal of fair queuing is to reward well-behaved hosts over badly-behaved hosts. If everyone is well-behaved, the queue lengths are the same, usually 1 or 0, and fair queuing does little. There is an inherent conflict between this goal and achieving maximum data transfer rates. If you try for near 100% utilization, the problems become much worse. You can run comfortably at maybe 70%. This was an accepted tradeoff for DoD systems. DoD wants things to keep working in a crisis, even if normal operation is a bit slower. This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and less immunity to gaming the system. I never wrote about that much at the time, because if I had, people would have realized earlier that traffic shaping is possible, which implies that you can sell and bill for bandwidth and quality of service. We might have ended up with pay per packet. [1] https://www.rfc-editor.org/pdfrfc/rfc970.txt.pdf https://www.rfc-editor.org/pdfrfc/rfc970.txt.pdf
    • throwawaaarrgh 3y ago
      Sales strategies optimize for groups of buyers, so we have pay per packet in categories. Some vendors market products based on traffic patterns, like unlimited transfer at a fixed throughput, limited transfer at unlimited throughput, rate-limited protocol layers, etc. You can absolutely find buyers who want to throw money at you for 100% utilization and then spend all their time in vain trying to get it to not be terrible.
    • o11c 3y ago
      > This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and less immunity to gaming the system. To be clear, are you mainly complaining about the multiple streams aspect here, or do you have other concerns? Because while I'm no expert, using HTTP/3 (or QUIC, I'm ignoring the terminology differences here to avoid confusion with pre-standard QUIC, though I guess maybe we're past that point by now?) with just a single stream seems to be the only scalable solution to a certain problem. The main problem I've had with TCP is that anybody can maliciously inject an RST, and for long-lived active connections, the chances of this happening approach 1. If you control both ends you can just tell your firewall to drop all RST packets so the applications can keep talking to each other, but ... Dealing with this at the application layer is ... marginally possible I guess, but not easy unless your application looks a lot like a web browser (and even those tend to usually force the end user to manually fix it). Creating a new TCP connection sucks and you have no idea how much data got dropped after it left the application's buffer. So we need a UDP reliability layer, since that's the only other general-purpose protocol that actually gets routed (and SCTP is flawed anyway). And dozens of those exist ... but almost none have major use, so I can't trust that they will play nice with the wider internet. With HTTP/3, if there are major flaws found, I have confidence that - like TCP - it has enough users that someone will come up with an acceptable solution. (admittedly, since it's not part of the kernel it will be harder to actually deploy the fix) (I guess TCP-over-VPN is also viable for some users)
      • fragmede 3y ago
        That's fascinating. RST packets are being generated by a malicious entity out there just throwing them around, to the point that the chances of that approaches 1. I've not seen this in the wild. Most firewalls I've seen will just silently start blocking packets if the connection is quiet for long enough, and not generate an RST. Is there anything you can share about your corner of the Internet where this is common?