draft-ietf-tsvwg-udp-guidelines-10.txt   draft-ietf-tsvwg-udp-guidelines-11.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: February 23, 2009 University of Aberdeen Expires: April 13, 2009 University of Aberdeen
August 22, 2008 October 10, 2008
Unicast UDP Usage Guidelines for Application Designers Unicast UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-10 draft-ietf-tsvwg-udp-guidelines-11
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 February 23, 2009. This Internet-Draft will expire on April 13, 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 . . . . . . . . . . . . . . 15 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 14
3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 16
3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
unreliable, best-effort, message-passing transport to applications unreliable, best-effort, message-passing transport to applications
and upper-layer protocols (both simply called "applications" in the and upper-layer protocols (both simply called "applications" in the
remainder of this document). Compared to other transport protocols, remainder of this document). Compared to other transport protocols,
UDP and its UDP-Lite variant [RFC3828] are unique in that they do not UDP and its UDP-Lite variant [RFC3828] are unique in that they do not
establish end-to-end connections between communicating end systems. establish end-to-end connections between communicating end systems.
UDP communication consequently does not incur connection UDP communication consequently does not incur connection
skipping to change at page 7, line 12 skipping to change at page 7, line 12
way that is independent of the transport protocol. Such mechanisms way that is independent of the transport protocol. Such mechanisms
have failed to see deployment, but would otherwise simplify the have failed to see deployment, but would otherwise simplify the
design of congestion control mechanisms for UDP sessions, so that design of congestion control mechanisms for UDP sessions, so that
they fulfill the requirements in [RFC2914]. 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 [RFC5348], 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. If an application implements TFRC, it need not follow the
[I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always remaining guidelines in Section 3.1.1, because TFRC already addresses
evaluate whether the latest published specification fits their needs. them, but SHOULD still follow the remaining guidelines in the
If an application implements TFRC, it need not follow the remaining subsequent subsections of Section 3.
guidelines in Section 3.1.1, because TFRC already addresses them, but
SHOULD still follow the remaining guidelines in the subsequent
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. Section 2 of [RFC3551] suggests that order of magnitude. Section 2 of [RFC3551] suggests that
applications SHOULD monitor the packet loss rate to ensure that it is applications SHOULD monitor the packet loss rate to ensure that it is
within acceptable parameters. Packet loss is considered acceptable within acceptable parameters. Packet loss is considered acceptable
if a TCP flow across the same network path under the same network if a TCP flow across the same network path under the same network
conditions would achieve an average throughput, measured on a conditions would achieve an average throughput, measured on a
reasonable timescale, that is not less than that of the UDP flow. reasonable timescale, that is not less than that of the UDP flow.
skipping to change at page 13, line 20 skipping to change at page 13, line 15
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 in terms of coding theory [RFC3819] and application protection 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 17, line 8 skipping to change at page 16, line 47
UDP for these deployments. On the other hand, there is anecdotal UDP for these deployments. On the other hand, there is anecdotal
evidence that suggests that direct communication through middleboxes, evidence that suggests that direct communication through middleboxes,
e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often
with TCP than with UDP. The tradeoffs between different transport with TCP than with UDP. The tradeoffs between different transport
protocols - especially when it comes to middlebox traversal - deserve protocols - especially when it comes to middlebox traversal - deserve
careful analysis. careful analysis.
3.6. Programming Guidelines 3.6. Programming Guidelines
The de facto standard application programming interface (API) for The de facto standard application programming interface (API) for
TCP/IP applications is the "sockets" interface [POSIX]. Although TCP/IP applications is the "sockets" interface [POSIX]. Some
this API was developed for UNIX in the early 1980s, a wide variety of platforms also offer applications the ability to directly assemble
non-UNIX operating systems also implements it. The sockets API and transmit IP packets through "raw sockets" or similar facilities.
supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs This is a second, more cumbersome method of using UDP. The
from that for TCP in several key ways. Because application guidelines in this document cover all such methods through which an
programmers are typically more familiar with the TCP sockets API, the application may use UDP. Because the sockets API is by far the most
remainder of this section discusses these differences. [STEVENS] common method, the remainder of this section discusses it in more
provides usage examples of the UDP sockets API. detail.
Although the sockets API was developed for UNIX in the early 1980s, a
wide variety of non-UNIX operating systems also implements it. The
sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets
API differs from that for TCP in several key ways. Because
application programmers are typically more familiar with the TCP
sockets API, the remainder of this section discusses these
differences. [STEVENS] provides usage examples of the UDP sockets
API.
UDP datagrams may be directly sent and received, without any UDP datagrams may be directly sent and received, without any
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.
skipping to change at page 18, line 28 skipping to change at page 18, line 28
state. This prevents delayed packets from the closed connection state. This prevents delayed packets from the closed connection
instance from being mistakenly associated with a later connection instance from being mistakenly associated with a later connection
instance that happens to reuse the same IP address and port pairs. instance that happens to reuse the same IP address and port pairs.
The UDP protocol does not implement such a mechanism. Therefore, The UDP protocol does not implement such a mechanism. Therefore,
UDP-based applications need to be robust in this case. One UDP-based applications need to be robust in this case. One
application may close a socket or terminate, followed in time by application may close a socket or terminate, followed in time by
another application receiving on the same port. This later another application receiving on the same port. This later
application may then receive packets intended for the first application may then receive packets intended for the first
application that were delayed in the network. application that were delayed in the network.
The Internet can provide service differentiation to applications
based on IP-layer packet markings [RFC2475]. This facility can be
used for UDP traffic. Different operating systems provide different
interfaces for marking packets to applications. Differentiated
services require support from the network, and application deployers
need to discuss the provisioning of this functionality with their
network operator.
3.7. ICMP Guidelines 3.7. ICMP Guidelines
Applications can utilize information about ICMP error messages that Applications can utilize information about ICMP error messages that
the UDP layer passes up for a variety of purposes [RFC1122]. the UDP layer passes up for a variety of purposes [RFC1122].
Applications SHOULD validate that the information in the ICMP message Applications SHOULD validate that the information in the ICMP message
payload, e.g., a reported error condition, corresponds to a UDP payload, e.g., a reported error condition, corresponds to a UDP
datagram that the application actually sent. Note that not all APIs datagram that the application actually sent. Note that not all APIs
have the necessary functions to support this validation, and some have the necessary functions to support this validation, and some
APIs already perform this validation internally before passing ICMP APIs already perform this validation internally before passing ICMP
information to the application. information to the application.
skipping to change at page 19, line 50 skipping to change at page 20, line 10
objects, such as files or messages, instead of individual UDP objects, such as files or messages, instead of individual UDP
payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or
OpenPGP [RFC4880] could be used. In addition, there are many non- OpenPGP [RFC4880] could be used. In addition, there are many non-
IETF protocols in this area. IETF protocols in this area.
Like congestion control mechanisms, security mechanisms are difficult Like congestion control mechanisms, security mechanisms are difficult
to design and implement correctly. It is hence RECOMMENDED that to design and implement correctly. It is hence RECOMMENDED that
applications employ well-known standard security mechanisms such as applications employ well-known standard security mechanisms such as
DTLS or IPsec, rather than inventing their own. DTLS or IPsec, rather than inventing their own.
The Generalized TTL Security Mechanism (GTSM) [RFC3682] may be used
with UDP applications (especially when the intended endpoint is on
the same link as the sender). This is a lightweight mechanism that
allows a receiver to filter unwanted packets.
In terms of congestion control, [RFC2309] and [RFC2914] discuss the In terms of congestion control, [RFC2309] and [RFC2914] discuss the
dangers of congestion-unresponsive flows to the Internet. This dangers of congestion-unresponsive flows to the Internet. This
document provides guidelines to designers of UDP-based applications document provides guidelines to designers of UDP-based applications
to congestion-control their transmissions, and does not raise any to congestion-control their transmissions, and does not raise any
additional security concerns. additional security concerns.
5. Summary 5. Summary
This section summarizes the guidelines made in Section 3 and This section summarizes the guidelines made in Section 3 and
Section 4 in a tabular format in Table 1 for easy referencing. Section 4 in a tabular format in Table 1 for easy referencing.
skipping to change at page 21, line 15 skipping to change at page 22, line 8
6. IANA Considerations 6. IANA Considerations
This document raises no IANA considerations. This document raises no IANA considerations.
(Note to the RFC Editor: Please remove this section upon (Note to the RFC Editor: Please remove this section upon
publication.) publication.)
7. Acknowledgments 7. Acknowledgments
Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van
Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Pasi Beijnum, Stewart Bryant, Remi Denis-Courmont, Lisa Dusseault, Wesley
Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman, Cullen Eddy, Pasi Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman,
Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip Matthews, Cullen Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip
Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi
Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their Sarolahti, Pascal Thubert, Joe Touch, Dave Ward and Magnus Westerlund
comments on this document. for their comments on this document.
The middlebox traversal guidelines in Section 3.5 incorporate ideas The middlebox traversal guidelines in Section 3.5 incorporate ideas
from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh
and Dan Kegel. and Dan Kegel.
Lars Eggert is partly funded by [TRILOGY], a research project Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
8. References 8. References
skipping to change at page 22, line 14 skipping to change at page 23, line 6
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
8.2. Informative References 8.2. Informative References
[FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in
TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,
March 1999. March 1999.
[I-D.ford-behave-app] [I-D.ford-behave-app]
Ford, B., "Application Design Guidelines for Traversal Ford, B., "Application Design Guidelines for Traversal
through Network Address Translators", through Network Address Translators",
draft-ford-behave-app-05 (work in progress), March 2007. draft-ford-behave-app-05 (work in progress), March 2007.
[I-D.ietf-dccp-ccid4] [I-D.ietf-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-ietf-dccp-ccid4-02 (work in progress), draft-ietf-dccp-ccid4-02 (work in progress),
February 2008. February 2008.
[I-D.ietf-dccp-rfc3448bis]
Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
draft-ietf-dccp-rfc3448bis-06 (work in progress),
April 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
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-19 (work in progress),
February 2008. September 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-16 (work in Signalling Transport", draft-ietf-nsis-ntlp-16 (work in
progress), July 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.
skipping to change at page 23, line 50 skipping to change at page 24, line 36
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998. Internet", RFC 2309, April 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999. RFC 2675, August 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001. RFC 3048, January 2001.
skipping to change at page 24, line 37 skipping to change at page 25, line 27
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004. Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004. Partial Reliability Extension", RFC 3758, May 2004.
 End of changes. 19 change blocks. 
48 lines changed or deleted 68 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/