Content deleted Content added
Artoria2e5 (talk | contribs) Huh, the large write thing boils down to sources that talk about delayed ACK interaction. Consolidate. |
Artoria2e5 (talk | contribs) m →Large-write case: date |
||
Line 45:
The interaction between delayed ACK and Nagle also extends to 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 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>
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|date=1999|title=A Proposed Modification to Nagle’s Algorithm|draft=draft-minshall-nagle}}</ref> Again, disabling delayed ACK would remove the issue completely.
==Interactions with real-time systems==
| |||