idnits 2.17.1 draft-iyengar-burst-mitigation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2581], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3390' is mentioned on line 157, but not defined ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Janardhan Iyengar 2 INTERNET DRAFT University of Delaware 3 draft-iyengar-burst-mitigation-01.txt Mark Allman 4 Expires: July, 2006 ICIR/ICSI 5 Ethan Blanton 6 Purdue University 7 January, 2006 9 TCP Burst Mitigation Through Congestion Window Limiting 10 draft-iyengar-burst-mitigation-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes Congestion Window Limiting (CWL), a method 42 for mitigating micro-bursts in TCP by limiting the congestion window 43 during interruptions in TCP's acknowledgment clock. 45 Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC2119]. 51 The reader is expected to be familiar with terminology from 52 [RFC2581]. 54 1. Introduction 56 TCP dynamics and application sending patterns can cause a TCP sender 57 to inject bursts into the network with potentially harmful effects 58 for both the network and the sender. Bursting can stress network 59 queues causing loss in the bursting connection as well as in other 60 flows sharing the stressed queues. Bursting can also cause scaling 61 on short timescales [JD03] and increase queueing delays in routers. 62 This document draws from previously proposed burst mitigation 63 techniques and presents one possible technique to reduce some of 64 TCP's burstiness. 66 In this document, we are concerned with one type of bursting which 67 we call "micro-bursts". Micro-bursts are generated by a TCP in 68 response to changes in the cumulative acknowledgment point. Each 69 TCP segment carrying a cumulative acknowledgment (ACK) that slides 70 the sender's transmission window allows previously unsent data 71 segments to be transmitted (when application data is available). 72 These segments are ideally transmitted at the line rate of the 73 sender's network (assuming the host's CPU can produce packets fast 74 enough). We refer to such bursts of segments sent in response to 75 receipt of a single ACK as "micro-bursts". 77 TCP exhibits other bursting behaviors as well, which we collectively 78 term as "macro-bursts" since they tend to occur over longer 79 timescales than micro-bursts. Macro-bursts can be caused by several 80 TCP and/or network phenomena, such as slow start [RFC2581] and ACK 81 compression [ZSC91]. Although macro-bursts and their mitigation 82 have also been the topic of much research ([AB05] briefly discusses 83 this research), we limit ourselves to only micro-burst mitigation in 84 this document. 86 Several situations can cause micro-bursting: 88 * Although TCP's cumulative ACK mechanism is robust to loss, ACK 89 loss causes a TCP sender's transmission window to slide by a 90 greater amount with lesser frequency, potentially triggering large 91 micro-bursts in the process. 93 * An application can send data in a bursty fashion, causing TCP to 94 transmit micro-bursts. 96 * Reordered ACKs cause an ACK stream that appears similar to an ACK 97 stream with loss, causing similar micro-bursting. 99 * In some cases, when a TCP sender exits fast recovery, a large 100 number of segments are transmitted at line rate [FF96]. This 101 dynamic occurs when the sender cannot transmit enough new 102 segments during the recovery phase (e.g., due to ACK loss) and 103 therefore stores "permission to send" until a cumulative ACK 104 arrives. This phenomenon is discussed in [FF96], where the 105 "MaxBurst" mechanism is introduced to contain the consequent 106 burst (see discussion in section 3). 108 These and other causes of bursting are described in more detail in 109 [JD03,AB05]. 111 In this document, we present one possible method for mitigating TCP 112 micro-bursts called Congestion Window Limiting (CWL), which is based 113 on work in [HTH01] and originally outlined in [AB05]. Alternate 114 schemes have been proposed to mitigate the impact of micro-bursts, 115 as discussed in section 3. We note that the question of whether or 116 not micro-bursts need mitigation remains open. [JD03] suggests that 117 TCP's bursting may need mitigation from the perspective of the 118 network, while [BA05] suggests that micro-bursts often do not cause 119 loss within the bursting connection. By specifying a particular 120 mitigation technique this document intends to draw community 121 attention to the issue of micro-bursts, and attempts to generate 122 discussion and further exploration and experimentation in the area. 124 2. Congestion Window Limiting (CWL) 126 CWL introduces a new parameter called "BLimit", which represents the 127 largest acceptable micro-burst a TCP should transmit. 129 Each time an ACK is received that slides the transmission window, 130 the congestion window (cwnd) modification (increase or decrease) 131 procedures outlined in [RFC2581] MUST be applied. When using CWL, 132 the following steps MUST be executed before any data is sent in 133 response to the received ACK: 135 (1) If cwnd > (FlightSize + BLimit) TCP will likely send a 136 micro-burst and steps (2) and (3) MUST be used; otherwise, 137 skip (2) and (3) and transmit data as usual. If this 138 condition holds, the only case where a micro-burst will not 139 occur is when not enough application data is available to 140 transmit. 142 (2) If ssthresh < cwnd then ssthresh MUST be set to cwnd. 144 (3) Set cwnd = (FlightSize + BLimit). 146 After these steps, available application data should be transmitted 147 as allowed by the cwnd and the receiver's advertised window. 149 CWL controls bursts by reducing cwnd when the ACK clock is lost or 150 interrupted to the point where the cumulative ACK will trigger a 151 burst of segments in excess of BLimit. History information 152 maintained in ssthresh allows the connection to exponentially 153 increase the cwnd (via slow start) back to the size before the 154 reduction. 156 BLimit SHOULD be chosen such that bursts are no larger than those 157 allowed by [RFC3390]. From [RFC3390], we therefore choose: 159 BLimit = min (4*MSS, max (2*MSS, 4380 bytes)) (1) 161 If useful, BLimit MAY be smaller than allowed by equation (1). 163 3. Related Work 165 CWL makes TCP congestion control more conservative and is therefore 166 implicitly allowed by [RFC2581]. 168 Congestion Window Validation (CWV) [RFC2861] attempts to protect the 169 network from a sender's incorrect or stale view of the available 170 capacity along the path. [RFC2861] recommends (i) not increasing 171 the cwnd when it is not fully used by an application-limited sender, 172 and (ii) decaying the cwnd after a sufficiently long idle period to 173 avoid use of an unvalidated cwnd. [RFC2861] suggests reducing the 174 cwnd of an application-limited sender by half for each idle RTO 175 interval. While CWV can prevent micro-bursts in some situations, 176 this is accidental and not part of the problem CWV is trying to 177 solve. CWL, on the other hand, aims at preventing micro-bursts by 178 reducing the cwnd when appropriate, and in doing so, protects the 179 network from an application-limited sender with stale cwnd 180 information. CWL also prevents a cwnd from increasing during 181 application-limited periods by limiting it to (FlightSize + 182 BLimit). Note that CWL is more aggressive in reducing cwnd than 183 [RFC2861]. 185 Several techniques have been proposed in the past for controlling 186 micro-bursts, as follows: 188 * As noted above, [FF96] introduces the "MaxBurst" mechanism. 189 MaxBurst is an additional constraint that limits the number of 190 data segments that can be transmitted in response to any given 191 ACK. 193 CWL provides a single control for the amount of data a TCP 194 connection can transmit into the network at any given point. 195 This is arguably a clean approach to controlling the load 196 imposed on the network. On the other hand, by introducing a 197 second control, MaxBurst provides for separation of concerns. 198 In other words, limiting the sizes of micro-bursts is, in some 199 sense, a different task than limiting the overall transmission 200 rate to control network congestion; therefore, using two 201 different controls may make sense. An additional drawback of 202 MaxBurst is that the two transmission controllers may interact 203 poorly, causing undesirable side effects. When BLimit == 204 MaxBurst, CWL and MaxBurst perform similarly [AB05]. 206 * [HTH01] introduces an algorithm called "Use it or Lose it" 207 (UI/LI) which modifies the cwnd to reflect the actual 208 outstanding number of bytes, thereby controlling bursts in 209 response to an ack. UI/LI is used in SCTP [RFC2960,RA+05] and 210 provides the basis for CWL. CWL extends UI/LI by modifying 211 ssthresh and enabling a sender to slow start up to the last 212 known safe cwnd (step (2) in the algo above). In the absence of 213 explicitly setting ssthresh as part of the burst mitigation 214 process the UI/LI algorithm is non-deterministic in its use of 215 slow start after reducing cwnd. [AB05] illustrates cases where 216 slow start is used and cases where it is not used, simply 217 depending on the state of the connection before UI/LI reduces 218 the cwnd. 220 * Rate-Based Pacing [VH97] imposes a limitation on the rate of 221 sending, and prevent bursts by pacing data into the network 222 until the ACK clock is established. Although this solution can 223 be very effective in burst mitigation in some cases, it requires 224 a new timer and parameters for pacing out the data segments. 225 Further, as shown in [AB05], there are cases where there is no 226 natural "lull" in the connection into which segments can be 227 nicely paced. Therefore, the exact application of pacing 228 requires more research. 230 4. Discussion 232 We emphasize that the question of whether or not micro-bursts need 233 mitigation remains open. While this document provides the 234 specification for one mitigation technique based on current 235 knowledge, continued research on bursts and alternative mitigation 236 mechanisms is strongly encouraged. 238 Finally, we note that some TCP stacks may already implement some 239 form of micro-burst mitigation, although the mechanisms used may not 240 be well understood and have not been through IETF community 241 review. This document presents an initial step towards encouraging 242 better understood and community reviewed micro-burst mitigation 243 mechanisms. 245 5. Security Considerations 247 This document calls for reducing the congestion window during loss 248 of TCP's ACK clock. An attacker can therefore reduce throughput of 249 a TCP connection by causing ACK loss or reordering of data or acks. 251 6. IANA Considerations 253 None. 255 Acknowledgments 257 Discussions with Sally Floyd have shaped some of the thinking that 258 is contained in this document. 260 Normative References 262 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 263 Requirement Levels, March 1997. BCP 14, RFC 2119. 265 [RFC2581] M. Allman, V. Paxson, W. Stevens. TCP Congestion Control, 266 April 1999. RFC 2581. 268 Informative References 270 [RFC2861] M. Handley, J. Padhye, S. Floyd. TCP Congestion Window 271 Validation, June 2000. RFC 2861. 273 [AB05] M. Allman, E. Blanton. Notes on Burst Mitigation for 274 Transport Protocols. ACM Computer Communication Review, 35(2), 275 April 2005. 277 [BA05] E. Blanton, M. Allman. On the Impact of Bursting on TCP 278 Performance. Proceedings of the Workshop for Passive and Active 279 Measurement, March 2005. 281 [FF96] K. Fall, S. Floyd. Simulation-based Comparisons of Tahoe, 282 Reno, and SACK TCP. Computer Communication Review, 26(3), July 283 1996. 285 [HTH01] A. Hughes, J. Touch, J. Heidemann. Issues in TCP Slow-Start 286 Restart After Idle. Internet draft 287 , December 2001 (expired). 288 URL: http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt. 290 [JD03] H. Jiang, C. Dovrolis. Source-Level IP Packet Bursts: Causes 291 and Effects. In ACM SIGCOMM/Usenix Internet Measurement 292 Conference, October 2003. 294 [SA+05] R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, 295 M. Tuexen. SCTP Specification Errata and Issues. Internet draft 296 , October 2005 (work in 297 progress). 299 [VH97] V. Visweswaraiah and J. Heidemann. Improving Restart of 300 Idle TCP Connections. Technical Report 97-661, University of 301 Southern California, November 1997. 303 [ZSC91] L. Zhang, S. Shenker, and D. Clark. Observations on the 304 Dynamics of a Congestion Control Algorithm: The Effects of 305 Two-Way Traffic. ACM SIGCOMM, September 1991. 307 Author's Addresses 309 Janardhan Iyengar 310 Protocol Engineering Lab, CIS Department 311 University of Delaware 312 103 Smith Hall 313 Newark, DE 19716 314 Email: iyengar@cis.udel.edu 315 URL: http//www.cis.udel.edu/~iyengar/ 317 Mark Allman 318 ICSI Center for Internet Research 319 1947 Center Street, Suite 600 320 Berkeley, CA 94704-1198 321 Phone: (440) 235-1792 322 Email: mallman@icir.org 323 URL: http://www.icir.org/mallman/ 325 Ethan Blanton 326 Purdue University Computer Sciences 327 250 North University Street 328 West Lafayette, IN 47907 329 Email: eblanton@cs.purdue.edu 330 URL: http://www.cs.purdue.edu/homes/eblanton/ 332 Intellectual Property Statement 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed 336 to pertain to the implementation or use of the technology described 337 in this document or the extent to which any license under such 338 rights might or might not be available; nor does it represent that 339 it has made any independent effort to identify any such rights. 340 Information on the procedures with respect to rights in RFC 341 documents can be found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use 346 of such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository 348 at http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Disclaimer of Validity 358 This document and the information contained herein are provided on 359 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 360 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 361 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 362 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 363 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 366 Copyright Statement 368 Copyright (C) The Internet Society (2006). This document is subject 369 to the rights, licenses and restrictions contained in BCP 78, and 370 except as set forth therein, the authors retain all their rights. 372 Acknowledgment 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.