draft-ietf-tsvwg-udp-guidelines-00.txt   draft-ietf-tsvwg-udp-guidelines-01.txt 
Transport Area Working Group L. Eggert Transport Area Working Group L. Eggert
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Best Current G. Fairhurst Intended status: Best Current G. Fairhurst
Practice University of Aberdeen Practice University of Aberdeen
Expires: November 29, 2007 May 28, 2007 Expires: December 13, 2007 June 11, 2007
UDP Usage Guidelines for Application Designers UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-00 draft-ietf-tsvwg-udp-guidelines-01
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 29, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4
3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5
3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7
3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 7 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 7
3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 8 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
unreliable, message-passing transport to applications and upper-layer unreliable, message-passing transport to applications and upper-layer
protocols (both simply called "applications" in the remainder of this protocols (both simply called "applications" in the remainder of this
document). Compared to other transport protocols, UDP and its UDP- document). Compared to other transport protocols, UDP and its UDP-
Lite variant [RFC3828] are unique in that they do not establish end- Lite variant [RFC3828] are unique in that they do not establish end-
to-end connections between communicating end systems. UDP to-end connections between communicating end systems. UDP
communication consequently does not incur connection establishment communication consequently does not incur connection establishment
skipping to change at page 3, line 43 skipping to change at page 3, line 43
up to the applications that use UDP for Internet communication to up to the applications that use UDP for Internet communication to
employ suitable mechanisms to prevent congestion collapse and employ suitable mechanisms to prevent congestion collapse and
establish a degree of fairness. [RFC2309] discusses the dangers of establish a degree of fairness. [RFC2309] discusses the dangers of
congestion-unresponsive flows and states that "all UDP-based congestion-unresponsive flows and states that "all UDP-based
streaming applications should incorporate effective congestion streaming applications should incorporate effective congestion
avoidance mechanisms." This is an important requirement, even for avoidance mechanisms." This is an important requirement, even for
applications that do not use UDP for streaming. For example, an applications that do not use UDP for streaming. For example, an
application that generates five 1500-byte UDP packets in one second application that generates five 1500-byte UDP packets in one second
can already exceed the capacity of a 56 Kb/s path. For applications can already exceed the capacity of a 56 Kb/s path. For applications
that can operate at higher, potentially unbounded data rates, that can operate at higher, potentially unbounded data rates,
congestion control becomes vital. Section 3 describes a number of congestion control becomes vital to prevent congestion collapse and
establish some degree of fairness. Section 3 describes a number of
simple guidelines for the designers of such applications. simple guidelines for the designers of such applications.
A UDP message is carried in a single IP packet and is hence limited A UDP message is carried in a single IP packet and is hence limited
to a maximum payload of 65,487 bytes. The transmission of large IP to a maximum payload of 65,487 bytes. The transmission of large IP
packets frequently requires IP fragmentation, which decreases packets frequently requires IP fragmentation, which decreases
communication reliability and efficiency and should be avoided communication reliability and efficiency and should be avoided
[I-D.heffner-frag-harmful]. Some of the guidelines in Section 3 [I-D.heffner-frag-harmful]. Some of the guidelines in Section 3
describe how applications should determine appropriate message sizes. describe how applications should determine appropriate message sizes.
This document provides guidelines to designers of applications that This document provides guidelines to designers of applications that
skipping to change at page 9, line 47 skipping to change at page 9, line 47
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 packets being and/or encryption are used, this can result in UDP-Lite packets being
treated the same as UDP packets, i.e., result in packet loss. Use of treated the same as UDP packets, i.e., result in packet loss. Use of
IP fragmentation can also prevent special treatment for UDP-Lite IP fragmentation can also prevent special treatment for UDP-Lite
packets, and is another reason why applications SHOULD avoid IP packets, and is another reason why applications SHOULD avoid IP
fragmentation Section 3.2. 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 perform 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.
Consequently, middleboxes may create per-flow state when they see a
packet that indicates a new flow, and destroy the state after some
period of time during which no packets belonging to the same flow
have arrived.
Depending on the specific function that the middlebox performs, this
behavior can introduce a time-dependency that restricts the kinds of
UDP traffic exchanges that will be successful across it. For
example, NATs and firewalls typically define the partial path on one
side of them to be interior to the domain they control, whereas the
partial path on their other side is defined to be exterior to that
domain. Per-flow state is typically created when the first packet
crosses from the interior to the exterior, and while the state is
present, NATs and firewalls will forward return traffic. Return
traffic arriving after the per-flow state has timed out is dropped,
as is other traffic arriving from the exterior.
Many applications use UDP for communication operate across
middleboxes without needing to employ additional mechanisms. One
example is the DNS, which has a strict request-response communication
pattern that typically completes within seconds.
Other applications may experience communication failures when
middleboxes destroy the per-flow state associated with an application
session during periods when the application does not exchange any UDP
traffic. Applications SHOULD be able to gracefully handle such
communication failures and implement mechanisms to re-establish their
UDP sessions.
Applications MAY in addition send periodic keep-alive messages to
attempt to refresh middlebox state. Unfortunately, no common timeout
has been specified for per-flow UDP state for arbitrary middleboxes.
For NATs, [RFC4787] requires a state timeout of 2 minutes or longer,
and it is likely that other types of middleboxes use timeouts of
similar timescales. Consequently, if applications choose to send
periodic keep-alives, they SHOULD NOT send them more frequently than
once every two minutes.
It is important to note that sending keep-alives is not a substitute
for implementing a robust connection handling. Like all UDP
messages, keep-alives can be delayed or dropped, causing middlebox
state to time out. In addition, the congestion control guidelines in
Section 3.1 cover all UDP transmissions by an application, including
the transmission of middlebox keep-alives. Congestion control may
thus lead to delays or temporary suspension of keep-alive
transmission.
4. Security Considerations 4. Security Considerations
[RFC2309] and [RFC2914] discuss the dangers of congestion- [RFC2309] and [RFC2914] discuss the dangers of congestion-
unresponsive flows to the Internet. This document provides unresponsive flows to the Internet. This document provides
guidelines to designers of UDP-based applications to congestion- guidelines to designers of UDP-based applications to congestion-
control their transmissions. As such, it does not raise any control their transmissions. As such, it does not raise any
additional security concerns. additional security concerns.
5. IANA Considerations 5. IANA Considerations
This document raises no IANA considerations. This document raises no IANA considerations.
6. Acknowledgments 6. Acknowledgments
Thanks to Mark Allman, Sally Floyd, Joerg Ott, Colin Perkins, Pasi Thanks to Mark Allman, Sally Floyd, Joerg Ott, Colin Perkins, Pasi
Sarolahti and Magnus Westerlund for their comments on this document. Sarolahti and Magnus Westerlund for their comments on this document.
The middlebox traversal guidelines in Section 3.5 incorporate ideas
from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh
and Dan Kegel.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
skipping to change at page 11, line 30 skipping to change at page 12, line 42
7.2. Informative References 7.2. Informative References
[I-D.floyd-dccp-ccid4] [I-D.floyd-dccp-ccid4]
Floyd, S. and E. Kohler, "Profile for Datagram Congestion Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Control Protocol (DCCP) Congestion ID 4: TCP-Friendly
Rate Control for Small Packets (TFRC-SP)", Rate Control for Small Packets (TFRC-SP)",
draft-floyd-dccp-ccid4-00 (work in progress), draft-floyd-dccp-ccid4-00 (work in progress),
November 2006. November 2006.
[I-D.ford-behave-app]
Ford, B., "Application Design Guidelines for Traversal
through Network Address Translators",
draft-ford-behave-app-05 (work in progress), March 2007.
[I-D.heffner-frag-harmful] [I-D.heffner-frag-harmful]
Heffner, J., "IPv4 Reassembly Errors at High Data Rates", Heffner, J., "IPv4 Reassembly Errors at High Data Rates",
draft-heffner-frag-harmful-05 (work in progress), draft-heffner-frag-harmful-05 (work in progress),
May 2007. May 2007.
[I-D.ietf-dccp-rfc3448bis] [I-D.ietf-dccp-rfc3448bis]
Handley, M., "TCP Friendly Rate Control (TFRC): Protocol Handley, M., "TCP Friendly Rate Control (TFRC): Protocol
Specification", draft-ietf-dccp-rfc3448bis-01 (work in Specification", draft-ietf-dccp-rfc3448bis-01 (work in
progress), March 2007. progress), March 2007.
skipping to change at page 13, line 5 skipping to change at page 14, line 18
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006. March 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification", Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006. RFC 4654, August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
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
 End of changes. 9 change blocks. 
12 lines changed or deleted 83 lines changed or added

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