diff options
Diffstat (limited to 'doc/rfc/rfc4336.txt')
| -rw-r--r-- | doc/rfc/rfc4336.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4336.txt b/doc/rfc/rfc4336.txt new file mode 100644 index 0000000..6cc41e4 --- /dev/null +++ b/doc/rfc/rfc4336.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group S. Floyd +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. + + + + + + + + + + + + + + + + + + + + + + +Floyd, et al. Informational [Page 1] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + + + +Floyd, et al. Informational [Page 2] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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].) + + + + + + + +Floyd, et al. Informational [Page 3] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + + +Floyd, et al. Informational [Page 4] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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 + + + +Floyd, et al. Informational [Page 5] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + +Floyd, et al. Informational [Page 6] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + +Floyd, et al. Informational [Page 7] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + +Floyd, et al. Informational [Page 8] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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 + + + +Floyd, et al. Informational [Page 9] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + + + + + +Floyd, et al. Informational [Page 10] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + 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. + + + + + + +Floyd, et al. Informational [Page 11] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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. + + + + +Floyd, et al. Informational [Page 12] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + + + +Floyd, et al. Informational [Page 13] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + +Floyd, et al. Informational [Page 14] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + + + +Floyd, et al. Informational [Page 15] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + + + +Floyd, et al. Informational [Page 16] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + + +Floyd, et al. Informational [Page 17] + +RFC 4336 Problem Statement for DCCP March 2006 + + + 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. + + + + + + + + + +Floyd, et al. Informational [Page 18] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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. + + + +Floyd, et al. Informational [Page 19] + +RFC 4336 Problem Statement for DCCP March 2006 + + + [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". + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd, et al. Informational [Page 20] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + +Floyd, et al. Informational [Page 21] + +RFC 4336 Problem Statement for DCCP March 2006 + + +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 + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Floyd, et al. Informational [Page 22] + |