draft-ietf-tsvwg-udp-guidelines-09.txt   draft-ietf-tsvwg-udp-guidelines-10.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: January 9, 2009 University of Aberdeen Expires: February 23, 2009 University of Aberdeen
July 8, 2008 August 22, 2008
Guidelines for Application Designers on Using Unicast UDP Unicast UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-09 draft-ietf-tsvwg-udp-guidelines-10
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 January 9, 2009. This Internet-Draft will expire on February 23, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . 15 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15
3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
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
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
skipping to change at page 7, line 22 skipping to change at page 7, line 22
[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.
TFRC has been designed to provide both congestion control and TFRC has been designed to provide both congestion control and
fairness in a way that is compatible with the IETF's other transport fairness in a way that is compatible with the IETF's other transport
protocols. TFRC is currently being updated protocols. TFRC is currently being updated
[I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always
evaluate whether the latest published specification fits their needs. evaluate whether the latest published specification fits their needs.
If an application implements TFRC, it need not follow the remaining If an application implements TFRC, it need not follow the remaining
guidelines in Section 3.1, because TFRC already addresses them, but guidelines in Section 3.1.1, because TFRC already addresses them, but
SHOULD still follow the remaining guidelines in the subsequent SHOULD still follow the remaining guidelines in the subsequent
subsections of Section 3. subsections of Section 3.
Bulk transfer applications that choose not to implement TFRC or TCP- Bulk transfer applications that choose not to implement TFRC or TCP-
like windowing SHOULD implement a congestion control scheme that like windowing SHOULD implement a congestion control scheme that
results in bandwidth use that competes fairly with TCP within an results in bandwidth use that competes fairly with TCP within an
order of magnitude. [RFC3551] suggests that applications SHOULD order of magnitude. Section 2 of [RFC3551] suggests that
monitor the packet loss rate to ensure that it is within acceptable applications SHOULD monitor the packet loss rate to ensure that it is
parameters. Packet loss is considered acceptable if a TCP flow within acceptable parameters. Packet loss is considered acceptable
across the same network path under the same network conditions would if a TCP flow across the same network path under the same network
achieve an average throughput, measured on a reasonable timescale, conditions would achieve an average throughput, measured on a
that is not less than that of the UDP flow. The comparison to TCP reasonable timescale, that is not less than that of the UDP flow.
cannot be specified exactly, but is intended as an "order-of- The comparison to TCP cannot be specified exactly, but is intended as
magnitude" comparison in timescale and throughput. an "order-of-magnitude" comparison in timescale and throughput.
Finally, some bulk transfer applications may choose not to implement Finally, some bulk transfer applications may choose not to implement
any congestion control mechanism and instead rely on transmitting any congestion control mechanism and instead rely on transmitting
across reserved path capacity. This might be an acceptable choice across reserved path capacity. This might be an acceptable choice
for a subset of restricted networking environments, but is by no for a subset of restricted networking environments, but is by no
means a safe practice for operation in the Internet. When the UDP means a safe practice for operation in the Internet. When the UDP
traffic of such applications leaks out on unprovisioned Internet traffic of such applications leaks out on unprovisioned Internet
paths, it can significantly degrade the performance of other traffic paths, it can significantly degrade the performance of other traffic
sharing the path and even result in congestion collapse. sharing the path and even result in congestion collapse.
Applications that support an uncontrolled or unadaptive transmission Applications that support an uncontrolled or unadaptive transmission
skipping to change at page 10, line 17 skipping to change at page 10, line 17
However, if the IP traffic in the tunnel is known to not be However, if the IP traffic in the tunnel is known to not be
congestion-controlled, additional measures are RECOMMENDED in order congestion-controlled, additional measures are RECOMMENDED in order
to limit the impact of the tunneled traffic on other traffic sharing to limit the impact of the tunneled traffic on other traffic sharing
the path. the path.
The following guidelines define these possible cases in more detail: The following guidelines define these possible cases in more detail:
1. A tunnel generates UDP traffic at a volume that corresponds to 1. A tunnel generates UDP traffic at a volume that corresponds to
the volume of payload traffic, and the payload traffic is IP- the volume of payload traffic, and the payload traffic is IP-
based and hence assumed to be congestion-controlled. based and congestion-controlled.
This is arguably the most common case for Internet tunnels. In This is arguably the most common case for Internet tunnels. In
this case, the UDP tunnel SHOULD NOT employ its own congestion this case, the UDP tunnel SHOULD NOT employ its own congestion
control mechanism, because congestion losses of tunneled traffic control mechanism, because congestion losses of tunneled traffic
will already trigger an appropriate congestion response at the will already trigger an appropriate congestion response at the
original senders of the tunneled traffic. original senders of the tunneled traffic.
Note that this guideline is built on the assumption that most IP- Note that this guideline is built on the assumption that most IP-
based communication is congestion-controlled. If a UDP tunnel is based communication is congestion-controlled. If a UDP tunnel is
used for IP-based traffic that is known to not be congestion- used for IP-based traffic that is known to not be congestion-
skipping to change at page 13, line 20 skipping to change at page 13, line 20
An application that requires 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 in terms of coding theory [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 a statistical guarantee that the payload The UDP checksum provides a statistical guarantee that the payload
was not corrupted in transit. It also allows the receiver to verify was not corrupted in transit. It also allows the receiver to verify
that it was the intended destination of the packet, because it covers that it was the intended destination of the packet, because it covers
the IP addresses, port numbers and protocol number, and it verifies the IP addresses, port numbers and protocol number, and it verifies
that the packet is not truncated or padded, because it covers the that the packet is not truncated or padded, because it covers the
skipping to change at page 16, line 14 skipping to change at page 16, line 14
An application that needs to employ keep-alives to deliver useful An application that needs to employ keep-alives to deliver useful
service over UDP in the presence of middleboxes SHOULD NOT transmit service over UDP in the presence of middleboxes SHOULD NOT transmit
them more frequently than once every 15 seconds and SHOULD use longer them more frequently than once every 15 seconds and SHOULD use longer
intervals when possible. No common timeout has been specified for intervals when possible. No common timeout has been specified for
per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787]
requires a state timeout of 2 minutes or longer. However, empirical requires a state timeout of 2 minutes or longer. However, empirical
evidence suggests that a significant fraction of the deployed evidence suggests that a significant fraction of the deployed
middleboxes unfortunately uses shorter timeouts. The timeout of 15 middleboxes unfortunately uses shorter timeouts. The timeout of 15
seconds originates with the Interactive Connectivity Establishment seconds originates with the Interactive Connectivity Establishment
(ICE) protocol [I-D.ietf-mmusic-ice]. Applications that operate in (ICE) protocol [I-D.ietf-mmusic-ice]. When applications are deployed
more controlled network environments SHOULD investigate whether the in more controlled network environments, the deployers SHOULD
environment they operate in allows them to use longer intervals, or investigate whether the target environment allows applications to use
whether it offers mechanisms to explicitly control middlebox state longer intervals, or whether it offers mechanisms to explicitly
timeout durations, for example, using MIDCOM [RFC3303], NSIS control middlebox state timeout durations, for example, using MIDCOM
[I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is RECOMMENDED that [RFC3303], NSIS [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is
applications apply slight random variations ("jitter") to the timing RECOMMENDED that applications apply slight random variations
of keep-alive transmissions, in order to reduce the potential for ("jitter") to the timing of keep-alive transmissions, in order to
persistent synchronization between keep-alive transmissions from reduce the potential for persistent synchronization between keep-
different hosts. alive transmissions from different hosts.
Sending keep-alives is not a substitute for implementing robust Sending keep-alives is not a substitute for implementing robust
connection handling. Like all UDP datagrams, keep-alives can be connection handling. Like all UDP datagrams, keep-alives can be
delayed or dropped, causing middlebox state to time out. In delayed or dropped, causing middlebox state to time out. In
addition, the congestion control guidelines in Section 3.1 cover all addition, the congestion control guidelines in Section 3.1 cover all
UDP transmissions by an application, including the transmission of UDP transmissions by an application, including the transmission of
middlebox keep-alives. Congestion control may thus lead to delays or middlebox keep-alives. Congestion control may thus lead to delays or
temporary suspension of keep-alive transmission. temporary suspension of keep-alive transmission.
Keep-alive messages are NOT RECOMMENDED for general use. They are Keep-alive messages are NOT RECOMMENDED for general use. They are
skipping to change at page 17, line 28 skipping to change at page 17, line 28
connection setup. Using the sockets API, applications can receive connection setup. Using the sockets API, applications can receive
packets from more than one IP source address on a single UDP socket. packets from more than one IP source address on a single UDP socket.
Some servers use this to exchange data with more than one remote host Some servers use this to exchange data with more than one remote host
through a single UDP socket at the same time. When applications need through a single UDP socket at the same time. When applications need
to ensure that they receive packets from a particular source address, to ensure that they receive packets from a particular source address,
they MUST implement corresponding checks at the application layer or they MUST implement corresponding checks at the application layer or
explicitly request that the operating system filter the received explicitly request that the operating system filter the received
packets. packets.
If a client/server application executes on a host with more than one If a client/server application executes on a host with more than one
IP interface, the application SHOULD send any UDP responses in reply IP interface, the application SHOULD send any UDP responses with an
to arriving UDP datagrams with an IP source address that matches the IP source address that matches the IP destination address of the UDP
IP destination address of the datagram that carried the request (see datagram that carried the request (see [RFC1122], Section 4.1.3.5).
[RFC1122], Section 4.1.3.5). Many middleboxes expect this Many middleboxes expect this transmission behavior and drop replies
transmission behavior and drop replies that are sent from a different that are sent from a different IP address, as explained in
IP address, as explained in Section 3.5. Section 3.5.
A UDP receiver can receive a valid UDP datagram with a zero-length A UDP receiver can receive a valid UDP datagram with a zero-length
payload. Note that this is different from a return value of zero payload. Note that this is different from a return value of zero
from a read() socket call, which for TCP indicates the end of the from a read() socket call, which for TCP indicates the end of the
connection. connection.
Many operating systems also allow a UDP socket to be connected, i.e., Many operating systems also allow a UDP socket to be connected, i.e.,
to bind a UDP socket to a specific pair of addresses and ports. This to bind a UDP socket to a specific pair of addresses and ports. This
is similar to the corresponding TCP sockets API functionality. is similar to the corresponding TCP sockets API functionality.
However, for UDP, this is only a local operation that serves to However, for UDP, this is only a local operation that serves to
skipping to change at page 19, line 6 skipping to change at page 19, line 6
context, such as local state about communication instances to each context, such as local state about communication instances to each
destination, that although readily available in connection-oriented destination, that although readily available in connection-oriented
transport protocols is not always maintained by UDP-based transport protocols is not always maintained by UDP-based
applications. applications.
4. Security Considerations 4. Security Considerations
UDP does not provide communications security. Applications that need UDP does not provide communications security. Applications that need
to protect their communications against eavesdropping, tampering, or to protect their communications against eavesdropping, tampering, or
message forgery SHOULD employ end-to-end security services provided message forgery SHOULD employ end-to-end security services provided
by other IETF protocols. by other IETF protocols. Applications that respond to short requests
with potentially large responses are vulnerable to amplification
attacks, and SHOULD authenticate the sender before responding. The
source IP address of a request is not a useful authenticator, because
it can be spoofed.
One option of securing UDP communications is with IPsec [RFC4301], One option of securing UDP communications is with IPsec [RFC4301],
which can provide authentication for flows of IP packets through the which can provide authentication for flows of IP packets through the
Authentication Header (AH) [RFC4302] and encryption and/or Authentication Header (AH) [RFC4302] and encryption and/or
authentication through the Encapsulating Security Payload (ESP) authentication through the Encapsulating Security Payload (ESP)
[RFC4303]. Applications use the Internet Key Exchange (IKE) [RFC4303]. Applications use the Internet Key Exchange (IKE)
[RFC4306] to configure IPsec for their sessions. Depending on how [RFC4306] to configure IPsec for their sessions. Depending on how
IPsec is configured for a flow, it can authenticate or encrypt the IPsec is configured for a flow, it can authenticate or encrypt the
UDP headers as well as UDP payloads. If an application only requires UDP headers as well as UDP payloads. If an application only requires
authentication, ESP with no encryption but with authentication is authentication, ESP with no encryption but with authentication is
skipping to change at page 23, line 15 skipping to change at page 23, line 19
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-18 (work in progress), draft-ietf-nsis-nslp-natfw-18 (work in progress),
February 2008. February 2008.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-15 (work in Signalling Transport", draft-ietf-nsis-ntlp-16 (work in
progress), February 2008. progress), July 2008.
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information [POSIX] IEEE Std. 1003.1-2001, "Standard for Information
Technology - Portable Operating System Interface (POSIX)", Technology - Portable Operating System Interface (POSIX)",
Open Group Technical Standard: Base Specifications Issue Open Group Technical Standard: Base Specifications Issue
6, ISO/IEC 9945:2002, December 2001. 6, ISO/IEC 9945:2002, December 2001.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984. RFC 896, January 1984.
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
 End of changes. 12 change blocks. 
36 lines changed or deleted 40 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/