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/