Request for Comments: 4336 ICIR
Category: Informational M. Handley
UCL
E. Kohler
UCLA
March 2006
Problem Statement for the
Datagram Congestion Control Protocol (DCCP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes for the historical record the motivation
behind the Datagram Congestion Control Protocol (DCCP), an unreliable
transport protocol incorporating end-to-end congestion control. DCCP
implements a congestion-controlled, unreliable flow of datagrams for
use by applications such as streaming media or on-line games.
Table of Contents
1. Introduction ....................................................2
2. Problem Space ...................................................3
2.1. Congestion Control for Unreliable Transfer .................4
2.2. Overhead ...................................................6
2.3. Firewall Traversal .........................................6
2.4. Parameter Negotiation ......................................7
3. Solution Space for Congestion Control of Unreliable Flows .......7
3.1. Providing Congestion Control Above UDP .....................8
3.1.1. The Burden on the Application Designer ..............8
3.1.2. Difficulties with ECN ...............................8
3.1.3. The Evasion of Congestion Control ..................10
3.2. Providing Congestion Control Below UDP ....................10
3.2.1. Case 1: Congestion Feedback at the Application .....11
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11
3.3. Providing Congestion Control at the Transport Layer .......12
3.3.1. Modifying TCP? .....................................12
3.3.2. Unreliable Variants of SCTP? .......................13
3.3.3. Modifying RTP? .....................................14
3.3.4. Designing a New Transport Protocol .................14
4. Selling Congestion Control to Reluctant Applications ...........15
5. Additional Design Considerations ...............................15
6. Transport Requirements of Request/Response Applications ........16
7. Summary of Recommendations .....................................17
8. Security Considerations ........................................18
9. Acknowledgements ...............................................18
Informative References ............................................19
1. Introduction
Historically, the great majority of Internet unicast traffic has used
congestion-controlled TCP, with UDP making up most of the remainder.
UDP has mainly been used for short, request-response transfers, like
DNS and SNMP, that wish to avoid TCP’s three-way handshake,
retransmission, and/or stateful connections. UDP also avoids TCP’s
built-in end-to-end congestion control, and UDP applications tended
not to implement their own congestion control. However, since UDP
traffic volume was small relative to congestion-controlled TCP flows,
the network didn’t collapse.
Recent years have seen the growth of applications that use UDP in a
different way. These applications, including streaming audio,
Internet telephony, and multiplayer and massively multiplayer on-line
games, share a preference for timeliness over reliability. TCP can
introduce arbitrary delay because of its reliability and in-order
delivery requirements; thus, the applications use UDP instead. This
growth of long-lived non-congestion-controlled traffic, relative to
congestion-controlled traffic, poses a real threat to the overall
health of the Internet [RFC2914, RFC3714].
Applications could implement their own congestion control mechanisms
on a case-by-case basis, with encouragement from the IETF. Some
already do this. However, experience shows that congestion control
is difficult to get right, and many application writers would like to
avoid reinventing this particular wheel. We believe that a new
protocol is needed, one that combines unreliable datagram delivery
with built-in congestion control. This protocol will act as an
enabling technology: existing and new applications could easily use
it to transfer timely data without destabilizing the Internet.
This document provides a problem statement for such a protocol. We
list the properties the protocol should have, then explain why those
properties are necessary. We describe why a new protocol is the best
solution for the more general problem of bringing congestion control
to unreliable flows of unicast datagrams, and discuss briefly
subsidiary requirements for mobility, defense against Denial of
Service (DoS) attacks and spoofing, interoperation with RTP, and
interactions with Network Address Translators (NATs) and firewalls.
One of the design preferences that we bring to this question is a
preference for a clean, understandable, low-overhead, and minimal
protocol. As described later in this document, this results in the
design decision to leave functionality such as reliability or Forward
Error Correction (FEC) to be layered on top, rather than provided in
the transport protocol itself.
This document began in 2002 as a formalization of the goals of DCCP,
the Datagram Congestion Control Protocol [RFC4340]. We intended DCCP
to satisfy this problem statement, and thus the original reasoning
behind many of DCCP’s design choices can be found here. However, we
believed, and continue to believe, that the problem should be solved
whether or not DCCP is the chosen solution.
2. Problem Space
We perceive a number of problems related to the use of unreliable
data flows in the Internet. The major issues are the following:
o The potential for non-congestion-controlled datagram flows to
cause congestion collapse of the network. (See Section 5 of
[RFC2914] and Section 2 of [RFC3714].)
o The difficulty of correctly implementing effective congestion
control mechanisms for unreliable datagram flows.
o The lack of a standard solution for reliably transmitting
congestion feedback for an unreliable data flow.
o The lack of a standard solution for negotiating Explicit
Congestion Notification (ECN) [RFC3168] usage for unreliable
flows.
o The lack of a choice of TCP-friendly congestion control
mechanisms.
We assume that most application writers would use congestion control
for long-lived unreliable flows if it were available in a standard,
easy-to-use form.
More minor issues include the following:
o The difficulty of deploying applications using UDP-based flows in
the presence of firewalls.
o The desire to have a single way to negotiate congestion control
parameters for unreliable flows, independently of the signalling
protocol used to set up the flow.
o The desire for low per-packet byte overhead.
The subsections below discuss these problems of providing congestion
control, traversing firewalls, and negotiating parameters in more
detail. A separate subsection also discusses the problem of
minimizing the overhead of packet headers.
2.1. Congestion Control for Unreliable Transfer
We aim to bring easy-to-use congestion control mechanisms to
applications that generate large or long-lived flows of unreliable
datagrams, such as RealAudio, Internet telephony, and multiplayer
games. Our motivation is to avoid congestion collapse. (The short
flows generated by request-response applications, such as DNS and
SNMP, don’t cause congestion in practice, and any congestion control
mechanism would take effect between flows, not within a single end-
to-end transfer of information.) However, before designing a
congestion control mechanism for these applications, we must
understand why they use unreliable datagrams in the first place, lest
we destroy the very properties they require.
There are several reasons why protocols currently use UDP instead of
TCP, among them:
o Startup Delay: they wish to avoid the delay of a three-way
handshake before initiating data transfer.
o Statelessness: they wish to avoid holding connection state, and
the potential state-holding attacks that come with this.
o Trading of Reliability against Timing: the data being sent is
timely in the sense that if it is not delivered by some deadline
(typically a small number of RTTs), then the data will not be
useful at the receiver.
Of these issues, applications that generate large or long-lived flows
of datagrams, such as media transfer and games, mostly care about
controlling the trade-off between timing and reliability. Such
applications use UDP because when they send a datagram, they wish to
send the most appropriate data in that datagram. If the datagram is
lost, they may or may not resend the same data, depending on whether
the data will still be useful at the receiver. Data may no longer be
useful for many reasons:
o In a telephony or streaming video session, data in a packet
comprises a timeslice of a continuous stream. Once a timeslice
has been played out, the next timeslice is required immediately.
If the data comprising that timeslice arrives at some later time,
then it is no longer useful. Such applications can cope with
masking the effects of missing packets to some extent, so when the
sender transmits its next packet, it is important for it to only
send data that has a good chance of arriving in time for its
playout.
o In an interactive game or virtual-reality session, position
information is transient. If a datagram containing position
information is lost, resending the old position does not usually
make sense -- rather, every position information datagram should
contain the latest position information.
In a congestion-controlled flow, the allowed packet sending rate
depends on measured network congestion. Thus, some control is given
up to the congestion control mechanism, which determines precisely
when packets can be sent. However, applications could still decide,
at transmission time, which information to put in a packet. TCP
doesn’t allow control over this; these applications demand it.
Often, these applications (especially games and telephony
applications) work on very short playout timescales. Whilst they are
usually able to adjust their transmission rate based on congestion
feedback, they do have constraints on how this adaptation can be
performed so that it has minimal impact on the quality of the
session. Thus, they tend to need some control over the short-term
dynamics of the congestion control algorithm, whilst being fair to
other traffic on medium timescales. This control includes, but is
not limited to, some influence on which congestion control algorithm
should be used -- for example, TCP-Friendly Rate Control (TFRC)
[RFC3448] rather than strict TCP-like congestion control. (TFRC has
been standardized in the IETF as a congestion control mechanism that
adjusts its sending rate more smoothly than TCP does, while
maintaining long-term fair bandwidth sharing with TCP [RFC3448].)
2.2. Overhead
The applications we are concerned with often send compressed data, or
send frequent small packets. For example, when Internet telephony or
streaming media are used over low-bandwidth modem links, highly
compressing the payload data is essential. For Internet telephony
applications and for games, the requirement is for low delay, and
hence small packets are sent frequently.
For example, a telephony application sending a 5.6 Kbps data stream
but wanting moderately low delay may send a packet every 20 ms,
sending only 14 data bytes in each packet. In addition, 20 bytes is
taken up by the IP header, with additional bytes for transport and/or
application headers. Clearly, it is desirable for such an
application to have a low-overhead transport protocol header.
In some cases, the correct solution would be to use link-based packet
header compression to compress the packet headers, although we cannot
guarantee the availability of such compression schemes on any
particular link.
The delay of data until after the completion of a handshake also
represents potentially unnecessary overhead. A new protocol might
therefore allow senders to include some data on their initial
datagrams.
2.3. Firewall Traversal
Applications requiring a flow of unreliable datagrams currently tend
to use signalling protocols such as the Real Time Streaming Protocol
(RTSP) [RFC2326], SIP [RFC3261], and H.323 in conjunction with UDP
for the data flow. The initial setup request uses a signalling
protocol to locate the correct remote end-system for the data flow,
sometimes after being redirected or relayed to other machines.
As UDP flows contain no explicit setup and teardown, it is hard for
firewalls to handle them correctly. Typically, the firewall needs to
parse RTSP, SIP, and H.323 to obtain the information necessary to
open a hole in the firewall. Although, for bi-directional flows, the
firewall can open a bi-directional hole if it receives a UDP packet
from inside the firewall, in this case the firewall can’t easily know
when to close the hole again.
While we do not consider these to be major problems, they are
nonetheless issues that application designers face. Currently,
streaming media players attempt UDP first, and then switch to TCP if
UDP is not successful. Streaming media over TCP is undesirable and
can result in the receiver needing to temporarily halt playout while
it "rebuffers" data. Telephony applications don’t even have this
option.
2.4. Parameter Negotiation
Different applications have different requirements for congestion
control, which may map into different congestion feedback. Examples
include ECN capability and desired congestion control dynamics (the
choice of congestion control algorithm and, therefore, the form of
feedback information required). Such parameters need to be reliably
negotiated before congestion control can function correctly.
While this negotiation could be performed using signalling protocols
such as SIP, RTSP, and H.323, it would be desirable to have a single
standard way of negotiating these transport parameters. This is of
particular importance with ECN, where sending ECN-marked packets to a
non-ECN-capable receiver can cause significant congestion problems to
other flows. We discuss the ECN issue in more detail below.
3. Solution Space for Congestion Control of Unreliable Flows
We thus want to provide congestion control for unreliable flows,
providing both ECN and the choice of different forms of congestion
control, and providing moderate overhead in terms of packet size,
state, and CPU processing. There are a number of options for
providing end-to-end congestion control for the unicast traffic that
currently uses UDP, in terms of the layer that provides the
congestion control mechanism:
o Congestion control above UDP.
o Congestion control below UDP.
o Congestion control at the transport layer in an alternative to
UDP.
We explore these alternatives in the sections below. The concerns
from the discussions below have convinced us that the best way to
provide congestion control for unreliable flows is to provide
congestion control at the transport layer, as an alternative to the
use of UDP and TCP.
3.1. Providing Congestion Control Above UDP
One possibility would be to provide congestion control at the
application layer, or at some other layer above UDP. This would
allow the congestion control mechanism to be closely integrated with
the application itself.
3.1.1. The Burden on the Application Designer
A key disadvantage of providing congestion control above UDP is that
it places an unnecessary burden on the application-level designer,
who might be just as happy to use the congestion control provided by
a lower layer. If the application can rely on a lower layer that
gives a choice between TCP-like or TFRC-like congestion control, and
that offers ECN, then this might be highly satisfactory to many
application designers.
The long history of debugging TCP implementations [RFC2525, PF01]
makes the difficulties in implementing end-to-end congestion control
abundantly clear. It is clearly more robust for congestion control
to be provided for the application by a lower layer. In rare cases,
there might be compelling reasons for the congestion control
mechanism to be implemented in the application itself, but we do not
expect this to be the general case. For example, applications that
use RTP over UDP might be just as happy if RTP itself implemented
end-to-end congestion control. (See Section 3.3.3 for more
discussion of RTP.)
In addition to congestion control issues, we also note the problems
with firewall traversal and parameter negotiation discussed in
Sections 2.3 and 2.4. Implementing on top of UDP requires that the
application designer also address these issues.
3.1.2. Difficulties with ECN
There is a second problem with providing congestion control above
UDP: it would require either giving up the use of ECN or giving the
application direct control over setting and reading the ECN field in
the IP header. Giving up the use of ECN would be problematic, since
ECN can be particularly useful for unreliable flows, where a dropped
packet will not be retransmitted by the data sender.
With the development of the ECN nonce, ECN can be useful even in the
absence of network support. The data sender can use the ECN nonce,
along with feedback from the data receiver, to verify that the data
receiver is correctly reporting all lost packets. This use of ECN
can be particularly useful for an application using unreliable
delivery, where the receiver might otherwise have little incentive to
report lost packets.
In order to allow the use of ECN by a layer above UDP, the UDP socket
would have to allow the application to control the ECN field in the
IP header. In particular, the UDP socket would have to allow the
application to specify whether or not the ECN-Capable Transport (ECT)
codepoints should be set in the ECN field of the IP header.
The ECN contract is that senders who set the ECT codepoint must
respond to Congestion Experienced (CE) codepoints by reducing their
sending rates. Therefore, the ECT codepoint can only safely be set
in the packet header of a UDP packet if the following is guaranteed:
o if the CE codepoint is set by a router, the receiving IP layer
will pass the CE status to the UDP layer, which will pass it to
the receiving application at the data receiver; and
o upon receiving a packet that had the CE codepoint set, the
receiving application will take the appropriate congestion control
action, such as informing the data sender.
However, the UDP implementation at the data sender has no way of
knowing if the UDP implementation at the data receiver has been
upgraded to pass a CE status up to the receiving application, let
alone whether or not the application will use the conformant end-to-
end congestion control that goes along with use of ECN.
In the absence of the widespread deployment of mechanisms in routers
to detect flows that are not using conformant congestion control,
allowing applications arbitrary control of the ECT codepoints for UDP
packets would seem like an unnecessary opportunity for applications
to use ECN while evading the use of end-to-end congestion control.
Thus, there is an inherent "chicken-and-egg" problem of whether first
to deploy policing mechanisms in routers, or first to enable the use
of ECN by UDP flows. Without the policing mechanisms in routers, we
would not advise adding ECN-capability to UDP sockets at this time.
In the absence of more fine-grained mechanisms for dealing with a
period of sustained congestion, one possibility would be for routers
to discontinue using ECN with UDP packets during the congested
period, and to use ECN only with TCP or DCCP packets. This would be
a reasonable response, for example, if TCP or DCCP flows were found
to be more likely to be using conformant end-to-end congestion
control than were UDP flows. If routers were to adopt such a policy,
then DCCP flows could be more likely to receive the benefits of ECN
in times of congestion than would UDP flows.
3.1.3. The Evasion of Congestion Control
A third problem of providing congestion control above UDP is that
relying on congestion control at the application level makes it
somewhat easier for some users to evade end-to-end congestion
control. We do not claim that a transport protocol such as DCCP
would always be implemented in the kernel, and do not attempt to
evaluate the relative difficulty of modifying code inside the kernel
vs. outside the kernel in any case. However, we believe that putting
the congestion control at the transport level rather than at the
application level makes it just slightly less likely that users will
go to the trouble of modifying the code in order to avoid using end-
to-end congestion control.
3.2. Providing Congestion Control Below UDP
Instead of providing congestion control above UDP, a second
possibility would be to provide congestion control for unreliable
applications at a layer below UDP, with applications using UDP as
their transport protocol. Given that UDP does not itself provide
sequence numbers or congestion feedback, there are two possible forms
for this congestion feedback:
1) Feedback at the application: The application above UDP could
provide sequence numbers and feedback to the sender, which would
then communicate loss information to the congestion control
mechanism. This is the approach currently standardized by the
Congestion Manager (CM) [RFC3124].
2) Feedback at the layer below UDP: The application could use UDP,
and a protocol could be implemented using a shim header between IP
and UDP to provide sequence number information for data packets
and return feedback to the data sender. The original proposal for
the Congestion Manager [BRS99] suggested providing this layer for
applications that did not have their own feedback about dropped
packets.
We discuss these two cases separately below.
3.2.1. Case 1: Congestion Feedback at the Application
In this case, the application provides sequence numbers and
congestion feedback above UDP, but communicates that feedback to a
congestion manager below UDP, which regulates when packets can be
sent. This approach suffers from most of the problems described in
Section 3.1, namely, forcing the application designer to reinvent the
wheel each time for packet formats and parameter negotiation, and
problems with ECN usage, firewalls, and evasion.
It would avoid the application writer needing to implement the
control part of the congestion control mechanism, but it is unclear
how easily multiple congestion control algorithms (such as receiver-
based TFRC) can be supported, given that the form of congestion
feedback usually needs to be closely coupled to the congestion
control algorithm being used. Thus, this design limits the choice of