--- 1/draft-ietf-tsvwg-udp-guidelines-08.txt 2008-07-08 17:12:25.000000000 +0200 +++ 2/draft-ietf-tsvwg-udp-guidelines-09.txt 2008-07-08 17:12:25.000000000 +0200 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia Intended status: BCP G. Fairhurst -Expires: December 15, 2008 University of Aberdeen - June 13, 2008 +Expires: January 9, 2009 University of Aberdeen + July 8, 2008 Guidelines for Application Designers on Using Unicast UDP - draft-ietf-tsvwg-udp-guidelines-08 + draft-ietf-tsvwg-udp-guidelines-09 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of @@ -49,25 +49,25 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13 - 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 14 - 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 16 + 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15 + 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 1. Introduction @@ -249,26 +249,26 @@ It is important to note that congestion control should not be viewed as an add-on to a finished application. Many of the mechanisms discussed in the guidelines below require application support to operate correctly. Application designers need to consider congestion control throughout the design of their application, similar to how they consider security aspects throughout the design process. In the past, the IETF has also investigated integrated congestion control mechanisms that act on the traffic aggregate between two - hosts, i.e., across all communication sessions active at a given time - independent of specific transport protocols, such as the Congestion - Manager [RFC3124]. Such mechanisms have failed to see deployment, - but would otherwise also fulfill the congestion control requirements - in [RFC2914], because they provide congestion control for UDP - sessions. + hosts, i.e., a framework such as the Congestion Manager [RFC3124], + where active sessions may share current congestion information in a + way that is independent of the transport protocol. Such mechanisms + have failed to see deployment, but would otherwise simplify the + design of congestion control mechanisms for UDP sessions, so that + they fulfill the requirements in [RFC2914]. 3.1.1. Bulk Transfer Applications Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a small number of UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC3448], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. @@ -358,22 +358,24 @@ because the lack of return traffic prevents the detection of packet loss, i.e., congestion events, and the application therefore cannot perform exponential back-off to reduce load. Applications that communicate bidirectionally SHOULD employ congestion control for both directions of the communication. For example, for a client-server, request-response-style application, clients SHOULD congestion control their request transmission to a server, and the server SHOULD congestion-control its responses to the clients. Congestion in the forward and reverse direction is - uncorrelated and an application SHOULD independently detect and - respond to congestion along both directions. + uncorrelated and an application SHOULD either independently detect + 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 One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original packets contained in the payload. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology, and can be used to create virtual (private) @@ -559,27 +561,30 @@ 3.4. Checksum Guidelines The UDP header includes an optional, 16-bit ones-complement checksum that provides an integrity check. This results in a relatively weak protection from a coding point of view [RFC3819] and application developers SHOULD implement additional checks where data integrity is important, e.g., through a Cyclic Redundancy Check (CRC) included with the data to verify the integrity of an entire object/file sent over UDP service. - The UDP checksum provides assurance that the payload was not - corrupted in transit. It also allows the receiver to verify that it - was the intended destination of the packet, because it covers the IP - addresses, port numbers and protocol number, and it verifies that the - packet is not truncated or padded, because it covers the size field. - It therefore protects an application against receiving corrupted - payload data in place of, or in addition to, the data that was sent. + The UDP checksum provides a statistical guarantee that the payload + was not corrupted in transit. It also allows the receiver to verify + that it was the intended destination of the packet, because it covers + the IP addresses, port numbers and protocol number, and it verifies + that the packet is not truncated or padded, because it covers the + size field. It therefore protects an application against receiving + 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 the option to disable their use. Applications that choose to disable UDP checksums when transmitting over IPv4 therefore MUST NOT make assumptions regarding the correctness of received data and MUST behave correctly when a UDP datagram is received that was originally sent to a different destination or is otherwise corrupted. The use of the UDP checksum is REQUIRED when applications transmit UDP over IPv6 [RFC2460]. @@ -594,42 +599,45 @@ should still follow the congestion control and other guidelines described for use with UDP in Section 3. UDP-Lite changes the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. Otherwise, UDP-Lite is semantically identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates a checksum coverage length value: at the sender, this specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error insensitive part". - If required, an application may dynamically modify this length value, - e.g., to offer greater protection to some messages. UDP-Lite always - verifies that a packet was delivered to the intended destination, - i.e., always verifies the header fields. Errors in the insensitive - part will not cause a UDP datagram to be discarded by the + By default, the UDP-Lite checksum coverage extends across the entire + datagram. If required, an application may dynamically modify this + length value, e.g., to offer greater protection to some messages. + UDP-Lite always verifies that a packet was delivered to the intended + 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 assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload. The sending application SHOULD select the minimum checksum coverage to include all sensitive protocol headers. For example, applications that use the Real-Time Protocol (RTP) [RFC3550] will likely want to protect the RTP header against corruption. Applications, where appropriate, MUST also introduce their own appropriate validity checks for protocol information carried in the insensitive part of 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 - sender. 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. + sender [RFC3828]. The receiver SHOULD select a threshold that is + sufficiently large to block packets with an inappropriately short + 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 corruption, when using UDP-Lite. The enhancements offered by UDP- Lite rely upon a link being able to intercept the UDP-Lite header to correctly identify the partial coverage required. When tunnels 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. Use of IP fragmentation can also prevent special treatment for UDP- Lite datagrams, and is another reason why applications SHOULD avoid IP fragmentation (Section 3.2). @@ -882,21 +890,21 @@ | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | | | | | SHOULD control rate of transmission | 3.1 | | SHOULD perform congestion control over all traffic | | | | | | for bulk transfers, | 3.1.1 | | SHOULD consider implementing TFRC | | | else, SHOULD otherwise use bandwidth similar to TCP | | | | | | 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 | | | | | | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | | SHOULD discover PMTU or send datagrams < minimum PMTU | | | | | | SHOULD handle datagram loss, duplication, reordering | 3.3 | | SHOULD be robust to delivery delays up to 2 minutes | | | | | | SHOULD enable UDP checksum | 3.4 | | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | @@ -1166,21 +1174,21 @@ Authors' Addresses Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com - URI: http://research.nokia.com/people/lars_eggert/ + URI: http://people.nokia.net/~lars/ Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/