idnits 2.17.1 draft-ietf-dccp-problem-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1052. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1020), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 August 2005) is 6791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MEASWEB' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'MC01' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC 1191' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC 3540' is defined on line 977, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-09 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sally Floyd 2 INTERNET-DRAFT ICIR 3 draft-ietf-dccp-problem-03.txt Mark Handley 4 UCL 5 Eddie Kohler 6 UCLA 7 24 August 2005 8 Expires: February 2006 10 Problem Statement for DCCP 12 Status of this Document 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document describes, for the historical record, the 46 motivation behind DCCP (the Datagram Congestion Control 47 Protocol), an unreliable transport protocol incorporating end- 48 to-end congestion control. DCCP implements a congestion- 49 controlled, unreliable flow of datagrams for use by 50 applications such as streaming media or on-line games. 52 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON 53 PUBLICATION. 55 Changes from draft-ietf-dccp-problem-02.txt: 57 * Added a table of contents. 59 Changes from draft-ietf-dccp-problem-01.txt: 61 * Add references to RFCs 2914 and 3714. Edits. 63 * Make historical-record motivation clearer. 65 * Fairer description of PR-SCTP. 67 * Updated addresses for Mark, Eddie. 69 * Added Security Considerations and IANA Considerations 70 sections. 72 Changes from draft-ietf-dccp-problem-00.txt: 74 * Updated references, minor editing changes. 76 Changes from draft-floyd-dcp-problem-01.txt: 78 * Added an "Acknowledgements" section. 80 * Added a section on "Transport Requirements of 81 Request/Response Applications" 83 Changes in response to feedback from Spencer Dawkins: 85 * Small phrasing changes. 87 * Added a section on Design Preferences in the beginning. 89 * Added a bullet about "Interactions with NATs and 90 Firewalls" under "Additional Design Considerations". 92 * Added a paragraph to the section on "Difficulties with 93 ECN" about the possibility that in times of congestion, 94 routers would first "turn off" the use of ECN to UDP 95 flows. 97 Table of Contents 99 1. Introduction. . . . . . . . . . . . . . . . . . . . 5 100 2. Problem Space . . . . . . . . . . . . . . . . . . . 6 101 2.1. Congestion Control for Unreliable Transfer . . 7 102 2.2. Overhead . . . . . . . . . . . . . . . . . . . 8 103 2.3. Firewall Traversal . . . . . . . . . . . . . . 9 104 2.4. Parameter Negotiation. . . . . . . . . . . . . 9 105 3. Solution Space for Congestion Control of Unreliable 106 Flows. . . . . . . . . . . . . . . . . . . . . . . . . 10 107 3.1. Providing Congestion Control Above UDP . . . . 10 108 3.1.1. The Burden on the Application Designer. . 10 109 3.1.2. Difficulties with ECN . . . . . . . . . . 11 110 3.1.3. The Evasion of Congestion Control . . . . 12 111 3.2. Providing Congestion Control Below UDP . . . . 12 112 3.2.1. Case 1: Congestion Feedback at the Applica- 113 tion . . . . . . . . . . . . . . . . . . . . . . 13 114 3.2.2. Case 2: Congestion Feedback at a Layer 115 below UDP. . . . . . . . . . . . . . . . . . . . 13 116 3.3. Providing Congestion Control at the Transport 117 Layer . . . . . . . . . . . . . . . . . . . . . . . 14 118 3.3.1. Modifying TCP?. . . . . . . . . . . . . . 14 119 3.3.2. Unreliable Variants of SCTP?. . . . . . . 15 120 3.3.3. Modifying RTP?. . . . . . . . . . . . . . 16 121 3.3.4. Designing a New Transport Protocol. . . . 17 122 4. Selling Congestion Control to Reluctant 123 Applications . . . . . . . . . . . . . . . . . . . . . 17 124 5. Additional Design Considerations. . . . . . . . . . 18 125 6. Transport Requirements of Request/Response Applica- 126 tions. . . . . . . . . . . . . . . . . . . . . . . . . 19 127 7. Summary of Recommendations. . . . . . . . . . . . . 20 128 8. Security Considerations . . . . . . . . . . . . . . 20 129 9. IANA Considerations . . . . . . . . . . . . . . . . 21 130 10. Acknowledgements . . . . . . . . . . . . . . . . . 21 131 11. Informative References . . . . . . . . . . . . . . 21 132 12. Authors' Addresses . . . . . . . . . . . . . . . . 23 133 13. Full Copyright Statement . . . . . . . . . . . . . 23 134 14. Intellectual Property. . . . . . . . . . . . . . . 23 136 1. Introduction 138 Historically, the great majority of Internet unicast traffic has 139 used congestion-controlled TCP, with UDP making up most of the 140 remainder. UDP has mainly been used for short, request-response 141 transfers, like DNS and SNMP, that wish to avoid TCP's three-way 142 handshake, retransmission, and/or stateful connections. UDP also 143 avoids TCP's built-in end-to-end congestion control, and UDP 144 applications tended not to implement their own congestion control. 145 However, since UDP traffic volume was small relative to congestion- 146 controlled TCP flows, the network didn't collapse. 148 Recent years have seen the growth of applications that use UDP in a 149 different way. These applications, including streaming audio, 150 Internet telephony, and multiplayer and massively multiplayer on- 151 line games, share a preference for timeliness over reliability. TCP 152 can introduce arbitrary delay because of its reliability and in- 153 order delivery requirements; thus, the applications use UDP instead. 154 This growth of long-lived non-congestion-controlled traffic, 155 relative to congestion-controlled traffic, poses a real threat to 156 the overall health of the Internet [RFC 2914, RFC 3714]. 158 Applications could implement their own congestion control mechanisms 159 on a case-by-case basis, with encouragement from the IETF. Some 160 already do this. However, experience shows that congestion control 161 is difficult to get right, and many application writers would like 162 to avoid reinventing this particular wheel. We believe that a new 163 protocol is needed, one that combines unreliable datagram delivery 164 with built-in congestion control. This protocol will act as an 165 enabling technology: existing and new applications could easily use 166 it to transfer timely data without destabilizing the Internet. 168 This document provides a problem statement for such a protocol. We 169 list the properties the protocol should have, then explain why those 170 properties are necessary. We describe why a new protocol is the 171 best solution for the more general problem of bringing congestion 172 control to unreliable flows of unicast datagrams, and discuss 173 briefly subsidiary requirements for mobility, defense against DOS 174 attacks and spoofing, interoperation with RTP, and interactions with 175 NATs and firewalls. 177 One of the design preferences that we bring to this question is a 178 preference for a clean, understandable, low-overhead, and minimal 179 protocol. As described later in this document, this results in the 180 design decision to leave functionality such as reliability or 181 Forward Error Correction (FEC) to be layered on top, rather than 182 provided in the transport protocol itself. 184 This document began in 2002 as a formalization of the goals of DCCP, 185 the Datagram Congestion Control Protocol [DCCP]. We intended DCCP 186 to satisfy this problem statement, and thus the original reasoning 187 behind many of DCCP's design choices can be found here. However, we 188 believed, and continue to believe, that the problem should be solved 189 whether or not DCCP is the chosen solution. 191 2. Problem Space 193 We perceive a number of problems related to the use of unreliable 194 data flows in the Internet. The major issues are: 196 o The potential for non-congestion-controlled datagram flows to 197 cause congestion collapse of the network. (See Section 5 of [RFC 198 2914] and Section 2 of [RFC 3714].) 200 o The difficulty of correctly implementing effective congestion 201 control mechanisms for unreliable datagram flows. 203 o The lack of a standard solution for reliably transmitting 204 congestion feedback for an unreliable data flow. 206 o The lack of a standard solution for negotiating Explicit 207 Congestion Notification (ECN) [RFC 2481] usage for unreliable 208 flows. 210 o The lack of a choice of TCP-friendly congestion control 211 mechanisms. 213 We assume that most application writers would use congestion control 214 for long-lived unreliable flows if it was available in a standard, 215 easy-to-use form. 217 More minor issues include: 219 o The difficulty of deploying applications using UDP-based flows in 220 the presence of firewalls. 222 o The desire to have a single way to negotiate congestion control 223 parameters for unreliable flows, independently of the signalling 224 protocol used to set up the flow. 226 o The desire for low per-packet byte overhead. 228 The subsections below discuss these problems of providing congestion 229 control, traversing firewalls, and negotiating parameters in more 230 detail. A separate subsection also discusses the problem of 231 minimizing the overhead of packet headers. 233 2.1. Congestion Control for Unreliable Transfer 235 We aim to bring easy-to-use congestion control mechanisms to 236 applications that generate large or long-lived flows of unreliable 237 datagrams, such as RealAudio, Internet telephony, and multiplayer 238 games. Our motivation is to avoid congestion collapse. (The short 239 flows generated by request-response applications, such as DNS, SNMP, 240 and SIP [RFC 3261], don't cause congestion in practice, and any 241 congestion control mechanism would take effect between flows, not 242 within a single end-to-end transfer of information.) However, 243 before designing a congestion control mechanism for these 244 applications, we must understand why they use unreliable datagrams 245 in the first place, lest we destroy the very properties they 246 require. 248 There are several reasons why protocols currently use UDP instead of 249 TCP, amongst them: 251 o Startup Delay: they wish to avoid the delay of a three-way 252 handshake before initiating data transfer. 254 o Statelessness: they wish to avoid holding connection state, and 255 the potential state-holding attacks that come with this. 257 o Trading of Reliability against Timing: the data being sent is 258 timely in the sense that if it is not delivered by some deadline 259 (typically a small number of RTTs) then the data will not be 260 useful at the receiver. 262 Of these issues, applications that generate large or long-lived 263 flows of datagrams, such as media transfer and games, mostly care 264 about controlling the tradeoff between timing and reliability. Such 265 applications use UDP because when they send a datagram, they wish to 266 send the most appropriate data in that datagram. If the datagram is 267 lost, they may or may not resend the same data, depending on whether 268 the data will still be useful at the receiver. Data may no longer 269 be useful for many reasons: 271 o In a telephony or streaming video session, data in a packet 272 comprises a timeslice of a continuous stream. Once a timeslice 273 has been played out, the next timeslice is required immediately. 274 If the data comprising that timeslice arrives at some later time, 275 then it is no longer useful. Such applications can cope with 276 masking the effects of missing packets to some extent, so when the 277 sender transmits its next packet, it is important for it to only 278 send data that has a good chance of arriving in time for its 279 playout. 281 o In an interactive game or virtual-reality session, position 282 information is transient. If a datagram containing position 283 information is lost, resending the old position does not usually 284 make sense -- rather, every position information datagram should 285 contain the latest position information. 287 In a congestion-controlled flow, the allowed packet sending rate 288 depends on measured network congestion. Thus, some control is given 289 up to the congestion control mechanism, which determines precisely 290 when packets can be sent. However, applications could still decide, 291 at transmission time, which information to put in a packet. TCP 292 doesn't allow control over this; these applications demand it. 294 Often, these applications (especially games and telephony 295 applications) work on very short playout timescales. Whilst they 296 are usually able to adjust their transmission rate based on 297 congestion feedback, they do have constraints on how this adaptation 298 can be performed so that it has minimal impact on the quality of the 299 session. Thus, they tend to need some control over the short-term 300 dynamics of the congestion control algorithm, whilst being fair to 301 other traffic on medium timescales. This control includes, but is 302 not limited to, some influence on which congestion control algorithm 303 should be used -- for example, TFRC rather than strict TCP-like 304 congestion control. (TCP-Friendly Rate Control, or TFRC, has been 305 standardized in the IETF as a congestion control mechanism that 306 adjusts its sending rate more smoothly than TCP does, while 307 maintaining long-term fair bandwidth sharing with TCP [RFC 3448].) 309 2.2. Overhead 311 The applications we are concerned with often send compressed data, 312 or send frequent small packets. For example, when internet 313 telephony or streaming media are used over low-bandwidth modem 314 links, highly compressing the payload data is essential. For 315 internet telephony applications and for games, the requirement is 316 for low delay, and hence small packets are sent frequently. 318 For example, a telephony application sending a 5.6Kbps data stream 319 but wanting moderately low delay may send a packet every 20ms, 320 sending only 14 data bytes in each packet. In addition, 20 bytes is 321 taken up by the IP header, with additional bytes for transport 322 and/or application headers. Clearly, for such an application it is 323 desirable to have a low overhead for the transport protocol header. 325 In some cases the correct solution would be to use link-based packet 326 header compression to compress the packet headers, although we 327 cannot guarantee the availability of such compression schemes on any 328 particular link. 330 The delay of data until after the completion of a handshake also 331 represents potentially unnecessary overhead. A new protocol might 332 therefore allow senders to include some data on their initial 333 datagrams. 335 2.3. Firewall Traversal 337 Applications requiring a flow of unreliable datagrams currently tend 338 to use signalling protocols such as RTSP [RFC 2326], SIP and H.323 339 in conjunction with UDP for the data flow. The initial setup 340 request uses a signalling protocol to locate the correct remote end- 341 system for the data flow, sometimes being redirected or relayed to 342 other machines, before the data flow is established. 344 As UDP flows contain no explicit setup and teardown, it is hard for 345 firewalls to handle them correctly. Typically the firewall needs to 346 parse RTSP, SIP and H.323 to obtain the information necessary to 347 open a hole in the firewall. Alternatively, for bi-directional 348 flows, the firewall can open a bi-directional hole if it receives a 349 UDP packet from inside the firewall, but in this case the firewall 350 can't easily know when to close the hole again. 352 While we do not consider these to be major problems, they are 353 nonetheless issues that application designers face. Currently 354 streaming media players attempt UDP first, and then switch to TCP if 355 UDP is not successful. Streaming media over TCP is undesirable, and 356 can result in the receiver needing to temporarily halt playout while 357 it "rebuffers" data. Telephony applications don't even have this 358 option. 360 2.4. Parameter Negotiation 362 Different applications have different requirements for congestion 363 control, which may map into different congestion feedback. Examples 364 include ECN capability and desired congestion control dynamics (the 365 choice of congestion control algorithm and, therefore, the form of 366 feedback information required). Such parameters need to be reliably 367 negotiated before congestion control can function correctly. 369 While this negotiation could be performed using signalling protocols 370 such as SIP, RTSP and H.323, it would be desirable to have a single 371 standard way of negotiating these transport parameters. This is of 372 particular importance with ECN, where sending ECN-marked packets to 373 a non-ECN-capable receiver can cause significant congestion problems 374 to other flows. We discuss the ECN issue in more detail below. 376 3. Solution Space for Congestion Control of Unreliable Flows 378 We thus want to provide congestion control for unreliable flows, 379 providing both ECN and the choice of different forms of congestion 380 control, and providing moderate overhead in terms of packet size, 381 state, and CPU processing. There are a number of options for 382 providing end-to-end congestion control for the unicast traffic that 383 currently uses UDP, in terms of the layer that provides the 384 congestion control mechanism: 386 o Congestion control above UDP. 388 o Congestion control below UDP. 390 o Congestion control at the transport layer in an alternative to 391 UDP. 393 We explore these alternatives in the sections below. The concerns 394 from the discussions below have convinced us that the best way to 395 provide congestion control for unreliable flows is to provide 396 congestion control at the transport layer, as an alternative to the 397 use of UDP and TCP. 399 3.1. Providing Congestion Control Above UDP 401 One possibility would be to provide congestion control at the 402 application layer, or at some other layer above UDP. This would 403 allow the congestion control mechanism to be closely integrated with 404 the application itself. 406 3.1.1. The Burden on the Application Designer 408 A key disadvantage of providing congestion control above UDP is that 409 it places an unnecessary burden on the application-level designer, 410 who might be just as happy to use the congestion control provided by 411 a lower layer. If the application can rely on a lower layer that 412 gives a choice between TCP-like or TFRC-like congestion control, and 413 that offers ECN, then this might be highly satisfactory to many 414 application designers. 416 The long history of debugging TCP implementations [RFC 2525, TBIT] 417 makes the difficulties in implementing end-to-end congestion control 418 abundantly clear. It is clearly more robust for congestion control 419 to be provided for the application by a lower layer. In rare cases 420 there might be compelling reasons for the congestion control 421 mechanism to be implemented in the application itself, but we do not 422 expect this to be the general case. For example, applications that 423 use RTP over UDP might be just as happy if RTP itself implemented 424 end-to-end congestion control. (See Section 3.3.3 for more 425 discussion of RTP.) 427 In addition to congestion control issues, we also note the problems 428 with firewall traversal and parameter negotiation discussed in 429 sections 2.3 and 2.4. Implementing on top of UDP requires that the 430 application designer also address these issues. 432 3.1.2. Difficulties with ECN 434 A second problem of providing congestion control above UDP is that 435 it would require either giving up the use of ECN, or giving the 436 application direct control over setting and reading the ECN field in 437 the IP header. Giving up the use of ECN would be problematic, since 438 ECN can be particularly useful for unreliable flows, where a dropped 439 packet will not be retransmitted by the data sender. 441 With the development of the ECN nonce, ECN can also be useful even 442 in the absence of ECN support from the network. The data sender can 443 use the ECN nonce, along with feedback from the data receiver, to 444 verify that the data receiver is correctly reporting all lost 445 packets. This use of ECN can be particularly useful for an 446 application using unreliable delivery, where the receiver might 447 otherwise have little incentive to report lost packets. 449 In order to allow the use of ECN by a layer above UDP, the UDP 450 socket would have to allow the application to control the ECN field 451 in the IP header. In particular, the UDP socket would have to allow 452 the application to specify whether or not the ECN-Capable Transport 453 (ECT) codepoints should be set in the ECN field of the IP header. 455 The ECN contract is that senders who set the ECT codepoint must 456 respond to Congestion Experienced (CE) codepoints by reducing their 457 sending rates. Therefore, the ECT codepoint can only safely be set 458 in the packet header of a UDP packet if the following is guaranteed: 460 o If the CE codepoint is set by a router, the receiving IP layer 461 will pass the CE status to the UDP layer, which will pass it to 462 the receiving application at the data receiver, and: 464 o Upon receiving a packet that had the CE codepoint set, the 465 receiving application will take the appropriate congestion control 466 action, such as informing the data sender. 468 However, the UDP implementation at the data sender has no way of 469 knowing if the UDP implementation at the data receiver has been 470 upgraded to pass a CE status up to the receiving application, let 471 alone whether or not the application will use the conformant end-to- 472 end congestion control that goes along with use of ECN. 474 In the absence of the widespread deployment of mechanisms in routers 475 to detect flows that are not using conformant congestion control, 476 allowing applications arbitrary control of the ECT codepoints for 477 UDP packets would seem like an unnecessary opportunity for 478 applications to use ECN while evading the use of end-to-end 479 congestion control. Thus, there is an inherent "chicken-and-egg" 480 problem of whether first to deploy policing mechanisms in routers, 481 or first to enable the use of ECN by UDP flows. Without the 482 policing mechanisms in routers, we would not advise adding ECN- 483 capability to UDP sockets at this time. 485 In the absence of more fine-grained mechanisms for dealing with a 486 period of sustained congestion, one possibility would be for routers 487 to discontinue using ECN with UDP packets during the congested 488 period, and to use ECN only with TCP or DCCP packets. This would be 489 a reasonable response, for example, if TCP or DCCP flows were found 490 to be more likely to be using conformant end-to-end congestion 491 control than were UDP flows. If routers were to adopt such a 492 policy, then DCCP flows could be more likely to receive the benefits 493 of ECN in times of congestion than would UDP flows. 495 3.1.3. The Evasion of Congestion Control 497 A third problem of providing congestion control above UDP is that 498 relying on congestion control at the application level makes it 499 somewhat easier for some users to evade end-to-end congestion 500 control. We do not claim that a transport protocol such as DCCP 501 would always be implemented in the kernel, and do not attempt to 502 evaluate the relative difficulty of modifying code inside the kernel 503 vs. outside the kernel in any case. However, we believe that 504 putting the congestion control at the transport level rather than at 505 the application level makes it just slightly less likely that users 506 will go to the trouble of modifying the code in order to avoid using 507 end-to-end congestion control. 509 3.2. Providing Congestion Control Below UDP 511 Instead of providing congestion control above UDP, a second 512 possibility would be to provide congestion control for unreliable 513 applications at a layer below UDP, with applications using UDP as 514 their transport protocol. Given that UDP does not itself provide 515 sequence numbers or congestion feedback, there are two possible 516 forms for this congestion feedback: 518 o (1) Feedback at the application: The application above UDP could 519 provide sequence numbers and feedback to the sender, which would 520 then communicate loss information to the congestion control 521 mechanism. This is the approach currently standardized by the 522 Congestion Manager (CM) [RFC 3124]. 524 o (2) Feedback at the layer below UDP: The application could use 525 UDP, and a protocol could be implemented using a shim header 526 between IP and UDP to provide sequence number information for data 527 packets and return feedback to the data sender. The original 528 proposal for the Congestion Manager [Bala99] suggested providing 529 this layer for applications that did not have their own feedback 530 about dropped packets. 532 We discuss these two cases separately below. 534 3.2.1. Case 1: Congestion Feedback at the Application 536 In this case, the application provides sequence numbers and 537 congestion feedback above UDP, but communicates that feedback to a 538 congestion manager below UDP, which regulates when packets can be 539 sent. This approach suffers from most of the problems described in 540 Section 3.1, namely forcing the application designer to reinvent the 541 wheel each time for packet formats and parameter negotiation, and 542 problems with ECN usage, firewalls and evasion. 544 It would avoid the application writer needing to implement the 545 control part of the congestion control mechanism, but it is unclear 546 how easily multiple congestion control algorithms (such as receiver- 547 based TFRC) can be supported, given that the form of congestion 548 feedback usually needs to be closely coupled to the congestion 549 control algorithm being used. Thus, this design limits the choice 550 of congestion control mechanisms available to applications while 551 simultaneously burdening the applications with implementations of 552 congestion feedback. 554 3.2.2. Case 2: Congestion Feedback at a Layer below UDP 556 Providing feedback at a layer below UDP would require an additional 557 packet header below UDP to carry sequence numbers in addition to the 558 eight-byte header for UDP itself. Unless this header were an IP 559 option (which is likely to cause problems for many IPv4 routers) 560 then its presence would need to be indicated using a different IP 561 protocol value from UDP. Thus, the packets would no longer look 562 like UDP on the wire, and the modified protocol would face 563 deployment challenges similar to those of an entirely new protocol. 565 To use congestion feedback at a layer below UDP most effectively, 566 the semantics of the UDP socket API (Application Programming 567 Interface) would also need changing, both to support a late decision 568 on what to send, and to provide access to the sequence numbers to 569 avoid the application needing to duplicate them for its own 570 purposes. Thus, the socket API would no longer look like UDP to end 571 hosts. This would effectively be a new transport protocol. 573 Given these complications, it seems cleaner to actually design a new 574 transport protocol, which also allows us to address the issues of 575 firewall traversal, flow setup, and parameter negotiation. We note 576 that any new transport protocol could also use a Congestion Manager 577 approach to share congestion state between flows using the same 578 congestion control algorithm, if this were deemed to be desirable. 580 3.3. Providing Congestion Control at the Transport Layer 582 The concerns from the discussions above have convinced us that the 583 best way to provide congestion control to applications that 584 currently use UDP is to provide congestion control at the transport 585 layer, in a transport protocol used as an alternative to UDP. One 586 advantage of providing end-to-end congestion control in an 587 unreliable transport protocol is that it could be used easily by a 588 wide range of the applications that currently use UDP, with minimal 589 changes to the application itself. The application itself would not 590 have to provide the congestion control mechanism, or even the 591 feedback from the data receiver to the data sender about lost or 592 marked packets. 594 The question then arises of whether to adapt TCP for use by 595 unreliable applications, to use an unreliable variant of SCTP or a 596 version of RTP with built-in congestion control, or to design a new 597 transport protocol. 599 As we argue below, the desire for minimal overhead results in the 600 design decision to use a transport protocol containing only the 601 minimal necessary functionality, and to leave other functionality 602 such as reliability, semi-reliability, or Forward Error Correction 603 (FEC) to be layered on top. 605 3.3.1. Modifying TCP? 607 One alternative might be to create an unreliable variant of TCP, 608 with the reliability layered on top for applications desiring 609 reliable delivery. However, our requirement is not simply for TCP 610 minus the in-order reliable delivery, but also for the application 611 to be able to choose congestion control algorithms. TCP's feedback 612 mechanism works well for TCP-like congestion control, but is 613 inappropriate (or at the very least, inefficient) for TFRC. In 614 addition, TCP sequence numbers are in bytes, not datagrams. This 615 would complicate both congestion feedback and any attempt to allow 616 the application to decide, at transmission time, what information 617 should go into a packet. Finally, there is the issue of whether a 618 modified TCP would require a new IP protocol number as well; a 619 significantly modified TCP using the same IP protocol number could 620 have unwanted interactions with some of the middleboxes already 621 deployed in the network. 623 It seems best simply to leave TCP as it is, and to create a new 624 congestion control protocol for unreliable transfer. This is 625 especially true since any change to TCP, no matter how small, takes 626 an inordinate amount of time to standardize and deploy, given TCP's 627 importance in the current Internet and the historical difficulty of 628 getting TCP implementations right. 630 3.3.2. Unreliable Variants of SCTP? 632 SCTP, the Stream Control Transmission Protocol [RFC 2960], was in 633 part designed to accommodate multiple streams within a single end- 634 to-end connection, modifying TCP's semantics of reliable, in-order 635 delivery to allow out-of-order delivery. However, explicit support 636 for multiple streams over a single flow at the transport layer is 637 not necessary for an unreliable transport protocol such as DCCP, 638 which of necessity allows out-of-order delivery. Because an 639 unreliable transport does not need streams support, applications 640 should not have to pay the penalties in terms of increased header 641 size that accompany the use of streams in SCTP. 643 The basic underlying structure of the SCTP packet, of a common SCTP 644 header followed by chunks for data, SACK information, and so on, is 645 motivated by SCTP's goal of accommodating multiple streams. 646 However, this use of chunks comes at the cost of an increased header 647 size for packets, as each chunk must be aligned on 32-bit 648 boundaries, and therefore requires a fixed-size 4-byte chunk header. 649 For example, for a connection using ECN, SCTP includes separate 650 control chunks for the Explicit Congestion Notification Echo and 651 Congestion Window Reduced functions, with the ECNE and CWR chunks 652 each requiring 8 bytes. As another example, the common header 653 includes a 4-byte verification tag to validate the sender. 655 As a second concern, SCTP as currently specified uses TCP-like 656 congestion control, and does not provide support for alternative 657 congestion control algorithms such as TFRC that would be more 658 attractive to some of the applications currently using UDP flows. 659 Thus, the current version of SCTP would not meet the requirements 660 for a choice between forms of end-to-end congestion control. 662 Finally, the SCTP Partial Reliability extension [RFC 3758] allows a 663 sender to selectively abandon outstanding messages, which ceases 664 retransmissions and allows the receiver to deliver any queued 665 messages on the affected streams. This service model, although 666 well-suited for some applications, differs from, and provides the 667 application somewhat less flexibility than, UDP's fully unreliable 668 service. 670 One could suggest adding support for alternative congestion control 671 mechanisms as an option to SCTP, and adding a fully-unreliable 672 variant that does not include the mechanisms for multiple streams. 673 We would argue against this. SCTP is well-suited for applications 674 that desire limited retransmission with multi-stream or multi-homing 675 support. Adding support for fully-unreliable variants, multiple 676 congestion control profiles, and reduced single-stream headers would 677 risk introducing unforeseen interactions and make further 678 modifications ever more difficult. We have chosen instead to 679 implement a minimal protocol, designed for fully-unreliable datagram 680 service, that provides only end-to-end congestion control and any 681 other mechanisms that cannot be provided in a higher layer. 683 3.3.3. Modifying RTP? 685 Several of our target applications currently use RTP layered above 686 UDP to transfer their data. Why not modify RTP to provide end-to- 687 end congestion control? 689 When RTP lives above UDP, modifying it to support congestion control 690 might encounter some of the problems described in Section 3.1. In 691 particular, user-level RTP implementations would want access to ECN 692 bits in UDP datagrams. It might be difficult or undesirable to 693 allow that access for RTP, but not for other user-level programs. 695 Kernel implementations of RTP would not suffer from this problem. In 696 the end, the argument against modifying RTP is the same as that 697 against modifying SCTP: Some applications, such as the export of 698 flow information from routers, need congestion control but don't 699 need much of RTP's functionality. From these applications' point of 700 view, RTP would induce unnecessary overhead. Again, we would argue 701 for a clean and minimal protocol focused on end-to-end congestion 702 control. 704 RTP would commonly be used as a layer above any new transport 705 protocol, however. The design of that new transport protocol should 706 take this into account, either by avoiding undue duplication of 707 information available in the RTP header, or by suggesting 708 modifications to RTP, such as a reduced RTP header that removes any 709 fields redundant with the new protocol's headers. 711 3.3.4. Designing a New Transport Protocol 713 In the first half of this document we have argued for providing 714 congestion control at the transport layer as an alternative to UDP, 715 instead of relying on congestion control supplied only above or 716 below UDP. In this section, we have examined the possibilities of 717 modifying SCTP, modifying TCP, and designing a new transport 718 protocol. In large part because of the requirement for unreliable 719 transport, and for accommodating TFRC as well as TCP-like congestion 720 control, we have concluded that modifications of SCTP or TCP are not 721 the best answer, and that a new transport protocol is needed. Thus, 722 we have argued for the need for a new transport protocol that offers 723 unreliable delivery; accommodates TFRC as well as TCP-like 724 congestion control; accommodates the use of ECN; and requires 725 minimal overhead in packet size and in the state and CPU processing 726 required at the data receiver. 728 4. Selling Congestion Control to Reluctant Applications 730 The goal of this work is to provide general congestion control 731 mechanisms that will actually be used by many of the applications 732 that currently use UDP. This may include applications that are 733 perfectly happy without end-to-end congestion control. Several of 734 our design requirements follow from a desire to design and deploy a 735 congestion-controlled protocol that is actually attractive to these 736 "reluctant" applications. These design requirements include the use 737 of Explicit Congestion Notification (ECN) and the ECN Nonce, which 738 both provide positive benefit to the application itself; the choice 739 between different forms of congestion control; and moderate overhead 740 in the size of the packet header. 742 There will always be a few flows that are resistant to the use of 743 end-to-end congestion control, preferring an environment where end- 744 to-end congestion control is used by everyone else, but not by 745 themselves. There has been substantial agreement [RFC 2309, FF99] 746 that in order to maintain the continued use of end-to-end congestion 747 control, router mechanisms are needed to detect and penalize 748 uncontrolled high-bandwidth flows in times of high congestion; these 749 router mechanisms are colloquially known as "penalty boxes". 750 However, before undertaking a concerted effort towards the 751 deployment of penalty boxes in the Internet, it seems reasonable, 752 and more effective, to first make a concerted effort to make end-to- 753 end congestion control easily available to applications currently 754 using UDP. 756 5. Additional Design Considerations 758 This section mentions some additional design considerations that 759 should be considered in designing a new transport protocol. 761 o Mobility: Mechanisms for multihoming and mobility are one area of 762 additional functionality that cannot necessarily be layered 763 cleanly and effectively on top of a transport protocol. Thus, one 764 outstanding design decision with any new transport protocol 765 concerns whether to incorporate mechanisms for multihoming and 766 mobility into the protocol itself. The current version of DCCP 767 includes no multihoming or mobility support. 769 o Defense against DoS attacks and spoofing: A reliable handshake for 770 connection setup and teardown offers protection against DoS and 771 spoofing attacks. Mechanisms allowing a server to avoid holding 772 any state for unacknowledged connection attempts or already- 773 finished connections offer additional protection against DoS 774 attacks. Thus, in designing a new transport protocol, even one 775 designed to provide minimal functionality, the requirements for 776 providing defense against DoS attacks and spoofing need to be 777 considered. 779 o Interoperation with RTP: As Section 3.3.3 describes, attention 780 should be paid to any necessary or desirable changes in RTP when 781 it is used over the new protocol, such as reduced RTP headers. 783 o API: Some functionality required by the protocol, or useful for 784 applications using the protocol, may require the definition of new 785 API mechanisms. Examples include allowing applications to decide 786 what information to put in a packet at transmission time, and 787 providing applications with some information about packet sequence 788 numbers. 790 o Interactions with NATs and Firewalls: NATs and firewalls don't 791 interact well with UDP, with its lack of explicit flow setup and 792 teardown and, in practice, the lack of well-known ports for many 793 UDP applications. Some of these issues are application-specific; 794 others should be addressed by the transport protocol itself. 796 o Consider general experiences with unicast transport: A 797 Requirements for Unicast Transport/Sessions (RUTS) BOF was held at 798 the IETF meeting in December, 1998, with the goal of understanding 799 the requirements of applications whose needs were not met by TCP 800 [RUTS]. Not all of those unmet needs are relevant to or 801 appropriate for a unicast, congestion-controlled, unreliable flow 802 of datagrams designed for long-lived transfers. Some are, 803 however, and any new protocol should address those needs, and 804 other requirements derived from the community's experience. We 805 believe that this document addresses the requirements relevant to 806 our problem area that were brought up at the RUTS BOF. 808 6. Transport Requirements of Request/Response Applications 810 Up until now, this document has discussed the transport and 811 congestion control requirements of applications that generate long- 812 lived, large flows of unreliable datagrams. This section discusses 813 briefly the transport needs of another class of applications, those 814 of request/response transfers where the response might be a small 815 number of packets, with preferences that include both reliable 816 delivery and a minimum of state maintained at the ends. The 817 reliable delivery could be accomplished, for example, by having the 818 receiver re-query when one or more of the packets in the response is 819 lost. This is a class of applications whose needs are not well-met 820 by either UDP or by TCP. 822 Although there is a legitimate need for a transport protocol for 823 such short-lived reliable flows of such request/response 824 applications, we believe that the overlap with the requirements of 825 DCCP is almost non-existent, and that DCCP should not be designed to 826 meet the needs of these request/response applications. Areas of 827 non-compatible requirements include the following: 829 o Reliability: DCCP applications don't need reliability (and long- 830 lived applications that do require reliability are well-suited to 831 TCP or SCTP). In contrast, these short-lived request/response 832 applications do require reliability (possibly client-driven 833 reliability in the form of requesting missing segments of a 834 response). 836 o Connection setup and teardown: Because DCCP is aimed at flows 837 whose duration is often unknown in advance, it addresses 838 interactions with NATs and firewalls by having explicit handshakes 839 for setup and teardown. In contrast, the short-lived 840 request/response applications know the transfer length in advance, 841 but cannot tolerate the additional delay of a handshake for flow 842 set-up. Thus, mechanisms for interacting with NATs and firewalls 843 are likely to be completely different for the two sets of 844 applications. 846 o Congestion-control mechanisms: The styles of congestion control 847 mechanisms and negotiations of congestion control features are 848 heavily dependent on the flow duration. In addition, the 849 preference of the request/response applications for a stateless 850 server strongly impacts the congestion control choices. Thus, 851 DCCP and the short-lived request/response applications have rather 852 different requirements both for congestion control mechanisms and 853 for negotiation procedures. 855 7. Summary of Recommendations 857 Our problem statement has discussed the need for implementing 858 congestion control for unreliable flows. Additional problems 859 concern the need for low overhead, the problems of firewall 860 traversal, and the need for reliable parameter negotiation. Our 861 consideration of the problem statement has resulted in the following 862 general recommendations: 864 o A unicast transport protocol for unreliable datagrams should be 865 developed, including mandatory, built-in congestion control, 866 explicit connection setup and teardown, reliable feature 867 negotiation, and reliable congestion feedback. 869 o The protocol must provide a set of congestion control mechanisms 870 from which the application may choose. These mechanisms should 871 include, at minimum, TCP-like congestion control and a more 872 slowly-responding congestion control such as TFRC. 874 o Important features of the connection, such as the congestion 875 control mechanism in use, should be reliably negotiated by both 876 endpoints. 878 o Support for ECN should be included. (Applications could still 879 make the decision not to use ECN for a particular session.) 881 o The overhead must be low, in terms of both packet size and 882 protocol complexity. 884 o Some DoS protection for servers must be included. In particular, 885 servers can make themselves resistant to spoofed connection 886 attacks ("SYN floods"). 888 o Connection setup and teardown must use explicit handshakes, 889 facilitating transmission through stateful firewalls. 891 In 2002, there was judged to be a consensus about the need for a new 892 unicast transport protocol for unreliable datagrams, and the next 893 step was then the consideration of more detailed architectural 894 issues. 896 8. Security Considerations 898 There are no security considerations for this document. The 899 security considerations for DCCP are discussed separately in [DCCP]. 901 9. IANA Considerations 903 There are no IANA Considerations for this document. 905 10. Acknowledgements 907 We would like to thank Spencer Dawkins, Jiten Goel, Jeff Hammond, 908 Lars-Erik Jonsson, John Loughney, Michael Mealling, and Rik Wade for 909 feedback on earlier versions of this document. We would also like 910 to thank members of the Transport Area Working Group and of the DCCP 911 Working Group for discussions of these issues. 913 11. Informative References 915 [Bala99] H. Balakrishnan, H. Rahul, and S. Seshan. An Integrated 916 Congestion Management Architecture for Internet Hosts. SIGCOMM, 917 Sept. 1999. 919 [CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP Congestion 920 Control ID 2: TCP-like Congestion Control. draft-ietf-dccp- 921 ccid2-08.txt, work in progress, November 2004. 923 [CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for 924 DCCP Congestion Control ID 3: TFRC Congestion Control. draft- 925 ietf-dccp-ccid3-08.txt, work in progress, November 2004. 927 [DCCP] E. Kohler, M. Handley, and S. Floyd. Datagram Congestion 928 Control Protocol. draft-ietf-dccp-spec-09.txt, work in 929 progress, November 2004. 931 [MEASWEB] Ramon Caceres and Sally Floyd. Measurement Studies of 932 End-to-End Congestion Control in the Internet. Web Page, 2001. 934 [FF99] S. Floyd and K. Fall. Promoting the Use of End-to-End 935 Congestion Control in the Internet. IEEE/ACM Transactions on 936 Networking, August 1999. 938 [MC01] S. McCreary and K.C. Claffy. Trends in Wide Area IP Traffic 939 Patterns: A View from Ames Internet Exchange. ITC Specialist 940 Seminar, 2001. URL 941 http://www.caida.org/outreach/papers/2000/AIX0005/. 943 [RFC 1191] J. C. Mogul and S. E. Deering. Path MTU Discovery. 944 RFC 1191. 946 [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 947 3. RFC 2026. 949 [RFC 2309] B. Braden et al. Recommendations on Queue Management and 950 Congestion Avoidance in the Internet. RFC 2309. 952 [RFC 2326] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time 953 Streaming Protocol (RTSP). RFC 2326. 955 [RFC 2481] K. Ramakrishnan and S. Floyd. A Proposal to add Explicit 956 Congestion Notification (ECN) to IP. RFC 2481. 958 [RFC 2525] V. Paxson et al. Known TCP Implementation Problems. 959 RFC 2525. 961 [RFC 2914] S. Floyd. Congestion Control Principles. RFC 2914. 963 [RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 964 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. 965 Paxson. Stream Control Transmission Protocol. RFC 2960. 967 [RFC 3124] H. Balakrishnan and S. Seshan. The Congestion Manager. 968 RFC 3124. 970 [RFC 3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 971 J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: 972 Session Initiation Protocol. RFC 3261. 974 [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer. TCP 975 Friendly Rate Control (TFRC): Protocol Specification. RFC 3448. 977 [RFC 3540] D. Wetherall, D. Ely, and N. Spring. Robust ECN 978 Signaling with Nonces. RFC 3540. 980 [RFC 3714] S. Floyd and J. Kempf, editors. IAB Concerns Regarding 981 Congestion Control for Voice Traffic in the Internet. RFC 3714. 983 [RFC 3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, and P. Conrad. 984 Stream Control Transmission Protocol (SCTP) Partial Reliability 985 Extension. RFC 3758. 987 [RUTS] Requirements for Unicast Transport/Sessions (RUTS) BOF, Dec. 988 7, 1998. URL "http://www.ietf.org/proceedings/98dec/43rd- 989 ietf-98dec-142.html". 991 [TBIT] J. Padhye and S. Floyd. Identifying the TCP Behavior of Web 992 Servers. SIGCOMM 2001. 994 12. Authors' Addresses 996 Sally Floyd 997 ICSI Center for Internet Research (ICIR), 998 International Computer Science Institute, 999 1947 Center Street, Suite 600 1000 Berkeley, CA 94704. 1001 USA 1003 Mark Handley 1004 Department of Computer Science 1005 University College London 1006 Gower Street 1007 London WC1E 6BT 1008 UK 1010 Eddie Kohler 1011 4531C Boelter Hall 1012 UCLA Computer Science Department 1013 Los Angeles, CA 90095 1014 USA 1016 13. Full Copyright Statement 1018 Copyright (C) The Internet Society 2005. This document is subject 1019 to the rights, licenses and restrictions contained in BCP 78, and 1020 except as set forth therein, the authors retain all their rights. 1022 This document and the information contained herein are provided on 1023 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1024 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1025 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1026 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1027 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1028 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1030 14. Intellectual Property 1032 The IETF takes no position regarding the validity or scope of any 1033 Intellectual Property Rights or other rights that might be claimed 1034 to pertain to the implementation or use of the technology described 1035 in this document or the extent to which any license under such 1036 rights might or might not be available; nor does it represent that 1037 it has made any independent effort to identify any such rights. 1038 Information on the procedures with respect to rights in RFC 1039 documents can be found in BCP 78 and BCP 79. 1041 Copies of IPR disclosures made to the IETF Secretariat and any 1042 assurances of licenses to be made available, or the result of an 1043 attempt made to obtain a general license or permission for the use 1044 of such proprietary rights by implementers or users of this 1045 specification can be obtained from the IETF on-line IPR repository 1046 at http://www.ietf.org/ipr. 1048 The IETF invites any interested party to bring to its attention any 1049 copyrights, patents or patent applications, or other proprietary 1050 rights that may cover technology that may be required to implement 1051 this standard. Please address the information to the IETF at ietf- 1052 ipr@ietf.org.