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/