< draft-floyd-dcp-problem-00.txt   draft-floyd-dcp-problem-01.txt >
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT Sally Floyd INTERNET-DRAFT Sally Floyd
draft-floyd-dcp-problem-00.txt Mark Handley draft-floyd-dcp-problem-01.txt Mark Handley
Eddie Kohler Eddie Kohler
ICIR ICIR
22 February 2002 26 August 2002
Expires: August 2002 Expires: February 2003
Problem Statement for DCP Problem Statement for DCCP
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. Internet-Drafts are all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 36 skipping to change at page 1, line 36
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document gives the problem statement underlying the This document gives the problem statement underlying the
development of an unreliable transport protocol incorporating development of an unreliable transport protocol incorporating
end-to-end congestion control. This is also the problem end-to-end congestion control. This is also the problem
statement underlying the development of DCP, the Datagram statement underlying the development of DCCP, the Datagram
Control Protocol. DCP implements a congestion-controlled, Congestion Control Protocol. DCCP implements a congestion-
unreliable flow of datagrams suitable for use by applications controlled, unreliable flow of datagrams suitable for use by
such as streaming media or on-line games. applications such as streaming media or on-line games.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Space . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Space . . . . . . . . . . . . . . . . . . . . . 4
2.1. Congestion Control for Unreliable Transfer . . . . . 4 2.1. Congestion Control for Unreliable Transfer . . . . . 4
2.2. Overhead . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Overhead . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Firewall Traversal . . . . . . . . . . . . . . . . . 6 2.3. Firewall Traversal . . . . . . . . . . . . . . . . . 7
2.4. Parameter Negotiation. . . . . . . . . . . . . . . . 7 2.4. Parameter Negotiation. . . . . . . . . . . . . . . . 7
3. Solution Space for Congestion Control of Unreli- 3. Solution Space for Congestion Control of Unreli-
able Flows . . . . . . . . . . . . . . . . . . . . . . . . 7 able Flows . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Providing Congestion Control above UDP . . . . . . . 8 3.1. Providing Congestion Control Above UDP . . . . . . . 8
3.1.1. The Burden on the Application Designer. . . . . . 8 3.1.1. The Burden on the Application Designer. . . . . . 8
3.1.2. Difficulties with ECN . . . . . . . . . . . . . . 9 3.1.2. Difficulties with ECN . . . . . . . . . . . . . . 9
3.1.3. The Evasion of Congestion Control . . . . . . . . 10 3.1.3. The Evasion of Congestion Control . . . . . . . . 10
3.2. Providing Congestion Control below UDP . . . . . . . 10 3.2. Providing Congestion Control Below UDP . . . . . . . 10
3.2.1. Case 1: Congestion Feedback at the Applica- 3.2.1. Case 1: Congestion Feedback at the Applica-
tion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 tion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Case 2: Congestion Feedback at a Layer 3.2.2. Case 2: Congestion Feedback at a Layer
below UDP. . . . . . . . . . . . . . . . . . . . . . . . 11 below UDP. . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Providing Congestion Control at the Transport 3.3. Providing Congestion Control at the Transport
Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Modifying TCP?. . . . . . . . . . . . . . . . . . 12 3.3.1. Modifying TCP?. . . . . . . . . . . . . . . . . . 12
3.3.2. Unreliable Variants of SCTP?. . . . . . . . . . . 12 3.3.2. Unreliable Variants of SCTP?. . . . . . . . . . . 12
3.3.3. Designing a New Transport Protocol. . . . . . . . 13 3.3.3. Modifying RTP?. . . . . . . . . . . . . . . . . . 13
3.3.4. Designing a New Transport Protocol. . . . . . . . 14
4. Selling Congestion Control to Reluctant Applica- 4. Selling Congestion Control to Reluctant Applica-
tions. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 tions. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Additional Design Considerations. . . . . . . . . . . . 14 5. Additional Design Considerations. . . . . . . . . . . . 15
6. Summary of Recommendations. . . . . . . . . . . . . . . 15 6. Summary of Recommendations. . . . . . . . . . . . . . . 16
7. References. . . . . . . . . . . . . . . . . . . . . . . 16 7. References. . . . . . . . . . . . . . . . . . . . . . . 17
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 17 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Historically, the great majority of Internet unicast traffic has Historically, the great majority of Internet unicast traffic has
used congestion-controlled TCP, with UDP making up most of the used congestion-controlled TCP, with UDP making up most of the
remainder. UDP has mainly been used for short, request-response remainder. UDP has mainly been used for short, request-response
transfers, like DNS and SNMP, that wish to avoid TCP's three-way transfers, like DNS and SNMP, that wish to avoid TCP's three-way
handshake, retransmission, and/or stateful connections. UDP also handshake, retransmission, and/or stateful connections. UDP also
avoids TCP's built-in end-to-end congestion control, and UDP avoids TCP's built-in end-to-end congestion control, and UDP
applications tended not to implement their own congestion control. applications tended not to implement their own congestion control.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
different way. These applications, including RealAudio, Internet different way. These applications, including RealAudio, Internet
telephony, and on-line games such as Half Life, Quake, and telephony, and on-line games such as Half Life, Quake, and
Starcraft, share a preference for timeliness over reliability. TCP Starcraft, share a preference for timeliness over reliability. TCP
can introduce arbitrary delay because of its reliability and in- can introduce arbitrary delay because of its reliability and in-
order delivery requirements; thus, the applications use UDP instead. order delivery requirements; thus, the applications use UDP instead.
This growth of long-lived non-congestion-controlled traffic, This growth of long-lived non-congestion-controlled traffic,
relative to congestion-controlled traffic, poses a real threat to relative to congestion-controlled traffic, poses a real threat to
the overall health of the Internet. the overall health of the Internet.
Applications could implement their own congestion control mechanisms Applications could implement their own congestion control mechanisms
on a case-by-case basis, with encouragement from the IETF. (Some on a case-by-case basis, with encouragement from the IETF. Some
already do this.) Unfortunately, experience shows that congestion already do this. However, experience shows that congestion control
control is difficult to get right, and application writers would is difficult to get right, and many application writers would like
likely avoid reinventing this particular wheel. We believe that a to avoid reinventing this particular wheel. We believe that a new
new protocol is needed, one that combines unreliable datagram protocol is needed, one that combines unreliable datagram delivery
delivery with built-in congestion control. This protocol would act with built-in congestion control. This protocol would act as an
as an enabling technology: existing and new applications could enabling technology: existing and new applications could easily use
easily use it to transfer timely data without destabilizing the it to transfer timely data without destabilizing the Internet.
Internet.
This document provides a problem statement for this protocol. We This document provides a problem statement for such a protocol. We
list the properties the protocol should have, then explain why those list the properties the protocol should have, then explain why those
properties are necessary. We also describe why a new protocol is the properties are necessary. We also describe why a new protocol is the
best solution for the more general problem of bringing congestion best solution for the more general problem of bringing congestion
control to unreliable flows of unicast datagrams. control to unreliable flows of unicast datagrams.
This problem statement began as a formalization of the goals of DCP, This problem statement began as a formalization of the goals of
a proposed protocol already described in several Internet-Drafts. We DCCP, a proposed protocol already described in several Internet-
intended DCP to satisfy the problem statement laid out here. Drafts. We intended DCCP to satisfy the problem statement laid out
However, we believe the problem should be solved whether or not the here. However, we believe the problem should be solved whether or
chosen solution is DCP, and the DCP drafts should be judged based on not the chosen solution is DCCP, and the DCCP drafts should be
this document or its successors. Nevertheless, for convenience, we judged based on this document or its successors. Nevertheless, for
write "DCP" to mean "any protocol that satisfies this problem convenience, we write "DCCP" to mean "any protocol that satisfies
statement". this problem statement".
2. Problem Space 2. Problem Space
We perceive a number of problems related to the use of unreliable We perceive a number of problems related to the use of unreliable
data flows in the Internet. The major issues are: data flows in the Internet. The major issues are:
o The potential for non-congestion-controlled datagram flows to o The potential for non-congestion-controlled datagram flows to
cause congestion collapse of the network. cause congestion collapse of the network.
o The difficulty of correctly implementing effective congestion o The difficulty of correctly implementing effective congestion
skipping to change at page 4, line 39 skipping to change at page 4, line 39
More minor problems are: More minor problems are:
o The difficulty of deploying applications using UDP-based flows in o The difficulty of deploying applications using UDP-based flows in
the presence of firewalls. the presence of firewalls.
o The desire to have a single way to negotiate congestion control o The desire to have a single way to negotiate congestion control
parameters for unreliable flows, independently of the signalling parameters for unreliable flows, independently of the signalling
protocol used to set up the flow. 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 The subsections below discuss these problems of providing congestion
control, traversing firewalls, and negotiating parameters in more control, traversing firewalls, and negotiating parameters in more
detail. A separate subsection also discusses the problem of detail. A separate subsection also discusses the problem of
minimizing the overhead of packet headers. minimizing the overhead of packet headers.
2.1. Congestion Control for Unreliable Transfer 2.1. Congestion Control for Unreliable Transfer
This project aims to bring easy-to-use congestion control mechanisms This project aims to bring easy-to-use congestion control mechanisms
to applications that generate long-lived, large flows of unreliable to applications that generate long-lived, large flows of unreliable
datagrams, such as RealAudio, Internet telephony, and multiplayer datagrams, such as RealAudio, Internet telephony, and multiplayer
skipping to change at page 5, line 25 skipping to change at page 5, line 27
handshake. handshake.
o Statelessness: they wish to avoid holding connection state, and o Statelessness: they wish to avoid holding connection state, and
the potential state-holding attacks that come with this. the potential state-holding attacks that come with this.
o Trading of Reliability against Timing: the data being sent is o Trading of Reliability against Timing: the data being sent is
timely in the sense that if it is not delivered by some deadline 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 (typically a small number of RTTs) then the data will not be
useful at the receiver. useful at the receiver.
Our applications -- media transfer, games, and the like -- mostly Of these, our target applications -- media transfer, games, and the
care about having control over the tradeoff between timing and like -- mostly care about having control over the tradeoff between
reliability. Such applications use UDP because when they send a timing and reliability. Such applications use UDP because when they
datagram, they wish to send the most appropriate data in that 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 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 same data, depending on whether the data will still be useful at the
receiver. Data may no longer be useful for many reasons: receiver. Data may no longer be useful for many reasons:
o In a telephony or streaming video session, data in a packet o In a telephony or streaming video session, data in a packet
comprises a timeslice of a continuous stream. If the previous comprises a timeslice of a continuous stream. Once a timeslice
timeslice has just been played out, the next timeslice must then has been played out, the next timeslice is required immediately.
be available. If the data comprising that timeslice arrives at If the data comprising that timeslice arrives at some later time,
some later time, then it is no longer useful. Such applications then it is no longer useful. Such applications can cope with
can cope with masking the effects of missing packets to some masking the effects of missing packets to some extent, so when the
extent, so when the sender transmits its next packet, it is sender transmits its next packet, it is important for it to only
important for it to only send data that has a good chance of send data that has a good chance of arriving in time for its
arriving in time for its playout. playout.
o In a interactive game or VR session, position information is o In a interactive game or VR session, position information is
transient. If a datagram containing position information is lost, transient. If a datagram containing position information is lost,
resending the old position does not usually make sense -- rather, resending the old position does not usually make sense -- rather,
every position information datagram should contain the latest every position information datagram should contain the latest
position information. position information.
In a congestion-controlled flow, the allowed packet sending rate In a congestion-controlled flow, the allowed packet sending rate
depends on measured network congestion. Thus, applications must give depends on measured network congestion. Thus, applications must give
up some control to the congestion control mechanism, which up some control to the congestion control mechanism, which
determines precisely when packets can be sent. However, applications determines precisely when packets can be sent. However, applications
could still decide, at transmission time, which information to put could still decide, at transmission time, which information to put
in a packet. TCP doesn't allow control over this; these applications in a packet. TCP doesn't allow control over this; these applications
demand it. demand it.
Often, these applications work on very short playout timescales Often, these applications (especially games and telephony
(especially games and telephony applications). Whilst they are applications) work on very short playout timescales. Whilst they
usually able to adjust their transmission rate based on congestion are usually able to adjust their transmission rate based on
feedback, they do have constraints on how this adaptation can be congestion feedback, they do have constraints on how this adaptation
performed so that it has minimal impact on the quality of the 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 session. Thus, they tend to need some control over the short-term
dynamics of the congestion control algorithm, whilst being fair to dynamics of the congestion control algorithm, whilst being fair to
other traffic on medium timescales. This control includes, but is other traffic on medium timescales. This control includes, but is
not limited to, some influence on which congestion control algorithm not limited to, some influence on which congestion control algorithm
should be used -- for example, TFRC rather than strict TCP-like should be used -- for example, TFRC rather than strict TCP-like
congestion control. congestion control.
2.2. Overhead 2.2. Overhead
The applications we are concerned with often send compressed data, The applications we are concerned with often send compressed data,
skipping to change at page 6, line 43 skipping to change at page 6, line 47
by the IP header, leaving only 30 bytes for the transport header and by the IP header, leaving only 30 bytes for the transport header and
payload. Of course this is a relatively extreme example, but it payload. Of course this is a relatively extreme example, but it
serves to illustrate the degree to which some of these applications serves to illustrate the degree to which some of these applications
care that the transport protocol is low overhead. care that the transport protocol is low overhead.
In some cases the correct solution would be to use link-based packet In some cases the correct solution would be to use link-based packet
header compression to compress the packet headers, although we header compression to compress the packet headers, although we
cannot guarantee the availability of such compression schemes on any cannot guarantee the availability of such compression schemes on any
particular link. 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 2.3. Firewall Traversal
Applications requiring a flow of unreliable datagrams currently tend Applications requiring a flow of unreliable datagrams currently tend
to use signalling protocols such as RTSP, SIP and H.323 in to use signalling protocols such as RTSP, SIP and H.323 in
conjunction with UDP for the data flow. The initial setup request conjunction with UDP for the data flow. The initial setup request
uses a signalling protocol to locate the correct remote end-system uses a signalling protocol to locate the correct remote end-system
for the data flow, sometimes being redirected or relayed to other for the data flow, sometimes being redirected or relayed to other
machines, before the data flow is established. machines, before the data flow is established.
As UDP flows contain no explicit setup and teardown, it is hard for As UDP flows contain no explicit setup and teardown, it is hard for
skipping to change at page 7, line 41 skipping to change at page 7, line 49
While this negotiation could be performed using signalling protocols While this negotiation could be performed using signalling protocols
such as SIP, RTSP and H.323, it would be desirable to have a single 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 standard way of negotiating these transport parameters. This is of
particular importance with ECN, where sending ECN-marked packets to particular importance with ECN, where sending ECN-marked packets to
a non-ECN-capable receiver can cause significant congestion problems a non-ECN-capable receiver can cause significant congestion problems
to other flows. We discuss the ECN issue in more detail below. to other flows. We discuss the ECN issue in more detail below.
3. Solution Space for Congestion Control of Unreliable Flows 3. Solution Space for Congestion Control of Unreliable Flows
From the previous section, we want to provide congestion control for We thus want to provide congestion control for unreliable flows,
unreliable flows, providing both ECN and the choice of different providing both ECN and the choice of different forms of congestion
forms of congestion control, and providing moderate overhead in control, and providing moderate overhead in terms of packet size,
terms of packet size, state, and CPU processing. There are a number state, and CPU processing. There are a number of options for
of options for providing end-to-end congestion control for the providing end-to-end congestion control for the unicast traffic that
unicast traffic that currently uses UDP, in terms of the layer that currently uses UDP, in terms of the layer that provides the
provides the congestion control mechanism: congestion control mechanism:
o Congestion control above UDP. o Congestion control above UDP.
o Congestion control below UDP. o Congestion control below UDP.
o Congestion control at the transport layer as an alternative to o Congestion control at the transport layer as an alternative to
UDP. UDP.
We explore these alternatives in the sections below. The concerns We explore these alternatives in the sections below. The concerns
from the discussions below have convinced us that the best way to from the discussions below have convinced us that the best way to
provide congestion control for unreliable flows is to provide provide congestion control for unreliable flows is to provide
congestion control at the transport layer, as an alternative to the congestion control at the transport layer, as an alternative to the
use of UDP and TCP. use of UDP and TCP.
3.1. Providing Congestion Control above UDP 3.1. Providing Congestion Control Above UDP
One possibility would be to provide congestion control at the One possibility would be to provide congestion control at the
application layer, or at some other layer above UDP. Implementing application layer, or at some other layer above UDP. Implementing
congestion control at a layer above UDP would allow the congestion congestion control at a layer above UDP would allow the congestion
control mechanism to be closely integrated with the application control mechanism to be closely integrated with the application
itself. itself.
3.1.1. The Burden on the Application Designer 3.1.1. The Burden on the Application Designer
A key disadvantage of providing congestion control above UDP is that A key disadvantage of providing congestion control above UDP is that
it places an unnecessary burden on the application-level designer, it places an unnecessary burden on the application-level designer,
who might be just as happy to use the congestion control provided by 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 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 gives a choice between TCP-like or TFRC-like congestion control, and
that offers ECN, then this might be highly satisfactory to many that offers ECN, then this might be highly satisfactory to many
application designers. application designers.
The long history of debugging TCP implementations [RFC 2525] [TBIT] The long history of debugging TCP implementations [RFC 2525] [TBIT]
makes the difficulties in implementing end-to-end congestion control makes the difficulties in implementing end-to-end congestion control
abundantly clear. It is clearly more robust for the congestion abundantly clear. It is clearly more robust for congestion control
control to be provided for the application by a lower layer. In to be provided for the application by a lower layer. In rare cases
rare cases there might be compelling reasons for the congestion there might be compelling reasons for the congestion control
control mechanism to be implemented in the application itself, but mechanism to be implemented in the application itself, but we do not
we do not expect this to be the general case. expect this to be the general case. For example, applications that
use RTP over UDP might be just as happy if RTP itself implemented
We note that applications that use RTP over UDP might be just as end-to-end congestion control. (See Section 3.3.3 for more
happy if RTP itself implemented end-to-end congestion control. The discussion of RTP.)
fact that RTP does not currently implement end-to-end congestion
control for unicast traffic can be seen as a testimony to the
difficulties of implementing congestion control mechanisms at the
different layers above UDP.
In addition to congestion control issues, we also note the problems In addition to congestion control issues, we also note the problems
with firewall traversal and parameter negotiation discussed in with firewall traversal and parameter negotiation discussed in
sections 2.3 and 2.4. Implementing on top of UDP requires that the sections 2.3 and 2.4. Implementing on top of UDP requires that the
application designer also addresses these issues. application designer also address these issues.
3.1.2. Difficulties with ECN 3.1.2. Difficulties with ECN
A second problem of providing congestion control above UDP is that A second problem of providing congestion control above UDP is that
it would require either giving up the use of ECN, or giving the it would require either giving up the use of ECN, or giving the
application direct control over setting and reading the ECN field in application direct control over setting and reading the ECN field in
the IP header. Giving up the use of ECN would be problematic, since the IP header. Giving up the use of ECN would be problematic, since
ECN can be particularly useful for unreliable flows, where a dropped ECN can be particularly useful for unreliable flows, where a dropped
packet will not be retransmitted by the data sender. packet will not be retransmitted by the data sender.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
problem of whether first to deploy policing mechanisms in routers, problem of whether first to deploy policing mechanisms in routers,
or first to enable the use of ECN by UDP flows. Without the or first to enable the use of ECN by UDP flows. Without the
policing mechanisms in routers, we would not advise adding ECN- policing mechanisms in routers, we would not advise adding ECN-
capability to UDP sockets at this time. capability to UDP sockets at this time.
3.1.3. The Evasion of Congestion Control 3.1.3. The Evasion of Congestion Control
A third problem of providing congestion control above UDP is that A third problem of providing congestion control above UDP is that
relying on congestion control at the application level makes it relying on congestion control at the application level makes it
somewhat easier for some users to evade end-to-end congestion somewhat easier for some users to evade end-to-end congestion
control. We do not claim that a transport protocol such as DCP control. We do not claim that a transport protocol such as DCCP
would always be implemented in the kernel, and do not attempt to would always be implemented in the kernel, and do not attempt to
evaluate the relative difficulty of modifying code inside the kernel evaluate the relative difficulty of modifying code inside the kernel
vs. outside the kernel in any case. However, we believe that vs. outside the kernel in any case. However, we believe that
putting the congestion control at the transport level rather than at putting the congestion control at the transport level rather than at
the application level makes it just slightly less likely that users 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 will go to the trouble of modifying the code in order to avoid using
end-to-end congestion control. end-to-end congestion control.
3.2. Providing Congestion Control below UDP 3.2. Providing Congestion Control Below UDP
Instead of providing congestion control above UDP, a second Instead of providing congestion control above UDP, a second
possibility would be to provide congestion control for unreliable possibility would be to provide congestion control for unreliable
applications at a layer below UDP, and the applications would use applications at a layer below UDP, and the applications would use
UDP as their transport protocol. Given that UDP does not itself UDP as their transport protocol. Given that UDP does not itself
provide sequence numbers or congestion feedback, there are two provide sequence numbers or congestion feedback, there are two
possible forms for this congestion feedback: possible forms for this congestion feedback:
o (1) Feedback at the application: The application above UDP could o (1) Feedback at the application: The application above UDP could
provide sequence numbers and feedback to the sender, which would provide sequence numbers and feedback to the sender, which would
skipping to change at page 11, line 33 skipping to change at page 11, line 33
Providing feedback at a layer below UDP would require an additional Providing feedback at a layer below UDP would require an additional
packet header below UDP to carry sequence numbers in addition to the packet header below UDP to carry sequence numbers in addition to the
eight-byte header for UDP itself. Unless this header were an IP eight-byte header for UDP itself. Unless this header were an IP
option (which is likely to cause problems for many IPv4 routers) option (which is likely to cause problems for many IPv4 routers)
then its presence would need to be indicated using a different IP then its presence would need to be indicated using a different IP
protocol value from UDP. Thus, the packets would no longer look protocol value from UDP. Thus, the packets would no longer look
like UDP on the wire. like UDP on the wire.
To use this mechanism most effectively, the semantics of the UDP To use this mechanism most effectively, the semantics of the UDP
socket API would also need changing, both to support a late decision socket API (Application Programming Interface) would also need
on what to send, and to provide access to the sequence numbers to changing, both to support a late decision on what to send, and to
avoid the application needing to duplicate them for its own provide access to the sequence numbers to avoid the application
purposes. Thus, the socket API would no longer look like UDP in the needing to duplicate them for its own purposes. Thus, the socket
end hosts. This would effectively be a new transport protocol. API would no longer look like UDP in the end hosts. This would
effectively be a new transport protocol.
Given these complications, it seems cleaner to actually design a new Given these complications, it seems cleaner to actually design a new
transport protocol, and this also allows us to address the issues of transport protocol, which also allows us to address the issues of
firewall traversal, flow setup, and parameter negotiation. We note firewall traversal, flow setup, and parameter negotiation. We note
that any new transport protocol could also use a Congestion Manager that any new transport protocol could also use a Congestion Manager
approach to share congestion state between flows using the same approach to share congestion state between flows using the same
congestion control algorithm, if this were deemed to be desirable. congestion control algorithm, if this were deemed to be desirable.
3.3. Providing Congestion Control at the Transport Layer 3.3. Providing Congestion Control at the Transport Layer
The concerns from the discussions above have convinced us that the The concerns from the discussions above have convinced us that the
best way to provide congestion control to applications that best way to provide congestion control to applications that
currently use UDP is to provide congestion control at the transport currently use UDP is to provide congestion control at the transport
layer, in a transport protocol used as an alternative to UDP. One layer, in a transport protocol used as an alternative to UDP. One
advantage of providing end-to-end congestion control in an advantage of providing end-to-end congestion control in an
unreliable transport protocol is that it could be used easily by a unreliable transport protocol is that it could be used easily by a
wide range of the applications that currently use UDP, with minimal wide range of the applications that currently use UDP, with minimal
changes to the application itself. The application itself would not changes to the application itself. The application itself would not
have to provide the congestion control mechanism, or even the have to provide the congestion control mechanism, or even the
feedback from the data receiver to the data sender about lost or feedback from the data receiver to the data sender about lost or
marked packets. marked packets.
The question then arises of whether to adapt TCP for use by The question then arises of whether to adapt TCP for use by
unreliable applications, or to use an unreliable variant of SCTP, or unreliable applications, to use an unreliable variant of SCTP or a
to design a new transport protocol such as DCP. 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 As we argue below, the desire for minimal overhead results in the
design decision to use a transport protocol containing only the design decision to use a transport protocol containing only the
minimal necessary functionality, and to leave other functionality minimal necessary functionality, and to leave other functionality
such as reliability, semi-reliability, or Forward Error Correction such as reliability, semi-reliability, or Forward Error Correction
(FEC) to be layered on top. (FEC) to be layered on top.
3.3.1. Modifying TCP? 3.3.1. Modifying TCP?
One alternative to be considered would be to create an unreliable One alternative to be considered would be to create an unreliable
skipping to change at page 12, line 47 skipping to change at page 12, line 49
In conclusion, it seems best simply to leave TCP as it is, and to In conclusion, it seems best simply to leave TCP as it is, and to
create a new congestion control protocol for unreliable transfer. create a new congestion control protocol for unreliable transfer.
3.3.2. Unreliable Variants of SCTP? 3.3.2. Unreliable Variants of SCTP?
SCTP was in part designed to accommodate multiple streams within a SCTP was in part designed to accommodate multiple streams within a
single end-to-end connection, modifying TCP's semantics of reliable, single end-to-end connection, modifying TCP's semantics of reliable,
in-order delivery to allow out-of-order delivery. However, explicit in-order delivery to allow out-of-order delivery. However, explicit
support for multiple streams over a single flow at the transport support for multiple streams over a single flow at the transport
layer is not necessary for an unreliable transport protocol such as layer is not necessary for an unreliable transport protocol such as
DCP, which of necessity allows out-of-order delivery. Because an DCCP, which of necessity allows out-of-order delivery. Because an
unreliable transport does not need streams support, applications unreliable transport does not need streams support, applications
should not have to pay the penalties in terms of increased header should not have to pay the penalties in terms of increased header
size that accompany the use of streams in SCTP. size that accompany the use of streams in SCTP.
The basic underlying structure of the SCTP packet, into a common The basic underlying structure of the SCTP packet, into a common
SCTP header followed by chunks for data, SACK information, and so SCTP header followed by chunks for data, SACK information, and so
on, is motivated by SCTP's goal of accommodating multiple streams, on, is motivated by SCTP's goal of accommodating multiple streams,
However, this use of chunks comes at the cost of an increased header 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 size for packets, as each chunk must be aligned on 32-bit
boundaries, and therefore requires a fixed-size 4-byte chunk header. boundaries, and therefore requires a fixed-size 4-byte chunk header.
skipping to change at page 13, line 45 skipping to change at page 13, line 46
We would argue against the ``kitchen sink'' approach in this case. We would argue against the ``kitchen sink'' approach in this case.
Applications that desire limited retransmission with multi-stream Applications that desire limited retransmission with multi-stream
support, or that desire multi-homing support, might be good support, or that desire multi-homing support, might be good
candidates for a semi-reliable version of SCTP such as U-SCTP. candidates for a semi-reliable version of SCTP such as U-SCTP.
However, we believe that variants of SCTP are not suitable for However, we believe that variants of SCTP are not suitable for
fully-unreliable applications, or for the bulk of applications that fully-unreliable applications, or for the bulk of applications that
today use UDP. We would argue that instead, an additional transport today use UDP. We would argue that instead, an additional transport
protocol is needed for unreliable transfer. protocol is needed for unreliable transfer.
3.3.3. Designing a New Transport Protocol 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?
As RTP lives above UDP, modifying it to support congestion control
might encounter 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.
3.3.4. Designing a New Transport Protocol
In the first half of this document we have argued for providing In the first half of this document we have argued for providing
congestion control at the transport layer as an alternative to UDP, congestion control at the transport layer as an alternative to UDP,
instead of relying on congestion control supplied only above or instead of relying on congestion control supplied only above or
below UDP. In this section, we have examined the possibilities of below UDP. In this section, we have examined the possibilities of
modifying SCTP, modifying TCP, and designing a new transport modifying SCTP, modifying TCP, and designing a new transport
protocol. In large part because of the requirement for unreliable protocol. In large part because of the requirement for unreliable
transport, and for accommodating TFRC and well as TCP-like transport, and for accommodating TFRC and well as TCP-like
congestion control, we have concluded that modifications of SCTP or congestion control, we have concluded that modifications of SCTP or
TCP are not the best answer, and that a new transport protocol is 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 needed. Thus, we have argued for the need for a new transport
protocol that offers unreliable delivery; accommodates TFRC as well protocol that offers unreliable delivery; accommodates TFRC as well
as TCP-like congestion control; accommodates the use of ECN; and as TCP-like congestion control; accommodates the use of ECN; and
requires minimal overhead in packet size and in the state and CPU requires minimal overhead in packet size and in the state and CPU
processing required at the data receiver. processing required at the data receiver.
This is the line of reasoning that has lead us to the development of This is the line of reasoning that has lead us to the development of
DCP. Both the problem statement presented in this document, and the DCCP. Both the problem statement presented in this document, and
detailed design decisions made in the design of DCP, have been the detailed design decisions made in the design of DCCP, have been
brought to the IETF for further feedback. This document addresses brought to the IETF for further feedback. This document addresses
only the problem statement; the design decisions resulting from this only the problem statement; the design decisions resulting from this
problem statement will be addressed in a later document. problem statement will be addressed in a later document.
4. Selling Congestion Control to Reluctant Applications 4. Selling Congestion Control to Reluctant Applications
The goal of this work is to provide general congestion control The goal of this work is to provide general congestion control
mechanisms that will actually be used by many of the applications mechanisms that will actually be used by many of the applications
that currently use UDP. This may include applications that are that currently use UDP. This may include applications that are
perfectly happy without end-to-end congestion control. Several of perfectly happy without end-to-end congestion control. Several of
skipping to change at page 14, line 51 skipping to change at page 15, line 36
router mechanisms are colloquially known as `penalty boxes'. router mechanisms are colloquially known as `penalty boxes'.
However, before undertaking a concerted effort towards the However, before undertaking a concerted effort towards the
deployment of penalty boxes in the Internet, it seems reasonable, deployment of penalty boxes in the Internet, it seems reasonable,
and more effective, to first make a concerted effort to make end-to- and more effective, to first make a concerted effort to make end-to-
end congestion control easily available to applications currently end congestion control easily available to applications currently
using UDP. using UDP.
5. Additional Design Considerations 5. Additional Design Considerations
This section mentions some additional design considerations that This section mentions some additional design considerations that
must be considered in designing a new transport protocol. We do not should be considered in designing a new transport protocol.
address these issues in detail in this document, but leave them to a
later document on design considerations.
o Mobility: Mechanisms for multi-homing and mobility are one area of o Mobility: Mechanisms for multi-homing and mobility are one area of
additional functionality that cannot necessarily be layered additional functionality that cannot necessarily be layered
cleanly and effectively on top of a transport protocol. Thus, one cleanly and effectively on top of a transport protocol. Thus, one
outstanding design decision with any new transport protocol outstanding design decision with any new transport protocol
concerns whether to incorporate mechanisms for multi-homing and concerns whether to incorporate mechanisms for multi-homing and
mobility into the protocol itself. mobility into the protocol itself.
o Defense against DoS attacks and spoofing: A reliable handshake for o Defense against DoS attacks and spoofing: A reliable handshake for
connection setup and teardown offers protection against DoS and connection setup and teardown offers protection against DoS and
spoofing attacks. Mechanisms allowing a server to avoid holding spoofing attacks. Mechanisms allowing a server to avoid holding
any state for unacknowledged connection attempts or already- any state for unacknowledged connection attempts or already-
finished connections offers additional protection against DoS finished connections offers additional protection against DoS
attacks. Thus, in designed a new transport protocol, even one attacks. Thus, in designed a new transport protocol, even one
designed to provide minimal functionality, the requirements for designed to provide minimal functionality, the requirements for
providing defense against DoS attacks and spoofing need to be providing defense against DoS attacks and spoofing need to be
considered. considered.
o Interoperation with RTP: Some subset of the unicast traffic o Interoperation with RTP: As Section 3.3.3 describes, attention
currently using UDP uses RTP on top of UDP. If congestion control should be paid to the changes that would be required by RTP in
is provided by a new transport protocol instead of by RTP, order to use any new protocol.
attention should be paid to the changes that would be required by
RTP in order to use this new protocol.
o Interactions with NATs and Firewalls: NATs and firewalls don't o API: Some functionality required by the protocol, or useful for
interact well with UDP, with its lack of explicit flow setup and applications using the protocol, may require the definition of new
teardown and, in practice, the lack of well-known ports for many API mechanisms. Examples include allowing applications to decide
UDP applications. Some of these issues are application-specific; what information to put in a packet at transmission timer, and
others should be addressed by the transport protocol itself. providing applications with some information about packet sequence
numbers.
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 the DCCP problem statement addresses the relevant
requirements brought up at the ruts BOF.
6. Summary of Recommendations 6. Summary of Recommendations
Our problem statement has discussed the need for implementing Our problem statement has discussed the need for implementing
congestion control for unreliable flows. Additional problems congestion control for unreliable flows. Additional problems
concern the need for low overhead, the problems of firewall concern the need for low overhead, the problems of firewall
traversal, and the need for reliable parameter negotiation. Our traversal, and the need for reliable parameter negotiation. Our
consideration of the problem statement has resulted in the following consideration of the problem statement has resulted in the following
general recommendations: general recommendations:
skipping to change at page 16, line 22 skipping to change at page 17, line 16
protocol complexity. protocol complexity.
o Some DoS protection for servers must be included. In particular, o Some DoS protection for servers must be included. In particular,
servers can make themselves invulnerable to spoofed connection servers can make themselves invulnerable to spoofed connection
attacks ("SYN floods"). attacks ("SYN floods").
o Connection setup and teardown must use explicit handshakes, o Connection setup and teardown must use explicit handshakes,
facilitating transmission through stateful firewalls. facilitating transmission through stateful firewalls.
If there is a consensus about the need for a new unicast transport If there is a consensus about the need for a new unicast transport
protocol for unreliable datagrams, then the next step can hopefully protocol for unreliable datagrams, then the next step can be the
be the chartering of a working group in the IETF, along with the consideration of more detailed architectural issues.
consideration of more detailed architectural issues, and a design
document.
Even if there is a consensus about the recommendations above, we are
not presupposing that the current proposal for DCP will be judged to
be the protocol that answers this problem statement. However, the
authors of DCP will continue with their work on this proposed
protocol concurrently with the work on clear and rigorous problem
statements and design documents.
7. References 7. References
[Bala99] H. Balakrishnan, H. Rahul, and S. Seshan, An Integrated [Bala99] H. Balakrishnan, H. Rahul, and S. Seshan, An Integrated
Congestion Management Architecture for Internet Hosts, SIGCOMM, Congestion Management Architecture for Internet Hosts, SIGCOMM,
Sept. 1999. Sept. 1999.
[MEASWEB] Ramon Caceres and Sally Floyd, Measurement Studies of End- [MEASWEB] Ramon Caceres and Sally Floyd, Measurement Studies of End-
to-End Congestion Control in the Internet, Web Page, 2001. to-End Congestion Control in the Internet, Web Page, 2001.
skipping to change at page 17, line 11 skipping to change at page 17, line 43
Patterns: A View from Ames Internet Exchange, ITC Specialist Patterns: A View from Ames Internet Exchange, ITC Specialist
Seminar, 2001. URL Seminar, 2001. URL
``http://www.caida.org/outreach/papers/2000/AIX0005/''. ``http://www.caida.org/outreach/papers/2000/AIX0005/''.
[RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3. [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3.
RFC 2026. RFC 2026.
[RFC 2481] K. Ramakrishnan, S. Floyd. A Proposal to add Explicit [RFC 2481] K. Ramakrishnan, S. Floyd. A Proposal to add Explicit
Congestion Notification (ECN) to IP. RFC 2481. Congestion Notification (ECN) to IP. RFC 2481.
[RFC 1191] J. C. Mogul, S. E. Deering. Path MTU discovery. RFC 1191. [RFC 1191] J. C. Mogul, S. E. Deering. Path MTU Discovery. RFC 1191.
[RFC 2309] B. Braden et al., Recommendations on Queue Management and [RFC 2309] B. Braden et al., Recommendations on Queue Management and
Congestion Avoidance in the Internet. RFC 2309, April 1998. Congestion Avoidance in the Internet. RFC 2309, April 1998.
[RFC 2525] V. Paxson et at., Known TCP Implementation Problems, RFC [RFC 2525] V. Paxson et al., Known TCP Implementation Problems, RFC
2525, March 1999. 2525, March 1999.
[RFC 2914] S. Floyd. Congestion Control Principles. RFC 2914, Sept. [RFC 2914] S. Floyd. Congestion Control Principles. RFC 2914, Sept.
2000. 2000.
[RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. [RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
Paxson. Stream Control Transmission Protocol. RFC 2960. Paxson. Stream Control Transmission Protocol. RFC 2960.
[RFC 3124] H. Balakrishnan, S. Seshan. The Congestion Manager. RFC [RFC 3124] H. Balakrishnan, S. Seshan. The Congestion Manager. RFC
3124. 3124.
[RUTS] Requirements for Unicast Transport/Sessions (ruts) BOF, Dec.
7, 1998. URL "http://www.ietf.org/proceedings/98dec/43rd-
ietf-98dec-142.html".
[TBIT] J. Padhye and S. Floyd, Identifying the TCP Behavior of Web [TBIT] J. Padhye and S. Floyd, Identifying the TCP Behavior of Web
Servers, SIGCOMM 2001. Servers, SIGCOMM 2001.
[WES01] David Wetherall, David Ely, Neil Spring. Robust ECN [WES01] David Wetherall, David Ely, Neil Spring. Robust ECN
Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-00.txt, work Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-03.txt, work
in progress, January 2001. in progress, April 2002.
8. Authors' Addresses 8. Authors' Addresses
Sally Floyd <floyd@icir.org> Sally Floyd <floyd@icir.org>
Mark Handley <mjh@icir.org> Mark Handley <mjh@icir.org>
Eddie Kohler <kohler@icir.org> Eddie Kohler <kohler@icir.org>
ICSI Center for Internet Research (ICIR), ICSI Center for Internet Research (ICIR),
International Computer Science Institute, International Computer Science Institute,
1947 Center Street, Suite 600 1947 Center Street, Suite 600
 End of changes. 37 change blocks. 
115 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/