idnits 2.17.1 draft-floyd-dccp-ccid4-01.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 698. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4828]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (29 June 2007) is 6146 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-06) exists of draft-ietf-dccp-tfrc-faster-restart-02 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sally Floyd 3 INTERNET-DRAFT ICIR 4 Intended status: Experimental Eddie Kohler 5 Expires: 29 December 2007 UCLA 6 29 June 2007 8 Profile for Datagram Congestion Control Protocol (DCCP) 9 Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) 10 draft-floyd-dccp-ccid4-01.txt 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on 29 December 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document contains the profile for Congestion Control Identifier 44 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in 45 the Datagram Congestion Control Protocol (DCCP). CCID 4 is for 46 experimental use, and uses TFRC-SP [RFC4828], a variant of TFRC 47 designed for applications that send small packets. The goal for 48 TFRC-SP is to achieve roughly the same bandwidth in bits per second 49 (bps) as a TCP flow using packets of up to 1500 bytes but 50 experiencing the same level of congestion. CCID 4 is for 51 experimental use for senders that send small packets and would like a 52 TCP-friendly sending rate, possibly with Explicit Congestion 53 Notification (ECN), while minimizing abrupt rate changes. 55 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 57 Changes from draft-floyd-dccp-ccid4-00.txt: 59 * Added a subsection describing calculation of the 60 average loss interval in TFRC-SP. 62 * Changed the assumed DCCP-Data header size from 12 bytes 63 to 16 bytes, for 48-bit sequence numbers. Feedback from 64 Ian McDonald. 66 * Added that the CCID4 sender can send two packets in a 67 burst, if limited by OS granularity. From Ian 68 McDonald. 70 * Added that the implementor may track Faster Restart 71 and implement it before an explicit update to the CCID4 72 RFC. From Ian McDonald. 74 * Added an example to Section 8.4 of when errors can 75 occur in using the Window Counter to detect loss 76 intervals of at most two round-trip times. 78 Changes from draft-floyd-ccid4-00.txt: 80 * Added the Dropped Packets option for reporting 81 the number of packets dropped in a loss interval. 83 * Added examples to Section 8.4 of the receiver incorrectly 84 inferring whether a loss interval was short or not. 86 END OF SECTION TO BE DELETED. 88 Table of Contents 90 1. Introduction ....................................................5 91 2. Conventions .....................................................5 92 3. Usage ...........................................................6 93 3.1. Relationship with TFRC .....................................6 94 3.2. Example Half-Connection ....................................6 95 4. Connection Establishment ........................................7 96 5. Congestion Control on Data Packets ..............................7 97 5.1. Response to Idle and Application-limited Periods ...........8 98 5.2. Response to Data Dropped and Slow Receiver .................9 99 5.3. Packet Sizes ...............................................9 100 6. Acknowledgements ................................................9 101 6.1. Loss Interval Definition ...................................9 102 6.2. Congestion Control on Acknowledgements .....................9 103 6.3. Acknowledgements of Acknowledgements ......................10 104 6.4. Quiescence ................................................10 105 7. Explicit Congestion Notification ...............................10 106 8. Options and Features ...........................................10 107 8.1. Window Counter Value ......................................11 108 8.2. Elapsed Time Options ......................................11 109 8.3. Receive Rate Option .......................................11 110 8.4. Send Loss Event Rate Feature ..............................11 111 8.5. Loss Event Rate Option ....................................12 112 8.6. Loss Intervals Option .....................................12 113 8.7. Dropped Packets Option ....................................12 114 8.8. Send Dropped Packets Feature ..............................12 115 9. Verifying Congestion Control Compliance With ECN ...............12 116 9.1. Verifying the ECN Nonce Echo ..............................13 117 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 118 ................................................................13 119 10. Implementation Issues .........................................13 120 10.1. Timestamp Usage ..........................................13 121 10.2. Determining Loss Events at the Receiver ..................13 122 10.3. Sending Feedback Packets .................................13 123 11. Security Considerations .......................................13 124 12. IANA Considerations ...........................................13 125 12.1. Reset Codes ..............................................14 126 12.2. Option Types .............................................14 127 12.3. Feature Numbers ..........................................14 128 13. Thanks ........................................................14 129 Normative References ..............................................14 130 Informative References ............................................15 131 Authors' Addresses ................................................15 132 Full Copyright Statement ..........................................16 133 Intellectual Property .............................................16 135 List of Tables 137 Table 1: DCCP CCID 4 Options ......................................10 138 Table 2: DCCP CCID 4 Feature Numbers ..............................10 140 1. Introduction 142 This document contains the profile for Congestion Control Identifier 143 4, TCP-Friendly Rate Control for Small Packets (TFRC-SP), in the 144 Datagram Congestion Control Protocol (DCCP) [RFC4340]. CCID 4 145 differs from CCID 3 in that CCID 4 uses TFRC-SP, the Small-Packet 146 variant of TFRC, while CCID 3 [RFC4342] uses standard TFRC [RFC3448]. 147 This document assumes that the reader is familiar with [RFC4342], 148 instead of repeating from that document unnecessarily. 150 CCID 4 differs from CCID 3 only in the following respects: 152 o Header size: For TFRC-SP, the allowed transmit rate in bytes per 153 second is reduced by a factor that accounts for packet header 154 size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], 155 and described for CCID 4 in Section 5 below. 157 o Minimum sending rate: TFRC-SP enforces a minimum interval of 158 10 milliseconds between data packets. This is specified for TFRC- 159 SP in Section 4.3 of [RFC4828], and described for CCID 4 in 160 Section 5 below. 162 o Loss rates for short loss intervals: For short lost intervals of 163 at most two round-trip times, the loss rate is computed by 164 counting the actual number of packets lost or marked. For such a 165 short loss interval with N data packets, including K lost or 166 marked data packets, the loss interval length is calculated as 167 N/K, instead of as N. This is specified for TFRC-SP in Section 168 4.4 of [RFC4828]. The CCID 3 Dropped Packets option [CCID3-DP] is 169 thus mandated in addition to CCID 3's Loss Intervals option, as 170 specified in Section 8.7 below. This section also describes the 171 use of the Dropped Packets option in calculating the loss event 172 rate. The computation of the loss rate by the receiver for the 173 Loss Event Rate option is described for CCID 4 in Section 8.4 174 below. 176 o The nominal segment size: In TFRC-SP, the nominal segment size 177 used by the TCP throughput equation is set to 1460 bytes. This is 178 specified for TFRC-SP in Section 4.5 of [RFC3448], and described 179 for CCID 4 in Section 5 below. 181 2. Conventions 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 Additional terminology is described in Section 2 of [RFC4342]. 189 3. Usage 191 Like CCID 3, CCID 4's congestion control is appropriate for flows 192 that would prefer to minimize abrupt changes in the sending rate, 193 including streaming media applications with small or moderate 194 receiver buffering before playback. 196 CCID 4 is designed to be used either by applications that use a small 197 fixed segment size, or by applications that change their sending rate 198 by varying the segment size. If CCID 4 is used by an application 199 that varies its segment size in response to changes in the allowed 200 sending rate in bps, we note that CCID 4 doesn't dictate the segment 201 size to be used by the application; this is done by the application 202 itself. The CCID 4 sender determines the allowed sending rate in 203 bps, in response to on-going feedback from the CCID 4 receiver, and 204 the application can use information about the current allowed sending 205 rate to decide whether to change the current segment size. 207 We note that in some environments there will be a feedback loop, with 208 changes in the packet size or in the sending rate in bps affecting 209 congestion along the path, therefore affecting the allowed sending 210 rate in the future. 212 3.1. Relationship with TFRC 214 The congestion control mechanisms described here follow the TFRC-SP 215 mechanism specified in [RFC4828]. As with CCID 3, conformant CCID 4 216 implementations MAY track updates to the TCP throughput equation 217 directly, as updates are standardized in the IETF, rather than 218 waiting for revisions of this document. However, conformant 219 implementations SHOULD wait for explicit updates to CCID 4 before 220 implementing other changes to TFRC congestion control. 222 3.2. Example Half-Connection 224 This example shows the typical progress of a half-connection using 225 CCID 4's TFRC Congestion Control, not including connection initiation 226 and termination. The example is informative, not normative. This 227 example differs from that for CCID 3 in [RFC4342] only in that the 228 allowed transmit rate is determined by [RFC4828] as well as by 229 [RFC3448]. 231 1. The sender transmits DCCP-Data packets, where the sending rate is 232 governed by the allowed transmit rate as specified in [RFC4828]. 233 Each DCCP-Data packet has a sequence number, and the DCCP header's 234 CCVal field contains the window counter value, used by the 235 receiver in determining when multiple losses belong in a single 236 loss event. 238 In the typical case of an ECN-capable half-connection, each DCCP- 239 Data and DCCP-DataAck packet is sent as ECN-Capable, with either 240 the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce 241 with TFRC is described in Section 9. 243 2. The receiver sends DCCP-Ack packets at least once per round-trip 244 time acknowledging the data packets, unless the sender is sending 245 at a rate of less than one packet per round-trip time, as 246 indicated by the TFRC specification [RFC3448] (Section 6). Each 247 DCCP-Ack packet uses a sequence number, identifies the most recent 248 packet received from the sender, and includes feedback about the 249 recent loss intervals experienced by the receiver. 251 3. The sender continues sending DCCP-Data packets as controlled by 252 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 253 sender updates its allowed transmit rate as specified in [RFC3448] 254 (Section 4.3) and [RFC4828]. This update is based upon a loss 255 event rate calculated by the sender, based on the receiver's loss 256 intervals feedback. If it prefers, the sender can also use a loss 257 event rate calculated and reported by the receiver. 259 4. The sender estimates round-trip times and calculates a nofeedback 260 time, as specified in [RFC3448] (Section 4.4). If no feedback is 261 received from the receiver in that time (at least four round-trip 262 times), the sender halves its sending rate. 264 4. Connection Establishment 266 The connection establishment is as specified in Section 4 of 267 [RFC4342]. 269 5. Congestion Control on Data Packets 271 CCID 4 uses the congestion control mechanisms of TFRC [RFC3448] and 272 TFRC-SP [RFC4828]. [RFC4828] should be considered normative except 273 where specifically indicated. 275 Loss Event Rate 277 As with CCID 3, the basic operation of CCID 4 centers around the 278 calculation of a loss event rate: the number of loss events as a 279 fraction of the number of packets transmitted, weighted over the last 280 several loss intervals. For CCID 4, this loss event rate, a round- 281 trip time estimate, and a nominal packet size of 1460 bytes are 282 plugged into the TCP throughput equation, as specified in RFC 3448 283 (Section 3.1) and [RFC4828]. 285 Because CCID 4 is intended for applications that send small packets, 286 the allowed transmit rate derived from the TCP throughput equation is 287 reduced by a factor that accounts for packet header size, as 288 specified in Section 4.2 of [RFC4828]. The header size on data 289 packets is estimated as 36 bytes (20 bytes for the IP header, and 16 290 bytes for the DCCP-Data header with 48-bit sequence numbers). If the 291 DCCP sender is sending N-byte data packets, the allowed transmit rate 292 is reduced by N/(N+36). CCID 4 senders are limited to this fair 293 rate. The header size would be 32 bytes instead of 36 bytes when 294 24-bit sequence numbers were used in the DCCP-Data header. 296 The loss event rate itself is calculated in CCID 4 using recent loss 297 interval lengths reported by the receiver. Loss intervals are 298 precisely defined in Section 6.1 of [RFC4342], with the modification 299 in [RFC4828] (Section 3) for loss intervals of at most two round-trip 300 times. In summary, a loss interval is up to 1 RTT of possibly lost 301 or ECN-marked data packets, followed by an arbitrary number of non- 302 dropped, non-marked data packets. The CCID 3 Loss Intervals option 303 is used to report loss interval lengths; see Section 8.6. 305 For loss intervals of at most two round-trip times, CCID 4 calculates 306 the loss event rate for that interval by counting the number of 307 packets lost or marked, as described in Section 4.4 of [RFC4828]. 308 Thus, for such a short loss interval with N data packets, including K 309 lost or marked data packets, the loss interval length is calculated 310 as N/K, instead as N. The CCID 3 Dropped Packets option is used to 311 report K, the count of lost or marked data packets. 313 Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms 314 between data packets, regardless of the allowed transmit rate. If 315 operating system scheduling granularity makes this impractical, up to 316 one additional packet MAY be sent per timeslice, providing that no 317 more than three packets are sent in any 30 ms interval. 319 Other Congestion Control Mechanisms 321 The other congestion control mechanisms such as slow-start, feedback 322 packets, and the like are exactly as in CCID 3, and are described in 323 the subsection on "Other Congestion Control Mechanisms" of Section 5 324 in [RFC4342]. 326 5.1. Response to Idle and Application-limited Periods 328 This is described in Section 5.1 of [RFC4342]. If Faster Restart is 329 standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be 330 implemented in CCID4 without having to wait for an explicit update to 331 this document. 333 5.2. Response to Data Dropped and Slow Receiver 335 This is described in Section 5.2 of [RFC4342]. 337 5.3. Packet Sizes 339 CCID 4 is intended for applications that use a fixed small segment 340 size, or that vary their segment size in response to congestion. 342 The CCID 4 sender uses a segment size of 1460 bytes in the TCP 343 throughput equation. This gives the CCID 4 sender roughly the same 344 sending rate in bytes per second as a TFRC flow using 1460-byte 345 segments but experiencing the same packet drop rate. 347 6. Acknowledgements 349 The acknowledgements are as specified in Section 6 of [RFC4342] with 350 the exception of the Loss Interval lengths specified below. 352 6.1. Loss Interval Definition 354 The loss interval definition is as defined in Section 6.1 of 355 [RFC4342], except as specified below. Section 6.1.1 of RFC 4342 356 specifies that for all loss intervals except the first one, the data 357 length equals the sequence length minus the number of non-data 358 packets the sender transmitted during the loss interval, with a 359 minimum data length of one packet. For TFRC-SP, for short loss 360 intervals of at most two round-trip times, the loss interval length 361 is computed not as the data length of the loss interval, but instead 362 as the data length divided by the number of dropped or marked data 363 packets. 365 Section 5.4 of RFC 4342 described when to use the most recent loss 366 interval in the calculation of the average loss interval. [RFC4828] 367 adds to this procedure the restriction that the most recent loss 368 interval is only used in the calculation of the average loss interval 369 if the most recent loss interval is greater than two round-trip 370 times. The pseudocode is given in Section 3 of [RFC4828]. 372 6.2. Congestion Control on Acknowledgements 374 The congestion control on acknowledgements is as specified in Section 375 6.2 of [RFC4342]. 377 6.3. Acknowledgements of Acknowledgements 379 Procedures for the acknowledgement of acknowledgements are as 380 specified in Section 6.3 of [RFC4342]. 382 6.4. Quiescence 384 The procedure for detecting that the sender has gone quiescent is as 385 specified in Section 6.4 of [RFC4342]. 387 7. Explicit Congestion Notification 389 Procedures for the use of Explicit Congestion Notification (ECN) are 390 as specified in Section 7 of [RFC4342]. 392 8. Options and Features 394 CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, 395 and Elapsed Time options, and its Send Ack Vector and ECN Incapable 396 features. CCID 4 also imports the currently defined CCID 3-specific 397 options and features [RFC4342], augmented by the Dropped Packets 398 options and features [CCID3-DP]. Each CCID 4-specific option and 399 feature contains the same data as the corresponding CCID 3 option or 400 feature, and is interpreted in the same way, except as specified 401 elsewhere in this document. 403 Option DCCP- Section 404 Type Length Meaning Data? Reference 405 ----- ------ ------- ----- --------- 406 128-191 Reserved 407 192 6 Loss Event Rate N 8.5 408 193 variable Loss Intervals N 8.6 409 194 6 Receive Rate N 8.3 410 195 variable Dropped Packets N 8.7 411 196-255 Reserved 413 Table 1: DCCP CCID 4 Options 414 The "DCCP-Data?" column indicates that all currently defined 415 CCID 4-specific options MUST be ignored when they occur on DCCP-Data 416 packets. 418 As with CCID 3, the following CCID-specific features are also 419 defined. 421 Rec'n Initial Section 422 Number Meaning Rule Value Req'd Reference 423 ------ ------- ----- ----- ----- --------- 424 128-191 Reserved 425 192 Send Loss Event Rate SP 0 N 8.4 426 193-194 Reserved 427 195 Send Dropped Packets SP 0 N 428 196-255 Reserved 430 Table 2: DCCP CCID 4 Feature Numbers 431 More information is available in Section 8 of [RFC4342] and in 432 [CCID3-DP]. 434 8.1. Window Counter Value 436 The use of the Window Counter Value in the DCCP generic header's 437 CCVal field is as specified in Section 8.1 of [RFC4342]. In addition 438 to their use described in CCID 3, the CCVal counters are used by the 439 receiver in CCID 4 to determine when the length of a loss interval is 440 at most two round-trip times. None of these procedures require the 441 receiver to maintain an explicit estimate of the round-trip time. 442 However, Section 8.1 of [RFC4342] gives a procedure that implementors 443 may use if they wish to keep such an RTT estimate using CCVal. 445 8.2. Elapsed Time Options 447 The use of the Elapsed Time option is defined in Section 8.2 of 448 [RFC4342]. 450 8.3. Receive Rate Option 452 The Receive Rate option is as specified in Section 8.3 of [RFC4342]. 454 8.4. Send Loss Event Rate Feature 456 The Send Loss Event Rate feature is as defined in Section 8.4 of 457 [RFC4342]. 459 See [RFC3448], Section 5 and [RFC4828], Section 4.4 for a normative 460 calculation of the loss event rate. Section 4.4 of [RFC4828] 461 modifies the calculation of the loss interval size for loss intervals 462 of at most two round-trip times. 464 If the CCID 4 receiver is using the Loss Event Rate option, the 465 receiver needs to be able to determine if a loss interval is short, 466 of at most two round-trip times. The receiver can heuristically 467 detect a short loss interval by using the Window Counter in arriving 468 data packets. The sender increases the Window Counter by 1 every 469 quarter of a round-trip time, with the caveat that the Window Counter 470 is never increased by more than five, modulo 16, from one data packet 471 to the next. Using the Window Counter to detect loss intervals of at 472 most two round-trip times could result in some false positives, with 473 some longer loss intervals incorrectly identified as short ones. For 474 example, if the loss interval contained data packets with only two 475 Window Counter values, say, k and k+5, then the receiver could not 476 tell if the loss interval was at most two round-trip times long or 477 not. Similarly, if the sender sent data packets with Window Counter 478 values of 4, 8, 12, 0, 5, but the packets with Window Counter values 479 of 8, 12, and 0 were lost in the network, then the receiver would 480 only receive data packets with Window Counter values of 4 and 5, and 481 would incorrectly infer that the loss interval was at most two round- 482 trip times. 484 8.5. Loss Event Rate Option 486 The Loss Event Rate option is as specified in Section 8.5 of 487 [RFC4342]. 489 See [RFC3448] (Section 5) and [RFC4828] for a normative calculation 490 of the loss event rate. 492 8.6. Loss Intervals Option 494 The Loss Intervals option is as specified in Section 8.6 of 495 [RFC4342]. 497 8.7. Dropped Packets Option 499 The Dropped Packets option is as specified in [CCID3-DP]. CCID 4 500 receivers MUST always include Dropped Packets options on their 501 feedback packets, regardless of the value of the Send Dropped Packets 502 feature. If, nevertheless, a feedback packet does not include a 503 relevant Dropped Packets option, a CCID 4 sender MUST act as if the 504 relevant loss intervals' Drop Counts equal the corresponding Loss 505 Lengths, as specified in [CCID3-DP]. 507 8.8. Send Dropped Packets Feature 509 The Send Dropped Packets feature is as specified in [CCID3-DP]. 511 9. Verifying Congestion Control Compliance With ECN 513 Verifying congestion control compliance with ECN is as discussed in 514 Section 9 of [RFC4342]. 516 9.1. Verifying the ECN Nonce Echo 518 Procedures for verifying the ECN Nonce Echo are as specified in 519 Section 9.1 of [RFC4342]. 521 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 523 Section 9.2 of [RFC4342] discusses the sender's possible verification 524 of loss intervals and loss event rate information reported by the 525 receiver. 527 10. Implementation Issues 529 10.1. Timestamp Usage 531 The use of the Timestamp option is as discussed in Section 10.1 of 532 [RFC4342]. 534 10.2. Determining Loss Events at the Receiver 536 The use of the window counter by the receiver to determine if 537 multiple lost packets belong to the same loss event is as described 538 in Section 10.2 of [RFC4342]. 540 10.3. Sending Feedback Packets 542 The procedure for sending feedback packets is as described in Section 543 10.3 of [RFC4342]. 545 11. Security Considerations 547 Security considerations include those discussed in Section 11 of 548 [RFC4342]. There are no new security considerations introduced by 549 CCID 4. 551 12. IANA Considerations 553 This specification defines the value 4 in the DCCP CCID namespace 554 managed by IANA. 556 CCID 4 also uses three sets of numbers whose values should be 557 allocated by IANA, namely CCID 4-specific Reset Codes, option types, 558 and feature numbers. This document makes no particular allocations 559 from the Reset Code range, except for experimental and testing use 560 [RFC3692]. We refer to the Standards Action policy outlined in 561 [RFC2434]. 563 12.1. Reset Codes 565 Each entry in the DCCP CCID 4 Reset Code registry contains a 566 CCID 4-specific Reset Code, which is a number in the range 128-255; a 567 short description of the Reset Code; and a reference to the RFC 568 defining the Reset Code. Reset Codes 184-190 and 248-254 are 569 permanently reserved for experimental and testing use. The remaining 570 Reset Codes -- 128-183, 191-247, and 255 -- are currently reserved, 571 and should be allocated with the Standards Action policy, which 572 requires IESG review and approval and standards-track IETF RFC 573 publication. 575 12.2. Option Types 577 Each entry in the DCCP CCID 4 option type registry contains a 578 CCID 4-specific option type, which is a number in the range 128-255; 579 the name of the option, such as "Loss Intervals"; and a reference to 580 the RFC defining the option type. The registry is initially 581 populated using the values in Table 1, in Section 8. This document 582 allocates option types 192-195, and option types 184-190 and 248-254 583 are permanently reserved for experimental and testing use. The 584 remaining option types -- 128-183, 191, 196-247, and 255 -- are 585 currently reserved, and should be allocated with the Standards Action 586 policy, which requires IESG review and approval and standards-track 587 IETF RFC publication. 589 12.3. Feature Numbers 591 Each entry in the DCCP CCID 4 feature number registry contains a 592 CCID 4-specific feature number, which is a number in the range 593 128-255; the name of the feature, such as "Send Loss Event Rate"; and 594 a reference to the RFC defining the feature number. The registry is 595 initially populated using the values in Table 2, in Section 8. This 596 document allocates feature numbers 192 and 195, and feature numbers 597 184-190 and 248-254 are permanently reserved for experimental and 598 testing use. The remaining feature numbers -- 128-183, 191, 193-194, 599 196-247, and 255 -- are currently reserved, and should be allocated 600 with the Standards Action policy, which requires IESG review and 601 approval and standards-track IETF RFC publication. 603 13. Thanks 605 Normative References 607 [RFC2119] S. Bradner. Key Words For Use in RFCs to Indicate 608 Requirement Levels. RFC 2119. 610 [RFC2434] T. Narten and H. Alvestrand. Guidelines for Writing 611 an IANA Considerations Section in RFCs. RFC 2434. 613 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 614 Friendly Rate Control (TFRC): Protocol Specification, 615 RFC 3448, Proposed Standard, January 2003. 617 [RFC3692] T. Narten. Assigning Experimental and Testing Numbers 618 Considered Useful. RFC 3692. 620 [RFC4340] Kohler, E., Handley, M., and S. Floyd. Datagram 621 Congestion Control Protocol (DCCP), RFC 4340, March 622 2006. 624 [RFC4342] Floyd, S., Kohler, E., and J. Padhye. Profile for 625 Datagram Congestion Control Protocol (DCCP) Congestion 626 Control ID 3: TCP-Friendly Rate Control (TFRC), RFC 627 4342, March 2006. 629 Informative References 631 [RFC4828] S. Floyd and E. Kohler. TCP Friendly Rate Control 632 (TFRC): the Small-Packet (SP) Variant. RFC 4828, 633 April 2007. 635 [CCID3-DP] Kohler, E., Datagram Congestion Control Protocol 636 (DCCP) Congestion Control ID 3 Dropped Packets Option, 637 Internet-draft draft-kohler-dccp-ccid3-drops-01.txt, 638 work-in-progress, June 2007. URL 639 "http://www.read.cs.ucla.edu/dccp/". 641 [KFS07] Kohler, E., S. Floyd, and A. Sathiaseelan, Faster 642 Restart for TCP Friendly Rate Control (TFRC), 643 Internet-draft draft-ietf-dccp-tfrc-faster- 644 restart-02.txt, work-in-progress, March 2007. 646 Authors' Addresses 648 Sally Floyd 649 ICSI Center for Internet Research 650 1947 Center Street, Suite 600 651 Berkeley, CA 94704 652 USA 654 Eddie Kohler 655 4531C Boelter Hall 656 UCLA Computer Science Department 657 Los Angeles, CA 90095 658 USA 660 Full Copyright Statement 662 Copyright (C) The IETF Trust (2007). 664 This document is subject to the rights, licenses and restrictions 665 contained in BCP 78, and except as set forth therein, the authors 666 retain all their rights. 668 This document and the information contained herein are provided on an 669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 671 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 672 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 673 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 Intellectual Property 678 The IETF takes no position regarding the validity or scope of any 679 Intellectual Property Rights or other rights that might be claimed to 680 pertain to the implementation or use of the technology described in 681 this document or the extent to which any license under such rights 682 might or might not be available; nor does it represent that it has 683 made any independent effort to identify any such rights. Information 684 on the procedures with respect to rights in RFC documents can be 685 found in BCP 78 and BCP 79. 687 Copies of IPR disclosures made to the IETF Secretariat and any 688 assurances of licenses to be made available, or the result of an 689 attempt made to obtain a general license or permission for the use of 690 such proprietary rights by implementers or users of this 691 specification can be obtained from the IETF on-line IPR repository at 692 http://www.ietf.org/ipr. 694 The IETF invites any interested party to bring to its attention any 695 copyrights, patents or patent applications, or other proprietary 696 rights that may cover technology that may be required to implement 697 this standard. Please address the information to the IETF at ietf- 698 ipr@ietf.org.