--- 1/draft-ietf-tsvwg-udp-guidelines-00.txt 2007-06-11 22:12:29.000000000 +0200 +++ 2/draft-ietf-tsvwg-udp-guidelines-01.txt 2007-06-11 22:12:29.000000000 +0200 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia Intended status: Best Current G. Fairhurst Practice University of Aberdeen -Expires: November 29, 2007 May 28, 2007 +Expires: December 13, 2007 June 11, 2007 UDP Usage Guidelines for Application Designers - draft-ietf-tsvwg-udp-guidelines-00 + draft-ietf-tsvwg-udp-guidelines-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 29, 2007. + This Internet-Draft will expire on December 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the @@ -52,28 +52,29 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 7 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 8 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 14 + 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 9 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 1. Introduction The User Datagram Protocol (UDP) [RFC0768] provides a minimal, unreliable, message-passing transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document). Compared to other transport protocols, UDP and its UDP- Lite variant [RFC3828] are unique in that they do not establish end- to-end connections between communicating end systems. UDP communication consequently does not incur connection establishment @@ -99,21 +100,22 @@ up to the applications that use UDP for Internet communication to employ suitable mechanisms to prevent congestion collapse and establish a degree of fairness. [RFC2309] discusses the dangers of congestion-unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." This is an important requirement, even for applications that do not use UDP for streaming. For example, an application that generates five 1500-byte UDP packets in one second can already exceed the capacity of a 56 Kb/s path. For applications that can operate at higher, potentially unbounded data rates, - congestion control becomes vital. Section 3 describes a number of + congestion control becomes vital to prevent congestion collapse and + establish some degree of fairness. Section 3 describes a number of simple guidelines for the designers of such applications. A UDP message is carried in a single IP packet and is hence limited to a maximum payload of 65,487 bytes. The transmission of large IP packets frequently requires IP fragmentation, which decreases communication reliability and efficiency and should be avoided [I-D.heffner-frag-harmful]. Some of the guidelines in Section 3 describe how applications should determine appropriate message sizes. This document provides guidelines to designers of applications that @@ -389,37 +391,97 @@ Applications may still experience packet loss, rather than corruption, when using UDP-Lite. The enhancements offered by UDP- Lite rely upon a link being able to intercept the UDP-Lite header to correctly identify the partial-coverage required. When tunnels and/or encryption are used, this can result in UDP-Lite packets being treated the same as UDP packets, i.e., result in packet loss. Use of IP fragmentation can also prevent special treatment for UDP-Lite packets, and is another reason why applications SHOULD avoid IP fragmentation Section 3.2. +3.5. Middlebox Traversal Guidelines + + Network address translators (NATs) and firewalls are examples of + intermediary devices ("middleboxes") that can exist along an end-to- + end path. A middlebox typically perform a function that requires it + to maintain per-flow state. For connection-oriented protocols, such + as TCP, middleboxes snoop and parse the connection-management traffic + and create and destroy per-flow state accordingly. For a + connectionless protocol such as UDP, this approach is not possible. + Consequently, middleboxes may create per-flow state when they see a + packet that indicates a new flow, and destroy the state after some + period of time during which no packets belonging to the same flow + have arrived. + + Depending on the specific function that the middlebox performs, this + behavior can introduce a time-dependency that restricts the kinds of + UDP traffic exchanges that will be successful across it. For + example, NATs and firewalls typically define the partial path on one + side of them to be interior to the domain they control, whereas the + partial path on their other side is defined to be exterior to that + domain. Per-flow state is typically created when the first packet + crosses from the interior to the exterior, and while the state is + present, NATs and firewalls will forward return traffic. Return + traffic arriving after the per-flow state has timed out is dropped, + as is other traffic arriving from the exterior. + + Many applications use UDP for communication operate across + middleboxes without needing to employ additional mechanisms. One + example is the DNS, which has a strict request-response communication + pattern that typically completes within seconds. + + Other applications may experience communication failures when + middleboxes destroy the per-flow state associated with an application + session during periods when the application does not exchange any UDP + traffic. Applications SHOULD be able to gracefully handle such + communication failures and implement mechanisms to re-establish their + UDP sessions. + + Applications MAY in addition send periodic keep-alive messages to + attempt to refresh middlebox state. Unfortunately, no common timeout + has been specified for per-flow UDP state for arbitrary middleboxes. + For NATs, [RFC4787] requires a state timeout of 2 minutes or longer, + and it is likely that other types of middleboxes use timeouts of + similar timescales. Consequently, if applications choose to send + periodic keep-alives, they SHOULD NOT send them more frequently than + once every two minutes. + + It is important to note that sending keep-alives is not a substitute + for implementing a robust connection handling. Like all UDP + messages, keep-alives can be delayed or dropped, causing middlebox + state to time out. In addition, the congestion control guidelines in + Section 3.1 cover all UDP transmissions by an application, including + the transmission of middlebox keep-alives. Congestion control may + thus lead to delays or temporary suspension of keep-alive + transmission. + 4. Security Considerations [RFC2309] and [RFC2914] discuss the dangers of congestion- unresponsive flows to the Internet. This document provides guidelines to designers of UDP-based applications to congestion- control their transmissions. As such, it does not raise any additional security concerns. 5. IANA Considerations This document raises no IANA considerations. 6. Acknowledgments Thanks to Mark Allman, Sally Floyd, Joerg Ott, Colin Perkins, Pasi Sarolahti and Magnus Westerlund for their comments on this document. + The middlebox traversal guidelines in Section 3.5 incorporate ideas + from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh + and Dan Kegel. + 7. References 7.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. @@ -464,20 +526,25 @@ 7.2. Informative References [I-D.floyd-dccp-ccid4] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", draft-floyd-dccp-ccid4-00 (work in progress), November 2006. + [I-D.ford-behave-app] + Ford, B., "Application Design Guidelines for Traversal + through Network Address Translators", + draft-ford-behave-app-05 (work in progress), March 2007. + [I-D.heffner-frag-harmful] Heffner, J., "IPv4 Reassembly Errors at High Data Rates", draft-heffner-frag-harmful-05 (work in progress), May 2007. [I-D.ietf-dccp-rfc3448bis] Handley, M., "TCP Friendly Rate Control (TFRC): Protocol Specification", draft-ietf-dccp-rfc3448bis-01 (work in progress), March 2007. @@ -531,20 +598,24 @@ [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006. + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + Authors' Addresses Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com