--- 1/draft-ietf-tsvwg-udp-guidelines-07.txt 2008-06-13 17:12:27.000000000 +0200 +++ 2/draft-ietf-tsvwg-udp-guidelines-08.txt 2008-06-13 17:12:27.000000000 +0200 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia Intended status: BCP G. Fairhurst -Expires: November 22, 2008 University of Aberdeen - May 21, 2008 +Expires: December 15, 2008 University of Aberdeen + June 13, 2008 Guidelines for Application Designers on Using Unicast UDP - draft-ietf-tsvwg-udp-guidelines-07 + draft-ietf-tsvwg-udp-guidelines-08 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 22, 2008. + This Internet-Draft will expire on December 15, 2008. 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 Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of @@ -132,35 +132,35 @@ This document provides guidelines and recommendations. Although most unicast UDP applications are expected to follow these guidelines, there do exist valid reasons why a specific application may decide not to follow a given guideline. In such cases, it is RECOMMENDED that the application designers document the rationale for their design choice in the technical specification of their application or protocol. This document provides guidelines to designers of applications that use UDP for unicast transmission, which is the most common case. - Specialized classed of applications use UDP for IP multicast + Specialized classes of applications use UDP for IP multicast [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions. The design of such specialized applications requires expertise that goes beyond the simple, unicast-specific guidelines given in this document. Multicast and broadcast senders may transmit to multiple receivers across potentially very heterogeneous paths at the same time, which significantly complicates congestion control, flow control and reliability mechanisms. The IETF has defined a reliable multicast framework [RFC3048] and several building blocks to aid the designers of multicast applications, such as [RFC3738] or [RFC4654]. Anycast senders must be aware that successive messages sent to the - same anycast address may be delivered to different underlying IP - addresses, i.e., arrive at different locations in the topology. It - is not intended that the guidelines in this document apply to - multicast, broadcast or anycast applications that use UDP. + same anycast IP address may be delivered to different anycast nodes, + i.e., arrive at different locations in the topology. It is not + intended that the guidelines in this document apply to multicast, + broadcast or anycast applications that use UDP. Finally, although this document specifically refers to unicast applications that use UDP, the spirit of some of its guidelines also applies to other message-passing applications and protocols (specifically on the topics of congestion control, message sizes and reliability). Examples include signaling or control applications that choose to run directly over IP by registering their own IP protocol number with IANA. This document may provide useful background reading to the designers of such applications and protocols. @@ -329,30 +329,30 @@ given application. TCP uses an initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and initial timeouts that are shorter than this are likely problematic in many cases. It is also important to note that the initial timeout is not the maximum possible timeout - the RECOMMENDED algorithm in [RFC2988] yields timeout values after a series of losses that are much longer than the initial value. Some applications cannot maintain a reliable RTT estimate for a - destination. The first case is applications that exchange too few - UDP datagrams with a peer to establish a statistically accurate RTT - estimate. Such applications MAY use a pre-determined transmission - interval that is exponentially backed-off when packets are lost. TCP - uses an initial value of 3 seconds [RFC2988], which is also - RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] - and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter - values are likely problematic in many cases. As in the previous - case, note that the initial timeout is not the maximum possible - timeout. + destination. The first case is that of applications that exchange + too few UDP datagrams with a peer to establish a statistically + accurate RTT estimate. Such applications MAY use a pre-determined + transmission interval that is exponentially backed-off when packets + are lost. TCP uses an initial value of 3 seconds [RFC2988], which is + also RECOMMENDED as an initial value for UDP applications. SIP + [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, + and shorter values are likely problematic in many cases. As in the + previous case, note that the initial timeout is not the maximum + possible timeout. A second class of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP datagram every 3 seconds, and SHOULD use an even less aggressive rate when possible. The 3-second interval was chosen based on TCP's retransmission timeout when the RTT is unknown [RFC2988], and shorter values are likely problematic in many cases. Note that the sending rate in this case must be more conservative than in the two previous cases, because the lack of return traffic prevents the detection of packet @@ -485,27 +485,27 @@ MTU information provided by the IP layer or implement path MTU discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation. Applications that do not follow this recommendation to do PMTU discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter that the default effective MTU for sending (EMTU_S - in [RFC1122]). EMTU_S is the smaller of 576 bytes and the first-hop - MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. The - effective PMTU for a directly connected destination (with no routers - on the path) is the configured interface MTU, which could be less - than the maximum link payload size. Transmission of minimum-sized - UDP datagrams is inefficient over paths that support a larger PMTU, - which is a second reason to implement PMTU discovery. + in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the + first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. + The effective PMTU for a directly connected destination (with no + routers on the path) is the configured interface MTU, which could be + less than the maximum link payload size. Transmission of minimum- + sized UDP datagrams is inefficient over paths that support a larger + PMTU, which is a second reason to implement PMTU discovery. To determine an appropriate UDP payload size, applications MUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length of the UDP header (8 bytes) from the PMTU size. This size, known as the MMS_S, can be obtained from the TCP/IP stack [RFC1122]. Applications that do not send messages that exceed the effective PMTU of IPv4 or IPv6 need not implement any of the above mechanisms. Note that the presence of tunnels can cause an additional reduction of the @@ -544,21 +544,21 @@ Finally, it is important to note that delay spikes can be very large. This can cause reordered packets to arrive many seconds after they were sent. [RFC0793] defines the the maximum delay a TCP segment should experience - the Maximum Segment Lifetime (MSL) - as 2 minutes. No other RFC defines an MSL for other transport protocols or IP itself. This document clarifies that the MSL value to be used for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD be robust to the reception of delayed or duplicate packets that are received within this 2-minute interval. - Applications that require reliable and ordered message delivery + An application that requires reliable and ordered message delivery SHOULD choose an IETF standard transport protocol that provides these features. If this is not possible, it will need to implement a set of appropriate mechanisms itself. 3.4. Checksum Guidelines The UDP header includes an optional, 16-bit ones-complement checksum that provides an integrity check. This results in a relatively weak protection from a coding point of view [RFC3819] and application developers SHOULD implement additional checks where data integrity is @@ -625,21 +625,21 @@ checksum coverage between the sender and receiver. 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 datagrams being treated the same as UDP datagrams, i.e., result in packet loss. Use of IP fragmentation can also prevent special treatment for UDP- Lite datagrams, and is another reason why applications SHOULD avoid - IP fragmentation Section 3.2. + 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 performs 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. @@ -718,21 +718,21 @@ sent can become the determining factor that governs power consumption, depending on the underlying network technology. Because many middleboxes are designed to require keep-alives for TCP connections at a frequency that is much lower than that needed for UDP, this difference alone can often be sufficient to prefer TCP over UDP for these deployments. On the other hand, there is anecdotal evidence that suggests that direct communication through middleboxes, e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often with TCP than with UDP. The tradeoffs between different transport protocols - especially when it comes to middlebox traversal - deserve - carful analysis. + careful analysis. 3.6. Programming Guidelines The de facto standard application programming interface (API) for TCP/IP applications is the "sockets" interface [POSIX]. Although this API was developed for UNIX in the early 1980s, a wide variety of non-UNIX operating systems also implements it. The sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs from that for TCP in several key ways. Because application programmers are typically more familiar with the TCP sockets API, the