idnits 2.17.1 draft-floyd-dcp-problem-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 694 has weird spacing: '... packet at tr...' -- 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 (26 August 2002) is 7907 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 753, but no explicit reference was found in the text == Unused Reference: 'MC01' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC 2481' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'RFC 1191' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC 2914' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC 2960' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'WES01' is defined on line 796, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bala99' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEASWEB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FF99' -- Possible downref: Non-RFC (?) normative reference: ref. 'MC01' ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 2525 ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. 'RUTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TBIT' == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-tcp-nonce-03 ** Downref: Normative reference to an Historic draft: draft-ietf-tsvwg-tcp-nonce (ref. 'WES01') Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Sally Floyd 3 draft-floyd-dcp-problem-01.txt Mark Handley 4 Eddie Kohler 5 ICIR 6 26 August 2002 7 Expires: February 2003 9 Problem Statement for DCCP 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document gives the problem statement underlying the 33 development of an unreliable transport protocol incorporating 34 end-to-end congestion control. This is also the problem 35 statement underlying the development of DCCP, the Datagram 36 Congestion Control Protocol. DCCP implements a congestion- 37 controlled, unreliable flow of datagrams suitable for use by 38 applications such as streaming media or on-line games. 40 Table of Contents 42 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 43 2. Problem Space . . . . . . . . . . . . . . . . . . . . . 4 44 2.1. Congestion Control for Unreliable Transfer . . . . . 4 45 2.2. Overhead . . . . . . . . . . . . . . . . . . . . . . 6 46 2.3. Firewall Traversal . . . . . . . . . . . . . . . . . 7 47 2.4. Parameter Negotiation. . . . . . . . . . . . . . . . 7 48 3. Solution Space for Congestion Control of Unreli- 49 able Flows . . . . . . . . . . . . . . . . . . . . . . . . 7 50 3.1. Providing Congestion Control Above UDP . . . . . . . 8 51 3.1.1. The Burden on the Application Designer. . . . . . 8 52 3.1.2. Difficulties with ECN . . . . . . . . . . . . . . 9 53 3.1.3. The Evasion of Congestion Control . . . . . . . . 10 54 3.2. Providing Congestion Control Below UDP . . . . . . . 10 55 3.2.1. Case 1: Congestion Feedback at the Applica- 56 tion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 3.2.2. Case 2: Congestion Feedback at a Layer 58 below UDP. . . . . . . . . . . . . . . . . . . . . . . . 11 59 3.3. Providing Congestion Control at the Transport 60 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 3.3.1. Modifying TCP?. . . . . . . . . . . . . . . . . . 12 62 3.3.2. Unreliable Variants of SCTP?. . . . . . . . . . . 12 63 3.3.3. Modifying RTP?. . . . . . . . . . . . . . . . . . 13 64 3.3.4. Designing a New Transport Protocol. . . . . . . . 14 65 4. Selling Congestion Control to Reluctant Applica- 66 tions. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 5. Additional Design Considerations. . . . . . . . . . . . 15 68 6. Summary of Recommendations. . . . . . . . . . . . . . . 16 69 7. References. . . . . . . . . . . . . . . . . . . . . . . 17 70 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 18 72 1. Introduction 74 Historically, the great majority of Internet unicast traffic has 75 used congestion-controlled TCP, with UDP making up most of the 76 remainder. UDP has mainly been used for short, request-response 77 transfers, like DNS and SNMP, that wish to avoid TCP's three-way 78 handshake, retransmission, and/or stateful connections. UDP also 79 avoids TCP's built-in end-to-end congestion control, and UDP 80 applications tended not to implement their own congestion control. 81 However, since UDP traffic volume was small relative to congestion- 82 controlled TCP flows, the network didn't collapse. 84 Recent years have seen the growth of applications that use UDP in a 85 different way. These applications, including RealAudio, Internet 86 telephony, and on-line games such as Half Life, Quake, and 87 Starcraft, share a preference for timeliness over reliability. TCP 88 can introduce arbitrary delay because of its reliability and in- 89 order delivery requirements; thus, the applications use UDP instead. 90 This growth of long-lived non-congestion-controlled traffic, 91 relative to congestion-controlled traffic, poses a real threat to 92 the overall health of the Internet. 94 Applications could implement their own congestion control mechanisms 95 on a case-by-case basis, with encouragement from the IETF. Some 96 already do this. However, experience shows that congestion control 97 is difficult to get right, and many application writers would like 98 to avoid reinventing this particular wheel. We believe that a new 99 protocol is needed, one that combines unreliable datagram delivery 100 with built-in congestion control. This protocol would act as an 101 enabling technology: existing and new applications could easily use 102 it to transfer timely data without destabilizing the Internet. 104 This document provides a problem statement for such a protocol. We 105 list the properties the protocol should have, then explain why those 106 properties are necessary. We also describe why a new protocol is the 107 best solution for the more general problem of bringing congestion 108 control to unreliable flows of unicast datagrams. 110 This problem statement began as a formalization of the goals of 111 DCCP, a proposed protocol already described in several Internet- 112 Drafts. We intended DCCP to satisfy the problem statement laid out 113 here. However, we believe the problem should be solved whether or 114 not the chosen solution is DCCP, and the DCCP drafts should be 115 judged based on this document or its successors. Nevertheless, for 116 convenience, we write "DCCP" to mean "any protocol that satisfies 117 this problem statement". 119 2. Problem Space 121 We perceive a number of problems related to the use of unreliable 122 data flows in the Internet. The major issues are: 124 o The potential for non-congestion-controlled datagram flows to 125 cause congestion collapse of the network. 127 o The difficulty of correctly implementing effective congestion 128 control mechanisms for unreliable datagram flows. 130 o The lack of a standard solution for performing reliable congestion 131 feedback for unreliable data flows. 133 o The need for a standard solution for negotiating ECN usage for 134 unreliable flows. 136 o The need for applications to have a choice of TCP-friendly 137 congestion control mechanisms. 139 While undoubtedly some application writers would prefer not to 140 perform congestion control at all for unreliable flows, we expect 141 that most responsible application writers would use congestion 142 control if it were available in a standard, easy to use form. 144 More minor problems are: 146 o The difficulty of deploying applications using UDP-based flows in 147 the presence of firewalls. 149 o The desire to have a single way to negotiate congestion control 150 parameters for unreliable flows, independently of the signalling 151 protocol used to set up the flow. 153 o The desire for low per-packet byte overhead. 155 The subsections below discuss these problems of providing congestion 156 control, traversing firewalls, and negotiating parameters in more 157 detail. A separate subsection also discusses the problem of 158 minimizing the overhead of packet headers. 160 2.1. Congestion Control for Unreliable Transfer 162 This project aims to bring easy-to-use congestion control mechanisms 163 to applications that generate long-lived, large flows of unreliable 164 datagrams, such as RealAudio, Internet telephony, and multiplayer 165 games. Our motivation is to avoid congestion collapse. (Request- 166 response applications, such as DNS, SNMP, and SIP, are not our 167 concern; their short flows don't cause congestion in practice, and 168 any congestion control mechanism would take effect between flows, 169 not within a single end-to-end transfer of information.) However, 170 before designing a congestion control mechanism for these 171 applications, we must understand why they use unreliable datagrams 172 in the first place, lest we destroy the very properties they 173 require. 175 There are several reasons why protocols currently use UDP instead of 176 TCP, amongst them: 178 o Startup Delay: they wish to avoid the delay of a three-way 179 handshake. 181 o Statelessness: they wish to avoid holding connection state, and 182 the potential state-holding attacks that come with this. 184 o Trading of Reliability against Timing: the data being sent is 185 timely in the sense that if it is not delivered by some deadline 186 (typically a small number of RTTs) then the data will not be 187 useful at the receiver. 189 Of these, our target applications -- media transfer, games, and the 190 like -- mostly care about having control over the tradeoff between 191 timing and reliability. Such applications use UDP because when they 192 send a datagram, they wish to send the most appropriate data in that 193 datagram. If the datagram is lost, they may or may not resend the 194 same data, depending on whether the data will still be useful at the 195 receiver. Data may no longer be useful for many reasons: 197 o In a telephony or streaming video session, data in a packet 198 comprises a timeslice of a continuous stream. Once a timeslice 199 has been played out, the next timeslice is required immediately. 200 If the data comprising that timeslice arrives at some later time, 201 then it is no longer useful. Such applications can cope with 202 masking the effects of missing packets to some extent, so when the 203 sender transmits its next packet, it is important for it to only 204 send data that has a good chance of arriving in time for its 205 playout. 207 o In a interactive game or VR session, position information is 208 transient. If a datagram containing position information is lost, 209 resending the old position does not usually make sense -- rather, 210 every position information datagram should contain the latest 211 position information. 213 In a congestion-controlled flow, the allowed packet sending rate 214 depends on measured network congestion. Thus, applications must give 215 up some control to the congestion control mechanism, which 216 determines precisely when packets can be sent. However, applications 217 could still decide, at transmission time, which information to put 218 in a packet. TCP doesn't allow control over this; these applications 219 demand it. 221 Often, these applications (especially games and telephony 222 applications) work on very short playout timescales. Whilst they 223 are usually able to adjust their transmission rate based on 224 congestion feedback, they do have constraints on how this adaptation 225 can be performed so that it has minimal impact on the quality of the 226 session. Thus, they tend to need some control over the short-term 227 dynamics of the congestion control algorithm, whilst being fair to 228 other traffic on medium timescales. This control includes, but is 229 not limited to, some influence on which congestion control algorithm 230 should be used -- for example, TFRC rather than strict TCP-like 231 congestion control. 233 2.2. Overhead 235 The applications we are concerned with often send compressed data, 236 or send frequent small packets. For example, when internet telephony 237 or streaming media are used over low-bandwidth modem links, highly 238 compressing the payload data is essential. For internet telephony 239 applications and for games, the requirement is for low delay, and 240 hence small packets are sent frequently. 242 For example, a telephony application sending a 20Kb/s packet stream 243 wanting moderately low delay may send a packet every 20ms, and so 244 each packet would be only 50 bytes. Of this, 20 bytes is taken up 245 by the IP header, leaving only 30 bytes for the transport header and 246 payload. Of course this is a relatively extreme example, but it 247 serves to illustrate the degree to which some of these applications 248 care that the transport protocol is low overhead. 250 In some cases the correct solution would be to use link-based packet 251 header compression to compress the packet headers, although we 252 cannot guarantee the availability of such compression schemes on any 253 particular link. 255 The delay of data until after the completion of a handshake also 256 represents potentially unnecessary overhead. A new protocol might 257 therefore allow senders to include some data on their initial 258 datagrams. 260 2.3. Firewall Traversal 262 Applications requiring a flow of unreliable datagrams currently tend 263 to use signalling protocols such as RTSP, SIP and H.323 in 264 conjunction with UDP for the data flow. The initial setup request 265 uses a signalling protocol to locate the correct remote end-system 266 for the data flow, sometimes being redirected or relayed to other 267 machines, before the data flow is established. 269 As UDP flows contain no explicit setup and teardown, it is hard for 270 firewalls to handle them correctly. Typically the firewall needs to 271 parse RTSP, SIP and H.323 to obtain the information necessary to 272 open a hole in the firewall. Alternatively, for bi-directional 273 flows, the firewall can open a bi-directional hole if it receives a 274 UDP packet from inside the firewall, but in this case the firewall 275 can't easily know when to close the hole again. 277 While we do not consider these to be major problems, they are 278 nonetheless issues that application designers face. Currently 279 streaming media players such as RealPlayer attempt UDP first, and 280 then switch to TCP if UDP is not successful. Streaming media over 281 TCP is undesirable, and can result in the receiver needing to 282 temporarily halt playout while it "rebuffers" data. Telephony 283 applications don't even have this option. 285 2.4. Parameter Negotiation 287 Different applications have different requirements of congestion 288 control, which may map into different congestion feedback. Examples 289 are the ECN capability, and desired congestion control dynamics, 290 which in turn determines the choice of congestion control algorithm 291 and the form of feedback information required. Such parameters need 292 to be reliably negotiated before congestion control can function 293 correctly. 295 While this negotiation could be performed using signalling protocols 296 such as SIP, RTSP and H.323, it would be desirable to have a single 297 standard way of negotiating these transport parameters. This is of 298 particular importance with ECN, where sending ECN-marked packets to 299 a non-ECN-capable receiver can cause significant congestion problems 300 to other flows. We discuss the ECN issue in more detail below. 302 3. Solution Space for Congestion Control of Unreliable Flows 304 We thus want to provide congestion control for unreliable flows, 305 providing both ECN and the choice of different forms of congestion 306 control, and providing moderate overhead in terms of packet size, 307 state, and CPU processing. There are a number of options for 308 providing end-to-end congestion control for the unicast traffic that 309 currently uses UDP, in terms of the layer that provides the 310 congestion control mechanism: 312 o Congestion control above UDP. 314 o Congestion control below UDP. 316 o Congestion control at the transport layer as an alternative to 317 UDP. 319 We explore these alternatives in the sections below. The concerns 320 from the discussions below have convinced us that the best way to 321 provide congestion control for unreliable flows is to provide 322 congestion control at the transport layer, as an alternative to the 323 use of UDP and TCP. 325 3.1. Providing Congestion Control Above UDP 327 One possibility would be to provide congestion control at the 328 application layer, or at some other layer above UDP. Implementing 329 congestion control at a layer above UDP would allow the congestion 330 control mechanism to be closely integrated with the application 331 itself. 333 3.1.1. The Burden on the Application Designer 335 A key disadvantage of providing congestion control above UDP is that 336 it places an unnecessary burden on the application-level designer, 337 who might be just as happy to use the congestion control provided by 338 a lower layer. If the application can rely on a lower layer that 339 gives a choice between TCP-like or TFRC-like congestion control, and 340 that offers ECN, then this might be highly satisfactory to many 341 application designers. 343 The long history of debugging TCP implementations [RFC 2525] [TBIT] 344 makes the difficulties in implementing end-to-end congestion control 345 abundantly clear. It is clearly more robust for congestion control 346 to be provided for the application by a lower layer. In rare cases 347 there might be compelling reasons for the congestion control 348 mechanism to be implemented in the application itself, but we do not 349 expect this to be the general case. For example, applications that 350 use RTP over UDP might be just as happy if RTP itself implemented 351 end-to-end congestion control. (See Section 3.3.3 for more 352 discussion of RTP.) 354 In addition to congestion control issues, we also note the problems 355 with firewall traversal and parameter negotiation discussed in 356 sections 2.3 and 2.4. Implementing on top of UDP requires that the 357 application designer also address these issues. 359 3.1.2. Difficulties with ECN 361 A second problem of providing congestion control above UDP is that 362 it would require either giving up the use of ECN, or giving the 363 application direct control over setting and reading the ECN field in 364 the IP header. Giving up the use of ECN would be problematic, since 365 ECN can be particularly useful for unreliable flows, where a dropped 366 packet will not be retransmitted by the data sender. 368 With the development of the ECN nonce, ECN can also be useful even 369 in the absence of ECN support from the network. The data sender can 370 use the ECN nonce, along with feedback from the data receiver, to 371 verify that the data receiver is correctly reporting all lost 372 packets. This use of ECN can be particularly useful for an 373 application using unreliable delivery, where the receiver might 374 otherwise have little incentive to report lost packets. 376 In order to allow the use of ECN by a layer above UDP, the UDP 377 socket would have to allow the application to control the ECN field 378 in the IP header. In particular, the UDP socket would have to allow 379 the application to specify whether or not the ECN-Capable Transport 380 (ECT) codepoints should be set in the ECN field of the IP header. 382 The ECT codepoint can only safely be set in the packet header of a 383 UDP packet if the following is guaranteed: 385 o If the Congestion Experienced (CE) codepoint is set by a router, 386 the receiving UDP will pass that CE status to the receiving 387 application at the data receiver, and: 389 o Upon receiving a packet that had the CE codepoint set, the 390 receiving application will take the appropriate congestion control 391 action, such as informing the data sender. 393 However, the UDP implementation at the data sender has no way of 394 knowing if the UDP implementation at the data receiver has been 395 upgraded to pass a CE status up to the receiving application, let 396 alone whether or not the application will use the conformant end-to- 397 end congestion control that goes along with use of ECN. 399 In the absence of the widespread deployment of mechanisms in routers 400 to detect flows that are not using conformant congestion control, 401 allowing applications arbitrary control of the ECT codepoints for 402 UDP packets would seem like an unnecessary opportunity for 403 applications to use ECN while evading the use of end-to-end 404 congestion control. Thus, there is an inherent "chicken-and-egg" 405 problem of whether first to deploy policing mechanisms in routers, 406 or first to enable the use of ECN by UDP flows. Without the 407 policing mechanisms in routers, we would not advise adding ECN- 408 capability to UDP sockets at this time. 410 3.1.3. The Evasion of Congestion Control 412 A third problem of providing congestion control above UDP is that 413 relying on congestion control at the application level makes it 414 somewhat easier for some users to evade end-to-end congestion 415 control. We do not claim that a transport protocol such as DCCP 416 would always be implemented in the kernel, and do not attempt to 417 evaluate the relative difficulty of modifying code inside the kernel 418 vs. outside the kernel in any case. However, we believe that 419 putting the congestion control at the transport level rather than at 420 the application level makes it just slightly less likely that users 421 will go to the trouble of modifying the code in order to avoid using 422 end-to-end congestion control. 424 3.2. Providing Congestion Control Below UDP 426 Instead of providing congestion control above UDP, a second 427 possibility would be to provide congestion control for unreliable 428 applications at a layer below UDP, and the applications would use 429 UDP as their transport protocol. Given that UDP does not itself 430 provide sequence numbers or congestion feedback, there are two 431 possible forms for this congestion feedback: 433 o (1) Feedback at the application: The application above UDP could 434 provide sequence numbers and feedback to the sender, which would 435 then communicate loss information to the congestion control 436 mechanism. This is the approach currently standardized by the 437 Congestion Manager [RFC 3124]. 439 o (2) Feedback at the layer below UDP: The application could use 440 UDP, and a protocol could be implemented using a shim header 441 between IP and UDP to provide sequence number information for data 442 packets and return feedback to the data sender. The original 443 proposal for the Congestion Manager [Bala99] suggested providing 444 this layer for applications that did not have their own feedback 445 about dropped packets. 447 We discuss these two cases separately below. 449 3.2.1. Case 1: Congestion Feedback at the Application 451 In this case, the application provides sequence numbers and 452 congestion feedback above UDP, but communicates that feedback to a 453 congestion manager below UDP, which regulates when packets can be 454 sent. This approach suffers from most of the problems described in 455 section 3.1, namely forcing the application designer to reinvent the 456 wheel each time for packet formats and parameter negotiation, and 457 problems with ECN usage, firewalls and evasion. 459 It would avoid the application writer needing to implement the 460 control part of the congestion control mechanism, but it is unclear 461 how easily multiple congestion control algorithms (such as receiver- 462 based TFRC) can be supported, given that the form of congestion 463 feedback usually needs to be closely coupled to the congestion 464 control algorithm being used. 466 3.2.2. Case 2: Congestion Feedback at a Layer below UDP 468 Providing feedback at a layer below UDP would require an additional 469 packet header below UDP to carry sequence numbers in addition to the 470 eight-byte header for UDP itself. Unless this header were an IP 471 option (which is likely to cause problems for many IPv4 routers) 472 then its presence would need to be indicated using a different IP 473 protocol value from UDP. Thus, the packets would no longer look 474 like UDP on the wire. 476 To use this mechanism most effectively, the semantics of the UDP 477 socket API (Application Programming Interface) would also need 478 changing, both to support a late decision on what to send, and to 479 provide access to the sequence numbers to avoid the application 480 needing to duplicate them for its own purposes. Thus, the socket 481 API would no longer look like UDP in the end hosts. This would 482 effectively be a new transport protocol. 484 Given these complications, it seems cleaner to actually design a new 485 transport protocol, which also allows us to address the issues of 486 firewall traversal, flow setup, and parameter negotiation. We note 487 that any new transport protocol could also use a Congestion Manager 488 approach to share congestion state between flows using the same 489 congestion control algorithm, if this were deemed to be desirable. 491 3.3. Providing Congestion Control at the Transport Layer 493 The concerns from the discussions above have convinced us that the 494 best way to provide congestion control to applications that 495 currently use UDP is to provide congestion control at the transport 496 layer, in a transport protocol used as an alternative to UDP. One 497 advantage of providing end-to-end congestion control in an 498 unreliable transport protocol is that it could be used easily by a 499 wide range of the applications that currently use UDP, with minimal 500 changes to the application itself. The application itself would not 501 have to provide the congestion control mechanism, or even the 502 feedback from the data receiver to the data sender about lost or 503 marked packets. 505 The question then arises of whether to adapt TCP for use by 506 unreliable applications, to use an unreliable variant of SCTP or a 507 version of RTP with built-in congestion control, or to design a new 508 transport protocol. 510 As we argue below, the desire for minimal overhead results in the 511 design decision to use a transport protocol containing only the 512 minimal necessary functionality, and to leave other functionality 513 such as reliability, semi-reliability, or Forward Error Correction 514 (FEC) to be layered on top. 516 3.3.1. Modifying TCP? 518 One alternative to be considered would be to create an unreliable 519 variant of TCP, with the reliability layered on top for applications 520 desiring reliable delivery. However, our requirement is not simply 521 for TCP minus the in-order reliable delivery, but also for the 522 application to be able to choose congestion control algorithms. 523 TCP's feedback mechanism works well for TCP-like congestion control, 524 but is inappropriate (or at the very least, inefficient) for TFRC. 525 In addition, TCP sequence numbers are in bytes, which is not optimal 526 for an unreliable datagram protocol. Finally, there is the issue of 527 whether a modified TCP would require a new IP protocol number as 528 well; a significantly modified TCP using the same IP protocol number 529 could have unwanted interactions with some of the middleboxes 530 already deployed in the network. 532 In conclusion, it seems best simply to leave TCP as it is, and to 533 create a new congestion control protocol for unreliable transfer. 535 3.3.2. Unreliable Variants of SCTP? 537 SCTP was in part designed to accommodate multiple streams within a 538 single end-to-end connection, modifying TCP's semantics of reliable, 539 in-order delivery to allow out-of-order delivery. However, explicit 540 support for multiple streams over a single flow at the transport 541 layer is not necessary for an unreliable transport protocol such as 542 DCCP, which of necessity allows out-of-order delivery. Because an 543 unreliable transport does not need streams support, applications 544 should not have to pay the penalties in terms of increased header 545 size that accompany the use of streams in SCTP. 547 The basic underlying structure of the SCTP packet, into a common 548 SCTP header followed by chunks for data, SACK information, and so 549 on, is motivated by SCTP's goal of accommodating multiple streams, 550 However, this use of chunks comes at the cost of an increased header 551 size for packets, as each chunk must be aligned on 32-bit 552 boundaries, and therefore requires a fixed-size 4-byte chunk header. 553 For example, for a connection using ECN, SCTP includes separate 554 control chunks for the Explicit Congestion Notification Echo and 555 Congestion Window Reduced functions, with the ECNE and CWR chunks 556 each requiring 8 bytes. As another example, the common header 557 includes a 4-byte verification tag to validate the sender. The 558 issue of a minimal header size is just one of the ways that the 559 underlying framework of SCTP does not fit the needs of an unreliable 560 transport as outlined in this document. 562 As a second concern, SCTP as currently specified uses TCP-like 563 congestion control, and does not provide support for alternative 564 congestion control algorithms such as TFRC that would be more 565 attractive to some of the applications currently using UDP flows. 566 Thus, the current version of SCTP would not meet the requirements 567 for a choice between forms of end-to-end congestion control. 569 One could suggest adding support for alternative congestion control 570 mechanisms as an option to SCTP, and adding a fully-unreliable 571 variant that does not include the mechanisms for multiple streams. 572 However, that path leads one to a choice between a ``kitchen sink'' 573 protocol that tries to include options to accommodate all 574 applications (i.e., the modified version of SCTP), and a clean and 575 minimal protocol that provides only end-to-end congestion control 576 and any other mechanisms that cannot be provided in a higher layer. 577 We would argue against the ``kitchen sink'' approach in this case. 579 Applications that desire limited retransmission with multi-stream 580 support, or that desire multi-homing support, might be good 581 candidates for a semi-reliable version of SCTP such as U-SCTP. 582 However, we believe that variants of SCTP are not suitable for 583 fully-unreliable applications, or for the bulk of applications that 584 today use UDP. We would argue that instead, an additional transport 585 protocol is needed for unreliable transfer. 587 3.3.3. Modifying RTP? 589 Several of our target applications currently use RTP layered above 590 UDP to transfer their data. Why not modify RTP to provide end-to-end 591 congestion control? 592 As RTP lives above UDP, modifying it to support congestion control 593 might encounter some of the problems described in Section 3.1. In 594 particular, user-level RTP implementations would want access to ECN 595 bits in UDP datagrams. It might be difficult or undesirable to allow 596 that access for RTP, but not for other user-level programs. 598 Kernel implementations of RTP would not suffer from this problem. In 599 the end, the argument against modifying RTP is the same as that 600 against modifying SCTP: Some applications, such as the export of 601 flow information from routers, need congestion control but don't 602 need much of RTP's functionality. From these applications' point of 603 view, RTP would induce unnecessary overhead. Again, we would argue 604 for a clean and minimal protocol focused on end-to-end congestion 605 control. 607 RTP would commonly be used as a layer above any new transport 608 protocol, however. The design of that new transport protocol should 609 take this into account, either by avoiding undue duplication of 610 information available in the RTP header, or by suggesting 611 modifications to RTP. 613 3.3.4. Designing a New Transport Protocol 615 In the first half of this document we have argued for providing 616 congestion control at the transport layer as an alternative to UDP, 617 instead of relying on congestion control supplied only above or 618 below UDP. In this section, we have examined the possibilities of 619 modifying SCTP, modifying TCP, and designing a new transport 620 protocol. In large part because of the requirement for unreliable 621 transport, and for accommodating TFRC and well as TCP-like 622 congestion control, we have concluded that modifications of SCTP or 623 TCP are not the best answer, and that a new transport protocol is 624 needed. Thus, we have argued for the need for a new transport 625 protocol that offers unreliable delivery; accommodates TFRC as well 626 as TCP-like congestion control; accommodates the use of ECN; and 627 requires minimal overhead in packet size and in the state and CPU 628 processing required at the data receiver. 630 This is the line of reasoning that has lead us to the development of 631 DCCP. Both the problem statement presented in this document, and 632 the detailed design decisions made in the design of DCCP, have been 633 brought to the IETF for further feedback. This document addresses 634 only the problem statement; the design decisions resulting from this 635 problem statement will be addressed in a later document. 637 4. Selling Congestion Control to Reluctant Applications 639 The goal of this work is to provide general congestion control 640 mechanisms that will actually be used by many of the applications 641 that currently use UDP. This may include applications that are 642 perfectly happy without end-to-end congestion control. Several of 643 our design requirements follow from a desire to design and deploy a 644 congestion-controlled protocol that is actually attractive to these 645 "reluctant" applications. These include the use of Explicit 646 Congestion Notification (ECN) and the ECN Nonce, which both provide 647 positive benefit to the application itself; the choice between 648 different forms of congestion control; and moderate overhead in the 649 size of the packet header. 651 There will always be a few flows that are resistant to the use of 652 end-to-end congestion control, preferring an environment where end- 653 to-end congestion control is used by everyone else, but not by 654 themselves. There has been substantial agreement [RFC 2309] [FF99] 655 that in order to maintain the continued use of end-to-end congestion 656 control, router mechanisms are needed to detect and penalize 657 uncontrolled high-bandwidth flows in times of high congestion; these 658 router mechanisms are colloquially known as `penalty boxes'. 659 However, before undertaking a concerted effort towards the 660 deployment of penalty boxes in the Internet, it seems reasonable, 661 and more effective, to first make a concerted effort to make end-to- 662 end congestion control easily available to applications currently 663 using UDP. 665 5. Additional Design Considerations 667 This section mentions some additional design considerations that 668 should be considered in designing a new transport protocol. 670 o Mobility: Mechanisms for multi-homing and mobility are one area of 671 additional functionality that cannot necessarily be layered 672 cleanly and effectively on top of a transport protocol. Thus, one 673 outstanding design decision with any new transport protocol 674 concerns whether to incorporate mechanisms for multi-homing and 675 mobility into the protocol itself. 677 o Defense against DoS attacks and spoofing: A reliable handshake for 678 connection setup and teardown offers protection against DoS and 679 spoofing attacks. Mechanisms allowing a server to avoid holding 680 any state for unacknowledged connection attempts or already- 681 finished connections offers additional protection against DoS 682 attacks. Thus, in designed a new transport protocol, even one 683 designed to provide minimal functionality, the requirements for 684 providing defense against DoS attacks and spoofing need to be 685 considered. 687 o Interoperation with RTP: As Section 3.3.3 describes, attention 688 should be paid to the changes that would be required by RTP in 689 order to use any new protocol. 691 o API: Some functionality required by the protocol, or useful for 692 applications using the protocol, may require the definition of new 693 API mechanisms. Examples include allowing applications to decide 694 what information to put in a packet at transmission timer, and 695 providing applications with some information about packet sequence 696 numbers. 698 o Consider general experiences with unicast transport: A 699 Requirements for Unicast Transport/Sessions (ruts) BOF was held at 700 the IETF meeting in December, 1998, with the goal of understanding 701 the requirements of applications whose needs were not met by TCP 702 [RUTS]. Not all of those unmet needs are relevant to or 703 appropriate for a unicast, congestion-controlled, unreliable flow 704 of datagrams designed for long-lived transfers. Some are, however, 705 and any new protocol should address those needs, and other 706 requirements derived from the community's experience. We believe 707 that the DCCP problem statement addresses the relevant 708 requirements brought up at the ruts BOF. 710 6. Summary of Recommendations 712 Our problem statement has discussed the need for implementing 713 congestion control for unreliable flows. Additional problems 714 concern the need for low overhead, the problems of firewall 715 traversal, and the need for reliable parameter negotiation. Our 716 consideration of the problem statement has resulted in the following 717 general recommendations: 719 o A unicast transport protocol for unreliable datagrams should be 720 developed, including mandatory, built-in congestion control. 722 o The protocol must provide a set of congestion control mechanisms 723 from which the application may choose. These mechanisms should 724 include, at minimum, TCP-like congestion control and a more 725 slowly-responding congestion control such as TFRC. 727 o Important features of the connection, such as the congestion 728 control mechanism in use, should be reliably negotiated by both 729 endpoints. 731 o Support for ECN should be included. 733 o The overhead must be low, in terms of both packet size and 734 protocol complexity. 736 o Some DoS protection for servers must be included. In particular, 737 servers can make themselves invulnerable to spoofed connection 738 attacks ("SYN floods"). 740 o Connection setup and teardown must use explicit handshakes, 741 facilitating transmission through stateful firewalls. 743 If there is a consensus about the need for a new unicast transport 744 protocol for unreliable datagrams, then the next step can be the 745 consideration of more detailed architectural issues. 747 7. References 749 [Bala99] H. Balakrishnan, H. Rahul, and S. Seshan, An Integrated 750 Congestion Management Architecture for Internet Hosts, SIGCOMM, 751 Sept. 1999. 753 [MEASWEB] Ramon Caceres and Sally Floyd, Measurement Studies of End- 754 to-End Congestion Control in the Internet, Web Page, 2001. 756 [FF99] S. Floyd and K. Fall, Promoting the Use of End-to-End 757 Congestion Control in the Internet, IEEE/ACM Transactions on 758 Networking, August 1999. 760 [MC01] S. McCreary and K.C. Claffy, Trends in Wide Area IP Traffic 761 Patterns: A View from Ames Internet Exchange, ITC Specialist 762 Seminar, 2001. URL 763 ``http://www.caida.org/outreach/papers/2000/AIX0005/''. 765 [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3. 766 RFC 2026. 768 [RFC 2481] K. Ramakrishnan, S. Floyd. A Proposal to add Explicit 769 Congestion Notification (ECN) to IP. RFC 2481. 771 [RFC 1191] J. C. Mogul, S. E. Deering. Path MTU Discovery. RFC 1191. 773 [RFC 2309] B. Braden et al., Recommendations on Queue Management and 774 Congestion Avoidance in the Internet. RFC 2309, April 1998. 776 [RFC 2525] V. Paxson et al., Known TCP Implementation Problems, RFC 777 2525, March 1999. 779 [RFC 2914] S. Floyd. Congestion Control Principles. RFC 2914, Sept. 780 2000. 782 [RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 783 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. 784 Paxson. Stream Control Transmission Protocol. RFC 2960. 786 [RFC 3124] H. Balakrishnan, S. Seshan. The Congestion Manager. RFC 787 3124. 789 [RUTS] Requirements for Unicast Transport/Sessions (ruts) BOF, Dec. 790 7, 1998. URL "http://www.ietf.org/proceedings/98dec/43rd- 791 ietf-98dec-142.html". 793 [TBIT] J. Padhye and S. Floyd, Identifying the TCP Behavior of Web 794 Servers, SIGCOMM 2001. 796 [WES01] David Wetherall, David Ely, Neil Spring. Robust ECN 797 Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-03.txt, work 798 in progress, April 2002. 800 8. Authors' Addresses 802 Sally Floyd 803 Mark Handley 804 Eddie Kohler 806 ICSI Center for Internet Research (ICIR), 807 International Computer Science Institute, 808 1947 Center Street, Suite 600 809 Berkeley, CA 94704.