draft-ietf-tsvwg-udp-guidelines-07.txt   draft-ietf-tsvwg-udp-guidelines-08.txt 
Transport Area Working Group L. Eggert Transport Area Working Group L. Eggert
Internet-Draft Nokia Internet-Draft Nokia
Intended status: BCP G. Fairhurst Intended status: BCP G. Fairhurst
Expires: November 22, 2008 University of Aberdeen Expires: December 15, 2008 University of Aberdeen
May 21, 2008 June 13, 2008
Guidelines for Application Designers on Using Unicast UDP Guidelines for Application Designers on Using Unicast UDP
draft-ietf-tsvwg-udp-guidelines-07 draft-ietf-tsvwg-udp-guidelines-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Abstract
The User Datagram Protocol (UDP) provides a minimal, message-passing The User Datagram Protocol (UDP) provides a minimal, message-passing
transport that has no inherent congestion control mechanisms. transport that has no inherent congestion control mechanisms.
Because congestion control is critical to the stable operation of the Because congestion control is critical to the stable operation of the
Internet, applications and upper-layer protocols that choose to use Internet, applications and upper-layer protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent UDP as an Internet transport must employ mechanisms to prevent
congestion collapse and establish some degree of fairness with congestion collapse and establish some degree of fairness with
concurrent traffic. This document provides guidelines on the use of concurrent traffic. This document provides guidelines on the use of
skipping to change at page 4, line 26 skipping to change at page 4, line 26
This document provides guidelines and recommendations. Although most This document provides guidelines and recommendations. Although most
unicast UDP applications are expected to follow these guidelines, unicast UDP applications are expected to follow these guidelines,
there do exist valid reasons why a specific application may decide there do exist valid reasons why a specific application may decide
not to follow a given guideline. In such cases, it is RECOMMENDED not to follow a given guideline. In such cases, it is RECOMMENDED
that the application designers document the rationale for their that the application designers document the rationale for their
design choice in the technical specification of their application or design choice in the technical specification of their application or
protocol. protocol.
This document provides guidelines to designers of applications that This document provides guidelines to designers of applications that
use UDP for unicast transmission, which is the most common case. 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. [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions.
The design of such specialized applications requires expertise that The design of such specialized applications requires expertise that
goes beyond the simple, unicast-specific guidelines given in this goes beyond the simple, unicast-specific guidelines given in this
document. Multicast and broadcast senders may transmit to multiple document. Multicast and broadcast senders may transmit to multiple
receivers across potentially very heterogeneous paths at the same receivers across potentially very heterogeneous paths at the same
time, which significantly complicates congestion control, flow time, which significantly complicates congestion control, flow
control and reliability mechanisms. The IETF has defined a reliable control and reliability mechanisms. The IETF has defined a reliable
multicast framework [RFC3048] and several building blocks to aid the multicast framework [RFC3048] and several building blocks to aid the
designers of multicast applications, such as [RFC3738] or [RFC4654]. designers of multicast applications, such as [RFC3738] or [RFC4654].
Anycast senders must be aware that successive messages sent to the Anycast senders must be aware that successive messages sent to the
same anycast address may be delivered to different underlying IP same anycast IP address may be delivered to different anycast nodes,
addresses, i.e., arrive at different locations in the topology. It i.e., arrive at different locations in the topology. It is not
is not intended that the guidelines in this document apply to intended that the guidelines in this document apply to multicast,
multicast, broadcast or anycast applications that use UDP. broadcast or anycast applications that use UDP.
Finally, although this document specifically refers to unicast Finally, although this document specifically refers to unicast
applications that use UDP, the spirit of some of its guidelines also applications that use UDP, the spirit of some of its guidelines also
applies to other message-passing applications and protocols applies to other message-passing applications and protocols
(specifically on the topics of congestion control, message sizes and (specifically on the topics of congestion control, message sizes and
reliability). Examples include signaling or control applications reliability). Examples include signaling or control applications
that choose to run directly over IP by registering their own IP that choose to run directly over IP by registering their own IP
protocol number with IANA. This document may provide useful protocol number with IANA. This document may provide useful
background reading to the designers of such applications and background reading to the designers of such applications and
protocols. protocols.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
given application. TCP uses an initial value of 3 seconds [RFC2988], given application. TCP uses an initial value of 3 seconds [RFC2988],
which is also RECOMMENDED as an initial value for UDP applications. 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 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 500 ms, and initial timeouts that are shorter than this are likely
problematic in many cases. It is also important to note that the problematic in many cases. It is also important to note that the
initial timeout is not the maximum possible timeout - the RECOMMENDED initial timeout is not the maximum possible timeout - the RECOMMENDED
algorithm in [RFC2988] yields timeout values after a series of losses algorithm in [RFC2988] yields timeout values after a series of losses
that are much longer than the initial value. that are much longer than the initial value.
Some applications cannot maintain a reliable RTT estimate for a Some applications cannot maintain a reliable RTT estimate for a
destination. The first case is applications that exchange too few destination. The first case is that of applications that exchange
UDP datagrams with a peer to establish a statistically accurate RTT too few UDP datagrams with a peer to establish a statistically
estimate. Such applications MAY use a pre-determined transmission accurate RTT estimate. Such applications MAY use a pre-determined
interval that is exponentially backed-off when packets are lost. TCP transmission interval that is exponentially backed-off when packets
uses an initial value of 3 seconds [RFC2988], which is also are lost. TCP uses an initial value of 3 seconds [RFC2988], which is
RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] also RECOMMENDED as an initial value for UDP applications. SIP
and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms,
values are likely problematic in many cases. As in the previous and shorter values are likely problematic in many cases. As in the
case, note that the initial timeout is not the maximum possible previous case, note that the initial timeout is not the maximum
timeout. possible timeout.
A second class of applications cannot maintain an RTT estimate for a A second class of applications cannot maintain an RTT estimate for a
destination, because the destination does not send return traffic. destination, because the destination does not send return traffic.
Such applications SHOULD NOT send more than one UDP datagram every 3 Such applications SHOULD NOT send more than one UDP datagram every 3
seconds, and SHOULD use an even less aggressive rate when possible. seconds, and SHOULD use an even less aggressive rate when possible.
The 3-second interval was chosen based on TCP's retransmission The 3-second interval was chosen based on TCP's retransmission
timeout when the RTT is unknown [RFC2988], and shorter values are timeout when the RTT is unknown [RFC2988], and shorter values are
likely problematic in many cases. Note that the sending rate in this likely problematic in many cases. Note that the sending rate in this
case must be more conservative than in the two previous cases, case must be more conservative than in the two previous cases,
because the lack of return traffic prevents the detection of packet because the lack of return traffic prevents the detection of packet
skipping to change at page 11, line 46 skipping to change at page 11, line 46
MTU information provided by the IP layer or implement path MTU MTU information provided by the IP layer or implement path MTU
discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the
path to a destination will support its desired message size without path to a destination will support its desired message size without
fragmentation. fragmentation.
Applications that do not follow this recommendation to do PMTU Applications that do not follow this recommendation to do PMTU
discovery SHOULD still avoid sending UDP datagrams that would result discovery SHOULD still avoid sending UDP datagrams that would result
in IP packets that exceed the path MTU. Because the actual path MTU in IP packets that exceed the path MTU. Because the actual path MTU
is unknown, such applications SHOULD fall back to sending messages is unknown, such applications SHOULD fall back to sending messages
that are shorter that the default effective MTU for sending (EMTU_S 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 in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the
MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. The first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460].
effective PMTU for a directly connected destination (with no routers The effective PMTU for a directly connected destination (with no
on the path) is the configured interface MTU, which could be less routers on the path) is the configured interface MTU, which could be
than the maximum link payload size. Transmission of minimum-sized less than the maximum link payload size. Transmission of minimum-
UDP datagrams is inefficient over paths that support a larger PMTU, sized UDP datagrams is inefficient over paths that support a larger
which is a second reason to implement PMTU discovery. PMTU, which is a second reason to implement PMTU discovery.
To determine an appropriate UDP payload size, applications MUST To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4 optional 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 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, header (8 bytes) from the PMTU size. This size, known as the MMS_S,
can be obtained from the TCP/IP stack [RFC1122]. can be obtained from the TCP/IP stack [RFC1122].
Applications that do not send messages that exceed the effective PMTU Applications that do not send messages that exceed the effective PMTU
of IPv4 or IPv6 need not implement any of the above mechanisms. Note 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 that the presence of tunnels can cause an additional reduction of the
skipping to change at page 13, line 9 skipping to change at page 13, line 9
Finally, it is important to note that delay spikes can be very large. Finally, it is important to note that delay spikes can be very large.
This can cause reordered packets to arrive many seconds after they This can cause reordered packets to arrive many seconds after they
were sent. [RFC0793] defines the the maximum delay a TCP segment were sent. [RFC0793] defines the the maximum delay a TCP segment
should experience - the Maximum Segment Lifetime (MSL) - as 2 should experience - the Maximum Segment Lifetime (MSL) - as 2
minutes. No other RFC defines an MSL for other transport protocols minutes. No other RFC defines an MSL for other transport protocols
or IP itself. This document clarifies that the MSL value to be used 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 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 be robust to the reception of delayed or duplicate packets that are
received within this 2-minute interval. 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 SHOULD choose an IETF standard transport protocol that provides these
features. If this is not possible, it will need to implement a set features. If this is not possible, it will need to implement a set
of appropriate mechanisms itself. of appropriate mechanisms itself.
3.4. Checksum Guidelines 3.4. Checksum Guidelines
The UDP header includes an optional, 16-bit ones-complement checksum The UDP header includes an optional, 16-bit ones-complement checksum
that provides an integrity check. This results in a relatively weak that provides an integrity check. This results in a relatively weak
protection from a coding point of view [RFC3819] and application protection from a coding point of view [RFC3819] and application
developers SHOULD implement additional checks where data integrity is developers SHOULD implement additional checks where data integrity is
skipping to change at page 14, line 43 skipping to change at page 14, line 43
checksum coverage between the sender and receiver. checksum coverage between the sender and receiver.
Applications may still experience packet loss, rather than Applications may still experience packet loss, rather than
corruption, when using UDP-Lite. The enhancements offered by UDP- corruption, when using UDP-Lite. The enhancements offered by UDP-
Lite rely upon a link being able to intercept the UDP-Lite header to Lite rely upon a link being able to intercept the UDP-Lite header to
correctly identify the partial coverage required. When tunnels correctly identify the partial coverage required. When tunnels
and/or encryption are used, this can result in UDP-Lite datagrams 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. being treated the same as UDP datagrams, i.e., result in packet loss.
Use of IP fragmentation can also prevent special treatment for UDP- Use of IP fragmentation can also prevent special treatment for UDP-
Lite datagrams, and is another reason why applications SHOULD avoid 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 3.5. Middlebox Traversal Guidelines
Network address translators (NATs) and firewalls are examples of Network address translators (NATs) and firewalls are examples of
intermediary devices ("middleboxes") that can exist along an end-to- intermediary devices ("middleboxes") that can exist along an end-to-
end path. A middlebox typically performs a function that requires it end path. A middlebox typically performs a function that requires it
to maintain per-flow state. For connection-oriented protocols, such to maintain per-flow state. For connection-oriented protocols, such
as TCP, middleboxes snoop and parse the connection-management traffic as TCP, middleboxes snoop and parse the connection-management traffic
and create and destroy per-flow state accordingly. For a and create and destroy per-flow state accordingly. For a
connectionless protocol such as UDP, this approach is not possible. connectionless protocol such as UDP, this approach is not possible.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
sent can become the determining factor that governs power sent can become the determining factor that governs power
consumption, depending on the underlying network technology. Because consumption, depending on the underlying network technology. Because
many middleboxes are designed to require keep-alives for TCP many middleboxes are designed to require keep-alives for TCP
connections at a frequency that is much lower than that needed for 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, this difference alone can often be sufficient to prefer TCP over
UDP for these deployments. On the other hand, there is anecdotal UDP for these deployments. On the other hand, there is anecdotal
evidence that suggests that direct communication through middleboxes, evidence that suggests that direct communication through middleboxes,
e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often
with TCP than with UDP. The tradeoffs between different transport with TCP than with UDP. The tradeoffs between different transport
protocols - especially when it comes to middlebox traversal - deserve protocols - especially when it comes to middlebox traversal - deserve
carful analysis. careful analysis.
3.6. Programming Guidelines 3.6. Programming Guidelines
The de facto standard application programming interface (API) for The de facto standard application programming interface (API) for
TCP/IP applications is the "sockets" interface [POSIX]. Although TCP/IP applications is the "sockets" interface [POSIX]. Although
this API was developed for UNIX in the early 1980s, a wide variety of this API was developed for UNIX in the early 1980s, a wide variety of
non-UNIX operating systems also implements it. The sockets API non-UNIX operating systems also implements it. The sockets API
supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs
from that for TCP in several key ways. Because application from that for TCP in several key ways. Because application
programmers are typically more familiar with the TCP sockets API, the programmers are typically more familiar with the TCP sockets API, the
 End of changes. 10 change blocks. 
29 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/