idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (July 9, 2007) is 6137 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-01 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-13 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group L. Eggert 3 Internet-Draft Nokia 4 Intended status: Best Current G. Fairhurst 5 Practice University of Aberdeen 6 Expires: January 10, 2008 July 9, 2007 8 UDP Usage Guidelines for Application Designers 9 draft-ietf-tsvwg-udp-guidelines-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The User Datagram Protocol (UDP) provides a minimal, message-passing 43 transport that has no inherent congestion control mechanisms. 44 Because congestion control is critical to the stable operation of the 45 Internet, applications and upper-layer protocols that choose to use 46 UDP as an Internet transport must employ mechanisms to prevent 47 congestion collapse and establish some degree of fairness with 48 concurrent traffic. This document provides guidelines on the use of 49 UDP for the designers of such applications and upper-layer protocols 50 that cover congestion-control and other topics, including message 51 sizes, reliability, checksums and middlebox traversal. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 59 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7 60 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 8 61 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 8 62 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 10 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 75 unreliable, best-effort, message-passing transport to applications 76 and upper-layer protocols (both simply called "applications" in the 77 remainder of this document). Compared to other transport protocols, 78 UDP and its UDP-Lite variant [RFC3828] are unique in that they do not 79 establish end-to-end connections between communicating end systems. 80 UDP communication consequently does not incur connection 81 establishment and teardown overheads and there is no associated end 82 system state. Because of these characteristics, UDP can offer a very 83 efficient communication transport to some applications. 85 A second unique characteristic of UDP is that it provides no inherent 86 congestion control mechanisms. [RFC2914] describes the best current 87 practice for congestion control in the Internet. It identifies two 88 major reasons why congestion control mechanisms are critical for the 89 stable operation of the Internet: 91 1. The prevention of congestion collapse, i.e., a state where an 92 increase in network load results in a decrease in useful work 93 done by the network. 95 2. The establishment of a degree of fairness, i.e., allowing 96 multiple flows to share the capacity of a path reasonably 97 equitably. 99 Because UDP itself provides no congestion control mechanisms, it is 100 up to the applications that use UDP for Internet communication to 101 employ suitable mechanisms to prevent congestion collapse and 102 establish a degree of fairness. [RFC2309] discusses the dangers of 103 congestion-unresponsive flows and states that "all UDP-based 104 streaming applications should incorporate effective congestion 105 avoidance mechanisms." This is an important requirement, even for 106 applications that do not use UDP for streaming. For example, an 107 application that generates five 1500-byte UDP packets in one second 108 can already exceed the capacity of a 56 Kb/s path. For applications 109 that can operate at higher, potentially unbounded data rates, 110 congestion control becomes vital to prevent congestion collapse and 111 establish some degree of fairness. Section 3 describes a number of 112 simple guidelines for the designers of such applications. 114 A UDP message is carried in a single IP packet and is hence limited 115 to a maximum payload of 65,487 bytes. The transmission of large IP 116 packets frequently requires IP fragmentation, which decreases 117 communication reliability and efficiency and should be avoided. One 118 reason for this decrease in reliability is because many NATs and 119 firewalls do not forward IP fragments; other reasons are documented 120 in [I-D.heffner-frag-harmful]. Some of the guidelines in Section 3 121 describe how applications should determine appropriate message sizes. 123 This document provides guidelines to designers of applications that 124 use UDP for unicast transmission. A special class of applications 125 uses UDP for IP multicast transmissions. Congestion control, flow 126 control or reliability for multicast transmissions is more difficult 127 to establish than for unicast transmissions, because a single sender 128 may transmit to multiple receivers across potentially very 129 heterogeneous paths at the same time. Designing multicast 130 applications requires expertise that goes beyond the simple 131 guidelines given in this document. The IETF has defined a reliable 132 multicast framework [RFC3048] and several building blocks to aid the 133 designers of multicast applications, such as [RFC3738] or [RFC4654]. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in BCP 14, RFC 2119 140 [RFC2119]. 142 3. UDP Usage Guidelines 144 The RECOMMENDED alternative to the UDP usage guidelines described in 145 this section is the use of a transport protocol that is congestion- 146 controlled, such as TCP [RFC0793], SCTP [RFC2960] or DCCP [RFC4340] 147 with its different congestion control types 148 [RFC4341][RFC4342][I-D.floyd-dccp-ccid4]. Congestion control 149 mechanisms are difficult to implement correctly, and for most 150 applications, the use of one of the existing, congestion-controlled 151 protocols is the simplest method of satisfying [RFC2914]. The same 152 is true for message size determination and reliability mechanisms. 154 If used correctly, congestion-controlled transport protocols are not 155 as "heavyweight" as often claimed. For example, TCP with SYN cookies 156 [I-D.ietf-tcpm-syn-flood], which are available on many platforms, 157 does not require a server to maintain per-connection state until the 158 connection is established. TCP also requires the end that closes a 159 connection to maintain the TIME-WAIT state that prevents delayed 160 segments from one connection instance to interfere with a later one. 161 Applications that are aware of this behavior can shift maintenance of 162 the TIME-WAIT state to conserve resources. Finally, TCP's built-in 163 capacity-probing and awareness of the maximum transmission unit 164 supported by the path (PMTU) results in efficient data transmission 165 that quickly compensates for the initial connection setup delay, for 166 transfers that exchange more than a few packets. 168 3.1. Congestion Control Guidelines 170 If an application or upper-layer protocol chooses not to use a 171 congestion-controlled transport protocol, it SHOULD control the rate 172 at which it sends UDP messages to a destination host. It is 173 important to stress that an application SHOULD perform congestion 174 control over all UDP traffic it sends to a destination, independent 175 of how it generates this traffic. For example, an application that 176 forks multiple worker processes or otherwise uses multiple sockets to 177 generate UDP messages SHOULD perform congestion control over the 178 aggregate traffic. The remainder of this section discusses several 179 approaches for this purpose. 181 It is important to note that congestion control should not be viewed 182 as an add-on to a finished application. Many of the mechanisms 183 discussed in the guidelines below require application support to 184 operate correctly. Application designers need to consider congestion 185 control throughout the design of their application, similar to how 186 they consider security aspects throughout the design process. 188 3.1.1. Bulk Transfer Applications 190 Applications that perform bulk transmission of data to a peer over 191 UDP SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC3448], 192 window-based, TCP-like congestion control, or otherwise ensure that 193 the application complies with the congestion control principles. 195 TFRC has been designed to provide both congestion control and 196 fairness in a way that is compatible with the IETF's other transport 197 protocols. TFRC is currently being updated 198 [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always 199 evaluate whether the latest published specification fits their needs. 200 If an application implements TFRC, it need not follow the remaining 201 guidelines in Section 3.1, because TFRC already addresses them, but 202 SHOULD still follow the remaining guidelines in the subsequent 203 subsections of Section 3. 205 Bulk transfer applications that choose not to implement TFRC or TCP- 206 like windowing SHOULD implement a congestion control scheme that 207 results in bandwidth use that competes fairly with TCP within an 208 order of magnitude. [RFC3551] suggests that applications SHOULD 209 monitor the packet loss rate to ensure that it is within acceptable 210 parameters. Packet loss is considered acceptable if a TCP flow 211 across the same network path under the same network conditions would 212 achieve an average throughput, measured on a reasonable timescale, 213 that is not less than that of the UDP flow. The comparison to TCP 214 cannot be specified exactly, but is intended as an "order-of- 215 magnitude" comparison in timescale and throughput. 217 Finally, some bulk transfer applications chose not to implement any 218 congestion control mechanism and instead rely on transmitting across 219 reserved path capacity. This might be an acceptable choice for a 220 subset of restricted networking environments, but is by no means a 221 safe practice for operation in the Internet. When the UDP traffic of 222 such applications leaks out on unprovisioned paths, results are 223 detrimental. 225 3.1.2. Low Data-Volume Applications 227 When applications that exchange only a small number of messages with 228 a destination at any time implement TFRC or one of the other 229 congestion control schemes in Section 3.1.1, the network sees little 230 benefit, because those mechanisms perform congestion control in a way 231 that is only effective for longer transmissions. 233 Applications that exchange only a small number of messages with a 234 destination at any time applications SHOULD still control their 235 transmission behavior by not sending more than one UDP message per 236 round-trip time (RTT) to a destination. Similar to the 237 recommendation in [RFC1536], an application SHOULD maintain an 238 estimate of the RTT for any destination it communicates with. 239 Applications SHOULD implement the algorithm specified in [RFC2988] to 240 compute a smoothed RTT (SRTT) estimate. A lost response from the 241 peer SHOULD be treated as a very large RTT sample, instead of being 242 ignored, in order to cause a sufficiently large (exponential) back- 243 off. When implementing this scheme, applications need to choose a 244 sensible initial value for the RTT. This value SHOULD generally be 245 as conservative as possible for the given application. TCP uses an 246 initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an 247 initial value for UDP applications. SIP [RFC3261] and GIST 248 [I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and initial 249 timeouts that are shorter than this are likely problematic in many 250 cases. It is also important to note that the initial timeout is not 251 the maximum possible timeout - the RECOMMENDED algorithm in [RFC2988] 252 yields timeout values after a series of losses that are much longer 253 than the initial value. 255 Some applications cannot maintain a reliable RTT estimate for a 256 destination. The first case is applications that exchange too few 257 messages with a peer to establish a statistically accurate RTT 258 estimate. Such applications MAY use a fixed transmission interval 259 that is exponentially backed-off during loss. TCP uses an initial 260 value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial 261 value for UDP applications. SIP [RFC3261] and GIST 263 [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter values 264 are likely problematic in many cases. As in the previous case, note 265 that the initial timeout is not the maximum possible timeout. 267 A second class of applications cannot maintain an RTT estimate for a 268 destination, because the destination does not send return traffic. 269 Such applications SHOULD NOT send more than one UDP message every 3 270 seconds, and SHOULD consider if they can use an even less aggressive 271 rate when possible. The 3-second interval was chosen based on TCP's 272 retransmission timeout when the RTT is unknown [RFC2988], and shorter 273 values are likely problematic in many cases. Note that the initial 274 timeout interval must be more conservative than in the two previous 275 cases, because the lack of return traffic prevents the detection of 276 packet loss, i.e., congestion events, and the application therefore 277 cannot perform exponential back-off to reduce load. 279 Applications that communicate bidirectionally SHOULD employ 280 congestion control for both directions of the communication. For 281 example, for a client-server, request-response-style application, 282 clients SHOULD congestion control their request transmission to a 283 server, and the server SHOULD congestion control its responses to the 284 clients. Congestion in the forward and reverse direction is 285 uncorrelated and an application SHOULD independently detect and 286 respond to congestion along both directions. 288 3.2. Message Size Guidelines 290 Because IP fragmentation lowers the efficiency and reliability of 291 Internet communication [I-D.heffner-frag-harmful], an application 292 SHOULD NOT send UDP messages that result in IP packets that exceed 293 the MTU of the path to the destination. Consequently, an application 294 SHOULD either use the path MTU information provided by the IP layer 295 or implement path MTU discovery itself [RFC1191][RFC1981][RFC4821] to 296 determine whether the path to a destination will support its desired 297 message size without fragmentation. 299 Applications that choose not adapt the packet size SHOULD NOT send 300 UDP messages that exceed the minimum PMTU. The minimum PMTU depends 301 on the IP version used for transmission, and is the lesser of 576 302 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for 303 IPv6 [RFC2460]. To determine an appropriate UDP payload size, 304 applications must subtract IP header and option lengths as well as 305 the length of the UDP header from the PMTU size. Transmission of 306 minimum-sized messages is inefficient over paths that support a 307 larger PMTU, which is a second reason to implement PMTU discovery. 309 Applications that do not send messages that exceed the minimum PMTU 310 of IPv4 or IPv6 need not implement any of the above mechanisms. 312 3.3. Reliability Guidelines 314 Application designers are generally aware that UDP does not provide 315 any reliability. Often, this is a main reason to consider UDP as a 316 transport. Applications that do require reliable message delivery 317 SHOULD implement an appropriate mechanism themselves. 319 UDP also does not protect against message duplication, i.e., an 320 application may receive multiple copies of the same message. 321 Application designers SHOULD consider whether their application 322 handles message duplication gracefully, and may need to implement 323 mechanisms to detect duplicates. Even if message reception triggers 324 idempotent operations, applications may want to suppress duplicate 325 messages to reduce load. 327 Finally, UDP messages may be reordered in the network and arrive at 328 the receiver in an order different from the transmission order. 329 Applications that require ordered delivery SHOULD reestablish message 330 ordering themselves. 332 3.4. Checksum Guidelines 334 The UDP header includes an optional, 16-bit ones' complement checksum 335 that provides an integrity check. The UDP checksum provides 336 assurance that the payload was not corrupted in transit. It also 337 verifies that the datagram was delivered to the intended end point, 338 because it covers the IP addresses, port numbers and protocol number, 339 and it verifies that the datagram is not truncated or padded, because 340 it covers the size field. It therefore protects an application 341 against receiving corrupted payload data in place of, or in addition 342 to, the data that was sent. 344 Applications SHOULD enable UDP checksums, although [RFC0793] permits 345 the option to disable their use. Applications that choose to disable 346 UDP checksums when transmitting over IPv4 therefore MUST NOT make 347 assumptions regarding the correctness of received data and MUST 348 behave correctly when a packet is received that was originally sent 349 to a different end point or is otherwise corrupted. The use of the 350 UDP checksum is MANDATORY when applications transmit UDP over IPv6 351 [RFC2460] and applications consequently MUST NOT disable their use. 352 (The IPv6 header does not have a separate checksum field to protect 353 the IP addressing information.) 355 The UDP checksum provides relatively weak protection from a coding 356 point of view [RFC3819] and, where data integrity is important, 357 application developers SHOULD provide additional checks, e.g., 358 through a CRC included with the data to verify the integrity of an 359 entire object/file sent over UDP service. 361 3.4.1. UDP-Lite 363 A special class of applications derive benefit from having partially 364 damaged payloads delivered rather than discarded when using paths 365 that include error-prone links. Such applications can tolerate 366 payload corruption and MAY choose to use the Lightweight User 367 Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 368 basic UDP. Applications that choose to use UDP-Lite instead of UDP 369 MUST still follow the congestion control and other guidelines 370 described for use with UDP in Section 3.1. 372 UDP-Lite changes the semantics of the UDP "payload length" field to 373 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 374 semantically identical to UDP. The interface of UDP-Lite differs 375 from that of UDP by the addition of a single (socket) option that 376 communicates a checksum coverage length value: at the sender, this 377 specifies the intended datagram checksum coverage, with the remaining 378 unprotected part of the payload called the "error insensitive part". 379 If required, an application may dynamically modify this length value, 380 e.g., to offer greater protection to some packets. UDP-Lite always 381 verifies that a datagram was delivered to the intended end point, 382 i.e., always verifies the header fields. Errors in the insensitive 383 part will not cause a packet to be discarded by the receiving end 384 host. Applications using UDP-Lite therefore MUST NOT make 385 assumptions regarding the correctness of the data received in the 386 insensitive part of the UDP-Lite payload. 388 The sending application SHOULD select the minimum checksum coverage 389 to include all sensitive protocol headers (e.g., the RTP header), 390 and, where appropriate, MUST also introduce their own appropriate 391 validity checks for protocol information carried in the insensitive 392 part of the UDP-Lite payload (e.g., internal CRCs). 394 The receiver MUST set a minimum coverage threshold for incoming 395 datagrams that is not smaller than the smallest coverage used by the 396 sender. This may be a fixed value, or may be negotiated by an 397 application. UDP-Lite does not provide mechanisms to negotiate the 398 checksum coverage between the sender and receiver. 400 Applications may still experience packet loss, rather than 401 corruption, when using UDP-Lite. The enhancements offered by UDP- 402 Lite rely upon a link being able to intercept the UDP-Lite header to 403 correctly identify the partial-coverage required. When tunnels 404 and/or encryption are used, this can result in UDP-Lite packets being 405 treated the same as UDP packets, i.e., result in packet loss. Use of 406 IP fragmentation can also prevent special treatment for UDP-Lite 407 packets, and is another reason why applications SHOULD avoid IP 408 fragmentation Section 3.2. 410 3.5. Middlebox Traversal Guidelines 412 Network address translators (NATs) and firewalls are examples of 413 intermediary devices ("middleboxes") that can exist along an end-to- 414 end path. A middlebox typically performs a function that requires it 415 to maintain per-flow state. For connection-oriented protocols, such 416 as TCP, middleboxes snoop and parse the connection-management traffic 417 and create and destroy per-flow state accordingly. For a 418 connectionless protocol such as UDP, this approach is not possible. 419 Consequently, middleboxes may create per-flow state when they see a 420 packet that indicates a new flow, and destroy the state after some 421 period of time during which no packets belonging to the same flow 422 have arrived. 424 Depending on the specific function that the middlebox performs, this 425 behavior can introduce a time-dependency that restricts the kinds of 426 UDP traffic exchanges that will be successful across it. For 427 example, NATs and firewalls typically define the partial path on one 428 side of them to be interior to the domain they control, whereas the 429 partial path on their other side is defined to be exterior to that 430 domain. Per-flow state is typically created when the first packet 431 crosses from the interior to the exterior, and while the state is 432 present, NATs and firewalls will forward return traffic. Return 433 traffic arriving after the per-flow state has timed out is dropped, 434 as is other traffic arriving from the exterior. 436 Many applications use UDP for communication operate across 437 middleboxes without needing to employ additional mechanisms. One 438 example is the DNS, which has a strict request-response communication 439 pattern that typically completes within seconds. 441 Other applications may experience communication failures when 442 middleboxes destroy the per-flow state associated with an application 443 session during periods when the application does not exchange any UDP 444 traffic. Applications SHOULD be able to gracefully handle such 445 communication failures and implement mechanisms to re-establish their 446 UDP sessions. 448 Applications MAY in addition send periodic keep-alive messages to 449 attempt to refresh middlebox state. Unfortunately, no common timeout 450 has been specified for per-flow UDP state for arbitrary middleboxes. 451 For NATs, [RFC4787] requires a state timeout of 2 minutes or longer, 452 and it is likely that other types of middleboxes use timeouts of 453 similar timescales. Consequently, if applications choose to send 454 periodic keep-alives, they SHOULD NOT send them more frequently than 455 once every two minutes. (Not that some deployed middleboxes use a 456 shorter timeout value than 2 minutes, violating [RFC4787].) 457 It is important to note that sending keep-alives is not a substitute 458 for implementing a robust connection handling. Like all UDP 459 messages, keep-alives can be delayed or dropped, causing middlebox 460 state to time out. In addition, the congestion control guidelines in 461 Section 3.1 cover all UDP transmissions by an application, including 462 the transmission of middlebox keep-alives. Congestion control may 463 thus lead to delays or temporary suspension of keep-alive 464 transmission. 466 4. Security Considerations 468 [RFC2309] and [RFC2914] discuss the dangers of congestion- 469 unresponsive flows to the Internet. This document provides 470 guidelines to designers of UDP-based applications to congestion- 471 control their transmissions. As such, it does not raise any 472 additional security concerns. 474 5. IANA Considerations 476 This document raises no IANA considerations. 478 6. Acknowledgments 480 Thanks to Mark Allman, Sally Floyd, Philip Matthews, Joerg Ott, Colin 481 Perkins, Pasi Sarolahti and Magnus Westerlund for their comments on 482 this document. 484 The middlebox traversal guidelines in Section 3.5 incorporate ideas 485 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 486 and Dan Kegel. 488 7. References 490 7.1. Normative References 492 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 493 August 1980. 495 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 496 RFC 793, September 1981. 498 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 499 November 1990. 501 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 502 for IP version 6", RFC 1981, August 1996. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 508 RFC 2914, September 2000. 510 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 511 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 512 Zhang, L., and V. Paxson, "Stream Control Transmission 513 Protocol", RFC 2960, October 2000. 515 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 516 Timer", RFC 2988, November 2000. 518 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 519 Friendly Rate Control (TFRC): Protocol Specification", 520 RFC 3448, January 2003. 522 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 523 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 524 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 525 RFC 3819, July 2004. 527 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 528 G. Fairhurst, "The Lightweight User Datagram Protocol 529 (UDP-Lite)", RFC 3828, July 2004. 531 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 532 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 534 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 535 Discovery", RFC 4821, March 2007. 537 7.2. Informative References 539 [I-D.floyd-dccp-ccid4] 540 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 541 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 542 Rate Control for Small Packets (TFRC-SP)", 543 draft-floyd-dccp-ccid4-01 (work in progress), July 2007. 545 [I-D.ford-behave-app] 546 Ford, B., "Application Design Guidelines for Traversal 547 through Network Address Translators", 548 draft-ford-behave-app-05 (work in progress), March 2007. 550 [I-D.heffner-frag-harmful] 551 Heffner, J., "IPv4 Reassembly Errors at High Data Rates", 552 draft-heffner-frag-harmful-05 (work in progress), 553 May 2007. 555 [I-D.ietf-dccp-rfc3448bis] 556 Handley, M., "TCP Friendly Rate Control (TFRC): Protocol 557 Specification", draft-ietf-dccp-rfc3448bis-01 (work in 558 progress), March 2007. 560 [I-D.ietf-nsis-ntlp] 561 Schulzrinne, H. and R. Hancock, "GIST: General Internet 562 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 563 progress), April 2007. 565 [I-D.ietf-tcpm-syn-flood] 566 Eddy, W., "TCP SYN Flooding Attacks and Common 567 Mitigations", draft-ietf-tcpm-syn-flood-05 (work in 568 progress), May 2007. 570 [RFC1122] Braden, R., "Requirements for Internet Hosts - 571 Communication Layers", STD 3, RFC 1122, October 1989. 573 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 574 Miller, "Common DNS Implementation Errors and Suggested 575 Fixes", RFC 1536, October 1993. 577 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 578 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 579 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 580 S., Wroclawski, J., and L. Zhang, "Recommendations on 581 Queue Management and Congestion Avoidance in the 582 Internet", RFC 2309, April 1998. 584 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 585 (IPv6) Specification", RFC 2460, December 1998. 587 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 588 Floyd, S., and M. Luby, "Reliable Multicast Transport 589 Building Blocks for One-to-Many Bulk-Data Transfer", 590 RFC 3048, January 2001. 592 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 593 A., Peterson, J., Sparks, R., Handley, M., and E. 594 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 595 June 2002. 597 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 598 Video Conferences with Minimal Control", STD 65, RFC 3551, 599 July 2003. 601 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 602 Control (WEBRC) Building Block", RFC 3738, April 2004. 604 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 605 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 606 Congestion Control", RFC 4341, March 2006. 608 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 609 Datagram Congestion Control Protocol (DCCP) Congestion 610 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 611 March 2006. 613 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 614 Congestion Control (TFMCC): Protocol Specification", 615 RFC 4654, August 2006. 617 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 618 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 619 RFC 4787, January 2007. 621 Authors' Addresses 623 Lars Eggert 624 Nokia Research Center 625 P.O. Box 407 626 Nokia Group 00045 627 Finland 629 Phone: +358 50 48 24461 630 Email: lars.eggert@nokia.com 631 URI: http://research.nokia.com/people/lars_eggert/ 633 Godred Fairhurst 634 University of Aberdeen 635 Department of Engineering 636 Fraser Noble Building 637 Aberdeen AB24 3UE 638 Scotland 640 Email: gorry@erg.abdn.ac.uk 641 URI: http://www.erg.abdn.ac.uk/ 643 Full Copyright Statement 645 Copyright (C) The IETF Trust (2007). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights. 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 654 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 655 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 656 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Acknowledgment 685 Funding for the RFC Editor function is provided by the IETF 686 Administrative Support Activity (IASA).