One document matched: draft-eggert-tsvwg-rfc5405bis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0768 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC0896 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0896.xml">
<!ENTITY RFC0919 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0919.xml">
<!ENTITY RFC1112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC1191 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1536 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1536.xml">
<!ENTITY RFC1546 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1546.xml">
<!ENTITY RFC1981 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2675 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2675.xml">
<!ENTITY RFC2743 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC2887 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2887.xml">
<!ENTITY RFC2914 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2914.xml">
<!ENTITY RFC3048 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3048.xml">
<!ENTITY RFC3124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3124.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3303.xml">
<!ENTITY RFC3493 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3493.xml">
<!ENTITY RFC3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC3738 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3738.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC3819 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml">
<!ENTITY RFC3828 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC4301 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4341.xml">
<!ENTITY RFC4342 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4342.xml">
<!ENTITY RFC4607 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY RFC4654 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4654.xml">
<!ENTITY RFC4787 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC4880 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC4960 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC4963 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4963.xml">
<!ENTITY RFC4987 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5245 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5348 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml">
<!ENTITY RFC5405 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5405.xml">
<!ENTITY RFC5622 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5622.xml">
<!ENTITY RFC5652 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC5740 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml">
<!ENTITY RFC5751 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY RFC5775 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5775.xml">
<!ENTITY RFC5885 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC5971 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5971.xml">
<!ENTITY RFC5973 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5973.xml">
<!ENTITY RFC5996 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC6298 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml">
<!ENTITY RFC6335 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY RFC6347 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6395 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6395.xml">
<!ENTITY RFC6396 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6396.xml">
<!ENTITY RFC6437 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY RFC6438 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml">
<!ENTITY RFC6513 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6726 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml">
<!ENTITY RFC6807 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6807.xml">
<!ENTITY RFC6936 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml">
<!ENTITY I-D.ford-behave-app SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ford-behave-app.xml">
<!ENTITY I-D.ietf-tsvwg-port-use SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-port-use.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.fairhurst-tsvwg-circuit-breaker SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.fairhurst-tsvwg-circuit-breaker.xml">
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="bcp" docName="draft-eggert-tsvwg-rfc5405bis-00"
ipr="noDerivativesTrust200902" number="" obsoletes="5405">
<front>
<title abbrev="UDP Usage Guidelines">UDP Usage Guidelines</title>
<author fullname="Lars Eggert" initials="L." surname="Eggert">
<organization>NetApp</organization>
<address>
<postal>
<street>Sonnenallee 1</street>
<city>Kirchheim</city>
<code>85551</code>
<country>Germany</country>
</postal>
<phone>+49 151 120 55791</phone>
<email>lars@netapp.com</email>
<uri>https://eggert.org/</uri>
</address>
</author>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>Department of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk/</uri>
</address>
</author>
<date />
<area>Transport Area</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>UDP</keyword>
<keyword>guidelines</keyword>
<abstract>
<t>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 other protocols that choose to use UDP as an Internet
transport must employ mechanisms to prevent congestion collapse and to
establish some degree of fairness with concurrent traffic. They may also
need to implement additional mechanisms, depending on how they use
UDP.</t>
<t>This document provides guidelines on the use of UDP for the designers
of applications, tunnels and other protocols that use UDP. Congestion
control guidelines are a primary focus, but the document also provides
guidance on other topics, including message sizes, reliability,
checksums, and middlebox traversal.</t>
<t>If published as an RFC, this document will obsolete RFC5405.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The User Datagram Protocol (UDP) <xref target="RFC0768"></xref>
provides a minimal, unreliable, best-effort, message-passing transport
to applications and other protocols (such as tunnels) that desire to
operate over UDP (both simply called "applications" in the remainder of
this document). Compared to other transport protocols, UDP and its
UDP-Lite variant <xref target="RFC3828"></xref> are unique in that they
do not establish end-to-end connections between communicating end
systems. UDP communication consequently does not incur connection
establishment and tear-down overheads, and there is minimal associated
end system state. Because of these characteristics, UDP can offer a very
efficient communication transport to some applications.</t>
<t>A second unique characteristic of UDP is that it provides no inherent
congestion control mechanisms. On many platforms, applications can send
UDP datagrams at the line rate of the link interface, which is often
much greater than the available path capacity, and doing so contributes
to congestion along the path. <xref target="RFC2914"></xref> describes
the best current practice for congestion control in the Internet. It
identifies two major reasons why congestion control mechanisms are
critical for the stable operation of the Internet: <list style="numbers">
<t>The prevention of congestion collapse, i.e., a state where an
increase in network load results in a decrease in useful work done
by the network.</t>
<t>The establishment of a degree of fairness, i.e., allowing
multiple flows to share the capacity of a path reasonably
equitably.</t>
</list></t>
<t>Because UDP itself provides no congestion control mechanisms, it is
up to the applications that use UDP for Internet communication to employ
suitable mechanisms to prevent congestion collapse and establish a
degree of fairness. <xref target="RFC2309"></xref> discusses the dangers
of congestion-unresponsive flows and states that "all UDP-based
streaming applications should incorporate effective congestion avoidance
mechanisms". This is an important requirement, even for applications
that do not use UDP for streaming. In addition, congestion-controlled
transmission is of benefit to an application itself, because it can
reduce self-induced packet loss, minimize retransmissions, and hence
reduce delays. Congestion control is essential even at relatively slow
transmission rates. For example, an application that generates five
1500-byte UDP datagrams in one second can already exceed the capacity of
a 56 Kb/s path. For applications that can operate at higher, potentially
unbounded data rates, congestion control becomes vital to prevent
congestion collapse and establish some degree of fairness. <xref
target="udpuni"></xref> describes a number of simple guidelines for the
designers of such applications.</t>
<t>A UDP datagram is carried in a single IP packet and is hence limited
to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6.
The transmission of large IP packets usually requires IP fragmentation.
Fragmentation decreases communication reliability and efficiency and
should be avoided. IPv6 allows the option of transmitting large packets
("jumbograms") without fragmentation when all link layers along the path
support this <xref target="RFC2675"></xref>. Some of the guidelines in
<xref target="udpuni"></xref> describe how applications should determine
appropriate message sizes. Other sections of this document provide
guidance on reliability, checksums, and middlebox traversal.</t>
<t>This document provides guidelines and recommendations. Although most
UDP applications are expected to follow these guidelines, there do exist
valid reasons why a specific application may decide not to follow a
given guideline. In such cases, it is RECOMMENDED that application
designers cite the respective section(s) of this document in the
technical specification of their application or protocol and explain
their rationale for their design choice.</t>
<t><xref target="RFC5405"></xref> was scoped to provide guidelines for
unicast applications only, whereas this document also provides
guidelines for UDP flows that use IP anycast, multicast and broadcast,
and applications that use UDP tunnels to support IP flows.</t>
<t>Finally, although this document specifically refers to applications
that use UDP, the spirit of some of its guidelines also applies to other
message-passing applications and protocols (specifically on the topics
of congestion control, message sizes, and reliability). Examples include
signaling or control applications that choose to run directly over IP by
registering their own IP protocol number with IANA. This document may
provide useful background reading to the designers of such applications
and protocols.</t>
</section>
<section anchor="term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="udpuni" title=" UDP Usage Guidelines">
<t>Internet paths can have widely varying characteristics, including
transmission delays, available bandwidths, congestion levels, reordering
probabilities, supported message sizes, or loss rates. Furthermore, the
same Internet path can have very different conditions over time.
Consequently, applications that may be used on the Internet MUST NOT
make assumptions about specific path characteristics. They MUST instead
use mechanisms that let them operate safely under very different path
conditions. Typically, this requires conservatively probing the current
conditions of the Internet path they communicate over to establish a
transmission behavior that it can sustain and that is reasonably fair to
other traffic sharing the path.</t>
<t>These mechanisms are difficult to implement correctly. For most
applications, the use of one of the existing IETF transport protocols is
the simplest method of acquiring the required mechanisms. Consequently,
the RECOMMENDED alternative to the UDP usage described in the remainder
of this section is the use of an IETF transport protocol such as TCP
<xref target="RFC0793"></xref>, Stream Control Transmission Protocol
(SCTP) <xref target="RFC4960"></xref>, and SCTP Partial Reliability
Extension (SCTP-PR) <xref target="RFC3758"></xref>, or Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4340"></xref> with
its different congestion control types <xref
target="RFC4341"></xref><xref target="RFC4342"></xref><xref
target="RFC5622"></xref>.</t>
<t>If used correctly, these more fully-featured transport protocols are
not as "heavyweight" as often claimed. For example, the TCP algorithms
have been continuously improved over decades, and have reached a level
of efficiency and correctness that custom application-layer mechanisms
will struggle to easily duplicate. In addition, many TCP implementations
allow connections to be tuned by an application to its purposes. For
example, TCP's "Nagle" algorithm <xref target="RFC0896"></xref> can be
disabled, improving communication latency at the expense of more
frequent -- but still congestion-controlled -- packet transmissions.
Another example is the TCP SYN cookie mechanism <xref
target="RFC4987"></xref>, which is available on many platforms. TCP with
SYN cookies does not require a server to maintain per-connection state
until the connection is established. TCP also requires the end that
closes a connection to maintain the TIME-WAIT state that prevents
delayed segments from one connection instance from interfering with a
later one. Applications that are aware of and designed for this behavior
can shift maintenance of the TIME-WAIT state to conserve resources by
controlling which end closes a TCP connection <xref
target="FABER"></xref>. Finally, TCP's built-in capacity-probing and
awareness of the maximum transmission unit supported by the path (PMTU)
results in efficient data transmission that quickly compensates for the
initial connection setup delay, in the case of transfers that exchange
more than a few segments.</t>
<section anchor="unicc" title="Congestion Control Guidelines">
<t>If an application or protocol chooses not to use a
congestion-controlled transport protocol, it SHOULD control the rate
at which it sends UDP datagrams to a destination host, in order to
fulfill the requirements of <xref target="RFC2914"></xref>. It is
important to stress that an application SHOULD perform congestion
control over all UDP traffic it sends to a destination, independently
from how it generates this traffic. For example, an application that
forks multiple worker processes or otherwise uses multiple sockets to
generate UDP datagrams SHOULD perform congestion control over the
aggregate traffic.</t>
<t>Several approaches to perform congestion control are discussed in
the remainder of this section. The section describes generic topics
with an intended emphasis on unicast and anycast <xref
target="RFC1546"></xref> usage. Not all approaches discussed below are
appropriate for all UDP-transmitting applications. <xref
target="unibt"></xref> discusses congestion control options for
applications that perform bulk transfers over UDP. Such applications
can employ schemes that sample the path over several subsequent RTTs
during which data is exchanged, in order to determine a sending rate
that the path at its current load can support. Other applications only
exchange a few UDP datagrams with a destination. <xref
target="unildr"></xref> discusses congestion control options for such
"low data-volume" applications. Because they typically do not transmit
enough data to iteratively sample the path to determine a safe sending
rate, they need to employ different kinds of congestion control
mechanisms. <xref target="tun"></xref> discusses congestion control
considerations when UDP is used as a tunneling protocol. <xref
target="udpmcast"></xref> provides additional recommendations for
broadcast and multicast usage.</t>
<t>UDP applications may take advantage of Explicit Congestion
Notification (ECN), providing that the application programming
interface can support ECN and the congestion control can appropriately
react to ECN-marked packets. <xref target="RFC6679"></xref> provides
guidance on how to use ECN for UDP-based applications using the
Real-Time Protocol (RTP).</t>
<t>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.</t>
<t>In the past, the IETF has also investigated integrated congestion
control mechanisms that act on the traffic aggregate between two
hosts, i.e., a framework such as the Congestion Manager <xref
target="RFC3124"></xref>, where active sessions may share current
congestion information in a way that is independent of the transport
protocol. Such mechanisms have currently failed to see deployment, but
would otherwise simplify the design of congestion control mechanisms
for UDP sessions, so that they fulfill the requirements in <xref
target="RFC2914"></xref>.</t>
<section anchor="unibt" title="Bulk Transfer Applications">
<t>Applications that perform bulk transmission of data to a peer
over UDP, i.e., applications that exchange more than a few
UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control
(TFRC) <xref target="RFC5348"></xref>, window-based TCP-like
congestion control, or otherwise ensure that the application
complies with the congestion control principles.</t>
<t>TFRC has been designed to provide both congestion control and
fairness in a way that is compatible with the IETF's other transport
protocols. If an application implements TFRC, it need not follow the
remaining guidelines in <xref target="unibt"></xref>, because TFRC
already addresses them, but SHOULD still follow the remaining
guidelines in the subsequent subsections of <xref
target="udpuni"></xref>.</t>
<t>Bulk transfer applications that choose not to implement TFRC or
TCP-like windowing SHOULD implement a congestion control scheme that
results in bandwidth use that competes fairly with TCP within an
order of magnitude. Section 2 of <xref target="RFC3551"></xref>
suggests that applications SHOULD monitor the packet loss rate to
ensure that it is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path
under the same network conditions would achieve an average
throughput, measured on a reasonable timescale, that is not less
than that of the UDP flow. The comparison to TCP cannot be specified
exactly, but is intended as an "order-of-magnitude" comparison in
timescale and throughput.</t>
<t>Finally, some bulk transfer applications may choose not to
implement any congestion control mechanism and instead rely on
transmitting across reserved path capacity. This might be an
acceptable choice for a subset of restricted networking
environments, but is by no means a safe practice for operation over
the wider Internet. When the UDP traffic of such applications leaks
out into unprovisioned Internet paths, it can significantly degrade
the performance of other traffic sharing the path and even result in
congestion collapse. Applications that support an uncontrolled or
unadaptive transmission behavior SHOULD NOT do so by default and
SHOULD instead require users to explicitly enable this mode of
operation.</t>
</section>
<section anchor="unildr" title="Low Data-Volume Applications">
<t>When applications that at any time exchange only a few
UDP datagrams with a destination implement TFRC or one of the
other congestion control schemes in <xref target="unibt"></xref>,
the network sees little benefit, because those mechanisms perform
congestion control in a way that is only effective for longer
transmissions.</t>
<t>Applications that at any time exchange only a few UDP
datagrams with a destination SHOULD still control their transmission
behavior by not sending on average more than one UDP datagram per
round-trip time (RTT) to a destination. Similar to the
recommendation in <xref target="RFC1536"></xref>, an application
SHOULD maintain an estimate of the RTT for any destination with
which it communicates. Applications SHOULD implement the algorithm
specified in <xref target="RFC6298"></xref> to compute a smoothed
RTT (SRTT) estimate. They SHOULD also detect packet loss and
exponentially back their retransmission timer off when a loss event
occurs. When implementing this scheme, applications need to choose a
sensible initial value for the RTT. This value SHOULD generally be
as conservative as possible for the given application. TCP uses an
initial value of 3 seconds <xref target="RFC6298"></xref>, which is
also RECOMMENDED as an initial value for UDP applications. SIP <xref
target="RFC3261"></xref> and GIST <xref target="RFC5971"></xref> use
an initial value of 500 ms, and initial timeouts that are shorter
than this are likely problematic in many cases. It is also important
to note that the initial timeout is not the maximum possible timeout
-- the RECOMMENDED algorithm in <xref target="RFC6298"></xref>
yields timeout values after a series of losses that are much longer
than the initial value.</t>
<t>Some applications cannot maintain a reliable RTT estimate for a
destination. The first case is that of applications that exchange
too few UDP datagrams with a peer to establish a statistically
accurate RTT estimate. Such applications MAY use a predetermined
transmission interval that is exponentially backed-off when packets
are lost. TCP uses an initial value of 3 seconds <xref
target="RFC6298"></xref>, which is also RECOMMENDED as an initial
value for UDP applications. SIP <xref target="RFC3261"></xref> and
GIST <xref target="RFC5971"></xref> use an interval of 500 ms, and
shorter values are likely problematic in many cases. As in the
previous case, note that the initial timeout is not the maximum
possible timeout.</t>
<t>A second class of applications cannot maintain an RTT estimate
for a destination, because the destination does not send return
traffic. Such applications SHOULD NOT send more than one UDP
datagram every 3 seconds, and SHOULD use an even less aggressive
rate when possible. The 3-second interval was chosen based on TCP's
retransmission timeout when the RTT is unknown <xref
target="RFC6298"></xref>, and shorter values are likely problematic
in many cases. Note that the sending rate in this case must be more
conservative than in the two previous cases, because the lack of
return traffic prevents the detection of packet loss, i.e.,
congestion, and the application therefore cannot perform exponential
back-off to reduce load.</t>
<t>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 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.</t>
</section>
<section anchor="uniburst" title="Burst Mitigation and Pacing">
<t>UDP applications SHOULD provide mechanisms to regulate the bursts
of transmission that the application may send to the network. Many
TCP and SCTP implementations provide mechanisms that prevent a
sender from generating long bursts at line-rate, since these are
known to induce early loss to applications sharing a common network
bottleneck. The use of pacing with TCP <!--[XXX REF-Pacing XXX]-->
has also been shown to improve the coexistence of TCP flows with
other flows.</t>
<t>Even low data-volume UDP flows may benefit from rate control,
e.g., an application that sends three copies of a packet to improve
robustness to loss is RECOMMENDED to pace out those three packets
over several RTTs, to reduce the probability that all three packets
will be lost due to the same congestion event.</t>
</section>
<section anchor="QoS"
title="QoS, Pre-Provisioned or Reserved Capacity">
<t>An application using UDP can use the differentiated services and
integrated services QoS frameworks. These are usually available
within controlled environments (e.g., within a single administrative
domain or bilaterally agreed connection between domains).
Applications intended for the Internet should not assume that QoS
mechanisms are supported by the networks they use, and therefore
need to provide congestion control, error recovery, etc. in case the
actual network path does not provide provisioned service.</t>
<t>Some UDP applications are only expected to be deployed over
network paths that use pre-provisioned capacity or capacity reserved
using dynamic provisioning, e.g., through the Resource Reservation
Protocol (RSVP). Multicast applications are also used with
pre-provisioned capacity (e.g., IPTV deployments within access
networks). These applications MAY choose not to implement any
congestion control mechanism and instead rely on transmitting only
on paths where the capacity is provisioned and reserved for this
use. This might be an acceptable choice for a subset of restricted
networking environments, but is by no means a safe practice for
operation over the wider Internet.</t>
<t>If the traffic of such applications leaks out into unprovisioned
Internet paths, it can significantly degrade the performance of
other traffic sharing the path and even result in congestion
collapse. For this reason, and to protect other applications sharing
the same path, applications SHOULD deploy an appropriate circuit
breaker, as described in <xref target="cb"></xref>. Applications
that support an uncontrolled or unadaptive transmission behavior
SHOULD NOT do so by default and SHOULD instead require users to
explicitly enable this mode of operation.</t>
<t>Applications used in networks within a controlled environment may
be able to exploit network management functions to detect whether
they are causing congestion, and react accordingly.</t>
</section>
<section anchor="cb" title="Circuit Breaker Mechanisms">
<t>A transport circuit breaker is an automatic mechanism that is
used to estimate the congestion caused by a flow, and to terminate
(or significantly reduce the rate of) the flow when excessive
congestion is detected <xref
target="I-D.fairhurst-tsvwg-circuit-breaker"></xref>. This is a
safety measure to prevent congestion collapse (starvation of
resources available to other flows), essential for an Internet that
is heterogeneous and for traffic that is hard to predict in
advance.</t>
<t>A circuit breaker is intended as a protection mechanism of last
resort. Under normal circumstances, a circuit breaker should not be
triggered; it is designed to protect things when there is severe
overload. The goal is usually to limit the maximum transmission rate
that reflects the available capacity of a network path. circuit
breakers can operate on individual UDP flows or traffic aggregates,
e.g., traffic sent using a network tunnel. Later sections provide
examples of cases where circuit breakers may or may not be
desirable.</t>
<t><xref target="I-D.fairhurst-tsvwg-circuit-breaker"></xref>
provides guidance on the use of circuit breakers and examples of
usage. The use of a circuit breaker in RTP is specified in <xref
target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>.</t>
<!--<t>XXX Drafts that may relate to this help:
draft-mahalingam-dutt-dcops-vxlan-08.txt (LC), checksums
draft-ietf-mpls-in-udp (LC) checksums. XXX</t>-->
</section>
<section anchor="tun" title="UDP Tunnels">
<t>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) networks. Using UDP as a tunneling protocol is attractive
when the payload protocol is not supported by middleboxes that may
exist along the path, because many middleboxes support transmission
using UDP.</t>
<t>Well-implemented tunnels are generally invisible to the endpoints
that happen to transmit over a path that includes tunneled links. On
the other hand, to the routers along the path of a UDP tunnel, i.e.,
the routers between the two tunnel endpoints, the traffic that a UDP
tunnel generates is a regular UDP flow, and the encapsulator and
decapsulator appear as regular UDP-sending and -receiving
applications. Because other flows can share the path with one or
more UDP tunnels, congestion control needs to be considered.</t>
<t>Two factors determine whether a UDP tunnel needs to employ
specific congestion control mechanisms -- first, whether the payload
traffic is IP-based; second, whether the tunneling scheme generates
UDP traffic at a volume that corresponds to the volume of payload
traffic carried within the tunnel.</t>
<t>IP-based traffic is generally assumed to be
congestion-controlled, i.e., it is assumed that the transport
protocols generating IP-based traffic at the sender already employ
mechanisms that are sufficient to address congestion on the path.
Consequently, a tunnel carrying IP-based traffic should already
interact appropriately with other traffic sharing the path, and
specific congestion control mechanisms for the tunnel are not
necessary.</t>
<t>However, if the IP traffic in the tunnel is known to not be
congestion-controlled, additional measures are RECOMMENDED in order
to limit the impact of the tunneled traffic on other traffic sharing
the path.</t>
<t>The following guidelines define these possible cases in more
detail:</t>
<t><list style="numbers">
<t>A tunnel generates UDP traffic at a volume that corresponds
to the volume of payload traffic, and the payload traffic is
IP-based and congestion-controlled.<vspace blankLines="1" />This
is arguably the most common case for Internet tunnels. In this
case, the UDP tunnel SHOULD NOT employ its own congestion
control mechanism, because congestion losses of tunneled traffic
will already trigger an appropriate congestion response at the
original senders of the tunneled traffic.<vspace
blankLines="1" />Note that this guideline is built on the
assumption that most IP-based communication is
congestion-controlled. If a UDP tunnel is used for IP-based
traffic that is known to not be congestion-controlled, the next
set of guidelines applies.</t>
<t>A tunnel generates UDP traffic at a volume that corresponds
to the volume of payload traffic, and the payload traffic is not
known to be IP-based, or is known to be IP-based but not
congestion-controlled.<vspace blankLines="1" />This can be the
case, for example, when some link-layer protocols are
encapsulated within UDP (but not all link-layer protocols; some
are congestion-controlled). Because it is not known that
congestion losses of tunneled non-IP traffic will trigger an
appropriate congestion response at the senders, the UDP tunnel
SHOULD employ an appropriate congestion control mechanism.
Because tunnels are usually bulk-transfer applications as far as
the intermediate routers are concerned, the guidelines in <xref
target="unibt"></xref> apply.</t>
<t>A tunnel generates UDP traffic at a volume that does not
correspond to the volume of payload traffic, independent of
whether the payload traffic is IP-based or
congestion-controlled.<vspace blankLines="1" />Examples of this
class include UDP tunnels that send at a constant rate, increase
their transmission rates under loss, for example, due to
increasing redundancy when Forward Error Correction is used, or
are otherwise unconstrained in their transmission behavior.
These specialized uses of UDP for tunneling go beyond the scope
of the general guidelines given in this document. The
implementer of such specialized tunnels SHOULD carefully
consider congestion control in the design of their tunneling
mechanism and SHOULD consider use of a circuit breaker
mechanism.</t>
</list></t>
<t>Designing a tunneling mechanism requires significantly more
expertise than needed for many other UDP applications, because
tunnels are usually intended to be transparent to the endpoints
transmitting over them, so they need to correctly emulate the
behavior of an IP link, e.g., handling fragmentation, generating and
responding to ICMP messages, etc. At the same time, the tunneled
traffic is application traffic like any other from the perspective
of the networks the tunnel transmits over. This document only
touches upon the congestion control considerations for implementing
UDP tunnels; a discussion of other required tunneling behavior is
out of scope.</t>
</section>
</section>
<section anchor="unimsg" title="Message Size Guidelines">
<t>IP fragmentation lowers the efficiency and reliability of Internet
communication. The loss of a single fragment results in the loss of an
entire fragmented packet, because even if all other fragments are
received correctly, the original packet cannot be reassembled and
delivered. This fundamental issue with fragmentation exists for both
IPv4 and IPv6. In addition, some network address translators (NATs)
and firewalls drop IP fragments. The network address translation
performed by a NAT only operates on complete IP packets, and some
firewall policies also require inspection of complete IP packets. Even
with these being the case, some NATs and firewalls simply do not
implement the necessary reassembly functionality, and instead choose
to drop all fragments. Finally, <xref target="RFC4963"></xref>
documents other issues specific to IPv4 fragmentation.</t>
<t>Due to these issues, an application SHOULD NOT send UDP datagrams
that result in IP packets that exceed the MTU of the path to the
destination. Consequently, an application SHOULD either use the path
MTU information provided by the IP layer or implement path MTU
discovery itself <xref target="RFC1191"></xref><xref
target="RFC1981"></xref><xref target="RFC4821"></xref> to determine
whether the path to a destination will support its desired message
size without fragmentation.</t>
<t>Applications that do not follow this recommendation to do PMTU
discovery SHOULD still avoid sending UDP datagrams that would result
in IP packets that exceed the path MTU. Because the actual path MTU is
unknown, such applications SHOULD fall back to sending messages that
are shorter than the default effective MTU for sending (EMTU_S in
<xref target="RFC1122"></xref>). For IPv4, EMTU_S is the smaller of
576 bytes and the first-hop MTU <xref target="RFC1122"></xref>. For
IPv6, EMTU_S is 1280 bytes <xref target="RFC2460"></xref>. The
effective PMTU for a directly connected destination (with no routers
on the path) is the configured interface MTU, which could be less than
the maximum link payload size. Transmission of minimum-sized UDP
datagrams is inefficient over paths that support a larger PMTU, which
is a second reason to implement PMTU discovery.</t>
<t>To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4 optional
headers or IPv6 extension headers) as well as the length of the UDP
header (8 bytes) from the PMTU size. This size, known as the MSS, can
be obtained from the TCP/IP stack <xref target="RFC1122"></xref>.</t>
<t>Applications that do not send messages that exceed the effective
PMTU of IPv4 or IPv6 need not implement any of the above mechanisms.
Note that the presence of tunnels can cause an additional reduction of
the effective PMTU, so implementing PMTU discovery may be
beneficial.</t>
<t>Applications that fragment an application-layer message into
multiple UDP datagrams SHOULD perform this fragmentation so that each
datagram can be received independently, and be independently
retransmitted in the case where an application implements its own
reliability mechanisms.</t>
<t>Packetization Layer Path MTU Discovery (PLPMTUD) <xref
target="RFC4821"></xref> does not rely upon network support for ICMP
messages and is therefore considered more robust than standard PMTUD.
To operate, PLPMTUD requires changes to the way the transport is used,
both to transmit probe packets, and to account for the loss or success
of these probes. This updates not only the PMTU algorithm, it also
impacts loss recovery, congestion control, etc. These updated
mechanisms can be implemented within a connection-oriented transport
(e.g., TCP, SCTP, DCCP), but are not a part of UDP. PLPMTUD therefore
places additional design requirements on a UDP application that wishes
to use this method.</t>
</section>
<section anchor="unirel" title="Reliability Guidelines">
<t>Application designers are generally aware that UDP does not provide
any reliability, e.g., it does not retransmit any lost packets. Often,
this is a main reason to consider UDP as a transport. Applications
that do require reliable message delivery MUST implement an
appropriate mechanism themselves.</t>
<t>UDP also does not protect against datagram duplication, i.e., an
application may receive multiple copies of the same UDP datagram, with
some duplicates arriving potentially much later than the first.
Application designers SHOULD verify that their application handles
such datagram duplication gracefully, and may consequently need to
implement mechanisms to detect duplicates. Even if UDP datagram
reception triggers only idempotent operations, applications may want
to suppress duplicate datagrams to reduce load.</t>
<t>Applications that require ordered delivery MUST reestablish
datagram ordering themselves. The Internet can significantly delay
some packets with respect to others, e.g., due to routing transients,
intermittent connectivity, or mobility. This can cause reordering,
where UDP datagrams arrive at the receiver in an order different from
the transmission order.</t>
<t>It is important to note that the time by which packets are
reordered or after which duplicates can still arrive can be very
large. Even more importantly, there is no well-defined upper boundary
here. <xref target="RFC0793"></xref> defines the maximum delay a TCP
segment should experience -- the Maximum Segment Lifetime (MSL) -- as
2 minutes. No other RFC defines an MSL for other transport protocols
or IP itself. The MSL value defined for TCP is conservative enough
that it SHOULD be used by other protocols, including UDP. Therefore,
applications SHOULD be robust to the reception of delayed or duplicate
packets that are received within this 2-minute interval.</t>
<t>Instead of implementing these relatively complex reliability
mechanisms by itself, an application that requires reliable and
ordered message delivery SHOULD whenever possible choose an IETF
standard transport protocol that provides these features.</t>
</section>
<section anchor="unichk" title="Checksum Guidelines">
<t>The UDP header includes an optional, 16-bit one's complement
checksum that provides an integrity check. These checks are not strong
from a coding or cryptographic perspective, and are not designed to
detect physical-layer errors or malicious modification of the datagram
<xref target="RFC3819"></xref>. 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 the UDP
service.</t>
<t>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. More description of the set of checks performed using the
checksum field are provided in Section 3.1 of <xref
target="RFC6396"></xref>.</t>
<t>Applications SHOULD enable UDP checksums. For IPv4, <xref
target="RFC0768"></xref> permits the option to disable their use. The
use of the UDP checksum was required when applications transmit UDP
over IPv6 <xref target="RFC2460"></xref>. This requirement was updated
in <xref target="RFC6395"></xref>, but only for specific protocols and
applications, and the implementation of the set of functions defined
in <xref target="RFC6396"></xref> is then REQUIRED. These additional
design requirements for using a zero IPv6 UDP checksum <xref
target="RFC6396"></xref> are not present for IPv4, since the
network-layer header validates information that is not protected for
an IPv6 packet.</t>
<t>Applications that choose to disable UDP checksums when transmitting
over IPv4 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.</t>
<section anchor="udplite" title="UDP-Lite">
<t>A special class of applications can derive benefit from having
partially-damaged payloads delivered, rather than discarded, when
using paths that include error-prone links. Such applications can
tolerate payload corruption and MAY choose to use the Lightweight
User Datagram Protocol (UDP-Lite) <xref target="RFC3828"></xref>
variant of UDP instead of basic UDP. Applications that choose to use
UDP-Lite instead of UDP should still follow the congestion control
and other guidelines described for use with UDP in <xref
target="udpuni"></xref>.</t>
<t>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".
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.</t>
<t>A UDP-Lite sender SHOULD select the minimum checksum coverage to
include all sensitive payload information. For example, applications
that use the Real-Time Protocol (RTP) <xref target="RFC3550"></xref>
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).</t>
<t>A UDP-Lite receiver MUST set a minimum coverage threshold for
incoming packets that is not smaller than the smallest coverage used
by the sender <xref target="RFC3828"></xref>. 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.</t>
<t>Applications can still experience packet loss 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 this is another reason why applications SHOULD avoid
IP fragmentation (<xref target="unimsg"></xref>).</t>
<t>Current support for middlebox traversal using UDP-Lite is poor,
because UDP-Lite uses a different IPv4 protocol number or IPv6 "next
header" value than that used for UDP; therefore, few middleboxes are
currently able to interpret UDP-Lite and take appropriate actions
when forwarding the packet. This makes UDP-Lite less suited for
applications needing general Internet support, until such time as
UDP-Lite has achieved better support in middleboxes and
endpoints.</t>
</section>
</section>
<section anchor="nat" title="Middlebox Traversal Guidelines">
<t>Network address translators (NATs) and firewalls are examples of
intermediary devices ("middleboxes") that can exist along an
end-to-end path. A middlebox typically performs a function that
requires it to maintain per-flow state. For connection-oriented
protocols, such as TCP, middleboxes snoop and parse the
connection-management information 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 -- according to some local
criteria -- indicates a new flow, and destroy the state after some
period of time during which no packets belonging to the same flow have
arrived.</t>
<t>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 the middlebox.
For example, NATs and firewalls typically define the partial path on
one side of them to be interior to the domain they serve, 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 that arrives after the per-flow state has timed out is
dropped, as is other traffic that arrives from the exterior.</t>
<t>Many applications that use UDP for communication operate across
middleboxes without needing to employ additional mechanisms. One
example is the Domain Name System (DNS), which has a strict
request-response communication pattern that typically completes within
seconds.</t>
<t>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
application-layer sessions and state.</t>
<t>For some applications, such as media transmissions, this
re-synchronization is highly undesirable, because it can cause
user-perceivable playback artifacts. Such specialized applications MAY
send periodic keep-alive messages to attempt to refresh middlebox
state. It is important to note that keep-alive messages are NOT
RECOMMENDED for general use -- they are unnecessary for many
applications and can consume significant amounts of system and network
resources.</t>
<t>An application that needs to employ keep-alives to deliver useful
service over UDP in the presence of middleboxes SHOULD NOT transmit
them more frequently than once every 15 seconds and SHOULD use longer
intervals when possible. No common timeout has been specified for
per-flow UDP state for arbitrary middleboxes. NATs require a state
timeout of 2 minutes or longer <xref target="RFC4787"></xref>.
However, empirical evidence suggests that a significant fraction of
currently deployed middleboxes unfortunately use shorter timeouts. The
timeout of 15 seconds originates with the Interactive Connectivity
Establishment (ICE) protocol <xref target="RFC5245"></xref>. When an
application is deployed in a controlled network environment, the
deployer SHOULD investigate whether the target environment allows
applications to use longer intervals, or whether it offers mechanisms
to explicitly control middlebox state timeout durations, for example,
using Middlebox Communications (MIDCOM) <xref
target="RFC3303"></xref>, Next Steps in Signaling (NSIS) <xref
target="RFC5973"></xref>, or Universal Plug and Play (UPnP) <xref
target="UPnP"></xref>. It is RECOMMENDED that applications apply
slight random variations ("jitter") to the timing of keep-alive
transmissions, to reduce the potential for persistent synchronization
between keep-alive transmissions from different hosts.</t>
<t>Sending keep-alives is not a substitute for implementing a
mechanism to recover from broken sessions. Like all UDP datagrams,
keep-alives can be delayed or dropped, causing middlebox state to time
out. In addition, the congestion control guidelines in <xref
target="unicc"></xref> 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.</t>
<t>Keep-alive messages are NOT RECOMMENDED for general use. They are
unnecessary for many applications and may consume significant
resources. For example, on battery-powered devices, if an application
needs to maintain connectivity for long periods with little traffic,
the frequency at which keep-alives are sent can become the determining
factor that governs power consumption, depending on the underlying
network technology. Because many middleboxes are designed to require
keep-alives for TCP connections at a frequency that is much lower than
that needed for UDP, this difference alone can often be sufficient to
prefer TCP over UDP for these deployments. On the other hand, there is
anecdotal evidence that suggests that direct communication through
middleboxes, e.g., by using ICE <xref target="RFC5245"></xref>, does
succeed less often with TCP than with UDP. The trade-offs between
different transport protocols -- especially when it comes to middlebox
traversal -- deserve careful analysis.</t>
<t>UDP applications need to be designed understanding that there are
many variants of middlebox behavior, and although UDP is
connection-less, middleboxes often maintain state for each UDP flow.
Using multiple flows can consume available state space and also can
lead to changes in the way the middlebox handles subsequent packets
(either to protect its internal resources, or to prevent perceived
misuse). This has implications on applications that use multiple UDP
flows in parallel, even on multiple ports <xref
target="multi-flow"></xref>.</t>
</section>
</section>
<section anchor="udpmcast" title="Multicast UDP Usage Guidelines">
<t>This section complements <xref target="udpuni"></xref> by providing
additional guidelines that are applicable to multicast and broacast
usage of UDP.</t>
<t>Multicast and broadcast transmission <xref target="RFC1112"> </xref>
usually employ the UDP transport protocol, although they may be used
with other transport protocols (e.g., UDP-Lite).</t>
<t>There are currently two models of multicast delivery: the Any-Source
Multicast (ASM) model as defined in <xref target="RFC1112"></xref> and
the Source-Specific Multicast (SSM) model as defined in <xref
target="RFC4607"></xref>. ASM group members will receive all data sent
to the group by any source, while SSM constrains the distribution tree
to only one single source.</t>
<t>Specialized classes of applications also use UDP for IP multicast or
broadcast <xref target="RFC0919"></xref>. The design of such specialized
applications requires expertise that goes beyond simple,
unicast-specific guidelines, since these senders may transmit to
potentially very many receivers across potentially very heterogeneous
paths at the same time, which significantly complicates congestion
control, flow control, and reliability mechanisms. This section provides
guidance on multicast UDP usage.</t>
<t>Use of broadcast by an application is normally constrained by routers
to the local subnetwork. However, use of tunneling techniques and
proxies can and does result in some broadcast traffic traversing
Internet paths. These guidelines therefore also apply to broadcast
traffic.</t>
<t>The IETF has defined a reliable multicast framework <xref
target="RFC3048"></xref> and several building blocks to aid the
designers of multicast applications, such as <xref
target="RFC3738"></xref> or <xref target="RFC4654"></xref>. Anycast
senders must be aware that successive messages sent to the same anycast
IP address may be delivered to different anycast nodes, i.e., arrive at
different locations in the topology.</t>
<t>Most UDP tunnels that carry IP multicast traffic use a tunnel
encapsulation with a unicast destination address. These MUST follow the
same requirements as a tunnel carrying unicast data (see <xref
target="tun"></xref>). There are deployment cases and solutions where the
outer header of a UDP tunnel contains a multicast destination address,
such as <xref target="RFC6513"></xref>. These cases are primarily
deployed in controlled environments over reserved capacity, often
operating within a single administrative domain, or between two domains
over a bi-laterally agreed upon path with reserved bandwidth, and so
congestion control is OPTIONAL, but circuit breaker techniques are still
RECOMMENDED in order to restore some degree of service should the
offered load exceed the reserved capacity (e.g., due to
misconfiguration).</t>
<section title="Multicast Congestion Control Guidelines">
<t>Unicast congestion-controlled transport mechanism are often not
applicable to multicast distribution services, or simply do not scale
to large multicast trees, since they require bi-directional
communication and adapt the sending rate to accommodate the network
conditions to a single receiver. In contrast, multicast distribution
trees may fan out to massive numbers of receivers, which limits the
scalability of an in-band return channel to control the sending rate,
and the one-to-many nature of multicast distribution trees prevents
adapting the rate to the requirements of an individual receiver. For
this reason, generating TCP-compatible aggregate flow rates for
Internet multicast data, either native or tunneled, is the
responsibility of the application.</t>
<t>Congestion control mechanisms for multicast may operate on longer
timescales than for unicast (e.g., due to the higher group RTT of a
heterogeneous group); appropriate methods are particularly for any
multicast session were all or part of the multicast distribution tree
spans an access network (e.g., a home gateway).</t>
<t>Multicast congestion control needs to consider the potential
heterogeneity of both the multicast distribution tree and the
receivers belonging to a group. Heterogeneity may manifest itself in
some receivers experiencing more loss that others, higher delay,
and/or less ability to respond to network conditions. Any
multicast-enabled receiver may attempt to join and receive traffic
from any group. This may imply the need for rate limits on individual
receivers or the aggregate multicast service. Note there is no way at
the transport layer to prevent a join message propagating to the
next-hop router. A multicast congestion control method MAY therefore
decide not to reduce the rate of the entire multicast group in
response to a report received by a single receiver; instead it can
decide to expel each congested receiver from the multicast group and
to then distribute content to these congested receivers at a
lower-rate using unicast congestion-control. Care needs to be taken
when this action results in many flows being simultaneously
transitioned, so that this does not result in excessive traffic
exasperating congestion and potentially contributing to congestion
collapse.</t>
<t>Some classes of multicast applications support real-time
transmissions in which the quality of the transfer may be monitored at
the receiver. Applications that detect a significant reduction in user
quality SHOULD regard this as a congestion signal (e.g., to leave a
group using layered multicast encoding).</t>
<section title="Bulk Transfer Multicast Applications">
<t>Applications that perform bulk transmission of data over a
multicast distribution tree, i.e., applications that exchange more
than a few UDP datagrams per RTT, SHOULD implement a
method for congestion control. The currently RECOMMENDED IETF
methods are: Asynchronous Layered Coding (ALC) <xref
target="RFC5775"></xref>, TCP-Friendly Multicast Congestion Control
(TFMCC) <xref target="RFC4654"></xref>, Wave and Equation Based Rate
Control (WEBRC) <xref target="RFC3738"></xref>, NACK-Oriented
Reliable Multicast (NORM) transport protocol <xref
target="RFC5740"></xref>, File Delivery over Unidirectional
Transport (FLUTE) <xref target="RFC6726"></xref>, Real Time
Protocol/Control Protocol (RTP/RTCP), <xref
target="RFC3550"></xref>.</t>
<t>An application can alternatively implement another congestion
control schemes following the guidelines of <xref
target="RFC2887"></xref> and utilizing the framework of <xref
target="RFC3048"></xref>. Bulk transfer applications that choose not
to implement <xref target="RFC4654">, </xref><xref
target="RFC5775"></xref>, <xref target="RFC3738"></xref>, <xref
target="RFC5740"></xref>, <xref target="RFC6726"></xref>, or <xref
target="RFC3550"></xref> SHOULD implement a congestion control
scheme that results in bandwidth use that competes fairly with TCP
within an order of magnitude.</t>
<t>Section 2 of <xref target="RFC3551"></xref> states that
multimedia applications SHOULD monitor the packet loss rate to
ensure that it is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path
under the same network conditions would achieve an average
throughput, measured on a reasonable timescale, that is not less
than that of the UDP flow. The comparison to TCP cannot be specified
exactly, but is intended as an "order-of-magnitude" comparison in
timescale and throughput.</t>
</section>
<section title="Low Data-Volume Multicast Applications">
<t>All the recommendations in <xref target="unildr"></xref> are
also applicable to such multicast applications.</t>
</section>
</section>
<section anchor="MPMTU" title="Message Size Guidelines for Multicast">
<t>A multicast application SHOULD NOT send UDP datagrams that result
in IP packets that exceed the effective MTU as described in section 3
of <xref target="RFC6807"> </xref>. Consequently, an application
SHOULD either use the effective MTU information provided by the
Population Count Extensions to Protocol Independent Multicast <xref
target="RFC6807"></xref> or implement path MTU discovery itself (see
<xref target="unimsg"></xref>) to determine whether the path to each
destination will support its desired message size without
fragmentation.</t>
</section>
</section>
<section anchor="prog" title="Programming Guidelines">
<t>The de facto standard application programming interface (API) for
TCP/IP applications is the "sockets" interface <xref
target="POSIX"></xref>. Some platforms also offer applications the
ability to directly assemble and transmit IP packets through "raw
sockets" or similar facilities. This is a second, more cumbersome method
of using UDP. The guidelines in this document cover all such methods
through which an application may use UDP. Because the sockets API is by
far the most common method, the remainder of this section discusses it
in more detail.</t>
<t>Although the sockets API was developed for UNIX in the early 1980s, a
wide variety of non-UNIX operating systems also implement it. The
sockets API supports both IPv4 and IPv6 <xref target="RFC3493"></xref>.
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, this section discusses these differences. <xref
target="STEVENS"></xref> provides usage examples of the UDP sockets
API.</t>
<t>UDP datagrams may be directly sent and received, without any
connection setup. Using the sockets API, applications can receive
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
through a single UDP socket at the same time. Many applications need to
ensure that they receive packets from a particular source address; these
applications MUST implement corresponding checks at the application
layer or explicitly request that the operating system filter the
received packets.</t>
<t>If a client/server application executes on a host with more than one
IP interface, the application SHOULD send any UDP responses with an IP
source address that matches the IP destination address of the UDP
datagram that carried the request (see <xref target="RFC1122"></xref>,
Section 4.1.3.5). Many middleboxes expect this transmission behavior and
drop replies that are sent from a different IP address, as explained in
<xref target="nat"></xref>.</t>
<t>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 from a
read() socket call, which for TCP indicates the end of the
connection.</t>
<t>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 is
similar to the corresponding TCP sockets API functionality. However, for
UDP, this is only a local operation that serves to simplify the local
send/receive functions and to filter the traffic for the specified
addresses and ports. Binding a UDP socket does not establish a
connection -- UDP does not notify the remote end when a local UDP socket
is bound. Binding a socket also allows configuring options that affect
the UDP or IP layers, for example, use of the UDP checksum or the IP
Timestamp option. On some stacks, a bound socket also allows an
application to be notified when ICMP error messages are received for its
transmissions <xref target="RFC1122"></xref>.</t>
<t>UDP provides no flow-control, i.e., the sender at any given time does
not know whether the receiver is able to handle incoming transmissions.
This is another reason why UDP-based applications need to be robust in
the presence of packet loss. This loss can also occur within the sending
host, when an application sends data faster than the line rate of the
outbound network interface. It can also occur on the destination, where
receive calls fail to return all the data that was sent when the
application issues them too infrequently (i.e., such that the receive
buffer overflows). Robust flow control mechanisms are difficult to
implement, which is why applications that need this functionality SHOULD
consider using a full-featured transport protocol such as TCP.</t>
<t>When an application closes a TCP, SCTP or DCCP socket, the transport
protocol on the receiving host is required to maintain TIME-WAIT state.
This prevents delayed packets from the closed connection instance from
being mistakenly associated with a later connection instance that
happens to reuse the same IP address and port pairs. The UDP protocol
does not implement such a mechanism. Therefore, UDP-based applications
need to be robust in this case. One application may close a socket or
terminate, followed in time by another application receiving on the same
port. This later application may then receive packets intended for the
first application that were delayed in the network.</t>
<section anchor="ports" title="Using UDP Ports">
<t>The rules procedures for the management of the Service Name and
Transport Protocol Port Number Registry are specified in <xref
target="RFC6335"></xref>. Recommendations for use of UDP ports are
provided in <xref target="I-D.ietf-tsvwg-port-use"></xref>.</t>
<t>A UDP sender SHOULD NOT use a zero source port value, and a UDP
receiver should not bind to port zero. Applications SHOULD implement
corresponding receiver checks at the application layer or explicitly
request that the operating system filter the received packets to
prevent receiving packets with an arbitrary port. This measure is
designed to provide additional protection from data injection attacks
from an off-path source (where the port values may not be known).
Although the source port value is often not directly used in multicast
applications, this should still be set to a random or pre-determined
value.</t>
<t>The UDP port number fields have been used as a basis to design
load-balancing solutions for IPv4. This approach has also been
leveraged for IPv6 <xref target="RFC6438"></xref>, but the IPv6 "flow
label" <xref target="RFC6437"></xref>may also be used as a basis for
entropy for load balancing. This use of the flow label for load
balancing is consistent with the intended use, although further
clarity was needed to ensure the field can be consistently used for
this purpose. Therefore, an updated IPv6 flow label <xref
target="RFC6437"></xref> and ECMP routing <xref
target="RFC6438"></xref> usage were specified. Router vendors are
encouraged to start using the flow label as a part of the flow hash,
providing support for IP-level ECMP without requiring use of UDP. The
end-to-end use of flow labels for load balancing is a long-term
solution. Even if the usage of the flow label has been clarified,
there will be a transition time before a significant proportion of
endpoints start to assign a good quality flow label to the flows that
they originate. The use of load balancing using the transport header
fields will likely continue until widespread deployment is finally
achieved.</t>
<section anchor="multi-flow"
title="Applications using Multiple UDP Ports">
<t>A single application may exchange several types of data. In some
cases, this may require multiple UDP flows (e.g., multiple sets of
flows, identified by different 5-tuples). <xref
target="RFC6335"></xref> recommends applications developers not to
apply to IANA to be assigned multiple well-known ports (user or
system). This does not discuss the implications of using multiple
flows with the same well-known port or pairs of dynamic ports (e.g.,
identified by a service name or signaling protocol).</t>
<t>Use of multiple flows can impact the network in several ways:</t>
<t><list style="symbols">
<t>Starting a series of successive connections can increase the
number of state bindings in middleboxes (e.g., NAPT or Firewall)
along the network path. UDP-based middlebox traversal usually
relies on timeouts to remove old state, since middleboxes are
unaware when a particular flow ceases to be used by an
application.</t>
<t>Using several flows at the same time may result in seeing
different network characteristics for each flow. It can not be
assumed both follow the same path (e.g., when ECMP is used,
traffic is intentionally hashed onto different parallel paths
based on the port numbers).</t>
<t>Using several flows can also increase the occupancy of a
binding or lookup table in a middlebox (e.g., NAPT or Firewall)
which may cause the device to change the way it manages the flow
state.</t>
<t>Further, using excessive numbers of flows can degrade the
ability of congestion control to react to congestion events,
unless the congestion state is shared between all flows in a
session.</t>
</list>Therefore, applications MUST NOT assume consistent behavior
of middleboxes when multiple UDP flows are used; many devices
respond differently as the number of ports used increases. Using
multiple flows with different QoS requirements requires applications
to verify that the expected performance is achieved using each
individual flow (five-tuple), see <xref target="QoS"></xref>.</t>
</section>
</section>
<section anchor="icmp" title="ICMP Guidelines">
<t>Applications can utilize information about ICMP error messages that
the UDP layer passes up for a variety of purposes <xref
target="RFC1122"></xref>. Applications SHOULD appropriately validate
the payload of ICMP messages to ensure these are received in response
to transmitted traffic (i.e., a reported error condition that
corresponds to a UDP datagram actually sent by the application). This
requires context, such as local state about communication instances to
each destination, that although readily available in
connection-oriented transport protocols is not always maintained by
UDP-based applications. Note that not all platforms have the necessary
APIs to support this validation, and some platforms already perform
this validation internally before passing ICMP information to the
application.</t>
<t>Any application response to ICMP error messages SHOULD be robust to
temporary routing failures, e.g., transient ICMP "unreachable"
messages should not normally cause a communication abort.</t>
</section>
</section>
<section anchor="seccons" title="Security Considerations">
<t>UDP does not provide communications security. Applications that need
to protect their communications against eavesdropping, tampering, or
message forgery SHOULD employ end-to-end security services provided 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 easily be
spoofed.</t>
<t>One option of securing UDP communications is with IPsec <xref
target="RFC4301"></xref>, which can provide authentication for flows of
IP packets through the Authentication Header (AH) <xref
target="RFC4302"></xref> and encryption and/or authentication through
the Encapsulating Security Payload (ESP) <xref target="RFC4303"></xref>.
Applications use the Internet Key Exchange (IKE) <xref
target="RFC5996"></xref> to configure IPsec for their sessions.
Depending on how IPsec is configured for a flow, it can authenticate or
encrypt the UDP headers as well as UDP payloads. If an application only
requires authentication, ESP with no encryption but with authentication
is often a better option than AH, because ESP can operate across
middleboxes. An application that uses IPsec requires the support of an
operating system that implements the IPsec protocol suite.</t>
<t>Although it is possible to use IPsec to secure UDP communications,
not all operating systems support IPsec or allow applications to easily
configure it for their flows. A second option of securing UDP
communications is through Datagram Transport Layer Security (DTLS) <xref
target="RFC6347"></xref>. DTLS provides communication privacy by
encrypting UDP payloads. It does not protect the UDP headers.
Applications can implement DTLS without relying on support from the
operating system.</t>
<t>Many other options for authenticating or encrypting UDP payloads
exist. For example, the GSS-API security framework <xref
target="RFC2743"></xref> or Cryptographic Message Syntax (CMS) <xref
target="RFC5652"></xref> could be used to protect UDP payloads. The IETF
standard for securing RTP <xref target="RFC3550"></xref> communication
sessions over UDP is the Secure Real-time Transport Protocol (SRTP)
<xref target="RFC3711"></xref>. In some applications, a better solution
is to protect larger stand-alone objects, such as files or messages,
instead of individual UDP payloads. In these situations, CMS <xref
target="RFC5652"></xref>, S/MIME <xref target="RFC5751"></xref> or
OpenPGP <xref target="RFC4880"></xref> could be used. In addition, there
are many non-IETF protocols in this area.</t>
<t>Like congestion control mechanisms, security mechanisms are difficult
to design and implement correctly. It is hence RECOMMENDED that
applications employ well-known standard security mechanisms such as DTLS
or IPsec, rather than inventing their own.</t>
<t>The Generalized TTL Security Mechanism (GTSM) <xref
target="RFC5082"></xref> 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.</t>
<t>In terms of congestion control, <xref target="RFC2309"></xref> and
<xref target="RFC2914"></xref> discuss the dangers of
congestion-unresponsive flows to the Internet. <xref
target="I-D.fairhurst-tsvwg-circuit-breaker"></xref> describes methods
that can be used to set a performance envelope that can assist in
preventing congestion collapse in the absence of congestion control or
when the congestion control fails to react to congestion events. This
document provides guidelines to designers of UDP-based applications to
congestion-control their transmissions, and does not raise any
additional security concerns.</t>
</section>
<section title="Summary">
<!-- <t>XXX to be updated prior to publication XXX</t>
<t>XXX Should set non-zero port values; should use a circuit breaker (especially if
not using CC); should consider pacing? XXX</t>
<t>XXX Multicast recommendations? XXX</t>
-->
<t>This section summarizes the guidelines made in Sections <xref
format="counter" target="udpuni"></xref> and <xref format="counter"
target="seccons"></xref> in a tabular format (<xref
target="sumtable"></xref>) for easy referencing.</t>
<texttable anchor="sumtable" title="Summary of recommendations">
<ttcol>Recommendation</ttcol>
<ttcol>Section</ttcol>
<c>MUST tolerate a wide range of Internet path conditions</c>
<c><xref format="counter" target="udpuni"></xref></c>
<c>SHOULD use a full-featured transport (TCP, SCTP, DCCP)</c>
<c></c>
<c> </c>
<c> </c>
<c>SHOULD control rate of transmission</c>
<c><xref format="counter" target="unicc"></xref></c>
<c>SHOULD perform congestion control over all traffic</c>
<c></c>
<c> </c>
<c> </c>
<c>for bulk transfers,</c>
<c><xref format="counter" target="unibt"></xref></c>
<c>SHOULD consider implementing TFRC</c>
<c></c>
<c>else, SHOULD in other ways use bandwidth similar to TCP</c>
<c></c>
<c> </c>
<c> </c>
<c>for non-bulk transfers,</c>
<c><xref format="counter" target="unildr"></xref></c>
<c>SHOULD measure RTT and transmit max. 1 datagram/RTT</c>
<c></c>
<c>else, SHOULD send at most 1 datagram every 3 seconds</c>
<c></c>
<c>SHOULD back-off retransmission timers following loss</c>
<c></c>
<c> </c>
<c> </c>
<c>for tunnels carrying IP Traffic,</c>
<c><xref format="counter" target="tun"></xref></c>
<c>SHOULD NOT perform congestion control</c>
<c></c>
<c> </c>
<c> </c>
<c>for non-IP tunnels or rate not determined by traffic,</c>
<c><xref format="counter" target="tun"></xref></c>
<c>SHOULD perform congestion control</c>
<c></c>
<c> </c>
<c> </c>
<c>SHOULD NOT send datagrams that exceed the PMTU, i.e.,</c>
<c><xref format="counter" target="unimsg"></xref></c>
<c>SHOULD discover PMTU or send datagrams < minimum PMTU; Specific
application mechanisms are REQUIRED if PLPMTUD is used.</c>
<c></c>
<c> </c>
<c> </c>
<c>SHOULD handle datagram loss, duplication, reordering</c>
<c><xref format="counter" target="unirel"></xref></c>
<c>SHOULD be robust to delivery delays up to 2 minutes</c>
<c></c>
<c> </c>
<c> </c>
<c>SHOULD enable IPv4 UDP checksum</c>
<c><xref format="counter" target="unichk"></xref></c>
<c>SHOULD enable IPv6 UDP checksum; Specific application mechanisms
are REQUIRED if a zero IPv6 UDP checksum is used.</c>
<c></c>
<c>else, MAY use UDP-Lite with suitable checksum coverage</c>
<c><xref format="counter" target="udplite"></xref></c>
<c> </c>
<c> </c>
<c>SHOULD NOT always send middlebox keep-alives</c>
<c><xref format="counter" target="nat"></xref></c>
<c>MAY use keep-alives when needed (min. interval 15 sec)</c>
<c></c>
<c> </c>
<c> </c>
<c>MUST check IP source address</c>
<c><xref format="counter" target="prog"></xref></c>
<c>and, for client/server applications</c>
<c></c>
<c>SHOULD send responses from src address matching request</c>
<c></c>
<c> </c>
<c> </c>
<c>SHOULD use standard IETF security protocols when needed</c>
<c><xref format="counter" target="seccons"></xref></c>
</texttable>
</section>
<section title="IANA Considerations">
<t>Note to RFC-Editor: please remove this entire section prior to
publication.</t>
<t>This document raises no IANA considerations.</t>
</section>
<section anchor="ack" title="Acknowledgments">
<t>The middlebox traversal guidelines in <xref target="nat"></xref>
incorporate ideas from Section 5 of <xref
target="I-D.ford-behave-app"></xref> by Bryan Ford, Pyda Srisuresh, and
Dan Kegel. The authors also acknowledge the contributions by Greg
Shepherd concerning the use of congestion control with multicast UDP
applications.</t>
<t></t>
<!-- ACK From original: <t>Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van
Beijnum, Stewart Bryant, Remi Denis-Courmont, Lisa Dusseault, Wesley
Eddy, Pasi Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman,
Cullen Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip
Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi
Sarolahti, Pascal Thubert, Joe Touch, Dave Ward, and Magnus Westerlund
for their comments on this document.</t>
<t>The middlebox traversal guidelines in <xref target="nat"></xref>
incorporate ideas from Section 5 of <xref target="I-D.ford-behave-app"></xref> by
Bryan Ford, Pyda Srisuresh, and Dan Kegel.</t>
<t>Lars Eggert is partly funded by <xref target="TRILOGY"></xref>, a
research project supported by the European Commission under its Seventh
Framework Program. Gorry Fairhurst was partly funded by the EC SatNEx
project.</t> -->
</section>
</middle>
<back>
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC1122;
&RFC1191;
&RFC1981;
&RFC2119;
&RFC2460;
&RFC2914;
&RFC3828;
&RFC4787;
&RFC4821;
&RFC5348;
&RFC5405;
&RFC6298;
</references>
<references title="Informative References">
&RFC0896;
&RFC0919;
&RFC1112;
&RFC1536;
&RFC1546;
&RFC2309;
<!--&RFC2475;-->
&RFC2675;
&RFC2743;
&RFC2887;
&RFC3048;
&RFC3124;
&RFC3261;
&RFC3303;
&RFC3493;
&RFC3550;
&RFC3551;
&RFC3711;
&RFC3738;
&RFC3758;
&RFC3819;
&RFC4301;
&RFC4302;
&RFC4303;
&RFC4340;
&RFC4341;
&RFC4342;
&RFC4607;
&RFC4654;
&RFC4880;
&RFC4960;
&RFC4963;
&RFC4987;
&RFC5082;
&RFC5245;
&RFC5622;
&RFC5652;
&RFC5740;
&RFC5751;
&RFC5775;
<!--&RFC5885;-->
&RFC5971;
&RFC5973;
&RFC5996;
&RFC6335;
&RFC6347;
&RFC6395;
&RFC6396;
&RFC6437;
&RFC6438;
&RFC6513;
&RFC6679;
&RFC6726;
&RFC6807;
<!--&RFC6936;-->
&I-D.ford-behave-app;
&I-D.fairhurst-tsvwg-circuit-breaker;
&I-D.ietf-tsvwg-port-use;
&I-D.ietf-avtcore-rtp-circuit-breakers;
<reference anchor="POSIX">
<front>
<title>Standard for Information Technology - Portable Operating
System Interface (POSIX)</title>
<author initials="" surname="IEEE Std. 1003.1-2001">
<organization></organization>
</author>
<date month="December" year="2001" />
</front>
<seriesInfo name="Open Group Technical Standard: Base Specifications"
value="Issue 6, ISO/IEC 9945:2002" />
</reference>
<reference anchor="STEVENS">
<front>
<title>UNIX Network Programming, The sockets Networking API</title>
<author initials="W. R." surname="Stevens">
<organization></organization>
</author>
<author initials="B." surname="Fenner">
<organization></organization>
</author>
<author initials="A. M." surname="Rudoff">
<organization></organization>
</author>
<date month="Addison-Wesley," year="2004" />
</front>
</reference>
<reference anchor="UPnP">
<front>
<title>Internet Gateway Device (IGD) Standardized Device Control
Protocol V 1.0</title>
<author surname="UPnP Forum">
<organization></organization>
</author>
<date month="November" year="2001" />
</front>
</reference>
<reference anchor="FABER">
<front>
<title>The TIME-WAIT State in TCP and Its Effect on Busy
Servers</title>
<author initials="T." surname="Faber">
<organization></organization>
</author>
<author initials="J." surname="Touch">
<organization></organization>
</author>
<author initials="W." surname="Yue">
<organization></organization>
</author>
<date month="March" year="1999" />
</front>
<seriesInfo name="Proc." value="IEEE Infocom" />
</reference>
</references>
<section title="Revision Notes">
<t>Note to RFC-Editor: please remove this entire section prior to
publication.</t>
<t>Changes in draft-eggert-tsvwg-rfc5405bis-00 (relative to
RFC5405):</t>
<t><list style="symbols">
<t>The words "application designers" were removed from the draft
title and the wording of the abstract was clarified abstract.</t>
<t>New text to clarify various issues and set new recommendations
not previously included in RFC 5405. These include new
recommendations for multicast, the use of checksums with IPv6, ECMP,
recommendations on port usage, use of ECN, use of DiffServ, circuit
breakers (initial text), etc.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:25 |