draft-ietf-tsvwg-udp-guidelines-08.txt		draft-ietf-tsvwg-udp-guidelines-09.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: December 15, 2008 University of Aberdeen		Expires: January 9, 2009 University of Aberdeen
	June 13, 2008		July 8, 2008
	Guidelines for Application Designers on Using Unicast UDP		Guidelines for Application Designers on Using Unicast UDP
	draft-ietf-tsvwg-udp-guidelines-08		draft-ietf-tsvwg-udp-guidelines-09
	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 December 15, 2008.		This Internet-Draft will expire on January 9, 2009.
	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 2, line 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5		3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6		3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6
	3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11		3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11
	3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12		3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12
	3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13		3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13
	3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 14		3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15
	3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 16		3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17
	3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18		3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 18		4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 22		8.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	Intellectual Property and Copyright Statements . . . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . . . 27
	1. Introduction		1. Introduction
	skipping to change at page 6, line 48		skipping to change at page 6, line 48
	It is important to note that congestion control should not be viewed		It is important to note that congestion control should not be viewed
	as an add-on to a finished application. Many of the mechanisms		as an add-on to a finished application. Many of the mechanisms
	discussed in the guidelines below require application support to		discussed in the guidelines below require application support to
	operate correctly. Application designers need to consider congestion		operate correctly. Application designers need to consider congestion
	control throughout the design of their application, similar to how		control throughout the design of their application, similar to how
	they consider security aspects throughout the design process.		they consider security aspects throughout the design process.
	In the past, the IETF has also investigated integrated congestion		In the past, the IETF has also investigated integrated congestion
	control mechanisms that act on the traffic aggregate between two		control mechanisms that act on the traffic aggregate between two
	hosts, i.e., across all communication sessions active at a given time		hosts, i.e., a framework such as the Congestion Manager [RFC3124],
	independent of specific transport protocols, such as the Congestion		where active sessions may share current congestion information in a
	Manager [RFC3124]. Such mechanisms have failed to see deployment,		way that is independent of the transport protocol. Such mechanisms
	but would otherwise also fulfill the congestion control requirements		have failed to see deployment, but would otherwise simplify the
	in [RFC2914], because they provide congestion control for UDP		design of congestion control mechanisms for UDP sessions, so that
	sessions.		they fulfill the requirements in [RFC2914].
	3.1.1. Bulk Transfer Applications		3.1.1. Bulk Transfer Applications
	Applications that perform bulk transmission of data to a peer over		Applications that perform bulk transmission of data to a peer over
	UDP, i.e., applications that exchange more than a small number of UDP		UDP, i.e., applications that exchange more than a small number of UDP
	datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC)		datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC)
	[RFC3448], window-based, TCP-like congestion control, or otherwise		[RFC3448], window-based, TCP-like congestion control, or otherwise
	ensure that the application complies with the congestion control		ensure that the application complies with the congestion control
	principles.		principles.
	skipping to change at page 9, line 15		skipping to change at page 9, line 15
	because the lack of return traffic prevents the detection of packet		because the lack of return traffic prevents the detection of packet
	loss, i.e., congestion events, and the application therefore cannot		loss, i.e., congestion events, and the application therefore cannot
	perform exponential back-off to reduce load.		perform exponential back-off to reduce load.
	Applications that communicate bidirectionally SHOULD employ		Applications that communicate bidirectionally SHOULD employ
	congestion control for both directions of the communication. For		congestion control for both directions of the communication. For
	example, for a client-server, request-response-style application,		example, for a client-server, request-response-style application,
	clients SHOULD congestion control their request transmission to a		clients SHOULD congestion control their request transmission to a
	server, and the server SHOULD congestion-control its responses to the		server, and the server SHOULD congestion-control its responses to the
	clients. Congestion in the forward and reverse direction is		clients. Congestion in the forward and reverse direction is
	uncorrelated and an application SHOULD independently detect and		uncorrelated and an application SHOULD either independently detect
	respond to congestion along both directions.		and respond to congestion along both directions, or limit new and
			retransmitted requests based on acknowledged responses across the
			entire round trip path.
	3.1.3. UDP Tunnels		3.1.3. UDP Tunnels
	One increasingly popular use of UDP is as a tunneling protocol, where		One increasingly popular use of UDP is as a tunneling protocol, where
	a tunnel endpoint encapsulates the packets of another protocol inside		a tunnel endpoint encapsulates the packets of another protocol inside
	UDP datagrams and transmits them to another tunnel endpoint, which		UDP datagrams and transmits them to another tunnel endpoint, which
	decapsulates the UDP datagrams and forwards the original packets		decapsulates the UDP datagrams and forwards the original packets
	contained in the payload. Tunnels establish virtual links that		contained in the payload. Tunnels establish virtual links that
	appear to directly connect locations that are distant in the physical		appear to directly connect locations that are distant in the physical
	Internet topology, and can be used to create virtual (private)		Internet topology, and can be used to create virtual (private)
	skipping to change at page 13, line 24		skipping to change at page 13, line 26
	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
	important, e.g., through a Cyclic Redundancy Check (CRC) included		important, e.g., through a Cyclic Redundancy Check (CRC) included
	with the data to verify the integrity of an entire object/file sent		with the data to verify the integrity of an entire object/file sent
	over UDP service.		over UDP service.
	The UDP checksum provides assurance that the payload was not		The UDP checksum provides a statistical guarantee that the payload
	corrupted in transit. It also allows the receiver to verify that it		was not corrupted in transit. It also allows the receiver to verify
	was the intended destination of the packet, because it covers the IP		that it was the intended destination of the packet, because it covers
	addresses, port numbers and protocol number, and it verifies that the		the IP addresses, port numbers and protocol number, and it verifies
	packet is not truncated or padded, because it covers the size field.		that the packet is not truncated or padded, because it covers the
	It therefore protects an application against receiving corrupted		size field. It therefore protects an application against receiving
	payload data in place of, or in addition to, the data that was sent.		corrupted payload data in place of, or in addition to, the data that
			was sent. This check is not strong from a coding or cryptographic
			perspective, and is not designed to detect physical-layer errors or
			malicious modification of the datagram [RFC3819].
	Applications SHOULD enable UDP checksums, although [RFC0768] permits		Applications SHOULD enable UDP checksums, although [RFC0768] permits
	the option to disable their use. Applications that choose to disable		the option to disable their use. Applications that choose to disable
	UDP checksums when transmitting over IPv4 therefore MUST NOT make		UDP checksums when transmitting over IPv4 therefore MUST NOT make
	assumptions regarding the correctness of received data and MUST		assumptions regarding the correctness of received data and MUST
	behave correctly when a UDP datagram is received that was originally		behave correctly when a UDP datagram is received that was originally
	sent to a different destination or is otherwise corrupted. The use		sent to a different destination or is otherwise corrupted. The use
	of the UDP checksum is REQUIRED when applications transmit UDP over		of the UDP checksum is REQUIRED when applications transmit UDP over
	IPv6 [RFC2460].		IPv6 [RFC2460].
	skipping to change at page 14, line 12		skipping to change at page 14, line 16
	should still follow the congestion control and other guidelines		should still follow the congestion control and other guidelines
	described for use with UDP in Section 3.		described for use with UDP in Section 3.
	UDP-Lite changes the semantics of the UDP "payload length" field to		UDP-Lite changes the semantics of the UDP "payload length" field to
	that of a "checksum coverage length" field. Otherwise, UDP-Lite is		that of a "checksum coverage length" field. Otherwise, UDP-Lite is
	semantically identical to UDP. The interface of UDP-Lite differs		semantically identical to UDP. The interface of UDP-Lite differs
	from that of UDP by the addition of a single (socket) option that		from that of UDP by the addition of a single (socket) option that
	communicates a checksum coverage length value: at the sender, this		communicates a checksum coverage length value: at the sender, this
	specifies the intended checksum coverage, with the remaining		specifies the intended checksum coverage, with the remaining
	unprotected part of the payload called the "error insensitive part".		unprotected part of the payload called the "error insensitive part".
	If required, an application may dynamically modify this length value,		By default, the UDP-Lite checksum coverage extends across the entire
	e.g., to offer greater protection to some messages. UDP-Lite always		datagram. If required, an application may dynamically modify this
	verifies that a packet was delivered to the intended destination,		length value, e.g., to offer greater protection to some messages.
	i.e., always verifies the header fields. Errors in the insensitive		UDP-Lite always verifies that a packet was delivered to the intended
	part will not cause a UDP datagram to be discarded by the		destination, i.e., always verifies the header fields. Errors in the
			insensitive part will not cause a UDP datagram to be discarded by the
	destination. Applications using UDP-Lite therefore MUST NOT make		destination. Applications using UDP-Lite therefore MUST NOT make
	assumptions regarding the correctness of the data received in the		assumptions regarding the correctness of the data received in the
	insensitive part of the UDP-Lite payload.		insensitive part of the UDP-Lite payload.
	The sending application SHOULD select the minimum checksum coverage		The sending application SHOULD select the minimum checksum coverage
	to include all sensitive protocol headers. For example, applications		to include all sensitive protocol headers. For example, applications
	that use the Real-Time Protocol (RTP) [RFC3550] will likely want to		that use the Real-Time Protocol (RTP) [RFC3550] will likely want to
	protect the RTP header against corruption. Applications, where		protect the RTP header against corruption. Applications, where
	appropriate, MUST also introduce their own appropriate validity		appropriate, MUST also introduce their own appropriate validity
	checks for protocol information carried in the insensitive part of		checks for protocol information carried in the insensitive part of
	the UDP-Lite payload (e.g., internal CRCs).		the UDP-Lite payload (e.g., internal CRCs).
	The receiver MUST set a minimum coverage threshold for incoming		The receiver must set a minimum coverage threshold for incoming
	packets that is not smaller than the smallest coverage used by the		packets that is not smaller than the smallest coverage used by the
	sender. This may be a fixed value, or may be negotiated by an		sender [RFC3828]. The receiver SHOULD select a threshold that is
	application. UDP-Lite does not provide mechanisms to negotiate the		sufficiently large to block packets with an inappropriately short
	checksum coverage between the sender and receiver.		coverage field. This may be a fixed value, or may be negotiated by
			an application. UDP-Lite does not provide mechanisms to negotiate
			the 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).
	skipping to change at page 20, line 19		skipping to change at page 20, line 24
	| SHOULD use a full-featured transport (TCP, SCTP, DCCP) | |		| SHOULD use a full-featured transport (TCP, SCTP, DCCP) | |
	| | |		| | |
	| SHOULD control rate of transmission | 3.1 |		| SHOULD control rate of transmission | 3.1 |
	| SHOULD perform congestion control over all traffic | |		| SHOULD perform congestion control over all traffic | |
	| | |		| | |
	| for bulk transfers, | 3.1.1 |		| for bulk transfers, | 3.1.1 |
	| SHOULD consider implementing TFRC | |		| SHOULD consider implementing TFRC | |
	| else, SHOULD otherwise use bandwidth similar to TCP | |		| else, SHOULD otherwise use bandwidth similar to TCP | |
	| | |		| | |
	| for non-bulk transfers, | 3.1.2 |		| for non-bulk transfers, | 3.1.2 |
	| SHOULD measure RTT and transmit 1 datagram/RTT | |		| SHOULD measure RTT and transmit max. 1 datagram/RTT | |
	| else, SHOULD send at most 1 datagram every 3 seconds | |		| else, SHOULD send at most 1 datagram every 3 seconds | |
	| | |		| | |
	| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 |		| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 |
	| SHOULD discover PMTU or send datagrams < minimum PMTU | |		| SHOULD discover PMTU or send datagrams < minimum PMTU | |
	| | |		| | |
	| SHOULD handle datagram loss, duplication, reordering | 3.3 |		| SHOULD handle datagram loss, duplication, reordering | 3.3 |
	| SHOULD be robust to delivery delays up to 2 minutes | |		| SHOULD be robust to delivery delays up to 2 minutes | |
	| | |		| | |
	| SHOULD enable UDP checksum | 3.4 |		| SHOULD enable UDP checksum | 3.4 |
	| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 |		| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 |
	skipping to change at page 26, line 18		skipping to change at page 26, line 21
	Authors' Addresses		Authors' Addresses
	Lars Eggert		Lars Eggert
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	Nokia Group 00045		Nokia Group 00045
	Finland		Finland
	Phone: +358 50 48 24461		Phone: +358 50 48 24461
	Email: lars.eggert@nokia.com		Email: lars.eggert@nokia.com
	URI: http://research.nokia.com/people/lars_eggert/		URI: http://people.nokia.net/~lars/
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	Department of Engineering		Department of Engineering
	Fraser Noble Building		Fraser Noble Building
	Aberdeen AB24 3UE		Aberdeen AB24 3UE
	Scotland		Scotland
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	URI: http://www.erg.abdn.ac.uk/		URI: http://www.erg.abdn.ac.uk/
End of changes. 13 change blocks.
	33 lines changed or deleted		41 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/