congestion control mechanisms available to applications while
simultaneously burdening the applications with implementations of
congestion feedback.
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP
Providing feedback at a layer below UDP would require an additional
packet header below UDP to carry sequence numbers in addition to the
8-byte header for UDP itself. Unless this header were an IP option
(which is likely to cause problems for many IPv4 routers), its
presence would need to be indicated using a different IP protocol
value from UDP. Thus, the packets would no longer look like UDP on
the wire, and the modified protocol would face deployment challenges
similar to those of an entirely new protocol.
To use congestion feedback at a layer below UDP most effectively, the
semantics of the UDP socket Application Programming Interface (API)
would also need changing, both to support a late decision on what to
send and to provide access to sequence numbers (so that the
application wouldn’t need to duplicate them for its own purposes).
Thus, the socket API would no longer look like UDP to end hosts.
This would effectively be a new transport protocol.
Given these complications, it seems cleaner to actually design a new
transport protocol, which also allows us to address the issues of
firewall traversal, flow setup, and parameter negotiation. We note
that any new transport protocol could also use a Congestion Manager
approach to share congestion state between flows using the same
congestion control algorithm, if this were deemed to be desirable.
3.3. Providing Congestion Control at the Transport Layer
The concerns from the discussions above have convinced us that the
best way to provide congestion control to applications that currently
use UDP is to provide congestion control at the transport layer, in a
transport protocol used as an alternative to UDP. One advantage of
providing end-to-end congestion control in an unreliable transport
protocol is that it could be used easily by a wide range of the
applications that currently use UDP, with minimal changes to the
application itself. The application itself would not have to provide
the congestion control mechanism, or even the feedback from the data
receiver to the data sender about lost or marked packets.
The question then arises of whether to adapt TCP for use by
unreliable applications, to use an unreliable variant of the Stream
Control Transmission Protocol (SCTP) or a version of RTP with built-
in congestion control, or to design a new transport protocol.
As we argue below, the desire for minimal overhead results in the
design decision to use a transport protocol containing only the
minimal necessary functionality, and to leave other functionality
such as reliability, semi-reliability, or Forward Error Correction
(FEC) to be layered on top.
3.3.1. Modifying TCP?
One alternative might be to create an unreliable variant of TCP, with
reliability layered on top for applications desiring reliable
delivery. However, our requirement is not simply for TCP minus in-
order reliable delivery, but also for the application to be able to
choose congestion control algorithms. TCP’s feedback mechanism works
well for TCP-like congestion control, but is inappropriate (or at the
very least, inefficient) for TFRC. In addition, TCP sequence numbers
are in bytes, not datagrams. This would complicate both congestion
feedback and any attempt to allow the application to decide, at
transmission time, what information should go into a packet.
Finally, there is the issue of whether a modified TCP would require a
new IP protocol number as well; a significantly modified TCP using
the same IP protocol number could have unwanted interactions with
some of the middleboxes already deployed in the network.
It seems best simply to leave TCP as it is, and to create a new
congestion control protocol for unreliable transfer. This is
especially true since any change to TCP, no matter how small, takes
an inordinate amount of time to standardize and deploy, given TCP’s
importance in the current Internet and the historical difficulty of
getting TCP implementations right.
3.3.2. Unreliable Variants of SCTP?
SCTP, the Stream Control Transmission Protocol [RFC2960], was in part
designed to accommodate multiple streams within a single end-to-end
connection, modifying TCP’s semantics of reliable, in-order delivery
to allow out-of-order delivery. However, explicit support for
multiple streams over a single flow at the transport layer is not
necessary for an unreliable transport protocol such as DCCP, which of
necessity allows out-of-order delivery. Because an unreliable
transport does not need streams support, applications should not have
to pay the penalties in terms of increased header size that accompany
the use of streams in SCTP.
The basic underlying structure of the SCTP packet, of a common SCTP
header followed by chunks for data, SACK information, and so on, is
motivated by SCTP’s goal of accommodating multiple streams. However,
this use of chunks comes at the cost of an increased header size for
packets, as each chunk must be aligned on 32-bit boundaries, and
therefore requires a fixed-size 4-byte chunk header. For example,
for a connection using ECN, SCTP includes separate control chunks for
the Explicit Congestion Notification Echo (ECNE) and Congestion
Window Reduced (CWR) functions, with the ECNE and CWR chunks each
requiring 8 bytes. As another example, the common header includes a
4-byte verification tag to validate the sender.
As a second concern, SCTP as currently specified uses TCP-like
congestion control, and does not provide support for alternative
congestion control algorithms such as TFRC that would be more
attractive to some of the applications currently using UDP flows.
Thus, the current version of SCTP would not meet the requirements for
a choice between forms of end-to-end congestion control.
Finally, the SCTP Partial Reliability extension [RFC3758] allows a
sender to selectively abandon outstanding messages, which ceases
retransmissions and allows the receiver to deliver any queued
messages on the affected streams. This service model, although
well-suited for some applications, differs from, and provides the
application somewhat less flexibility than, UDP’s fully unreliable
service.
One could suggest adding support for alternative congestion control
mechanisms as an option to SCTP, and adding a fully-unreliable
variant that does not include the mechanisms for multiple streams.
We would argue against this. SCTP is well-suited for applications
that desire limited retransmission with multistream or multihoming
support. Adding support for fully-unreliable variants, multiple
congestion control profiles, and reduced single-stream headers would
risk introducing unforeseen interactions and make further
modifications ever more difficult. We have chosen instead to
implement a minimal protocol, designed for fully-unreliable datagram
service, that provides only end-to-end congestion control and any
other mechanisms that cannot be provided in a higher layer.
3.3.3. Modifying RTP?
Several of our target applications currently use RTP layered above
UDP to transfer their data. Why not modify RTP to provide end-to-end
congestion control?
When RTP lives above UDP, modifying it to support congestion control
might create some of the problems described in Section 3.1. In
particular, user-level RTP implementations would want access to ECN
bits in UDP datagrams. It might be difficult or undesirable to allow
that access for RTP, but not for other user-level programs.
Kernel implementations of RTP would not suffer from this problem. In
the end, the argument against modifying RTP is the same as that
against modifying SCTP: Some applications, such as the export of flow
information from routers, need congestion control but don’t need much
of RTP’s functionality. From these applications’ point of view, RTP
would induce unnecessary overhead. Again, we would argue for a clean
and minimal protocol focused on end-to-end congestion control.
RTP would commonly be used as a layer above any new transport
protocol, however. The design of that new transport protocol should
take this into account, either by avoiding undue duplication of
information available in the RTP header, or by suggesting
modifications to RTP, such as a reduced RTP header that removes any
fields redundant with the new protocol’s headers.
3.3.4. Designing a New Transport Protocol
In the first half of this document, we have argued for providing
congestion control at the transport layer as an alternative to UDP,
instead of relying on congestion control supplied only above or below
UDP. In this section, we have examined the possibilities of
modifying SCTP, modifying TCP, and designing a new transport
protocol. In large part because of the requirement for unreliable
transport, and for accommodating TFRC as well as TCP-like congestion
control, we have concluded that modifications of SCTP or TCP are not
the best answer and that a new transport protocol is needed. Thus,
we have argued for the need for a new transport protocol that offers
unreliable delivery, accommodates TFRC as well as TCP-like congestion
control, accommodates the use of ECN, and requires minimal overhead
in packet size and in the state and CPU processing required at the
data receiver.
4. Selling Congestion Control to Reluctant Applications
The goal of this work is to provide general congestion control
mechanisms that will actually be used by many of the applications
that currently use UDP. This may include applications that are
perfectly happy without end-to-end congestion control. Several of
our design requirements follow from a desire to design and deploy a
congestion-controlled protocol that is actually attractive to these
"reluctant" applications. These design requirements include a choice
between different forms of congestion control, moderate overhead in
the size of the packet header, and the use of Explicit Congestion
Notification (ECN) and the ECN nonce [RFC3540], which provide
positive benefit to the application itself.
There will always be a few flows that are resistant to the use of
end-to-end congestion control, preferring an environment where end-
to-end congestion control is used by everyone else, but not by
themselves. There has been substantial agreement [RFC2309, FF99]
that in order to maintain the continued use of end-to-end congestion
control, router mechanisms are needed to detect and penalize
uncontrolled high-bandwidth flows in times of high congestion; these
router mechanisms are colloquially known as "penalty boxes".
However, before undertaking a concerted effort toward the deployment
of penalty boxes in the Internet, it seems reasonable, and more
effective, to first make a concerted effort to make end-to-end
congestion control easily available to applications currently using
UDP.
5. Additional Design Considerations
This section mentions some additional design considerations that
should be considered in designing a new transport protocol.
o Mobility: Mechanisms for multihoming and mobility are one area of
additional functionality that cannot necessarily be layered
cleanly and effectively on top of a transport protocol. Thus, one
outstanding design decision with any new transport protocol
concerns whether to incorporate mechanisms for multihoming and
mobility into the protocol itself. The current version of DCCP
[RFC4340] includes no multihoming or mobility support.
o Defense against DoS attacks and spoofing: A reliable handshake for
connection setup and teardown offers protection against DoS and
spoofing attacks. Mechanisms allowing a server to avoid holding
any state for unacknowledged connection attempts or already-
finished connections offer additional protection against DoS
attacks. Thus, in designing a new transport protocol, even one
designed to provide minimal functionality, the requirements for
providing defense against DoS attacks and spoofing need to be
considered.
o Interoperation with RTP: As Section 3.3.3 describes, attention
should be paid to any necessary or desirable changes in RTP when
it is used over the new protocol, such as reduced RTP headers.
o API: Some functionality required by the protocol, or useful for
applications using the protocol, may require the definition of new
API mechanisms. Examples include allowing applications to decide
what information to put in a packet at transmission time, and
providing applications with some information about packet sequence
numbers.
o Interactions with NATs and firewalls: NATs and firewalls don’t
interact well with UDP, with its lack of explicit flow setup and
teardown and, in practice, the lack of well-known ports for many
UDP applications. Some of these issues are application specific;
others should be addressed by the transport protocol itself.
o Consider general experiences with unicast transport: A
Requirements for Unicast Transport/Sessions (RUTS) BOF was held at
the IETF meeting in December 1998, with the goal of understanding
the requirements of applications whose needs were not met by TCP
[RUTS]. Not all of those unmet needs are relevant to or
appropriate for a unicast, congestion-controlled, unreliable flow
of datagrams designed for long-lived transfers. Some are,
however, and any new protocol should address those needs and other
requirements derived from the community’s experience. We believe
that this document addresses the requirements relevant to our
problem area that were brought up at the RUTS BOF.
6. Transport Requirements of Request/Response Applications
Up until now, this document has discussed the transport and
congestion control requirements of applications that generate long-
lived, large flows of unreliable datagrams. This section discusses
briefly the transport needs of another class of applications, those
of request/response transfers where the response might be a small
number of packets, with preferences that include both reliable
delivery and a minimum of state maintained at the ends. The reliable
delivery could be accomplished, for example, by having the receiver
re-query when one or more of the packets in the response is lost.
This is a class of applications whose needs are not well-met by
either UDP or by TCP.
Although there is a legitimate need for a transport protocol for such
short-lived reliable flows of such request/response applications, we
believe that the overlap with the requirements of DCCP is almost
non-existent and that DCCP should not be designed to meet the needs
of these request/response applications. Areas of non-compatible
requirements include the following:
o Reliability: DCCP applications don’t need reliability (and long-
lived applications that do require reliability are well-suited to
TCP or SCTP). In contrast, these short-lived request/response
applications do require reliability (possibly client-driven
reliability in the form of requesting missing segments of a
response).
o Connection setup and teardown: Because DCCP is aimed at flows
whose duration is often unknown in advance, it addresses
interactions with NATs and firewalls by having explicit handshakes
for setup and teardown. In contrast, the short-lived
request/response applications know the transfer length in advance,
but cannot tolerate the additional delay of a handshake for flow
setup. Thus, mechanisms for interacting with NATs and firewalls
are likely to be completely different for the two sets of
applications.
o Congestion control mechanisms: The styles of congestion control
mechanisms and negotiations of congestion control features are
heavily dependent on the flow duration. In addition, the
preference of the request/response applications for a stateless
server strongly impacts the congestion control choices. Thus,
DCCP and the short-lived request/response applications have rather
different requirements both for congestion control mechanisms and
for negotiation procedures.
7. Summary of Recommendations
Our problem statement has discussed the need for implementing
congestion control for unreliable flows. Additional problems concern
the need for low overhead, the problems of firewall traversal, and
the need for reliable parameter negotiation. Our consideration of
the problem statement has resulted in the following general
recommendations:
o A unicast transport protocol for unreliable datagrams should be
developed, including mandatory, built-in congestion control,
explicit connection setup and teardown, reliable feature
negotiation, and reliable congestion feedback.
o The protocol must provide a set of congestion control mechanisms
from which the application may choose. These mechanisms should
include, at minimum, TCP-like congestion control and a more
slowly-responding congestion control such as TFRC.
o Important features of the connection, such as the congestion
control mechanism in use, should be reliably negotiated by both
endpoints.
o Support for ECN should be included. (Applications could still
make the decision not to use ECN for a particular session.)
o The overhead must be low, in terms of both packet size and
protocol complexity.
o Some DoS protection for servers must be included. In particular,
servers can make themselves resistant to spoofed connection
attacks ("SYN floods").
o Connection setup and teardown must use explicit handshakes,
facilitating transmission through stateful firewalls.
In 2002, there was judged to be a consensus about the need for a new
unicast transport protocol for unreliable datagrams, and the next
step was then the consideration of more detailed architectural
issues.
8. Security Considerations
There are no security considerations for this document. It does
discuss a number of security issues in the course of problem
analysis, such as DoS resistance and firewall traversal. The
security considerations for DCCP are discussed separately in
[RFC4340].
9. Acknowledgements
We would like to thank Spencer Dawkins, Jiten Goel, Jeff Hammond,
Lars-Erik Jonsson, John Loughney, Michael Mealling, and Rik Wade for
feedback on earlier versions of this document. We would also like to
thank members of the Transport Area Working Group and of the DCCP
Working Group for discussions of these issues.
Informative References
[BRS99] Balakrishnan, H., Rahul, H., and S. Seshan, "An
Integrated Congestion Management Architecture for
Internet Hosts", SIGCOMM, Sept. 1999.
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-
End Congestion Control in the Internet", IEEE/ACM
Transactions on Networking, August 1999.
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior
of Web Servers", SIGCOMM 2001.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J., and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W.,
Griner, J., Heavens, I., Lahey, K., Semke, J., and B.
Volz, "Known TCP Implementation Problems", RFC 2525,
March 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion
Manager", RFC 3124, June 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
"TCP Friendly Rate Control (TFRC): Protocol
Specification", RFC 3448, January 2003.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
Explicit Congestion Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RUTS] Requirements for Unicast Transport/Sessions (RUTS)
BOF, Dec. 7, 1998. URL
"http://www.ietf.org/proceedings/98dec/43rd-ietf-
98dec-142.html".
Authors’ Addresses
Sally Floyd
ICSI Center for Internet Research (ICIR),
International Computer Science Institute,
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
EMail: floyd@icir.org
Mark Handley
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
UK
EMail: M.Handley@cs.ucl.ac.uk
Eddie Kohler
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
EMail: kohler@cs.ucla.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to