idnits 2.17.00 (12 Aug 2021) /tmp/idnits8731/draft-minshall-nagle-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 249 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1122], [RFC896]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 18, 1998) is 8554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 896 (Obsoleted by RFC 7805) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Greg Minshall 2 INTERNET-DRAFT Siara Systems 3 draft-minshall-nagle-00 December 18, 1998 5 A Suggested Modification to Nagle's Algorithm 7 Status of This Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- Drafts 17 as reference material or to cite them other than as ``work in 18 progress.'' 20 To view the entire list of current Internet-Drafts, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 25 West Coast). 27 This draft proposes a modification to Nagle's algorithm (as 28 specified in RFC896) to allow TCP, under certain conditions, to 29 send a small sized packet immediately after one or more maximum 30 segment sized packet. 32 Abstract 34 The Nagle algorithm is one of the primary mechanisms which protects 35 the internet from poorly designed and/or implemented applications. 36 However, for a certain class of applications (notably, 37 request-response protocols) the Nagle algorithm interacts poorly 38 with delayed acknowledgements to give these applications poorer 39 performance. 41 This draft is NOT suggesting that these applications should disable 42 the Nagle algorithm. 44 This draft suggests a fairly small and simple modification to the 45 Nagle algorithm to preserve Nagle as a means of protecting the 46 internet while at the same time giving better performance to a 47 wider class of applications. 49 Introduction to the Nagle algorithm 51 The Nagle algorithm [RFC896] protects the internet from 52 applications (most notably Telnet, at the time the algorithm was 53 developed) which tend to dribble small amounts of data to TCP. 54 Without the Nagle algorithm, TCP would transmit a packet, with a 55 small amount of data, in response to each of the application's 56 writes to TCP. With the Nagle algorithm, a first small packet will 57 be transmitted, then subsequent writes from the application will be 58 buffered at the sending TCP until either i) enough application data 59 has accumulated to enable TCP to transmit a maximum sized packet, 60 or ii) the initial small packet is acknowledged by the receiving 61 TCP. This limits the number of small packets to one per round trip 62 time. 64 While the current Nagle algorithm does a very good job of 65 protecting the internet from such applications, there are other 66 applications, such as request-response protocols (with HTTP 1.1 67 being a topical example) in which the current Nagle algorithm 68 produces non-optimal results. In this context, the Nagle algorithm 69 is interacting with TCP's ``delayed ACK'' policy [RFC1122]. 71 Delayed ACKs 73 A receiving TCP tries to avoid acknowledging every received data 74 packet. This process, known as ``delayed ACKing'' [RFC1122], 75 typically causes an ACK to be generated for every other received 76 (full-sized) data packet. In the case of an ``isolated'' TCP 77 packet (i.e., where a second TCP packet is not going to arrive 78 anytime soon), the delayed ACK policy causes an acknowledgement for 79 the data in the isolated packet to be sent within 200 milliseconds 80 of the receipt of the isolated packet. (The way delayed ACKs are 81 implemented in some systems causes the delayed ACK to be generated 82 anytime between 0 and 200ms; in this case, the average amount of 83 time before the delayed ACK is generated is 100ms.) 85 The interaction of delayed ACKs and Nagle 87 If a TCP has more application data to transmit than will fit in one 88 packet, but less than two full-sized packets' worth of data, it 89 will transmit the first packet. As a result of Nagle, it will not 90 transmit the second packet until the first packet has been 91 acknowledged. On the other hand, the receiving TCP will delay 92 acknowledging the first packet until either i) a second packet 93 arrives (which, in this case, won't arrive), or ii) approximately 94 100ms (and a maximum of 200ms) has elapsed. 96 When the sending TCP receives the delayed ACK, it can then transmit 97 its second packet. 99 In a request-response protocol, this second packet will complete 100 either a request or a response, which then enables a succeeding 101 response or request. 103 Note two (related) bad results of the interaction of delayed ACKs 104 and the Nagle algorithm in this case: the request-response time may 105 be increased by up to 400ms (if both the request and the response 106 are delayed); and, the number of transactions per second is 107 substantially reduced. 109 A proposed modification to the Nagle algorithm 111 The current Nagle algorithm can be described as follows: 113 If a TCP has less than a full-sized packet to transmit, 114 and if any previous packet has not yet been acknowledged, 115 do not transmit a packet. 117 The proposed Nagle algorithm modifies this as follows: 119 If a TCP has less than a full-sized packet to transmit, 120 and if any previous less than full-sized packet has not 121 yet been acknowledged, do not transmit a packet. 123 In other words, when running Nagle, only look at the recent 124 transmission (and acknowledgement) of small packets (rather than 125 all packets, as in the current Nagle). 127 (In writing the above, I am aware that TCP acknowledges BYTES, not 128 packets. However, expressing the algorithm in terms of packets 129 seems to make the explanation a bit clearer.) 131 Implementation of the modified Nagle algorithm in a system 133 The current Nagle algorithm does not require any more state to be 134 kept by TCP on a system. SND_NXT is a TCP variable which names the 135 next byte of data to be transmitted. SND_UNA is a TCP variable 136 which names the next byte of data to be acknowledged. If SND_NXT 137 equals SND_UNA, then all previous packets have been acknowledged. 139 The proposed modification to the Nagle algorithm does, 140 unfortunately, require one new state variable to be kept by TCP. 141 SND_SML is a TCP variable which names the last byte of data in the 142 most recently transmitted small packet. 144 An implementation could be as follows: 146 1. When transmitting a small packet, record the sequence 147 number of the last byte of the small packet in SND_SML. 149 2. When deciding whether or not to transmit a small packet, 150 check to ensure that SND_SML is less than, or equal to, 151 SND_UNA. 153 A Failure Mode 155 If an application sends a large amount of data, followed by a small 156 amount of data, followed by a large amount of data, the current 157 Nagle algorithm would perform better than the proposed 158 modification. The current Nagle algorithm would send at most one 159 small packet (possibly the last packet), delaying the middle 160 (small) amount of data which would allow the application to send 161 the following large amount of data; the proposed Nagle algorithm 162 would send two small packets (the middle packet, plus possibly a 163 last packet). 165 A separate, but desirable, system facility 167 In addition to the Nagle algorithm (or the modification proposed by 168 this draft), it would be desirable for a system providing TCP 169 service to applications to allow the application to set TCP into a 170 mode in which the TCP would only transmit small packets at the 171 explicit direction of the application. For example, a system based 172 on BSD might implement a socket option (using setsockopt(2)) 173 SO_EXPLICITPUSH, as well as a flag to sendto(2) (possibly 174 overloading the semantics of an existing flag, such as MSG_EOF). 176 In this scenario, an application would set a socket into 177 SO_EXPLICITPUSH mode, then enter a mode of writing data to the 178 socket and, at the last write, using send(2) with the MSG_EOF flag. 179 The underlying TCP would recognize the MSG_EOF flag as an indicator 180 to transmit the (possibly) small packet. 182 Like the proposed modification to the Nagle algorithm, this is 183 fairly simple to implement. 185 If a system were to implement this interface, it would be important 186 to NOT disable Nagle when using this interface. In other words, 187 when using this interface, the default mode for TCP would be to NOT 188 transmit a small packet (even in the presence of MSG_EOF) if a 189 previously transmitted small packet was as yet unacknowledged. 191 Note, also, that implementing this interface does not eliminate the 192 desirability of using the modification of the Nagle as the default 193 for applications. More sophisticated networking applications might 194 well use the new interface, but naive applications will often be 195 adequately served by the modified Nagle algorithm. 197 Acknowledgements 199 Jim Gettys, Henrik Frystyk Nielsen, Jeff Mogul, and Yasushi Saito, 200 as well as a message forwarded to the end2end-interest list by Sean 201 Doran, have motivated my current interest in the Nagle algorithm. 202 John Heidemann's work related to the Nagle algorithm has informed 203 some of the thinking in this draft; discussions with John have also 204 been helpful. Members of the End-to-End Research Group (under 205 the direction of Bob Braden) patiently listened to my discussion of 206 the current state of the Nagle algorithm and to the modifications 207 proposed in this document. 209 Security Considerations 211 The Nagle algorithm does not have major security consequences. 213 Implementation of this algorithm should not negatively impact 214 the performance of the internet. The negative impact of 215 implementation of this algorithm should be significantly less 216 than disabling the Nagle algorithm. 218 References 220 [RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", 221 Jan-06-1984. 222 [RFC1122] Braden, R. T., "Requirements for Internet hosts - 223 communication layers", Oct-01-1989. 225 Author's Addresses 227 Greg Minshall 228 Siara Systems 229 1399 Charleston Road 230 Mountain View, CA 94043 231 USA 233