Nagle's algorithm: Difference between revisions

Revision as of 16:40, 31 August 2023

Revision as of 16:50, 5 September 2023

Line 35:

</blockquote>

Nagle considers delayed ACKs a "bad idea", since the application layer does not usually respond within the time window.<ref>{{cite web|last1=Nagle|first1=John|title=Sigh. If you're doing bulk file transfers, you never hit that problem. (reply 9048947)|url=https://news.ycombinator.com/item?id=9048947|website=Hacker News|accessdate=9 May 2018}}</ref> For typical (non-realtime) use cases, he recommends disabling "delayed ACK" instead of his algorithm, as "quick" ACKs do not incur as much overhead as many small packets do for the same improvement in round-trip time.<ref name=hn9050645>{{cite web|last1=Nagle|first1=John|title=That fixed 200ms ACK delay timer was a horrible mistake. Why 200ms? Human reaction time. (reply 9050645)|url=https://news.ycombinator.com/item?id=9050645|website=Hacker News|accessdate=9 May 2018|quote=[...] One of the few legit cases for turning off the Nagle algorithm is for a FPS game running over the net. There, one-way latency matters; getting your shots and moves to the server before the other players affects gameplay.}}</ref>

=== Disabling either Nagle or delayed ACK ===

Line 42:

The interface for disabling delayed ACK is not consistent among systems. The {{code|TCP_QUICKACK}} flag is available on Linux since 2001 (2.4.4) and potentially on Windows, where the official interface is {{code|SIO_TCP_SET_ACK_FREQUENCY}}.<ref>{{cite web |title=sockets - C++ Disable Delayed Ack on Windows |url=https://stackoverflow.com/a/55035021 |website=Stack Overflow}}</ref> Setting <code>TcpAckFrequency</code> to 1 in the Windows registry turns off delayed ACK by default.<ref>{{cite web |url=https://support.microsoft.com/en-us/help/328890/new-registry-entry-for-controlling-the-tcp-acknowledgment-ack-behavior |title=New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003|date=23 February 2023 }}</ref>

===Large-write case===

==Negative effect on larger writes==

The Nagleinteraction algorithmbetween appliesdelayed toACK dataand writesNagle ofalso anyextends sizeto larger writes. If the data in a single write spans 2''n'' packets, where there are 2''n''-1 full-sized TCP segments followed by a partial TCP segment, the original Nagle algorithm would withhold the last packet, waiting for either more data to send (to fill the packet), or the ACK for the previous packet (indicating that all the previous packets have left the network). A delayed ACK would, again, add a maximum of 500&nbsp;ms before the last packet is sent.<ref>{{cite web|url=http://www.stuartcheshire.org/papers/NagleDelayedAck/ |title=TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK |publisher=Stuartcheshire.org |date= |accessdate=November 14, 2012}}</ref> This behavior limits performance for non-pipelined stop-and-wait request-response application protocol such as HTTP with persistent connection.<ref>{{cite journal|last = Heidemann | first = John | title = Performance Interactions Between P-HTTP and TCP Implementations|journal = Computer Communications Review|volume = 27|issue = 2|pages = 65–73|publisher = ACM|date = April 1997|doi = 10.1145/263876.263886| s2cid = 6992265 |doi-access = free}}</ref><ref>{{cite web|url=http://www.stuartcheshire.org/papers/NagleDelayedAck/ |title=TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK |publisher=Stuartcheshire.org |date= |accessdate=November 14, 2012}}</ref>

Minshall's modification to Nagle's algorithm makes it such that the algorithm always sends if the last packet is ''full-sized'', only waiting for an acknowledgement when the last packet is partial. The goal was to weaken the incentive for disabling Nagle by taking care of this large-write penalty.<ref>{{cite IETF|title=A Proposed Modification to Nagle’s Algorithm|draft=draft-minshall-nagle}}</ref> Again, disabling delayed ACK would remove the issue completely.

In any non-pipelined stop-and-wait request-response application protocol where request data can be larger than a packet, this can artificially impose a few hundred milliseconds latency between the requester and the responder. Originally this was not felt to be a problem, since any non-pipelined stop-and-wait protocol is probably not designed to achieve high performance in the first place, so a few hundred milliseconds extra delay should make little difference. A later refinement to Nagle’s algorithm, called Minshall’s Modification,<ref>{{cite IETF|title=A Proposed Modification to Nagle’s Algorithm|draft=draft-minshall-nagle}}</ref> solved this problem with stop-and-wait protocols that send one short message and then wait for an acknowledgement before sending the next, removing the incentive for them to disable Nagle’s algorithm (though such protocols will still be limited by their design to one message exchange per network round-trip time).

In general, since Nagle's algorithm is only a defense against careless applications, disabling Nagle’s algorithm will not benefit most carefully written applications that take proper care of buffering. Disabling Nagle’s algorithm will enable the application to have many small packets in flight on the network at once, instead of a smaller number of large packets, which may increase load on the network, and may or may not benefit the application performance.

==Interactions with real-time systems==

Applications that expect real-time responses and low [[latency (engineering)|latency]] can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing [[Bandwidth (computing)|bandwidth]] efficiency at the expense of one-way [[latency (engineering)|latency]].<ref name=hn9050645/> For this reason applications with low-bandwidth time-sensitive transmissions typically use <code>TCP_NODELAY</code> to bypass the Nagle-delayed ACK delay.<ref>[https://bugs.freedesktop.org/show_bug.cgi?id=17868 Bug 17868 &ndash; Some Java applications are slow on remote X connections].</ref>

Another option is to use [[User Datagram Protocol|UDP]] instead.