idnits 2.17.1 draft-floyd-ccid4-00.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 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. ** 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. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TFRC-SP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (18 June 2006) is 6514 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-07) exists of draft-ietf-dccp-tfrc-voip-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-dccp-tfrc-voip (ref. 'TFRC-SP') Summary: 7 errors (**), 0 flaws (~~), 3 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 draft-floyd-ccid4-00.txt Eddie Kohler 5 Expires: 18 December 2006 UCLA 6 18 June 2006 8 Profile for DCCP Congestion Control ID 4: 9 the Small-Packet Variant of 10 TFRC Congestion Control 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 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference 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 18 December 2006. 37 Abstract 39 This document contains the profile for Congestion Control Identifier 40 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in 41 the Datagram Congestion Control Protocol (DCCP). CCID 4 is for 42 experimental use, and uses TFRC-SP [TFRC-SP], a Small-Packet (SP) 43 variant of TFRC designed for applications that send small packets. 44 The goal for TFRC-SP is to achieve roughly the same bandwidth in 45 bits per second (bps) as a TCP flow using packets of up to 1500 46 bytes but experiencing the same level of congestion. CCID 4 is for 47 experimental use for senders that send small packets and would like 48 a TCP-friendly sending rate, possibly with Explicit Congestion 49 Notification (ECN), while minimizing abrupt rate changes. 51 Table of Contents 53 1. Introduction ...................................................5 54 2. Conventions ....................................................5 55 3. Usage ..........................................................6 56 3.1. Relationship with TFRC ....................................6 57 3.2. Example Half-Connection ...................................6 58 4. Connection Establishment .......................................7 59 5. Congestion Control on Data Packets .............................7 60 5.1. Response to Idle and Application-limited Periods ..........8 61 5.2. Response to Data Dropped and Slow Receiver ................8 62 5.3. Packet Sizes ..............................................9 63 6. Acknowledgements ...............................................9 64 6.1. Loss Interval Definition ..................................9 65 6.1.1. Loss Interval Lengths ..............................9 66 6.2. Congestion Control on Acknowledgements ....................9 67 6.3. Acknowledgements of Acknowledgements ......................9 68 6.4. Quiescence ................................................9 69 7. Explicit Congestion Notification ...............................9 70 8. Options and Features ..........................................10 71 8.1. Window Counter Value .....................................10 72 8.2. Elapsed Time Options .....................................11 73 8.3. Receive Rate Option ......................................11 74 8.4. Send Loss Event Rate Feature .............................11 75 8.5. Loss Event Rate Option ...................................11 76 8.6. Loss Intervals Option ....................................11 77 8.6.1. Option Details ....................................12 78 9. Verifying Congestion Control Compliance With ECN ..............13 79 9.1. Verifying the ECN Nonce Echo .............................13 80 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 81 ...............................................................13 82 10. Implementation Issues ........................................13 83 10.1. Timestamp Usage .........................................13 84 10.2. Determining Loss Events at the Receiver .................13 85 10.3. Sending Feedback Packets ................................13 86 11. Security Considerations ......................................13 87 12. IANA Considerations ..........................................13 88 12.1. Reset Codes .............................................14 89 12.2. Option Types ............................................14 90 12.3. Feature Numbers .........................................14 91 13. Thanks .......................................................15 92 Normative References .............................................15 93 Informative References ...........................................15 94 Authors' Addresses ...............................................15 95 Full Copyright Statement .........................................16 96 Intellectual Property ............................................16 98 List of Tables 100 Table 1: DCCP CCID 4 Options .....................................10 101 Table 2: DCCP CCID 4 Feature Numbers .............................10 103 1. Introduction 105 This document contains the profile for Congestion Control Identifier 106 4, the Small-Packet variant of TCP-friendly rate control (TFRC), in 107 the Datagram Congestion Control Protocol (DCCP) [RFC 4340]. CCID 4 108 differs from CCID 3 in that CCID 4 uses TFRC-PS, while CCID 3 [RFC 109 4342] uses standard TFRC [RFC 3448]. This document assumes that the 110 reader is familiar with [RFC 4342], instead of repeating from that 111 document unnecessarily. 113 CCID 4 differs from CCID 3 only in the following respects: 115 o Header size: For TFRC-SP, the allowed transmit rate in bytes per 116 second is reduced by a factor that accounts for packet header 117 size. This is specified for TFRC-SP in Section 4.2 of [TFRC-SP], 118 and described for CCID 4 in Section 5 below. 120 o Minimum sending rate: TFRC-SP enforces a minimum interval of 10 121 ms. between data packets. This is specified for TFRC-SP in 122 Section 4.3 of [TFRC-SP], and described for CCID 4 in Section 5 123 below. 125 o Loss rates for short loss intervals: For short lost intervals of 126 at most two round-trip times, the loss rate is computed by 127 counting the actual number of packets lost or marked. For such a 128 short loss interval with N data packets, including K lost or 129 marked data packets, the loss interval length is calculated as 130 N/K, instead of as N. This is specified for TFRC-SP in Section 131 4.4 of [TFRC-SP]. The addition of a Dropped Packets field to 132 CCID 4's Loss Intervals Option is specified in 8.6 below, and its 133 use in calculating the loss event rate is specified in 8.6 below. 134 The computation of the loss rate by the receiver for the Loss 135 Event Rate option is described for CCID 4 in Section 8.4 below. 137 o The nominal segment size: In TFRC-SP, the nominal segment size 138 used by the TCP throughput equation is set to 1460 bytes. This 139 is specified for TFRC-SP in Section 4.5 of RFC 3448, and 140 described for CCID 4 in Section 5 below. 142 2. Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC 2119]. 148 Additional terminology is described in Section 2 of [RFC 4342]. 150 3. Usage 152 Like CCID 3, CCID 4's congestion control is appropriate for flows 153 that would prefer to minimize abrupt changes in the sending rate, 154 including streaming media applications with small or moderate 155 receiver buffering before playback. 157 CCID 4 is designed to be used either by applications that use a 158 small fixed segment size, or by applications that change their 159 sending rate by varying the segment size. If CCID 4 is used by an 160 application that varies its segment size in response to changes in 161 the allowed sending rate in bps, we note that CCID 4 doesn't dictate 162 the segment size to be used by the application; this is done by the 163 application itself. The CCID 4 sender determines the allowed 164 sending rate in bps, in response to on-going feedback from the 165 CCID 4 receiver, and the application can use information about the 166 current allowed sending rate to decide whether to change the current 167 segment size. 169 We note that in some environments there will be a feedback loop, 170 with changes in the packet size or in the sending rate in bps 171 affecting congestion along the path, therefore affecting the allowed 172 sending rate in the future. 174 3.1. Relationship with TFRC 176 The congestion control mechanisms described here follow the TFRC-SP 177 mechanism specified in [TFRC-SP]. As with CCID 3, conformant CCID 4 178 implementations MAY track updates to the TCP throughput equation 179 directly, as updates are standardized in the IETF, rather than 180 waiting for revisions of this document. However, conformant 181 implementations SHOULD wait for explicit updates to CCID 4 before 182 implementing other changes to TFRC congestion control. 184 3.2. Example Half-Connection 186 This example shows the typical progress of a half-connection using 187 CCID 4's TFRC Congestion Control, not including connection 188 initiation and termination. The example is informative, not 189 normative. This example differs from that for CCID 3 in [RFC 4342] 190 only in that the allowed transmit rate is determined by [TFRC-SP] as 191 well as by [RFC 3448]. 193 1. The sender transmits DCCP-Data packets, where the sending rate 194 is governed by the allowed transmit rate as specified in [TFRC- 195 SP]. Each DCCP-Data packet has a sequence number, and the DCCP 196 header's CCVal field contains the window counter value, used by 197 the receiver in determining when multiple losses belong in a 198 single loss event. 200 In the typical case of an ECN-capable half-connection, each 201 DCCP-Data and DCCP-DataAck packet is sent as ECN-Capable, with 202 either the ECT(0) or the ECT(1) codepoint set. The use of the 203 ECN Nonce with TFRC is described in Section 9. 205 2. The receiver sends DCCP-Ack packets at least once per round-trip 206 time acknowledging the data packets, unless the sender is 207 sending at a rate of less than one packet per round-trip time, 208 as indicated by the TFRC specification [RFC 3448] (Section 6). 209 Each DCCP-Ack packet uses a sequence number, identifies the most 210 recent packet received from the sender, and includes feedback 211 about the recent loss intervals experienced by the receiver. 213 3. The sender continues sending DCCP-Data packets as controlled by 214 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 215 sender updates its allowed transmit rate as specified in [RFC 216 3448] (Section 4.3) and [TFRC-SP]. This update is based upon a 217 loss event rate calculated by the sender, based on the 218 receiver's loss intervals feedback. If it prefers, the sender 219 can also use a loss event rate calculated and reported by the 220 receiver. 222 4. The sender estimates round-trip times and calculates a 223 nofeedback time, as specified in [RFC 3448] (Section 4.4). If 224 no feedback is received from the receiver in that time (at least 225 four round-trip times), the sender halves its sending rate. 227 4. Connection Establishment 229 The connection establishment is as specified in Section 4 of [RFC 230 4342]. 232 5. Congestion Control on Data Packets 234 CCID 4 uses the congestion control mechanisms of TFRC [RFC 3448] and 235 TFRC-SP [TFRC-SP]. [TFRC-SP] should be considered normative except 236 where specifically indicated. 238 Loss Event Rate 240 As with CCID 3, the basic operation of CCID 4 centers around the 241 calculation of a loss event rate: the number of loss events as a 242 fraction of the number of packets transmitted, weighted over the 243 last several loss intervals. For CCID 4, this loss event rate, a 244 round-trip time estimate, and a nominal packet size of 1460 bytes 245 are plugged into the TCP throughput equation, as specified in 246 RFC 3448 (Section 3.1) and [TFRC-SP]. 248 Because CCID 4 is intended for applications that send small packets, 249 the allowed transmit rate derived from the TCP throughput equation 250 is reduced by a factor that accounts for packet header size, as 251 specified in Section 4.2 of [TFRC-SP]. The header size on data 252 packets is estimated as 32 bytes (20 bytes for the IP header, and 12 253 bytes for the DCCP-Data header with 24-bit sequence numbers). If 254 the DCCP sender is sending N-byte data packets, the allowed transmit 255 rate is reduced by N/(N+32). CCID 4 senders are limited to this 256 fair rate. 258 The loss event rate itself is calculated in CCID 4 using recent loss 259 interval lengths reported by the receiver. Loss intervals are 260 precisely defined in Section 6.1 of [RFC 4342], with the 261 modification in [TFRC-SP] (Section 3) for loss intervals of at most 262 two round-trip times. In summary, a loss interval is up to 1 RTT of 263 possibly lost or ECN-marked data packets, followed by an arbitrary 264 number of non-dropped, non-marked data packets. The CCID 4 Loss 265 Intervals option is used to report loss interval lengths; see 266 Section 8.6. 268 For loss intervals of at most two round-trip times, CCID 4 269 calculates the loss event rate for that interval by counting the 270 number of packets lost or marked, as described in Section 4.4 of 271 [TFRC-SP]. Thus, for such a short loss interval with N data 272 packets, including K lost or marked data packets, the loss interval 273 length is calculated as N/K, instead as N. 275 Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 276 ms. between data packets, regardless of the allowed transmit rate. 278 Other Congestion Control Mechanisms 280 The other congestion control mechanisms such as slow-start, feedback 281 packets, and the like are exactly as in CCID 3, and are described in 282 the subsection on "Other Congestion Control Mechanisms" of Section 5 283 in [RFC 4342]. 285 5.1. Response to Idle and Application-limited Periods 287 This is described in Section 5.1 of [RFC 4342]. 289 5.2. Response to Data Dropped and Slow Receiver 291 This is described in Section 5.2 of [RFC 4342]. 293 5.3. Packet Sizes 295 CCID 4 is intended for applications that use a fixed small segment 296 size, or that vary their segment size in response to congestion. 298 The CCID 4 sender uses a segment size of 1460 bytes in the TCP 299 throughput equation. This gives the CCID 4 sender roughly the same 300 sending rate in bytes per second as a TFRC flow using 1460-byte 301 segments but experiencing the same packet drop rate. 303 6. Acknowledgements 305 The acknowledgements are as specified in Section 6 of [RFC 4342] 306 with the exception of the Loss Interval lengths specified below. 308 6.1. Loss Interval Definition 310 The loss interval definition is as defined in Section 6.1 of [RFC 311 4342]. 313 6.1.1. Loss Interval Lengths 315 The Loss Intervals option specified for CCID 3 in [RFC 4342] reports 316 three lengths for each loss interval, the lengths of the lossy and 317 lossless parts, and a separate data length; the data length is used 318 in TFRC's loss event rate calculation. The Loss Intervals option 319 specified in this document for CCID 4 includes an additional Dropped 320 Packets field, described below in Section 8.6. 322 6.2. Congestion Control on Acknowledgements 324 The congestion control on acknowledgements is as specified in 325 Section 6.2 of [RFC 4342]. 327 6.3. Acknowledgements of Acknowledgements 329 Procedures for the acknowledgement of acknowledgements are as 330 specified in Section 6.3 of [RFC 4342]. 332 6.4. Quiescence 334 The procedure for detecting that the sender has gone quiescent is as 335 specified in Section 6.4 of [RFC 4342]. 337 7. Explicit Congestion Notification 339 Procedures for the use of Explicit Congestion Notification (ECN) are 340 as specified in Section 7 of [RFC 4342]. 342 8. Options and Features 344 CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, 345 and Elapsed Time options, and its Send Ack Vector and ECN Incapable 346 features. As with CCID 3, the following CCID-specific options 347 defined for use with CCID 4. 349 Option DCCP- Section 350 Type Length Meaning Data? Reference 351 ----- ------ ------- ----- --------- 352 128-191 Reserved 353 192 6 Loss Event Rate N 8.5 354 193 variable Loss Intervals N 8.6 355 194 6 Receive Rate N 8.3 356 195-255 Reserved 358 Table 1: DCCP CCID 4 Options 360 The "DCCP-Data?" column indicates that all currently defined 361 CCID 4-specific options MUST be ignored when they occur on DCCP-Data 362 packets. 364 As with CCID 3, the following CCID-specific feature is also defined. 366 Rec'n Initial Section 367 Number Meaning Rule Value Req'd Reference 368 ------ ------- ----- ----- ----- --------- 369 128-191 Reserved 370 192 Send Loss Event Rate SP 0 N 8.4 371 193-255 Reserved 373 Table 2: DCCP CCID 4 Feature Numbers 375 More information is available in Section 8 of [RFC 4342]. 377 8.1. Window Counter Value 379 The use of the Window Counter Value in the DCCP generic header's 380 CCVal field is as specified in Section 8.1 of [RFC 4342]. 382 In addition to their use described in CCID 3, the CCVal counters are 383 used by the receiver in CCID 4 to determine when the length of a 384 loss interval is at most two round-trip times. None of these 385 procedures require the receiver to maintain an explicit estimate of 386 the round-trip time. However, Section 8.1 of [RFC 4342] gives a 387 procedure that implementors may use if they wish to keep such an RTT 388 estimate using CCVal. 390 8.2. Elapsed Time Options 392 The use of the Elapsed Time option is defined in Section 8.2 of [RFC 393 4342]. 395 8.3. Receive Rate Option 397 The Receive Rate Option is as specified in Section 8.3 of [RFC 398 4342]. 400 8.4. Send Loss Event Rate Feature 402 The Send Loss Event Rate feature is as defined in Section 8.4 of 403 [RFC 4342]. 405 See [RFC 3448], Section 5 and [TFRC-SP], Section 4.4 for a normative 406 calculation of the loss event rate. Section 4.4 of [TFRC-SP] 407 modifies the calculation of the loss interval size for loss 408 intervals of at most two round-trip times. 410 If the CCID 4 receiver is using the Loss Event Rate option, the 411 receiver needs to be able to determine if a loss interval is short, 412 of at most two round-trip times. The receiver can heuristically 413 detect a short loss interval by using the Window Counter in arriving 414 data packets. The sender increases the Window Counter by 1 every 415 quarter of a round-trip time, with the caveat that the Window 416 Counter is never increased by more than five, modulo 16, from one 417 data packet to the next. Using the Window Counter to detect loss 418 intervals of at most two round-trip times could result in some false 419 positives, with some longer loss intervals incorrectly identified as 420 short ones. 422 8.5. Loss Event Rate Option 424 The Loss Event Rate Option is as specified in Section 8.5 of [RFC 425 4342]. 427 See [RFC 3448] (Section 5) and [TFRC-SP] for a normative calculation 428 of loss event rate. 430 8.6. Loss Intervals Option 432 In CCID 3, each Loss Interval reported in the Loss Intervals Option 433 includes a Lossless Length, Loss Length, and Data Length. The Data 434 Length is used in the calculation of the loss event rate, and the 435 Lossless Length is used for the ECN Nonce Echo. In CCID 4, each 436 Loss Interval includes an additional 3-byte field, the Dropped 437 Packets field. 439 +--------+--------+--------+--------...--------+--------+--- 440 |11000001| Length | Skip | Loss Interval | More Loss 441 | | | Length | | Intervals... 442 +--------+--------+--------+--------...--------+--------+--- 443 Type=193 12 bytes 445 For CCID 4, each 12-byte Loss Interval contains four fields, as 446 follows: 448 ____________________ Loss Interval _________________________ 449 / \ 450 +-------...-------+------...------+-----...-----+------...-----+ 451 | Lossless Length |E| Loss Length | Data Length | Dropped Pkts | 452 +-------...-------+------...------+-----...-----+------...-----+ 453 3 bytes 3 bytes 3 bytes 3 bytes 455 The receiver reports its observed loss intervals using a Loss 456 Intervals option. Section 6.1 defines loss intervals. This option 457 MUST be sent by the data receiver on all required acknowledgements. 458 The option reports up to 21 loss intervals seen by the receiver 459 (although TFRC currently uses at most the latest 9 of these). This 460 lets the sender calculate a loss event rate and probabilistically 461 verify the receiver's ECN Nonce Echo. 463 The Loss Intervals option serves several purposes, as described in 464 Section 8.6 of [RFC 4342]. 466 Loss Intervals options MUST NOT be sent on DCCP-Data packets, and 467 any Loss Intervals options on received DCCP-Data packets MUST be 468 ignored. 470 8.6.1. Option Details 472 The details for the use of the Loss Intervals Option are as 473 described in Section 8.6.1 of [RFC 4342], with the exception of the 474 added field for Dropped Packets. 476 Dropped Packets: Dropped Packets, a 24-bit number, specifies the 477 number of dropped or marked packets in the loss interval. For Loss 478 Intervals of at most two round-trip times, the Dropped Packets field 479 MUST report the receiver's estimate of the number of dropped or 480 marked data packets in that loss interval. For Loss Intervals 481 greater than two round-trip times, the Dropped Packets field MAY 482 instead be set to zero. 484 9. Verifying Congestion Control Compliance With ECN 486 Verifying congestion control compliance with ECN is as discussed in 487 Section 9 of [RFC 4342]. 489 9.1. Verifying the ECN Nonce Echo 491 Procedures for verifying the ECN Nonce Echo are as specified in 492 Section 9.1 of [RFC 4342]. 494 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 496 Section 9.2 of [RFC 4342] discusses the sender's possible 497 verification of loss intervals and loss event rate information 498 reported by the receiver. 500 10. Implementation Issues 502 10.1. Timestamp Usage 504 The use of the Timestamp option is as discussed in Section 10.1 of 505 [RFC 4342]. 507 10.2. Determining Loss Events at the Receiver 509 The use of the window counter by the receiver to determine if 510 multiple lost packets belong to the same loss event is as described 511 in Section 10.2 of [RFC 4342]. 513 10.3. Sending Feedback Packets 515 The procedure for sending feedback packets is as described in 516 Section 10.3 of [RFC 4342]. 518 11. Security Considerations 520 Security considerations include those discussed in Section 11 of 521 [RFC 4342]. There are no new security considerations introduced by 522 CCID 4. 524 12. IANA Considerations 526 This specification defines the value 4 in the DCCP CCID namespace 527 managed by IANA. 529 CCID 4 also uses three sets of numbers whose values should be 530 allocated by IANA, namely CCID 4-specific Reset Codes, option types, 531 and feature numbers. This document makes no particular allocations 532 from the Reset Code range, except for experimental and testing use 533 [RFC 3692]. We refer to the Standards Action policy outlined in 534 [RFC 2434]. 536 12.1. Reset Codes 538 Each entry in the DCCP CCID 4 Reset Code registry contains a 539 CCID 4-specific Reset Code, which is a number in the range 128-255; 540 a short description of the Reset Code; and a reference to the RFC 541 defining the Reset Code. Reset Codes 184-190 and 248-254 are 542 permanently reserved for experimental and testing use. The 543 remaining Reset Codes -- 128-183, 191-247, and 255 -- are currently 544 reserved, and should be allocated with the Standards Action policy, 545 which requires IESG review and approval and standards-track IETF RFC 546 publication. 548 12.2. Option Types 550 Each entry in the DCCP CCID 4 option type registry contains a 551 CCID 4-specific option type, which is a number in the range 128-255; 552 the name of the option, such as "Loss Intervals"; and a reference to 553 the RFC defining the option type. The registry is initially 554 populated using the values in Table 1, in Section 8. This document 555 allocates option types 192-194, and option types 184-190 and 248-254 556 are permanently reserved for experimental and testing use. The 557 remaining option types -- 128-183, 191, 195-247, and 255 -- are 558 currently reserved, and should be allocated with the Standards 559 Action policy, which requires IESG review and approval and 560 standards-track IETF RFC publication. 562 12.3. Feature Numbers 564 Each entry in the DCCP CCID 4 feature number registry contains a 565 CCID 4-specific feature number, which is a number in the range 566 128-255; the name of the feature, such as "Send Loss Event Rate"; 567 and a reference to the RFC defining the feature number. The 568 registry is initially populated using the values in Table 2, in 569 Section 8. This document allocates feature number 192, and feature 570 numbers 184-190 and 248-254 are permanently reserved for 571 experimental and testing use. The remaining feature numbers -- 572 128-183, 191, 193-247, and 255 -- are currently reserved, and should 573 be allocated with the Standards Action policy, which requires IESG 574 review and approval and standards-track IETF RFC publication. 576 13. Thanks 578 Normative References 580 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 581 Requirement Levels. RFC 2119. 583 [RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing 584 an IANA Considerations Section in RFCs. RFC 2434. 586 [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 587 Friendly Rate Control (TFRC): Protocol 588 Specification, RFC 3448, Proposed Standard, January 589 2003. 591 [RFC 3692] T. Narten. Assigning Experimental and Testing 592 Numbers Considered Useful. RFC 3692. 594 [RFC 4340] Kohler, E., Handley, M., and S. Floyd. Datagram 595 Congestion Control Protocol (DCCP), RFC 4340, March 596 2006. 598 [RFC 4342] Floyd, S., Kohler, E., and J. Padhye. Profile for 599 Datagram Congestion Control Protocol (DCCP) 600 Congestion Control ID 3: TCP-Friendly Rate Control 601 (TFRC), RFC 4342, March 2006. 603 [TFRC-SP] S. Floyd and E. Kohler. TCP Friendly Rate Control 604 (TFRC): the Small-Packet (SP) Variant. Internet- 605 draft draft-ietf-dccp-tfrc-voip-05.txt, March 2005. 607 Informative References 609 Authors' Addresses 611 Sally Floyd 612 ICSI Center for Internet Research 613 1947 Center Street, Suite 600 614 Berkeley, CA 94704 615 USA 617 Eddie Kohler 618 4531C Boelter Hall 619 UCLA Computer Science Department 620 Los Angeles, CA 90095 621 USA 623 Full Copyright Statement 625 Copyright (C) The Internet Society (2006). This document is subject 626 to the rights, licenses and restrictions contained in BCP 78, and 627 except as set forth therein, the authors retain all their rights. 629 This document and the information contained herein are provided on 630 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 631 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 632 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 633 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed 641 to pertain to the implementation or use of the technology described 642 in this document or the extent to which any license under such 643 rights might or might not be available; nor does it represent that 644 it has made any independent effort to identify any such rights. 645 Information on the procedures with respect to rights in RFC 646 documents can be found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use 651 of such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository 653 at http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at ietf- 659 ipr@ietf.org.