idnits 2.17.1 draft-ietf-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 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 868. 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 (18 November 2007) is 6002 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) -- Duplicate reference: RFC3448, mentioned in 'RFC3448Errat', was also mentioned in 'RFC3448'. ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) -- Duplicate reference: RFC4342, mentioned in 'RFC4342Errat', was also mentioned in 'RFC4342'. == Outdated reference: A later version (-06) exists of draft-ietf-dccp-tfrc-faster-restart-04 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: 18 May 2008 UCLA 6 18 November 2007 8 Profile for Datagram Congestion Control Protocol (DCCP) 9 Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) 10 draft-ietf-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 18 May 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies an experimental profile for Congestion 44 Control Identifier 4, the Small-Packet variant of TCP-Friendly Rate 45 Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). 46 CCID 4 is for experimental use, and uses TFRC-SP [RFC4828], a variant 47 of TFRC designed for applications that send small packets. CCID 4 is 48 considered experimental because TFRC-SP is itself experimental, and 49 is not proposed for widespread deployment in the global Internet at 50 this time. The goal for TFRC-SP is to achieve roughly the same 51 bandwidth in bits per second (bps) as a TCP flow using packets of up 52 to 1500 bytes but experiencing the same level of congestion. CCID 4 53 is for experimental use for senders that send small packets and would 54 like a TCP-friendly sending rate, possibly with Explicit Congestion 55 Notification (ECN), while minimizing abrupt rate changes. 57 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 59 Changes from draft-ietf-dccp-ccid4-00.txt: 61 * Added that the RFC 4342 errata applies to CCID 4 as well. From 62 email from Leandro Sales. 64 * Added the phrase "If the sender is calculating the loss event rate 65 itself" to a non-normative description in Section 5. Feedback from 66 Gerrit Renker. 68 * Deleted the Send Dropped Packets feature, since it is not used in 69 CCID 4. In CCID 4, the Dropped Packets option is mandatory. 71 Changes from draft-floyd-dccp-ccid4-01.txt: 73 * Title changed to draft-ietf-dccp-ccid4-00.txt. 75 * Incorporated material from draft-kohler-dccp-ccid3-drops-01.txt. 77 * Added a reference to RFC3448bis. 79 * Added a sentence saying that this is Experimental because TFRC-SP 80 is Experimental. 82 * General editing in response to feedback from Gorry. 84 Changes from draft-floyd-dccp-ccid4-00.txt: 86 * Added a subsection describing calculation of the average loss 87 interval in TFRC-SP. 89 * Changed the assumed DCCP-Data header size from 12 bytes to 16 90 bytes, for 48-bit sequence numbers. Feedback from Ian McDonald. 92 * Added that the CCID4 sender can send two packets in a burst, if 93 limited by OS granularity. From Ian McDonald. 95 * Added that the implementor may track Faster Restart and implement 96 it before an explicit update to the CCID4 RFC. From Ian McDonald. 98 * Added an example to Section 8.4 of when errors can occur in using 99 the Window Counter to detect loss intervals of at most two round-trip 100 times. 102 Changes from draft-floyd-ccid4-00.txt: 104 * Added the Dropped Packets option for reporting the number of 105 packets dropped in a loss interval. 107 * Added examples to Section 8.4 of the receiver incorrectly inferring 108 whether a loss interval was short or not. 110 END OF SECTION TO BE DELETED. 112 Table of Contents 114 1. Introduction ....................................................6 115 2. Conventions .....................................................6 116 3. Usage ...........................................................7 117 3.1. Relationship with TFRC .....................................7 118 3.2. Example Half-Connection ....................................7 119 4. Connection Establishment ........................................8 120 5. Congestion Control on Data Packets ..............................8 121 5.1. Response to Idle and Application-limited Periods ..........10 122 5.2. Response to Data Dropped and Slow Receiver ................10 123 5.3. Packet Sizes ..............................................10 124 6. Acknowledgements ...............................................10 125 6.1. Loss Interval Definition ..................................10 126 6.2. Congestion Control on Acknowledgements ....................11 127 6.3. Acknowledgements of Acknowledgements ......................11 128 6.4. Quiescence ................................................11 129 7. Explicit Congestion Notification ...............................11 130 8. Options and Features ...........................................11 131 8.1. Window Counter Value ......................................12 132 8.2. Elapsed Time Options ......................................12 133 8.3. Receive Rate Option .......................................13 134 8.4. Send Loss Event Rate Feature ..............................13 135 8.5. Loss Event Rate Option ....................................13 136 8.6. Loss Intervals Option .....................................13 137 8.7. Dropped Packets Option ....................................14 138 8.7.1. Example ............................................15 139 9. Verifying Congestion Control Compliance With ECN ...............16 140 9.1. Verifying the ECN Nonce Echo ..............................16 141 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 142 ................................................................17 143 10. Implementation Issues .........................................17 144 10.1. Timestamp Usage ..........................................17 145 10.2. Determining Loss Events at the Receiver ..................17 146 10.3. Sending Feedback Packets .................................17 147 11. Security Considerations .......................................17 148 12. IANA Considerations ...........................................17 149 12.1. Reset Codes ..............................................17 150 12.2. Option Types .............................................18 151 12.3. Feature Numbers ..........................................18 152 13. Thanks ........................................................18 153 Normative References ..............................................18 154 Informative References ............................................19 155 Authors' Addresses ................................................20 156 Full Copyright Statement ..........................................20 157 Intellectual Property .............................................20 158 Acknowledgement ...................................................21 160 List of Tables 162 Table 1: DCCP CCID 4 Options ......................................11 163 Table 2: DCCP CCID 4 Feature Numbers ..............................12 165 1. Introduction 167 This document contains the profile for Congestion Control Identifier 168 4, TCP-Friendly Rate Control for Small Packets (TFRC-SP), in the 169 Datagram Congestion Control Protocol (DCCP) [RFC4340]. CCID 4 170 differs from CCID 3 in that CCID 4 uses TFRC-SP, the Small-Packet 171 variant of TFRC, while CCID 3 [RFC4342] uses standard TFRC [RFC3448]. 172 This document assumes that the reader is familiar with [RFC4342], 173 instead of repeating from that document unnecessarily. 175 CCID 4 differs from CCID 3 only in the following respects: 177 o Header size: For TFRC-SP, the allowed transmit rate in bytes per 178 second is reduced by a factor that accounts for packet header 179 size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], 180 and described for CCID 4 in Section 5 below. 182 o Minimum sending rate: TFRC-SP enforces a minimum interval of 183 10 milliseconds between data packets. This is specified for TFRC- 184 SP in Section 4.3 of [RFC4828], and described for CCID 4 in 185 Section 5 below. 187 o Loss rates for short loss intervals: For short lost intervals of 188 at most two round-trip times, the loss rate is computed by 189 counting the actual number of packets lost or marked. For such a 190 short loss interval with N data packets, including K lost or 191 marked data packets, the loss interval length is calculated as 192 N/K, instead of as N. This is specified for TFRC-SP in Section 193 4.4 of [RFC4828]. If the sender is computing the loss event rate, 194 the Dropped Packets option specified in Section 8.7 is required, 195 in addition to the default CCID 3's Loss Intervals option. 196 Section 8.7 describes the use of the Dropped Packets option in 197 calculating the loss event rate. The computation of the loss rate 198 by the receiver for the Loss Event Rate option is described for 199 CCID 4 in Section 8.4 below. 201 o The nominal segment size: In TFRC-SP, the nominal segment size 202 used by the TCP throughput equation is set to 1460 bytes. This is 203 specified for TFRC-SP in Section 4.5 of [RFC3448], and described 204 for CCID 4 in Section 5 below. 206 2. Conventions 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 Additional terminology is described in Section 2 of [RFC4342]. 214 3. Usage 216 Like CCID 3, CCID 4's congestion control is appropriate for flows 217 that would prefer to minimize abrupt changes in the sending rate, 218 including streaming media applications with small or moderate 219 receiver buffering before playback. 221 CCID 4 is designed to be used either by applications that use a small 222 fixed segment size, or by applications that change their sending rate 223 by varying the segment size. If CCID 4 is used by an application 224 that varies its segment size in response to changes in the allowed 225 sending rate in bps, we note that CCID 4 doesn't dictate the segment 226 size to be used by the application; this is done by the application 227 itself. The CCID 4 sender determines the allowed sending rate in 228 bps, in response to on-going feedback from the CCID 4 receiver, and 229 the application can use information about the current allowed sending 230 rate to decide whether to change the current segment size. 232 We note that in some environments there will be a feedback loop, with 233 changes in the packet size or in the sending rate in bps affecting 234 congestion along the path, therefore affecting the allowed sending 235 rate in the future. 237 3.1. Relationship with TFRC 239 The congestion control mechanisms described here follow the TFRC-SP 240 mechanism specified in [RFC4828]. As with CCID 3, conformant CCID 4 241 implementations MAY track updates to the TCP throughput equation 242 directly, as updates are standardized in the IETF, rather than 243 waiting for revisions of this document. This document is based on 244 CCID 3 [RFC4342] as modified by the RFC 4342 Errata [RFC4342Errat], 245 and on TFRC [RFC3448] as modified by the RFC 3448 Errata 246 [RFC3448Errat]. (We don't expect that errata would be added to CCID 247 3 that didn't apply to CCID 4, but if this should happen, we would 248 say this explicitly in the errata.) If [RFC3448bis] is standardized 249 in the IETF as a revision of [RFC3448], then [RFC3448bis] MAY be 250 implemented with CCID4 without having to wait for an explicit update 251 to this document. 253 3.2. Example Half-Connection 255 This example shows the typical progress of a half-connection using 256 CCID 4's TFRC Congestion Control, not including connection initiation 257 and termination. The example is informative, not normative. This 258 example differs from that for CCID 3 in [RFC4342] only in that the 259 allowed transmit rate is determined by [RFC4828] as well as by 261 [RFC3448]. 263 1. The sender transmits DCCP-Data packets, where the sending rate is 264 governed by the allowed transmit rate as specified in [RFC4828]. 265 Each DCCP-Data packet has a sequence number, and the DCCP header's 266 CCVal field contains the window counter value, used by the 267 receiver in determining when multiple losses belong in a single 268 loss event. 270 In the typical case of an ECN-capable half-connection, each DCCP- 271 Data and DCCP-DataAck packet is sent as ECN-Capable, with either 272 the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce 273 with TFRC is described in Section 9. 275 2. The receiver sends DCCP-Ack packets acknowledging the data packets 276 at least once per round-trip time, unless the sender is sending at 277 a rate of less than one packet per round-trip time [RFC3448] 278 (Section 6). Each DCCP-Ack packet uses a sequence number, 279 identifies the most recent packet received from the sender, and 280 includes feedback about the recent loss intervals experienced by 281 the receiver. 283 3. The sender continues sending DCCP-Data packets as controlled by 284 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 285 sender updates its allowed transmit rate as specified in [RFC3448] 286 (Section 4.3) and [RFC4828]. This update is based upon a loss 287 event rate calculated by the sender, based on the receiver's loss 288 intervals feedback. If it prefers, the sender can also use a loss 289 event rate calculated and reported by the receiver. 291 4. The sender estimates round-trip times and calculates a nofeedback 292 time, as specified in [RFC3448] (Section 4.4). If no feedback is 293 received from the receiver in that time (at least four round-trip 294 times), the sender halves its sending rate. 296 4. Connection Establishment 298 The connection establishment is as specified in Section 4 of 299 [RFC4342]. 301 5. Congestion Control on Data Packets 303 CCID 4 uses the congestion control mechanisms of TFRC [RFC3448] and 304 TFRC-SP [RFC4828]. [RFC4828] MUST be considered normative except 305 where specifically indicated. 307 Loss Event Rate 308 As with CCID 3, the basic operation of CCID 4 centers around the 309 calculation of a loss event rate: the number of loss events as a 310 fraction of the number of packets transmitted, weighted over the last 311 several loss intervals. For CCID 4, this loss event rate, a round- 312 trip time estimate, and a nominal packet size of 1460 bytes are 313 plugged into the TCP throughput equation, as specified in RFC 3448 314 (Section 3.1) and [RFC4828]. 316 Because CCID 4 is intended for applications that send small packets, 317 the allowed transmit rate derived from the TCP throughput equation is 318 reduced by a factor that accounts for packet header size, as 319 specified in Section 4.2 of [RFC4828]. The header size on data 320 packets is estimated as 36 bytes (20 bytes for the IP header, and 16 321 bytes for the DCCP-Data header with 48-bit sequence numbers). If the 322 DCCP sender is sending N-byte data packets, the allowed transmit rate 323 is reduced by N/(N+36). CCID 4 senders are limited to this fair 324 rate. The header size would be 32 bytes instead of 36 bytes when 325 24-bit sequence numbers were used in the DCCP-Data header. 327 As explained in Section 4.2 of [RFC4828], the actual header could be 328 larger or smaller than the assumed value, due to IP or DCCP options, 329 IPv6, IP tunnels, header compression, and the like. Because we are 330 only aiming at rough fairness, and at a rough incentive for 331 applications, the default use of a 32-byte or 36-byte header in the 332 calculations of the header bandwidth is sufficient for both IPv4 and 333 IPv6. 335 If the sender is calculating the loss event rate itself, the loss 336 event rate can be calculated using recent loss interval lengths 337 reported by the receiver. Loss intervals are precisely defined in 338 Section 6.1 of [RFC4342], with the modification in [RFC4828] 339 (Section 3) for loss intervals of at most two round-trip times. In 340 summary, a loss interval is up to 1 RTT of possibly lost or ECN- 341 marked data packets, followed by an arbitrary number of non-dropped, 342 non-marked data packets. The CCID 3 Loss Intervals option is used to 343 report loss interval lengths; see Section 8.6. 345 For loss intervals of at most two round-trip times, CCID 4 calculates 346 the loss event rate for that interval by counting the number of 347 packets lost or marked, as described in Section 4.4 of [RFC4828]. 348 Thus, for such a short loss interval with N data packets, including K 349 lost or marked data packets, the loss interval length is calculated 350 as N/K, instead as N. The Dropped Packets option is used to report 351 K, the count of lost or marked data packets. 353 Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms 354 between data packets, regardless of the allowed transmit rate. If 355 operating system scheduling granularity makes this impractical, up to 356 one additional packet MAY be sent per timeslice, providing that no 357 more than three packets are sent in any 30 ms interval. 359 Other Congestion Control Mechanisms 361 The other congestion control mechanisms such as slow-start, feedback 362 packets, and the like are exactly as in CCID 3, and are described in 363 the subsection on "Other Congestion Control Mechanisms" of Section 5 364 in [RFC4342]. 366 5.1. Response to Idle and Application-limited Periods 368 This is described in Section 5.1 of [RFC4342]. If Faster Restart is 369 standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be 370 implemented in CCID4 without having to wait for an explicit update to 371 this document. 373 5.2. Response to Data Dropped and Slow Receiver 375 This is described in Section 5.2 of [RFC4342]. 377 5.3. Packet Sizes 379 CCID 4 is intended for applications that use a fixed small segment 380 size, or that vary their segment size in response to congestion. 382 The CCID 4 sender uses a segment size of 1460 bytes in the TCP 383 throughput equation. This gives the CCID 4 sender roughly the same 384 sending rate in bytes per second as a TFRC flow using 1460-byte 385 segments but experiencing the same packet drop rate. 387 6. Acknowledgements 389 The acknowledgements are as specified in Section 6 of [RFC4342] with 390 the exception of the Loss Interval lengths specified below. 392 6.1. Loss Interval Definition 394 The loss interval definition is as defined in Section 6.1 of 395 [RFC4342], except as specified below. Section 6.1.1 of RFC 4342 396 specifies that for all loss intervals except the first one, the data 397 length equals the sequence length minus the number of non-data 398 packets the sender transmitted during the loss interval, with a 399 minimum data length of one packet. For TFRC-SP, for short loss 400 intervals of at most two round-trip times, the loss interval length 401 is computed not as the data length of the loss interval, but instead 402 as the data length divided by the number of dropped or marked data 403 packets. 405 Section 5.4 of RFC 4342 described when to use the most recent loss 406 interval in the calculation of the average loss interval. [RFC4828] 407 adds to this procedure the restriction that the most recent loss 408 interval is only used in the calculation of the average loss interval 409 if the most recent loss interval is greater than two round-trip 410 times. The pseudocode is given in Section 3 of [RFC4828]. 412 6.2. Congestion Control on Acknowledgements 414 The congestion control on acknowledgements is as specified in Section 415 6.2 of [RFC4342]. 417 6.3. Acknowledgements of Acknowledgements 419 Procedures for the acknowledgement of acknowledgements are as 420 specified in Section 6.3 of [RFC4342]. 422 6.4. Quiescence 424 The procedure for detecting that the sender has gone quiescent is as 425 specified in Section 6.4 of [RFC4342]. 427 7. Explicit Congestion Notification 429 Procedures for the use of Explicit Congestion Notification (ECN) are 430 as specified in Section 7 of [RFC4342]. 432 8. Options and Features 434 CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, 435 and Elapsed Time options, and its Send Ack Vector and ECN Incapable 436 features. CCID 4 also imports the currently defined CCID 3-specific 437 options and features [RFC4342], augmented by the Dropped Packets 438 option specified in this document. Each CCID 4-specific option and 439 feature contains the same data as the corresponding CCID 3 option or 440 feature, and is interpreted in the same way, except as specified 441 elsewhere in this document. 443 Option DCCP- Section 444 Type Length Meaning Data? Reference 445 ----- ------ ------- ----- --------- 446 128-191 Reserved 447 192 6 Loss Event Rate N 8.5 448 193 variable Loss Intervals N 8.6 449 194 6 Receive Rate N 8.3 450 195 variable Dropped Packets N 8.7 451 196-255 Reserved 453 Table 1: DCCP CCID 4 Options 454 The "DCCP-Data?" column indicates that all currently defined 455 CCID 4-specific options MUST be ignored when they occur on DCCP-Data 456 packets. 458 As with CCID 3, the following CCID-specific features are also 459 defined. 461 Rec'n Initial Section 462 Number Meaning Rule Value Req'd Reference 463 ------ ------- ----- ----- ----- --------- 464 128-191 Reserved 465 192 Send Loss Event Rate SP 0 N 8.4 466 193-255 Reserved 468 Table 2: DCCP CCID 4 Feature Numbers 470 More information is available in Section 8 of [RFC4342]. 472 8.1. Window Counter Value 474 The use of the Window Counter Value in the DCCP generic header's 475 CCVal field is as specified in Section 8.1 of [RFC4342]. In addition 476 to their use described in CCID 3, the CCVal counters are used by the 477 receiver in CCID 4 to determine when the length of a loss interval is 478 at most two round-trip times. None of these procedures require the 479 receiver to maintain an explicit estimate of the round-trip time. 480 However, Section 8.1 of [RFC4342] gives a procedure that implementors 481 may use if they wish to keep such an RTT estimate using CCVal. 483 8.2. Elapsed Time Options 485 The use of the Elapsed Time option is defined in Section 8.2 of 486 [RFC4342]. 488 8.3. Receive Rate Option 490 The Receive Rate option is as specified in Section 8.3 of [RFC4342]. 492 8.4. Send Loss Event Rate Feature 494 The Send Loss Event Rate feature is as defined in Section 8.4 of 495 [RFC4342]. 497 See [RFC3448], Section 5 and [RFC4828], Section 4.4 for a normative 498 calculation of the loss event rate. Section 4.4 of [RFC4828] 499 modifies the calculation of the loss interval size for loss intervals 500 of at most two round-trip times. 502 If the CCID 4 receiver is using the Loss Event Rate option, the 503 receiver needs to be able to determine if a loss interval is short, 504 of at most two round-trip times. The receiver can heuristically 505 detect a short loss interval by using the Window Counter in arriving 506 data packets. The sender increases the Window Counter by 1 every 507 quarter of a round-trip time, with the caveat that the Window Counter 508 is never increased by more than five, modulo 16, from one data packet 509 to the next. Using the Window Counter to detect loss intervals of at 510 most two round-trip times could result in some false positives, with 511 some longer loss intervals incorrectly identified as short ones. For 512 example, if the loss interval contained data packets with only two 513 Window Counter values, say, k and k+5, then the receiver could not 514 tell if the loss interval was at most two round-trip times long or 515 not. Similarly, if the sender sent data packets with Window Counter 516 values of 4, 8, 12, 0, 5, but the packets with Window Counter values 517 of 8, 12, and 0 were lost in the network, then the receiver would 518 only receive data packets with Window Counter values of 4 and 5, and 519 would incorrectly infer that the loss interval was at most two round- 520 trip times. 522 8.5. Loss Event Rate Option 524 The Loss Event Rate option is as specified in Section 8.5 of 525 [RFC4342]. 527 See [RFC3448] (Section 5) and [RFC4828] for a normative calculation 528 of the loss event rate. 530 8.6. Loss Intervals Option 532 The Loss Intervals option is as specified in Section 8.6 of 533 [RFC4342]. 535 8.7. Dropped Packets Option 537 This section describes the Dropped Packets option, a mechanism for 538 reporting the number of lost and marked packets per loss interval. 539 By reporting both the Loss Intervals and Dropped Packets options on 540 the feedback packets, the receiver gives the sender sufficient 541 information to calculate the loss event rate, or to verify the 542 calculation of the reported loss event rate, if the sender so 543 desires. 545 The core information reported by CCID 4 receivers is a list of recent 546 loss intervals, where a loss interval begins with a lost or ECN- 547 marked data packet; continues with at most one round-trip time's 548 worth of packets that may or may not be lost or marked; and completes 549 with an arbitrarily long series of non-dropped, non-marked data 550 packets. Loss intervals model the congestion behavior of TCP NewReno 551 senders, which reduce their sending rate at most once per window of 552 data packets. Consequently, the number of packets lost in a loss 553 interval is not important for either TCP's or TFRC's congestion 554 response. CCID 3's Loss Intervals option reports the length of each 555 loss interval's lossy part, not the number of packets that were 556 actually lost or marked in that lossy part. 558 However, for computing the loss event rate for periods that include 559 short loss intervals the TFRC-SP sender needs to know the number of 560 packets lost or marked in a loss interval, over and above the length 561 of the loss interval in packets. The Dropped Packets option, a 562 CCID 4-specific option, reports this information. Together with the 563 existing Loss Intervals option, the Dropped Packets option allows the 564 CCID 4 sender to discover exactly how many packets were dropped from 565 each loss interval. The receiver reports the number of lost or 566 marked packets in its recently observed loss intervals using the 567 Dropped Packets option. 569 The Dropped Packets Option is specified as follows: 571 +--------+--------+-------...-------+--------+------- 572 |11000011| Length | Drop Count | More Drop Counts... 573 +--------+--------+-------...-------+--------+------- 574 Type=195 3 bytes 576 The Dropped Packets option contains information about one to 84 577 consecutive loss intervals, always including the most recent loss 578 interval. As with the Loss Intervals option, intervals are listed in 579 reverse chronological order. Should more than 84 loss intervals need 580 to be reported, multiple Dropped Packets options can be sent; the 581 second option begins where the first left off, and so forth. 583 One Drop Count is specified per loss interval. Drop Count is a 584 24-bit number that equals the number of packets lost or received ECN- 585 marked during the corresponding loss interval. By definition, this 586 number MUST NOT exceed the corresponding loss interval's Loss Length. 588 CCID 4 receivers MUST report Dropped Packets options with every 589 feedback packet. Any packet containing a Loss Intervals option MUST 590 also contain a Dropped Packets option covering the same loss 591 intervals. If a feedback packet does not include a relevant Dropped 592 Packets option, and the CCID 4 sender is computing the loss event 593 rate itself, the sender MUST treat the relevant loss intervals' Drop 594 Counts as equal to the corresponding Loss Lengths, as specified 595 below. This conservative assumption leads to the minimum send rate 596 for the corresponding loss intervals. 598 Consider a CCID 4 receiver. As specified in Section 8.6.1 of RFC 599 4342, the receiver sends the Loss Intervals option for all intervals 600 that have not been acknowledged by the sender. When this receiver 601 sends a feedback packet containing information about the N most 602 recent loss intervals (packaged in one or more Loss Intervals 603 options), then the receiver includes on the same feedback packet one 604 or more Dropped Packets options covering exactly those N loss 605 intervals. CCID 4 senders MUST ignore Drop Counts information for 606 loss intervals not covered by a Loss Intervals option on the same 607 feedback packet. Conversely, a CCID 4 sender might want to 608 interpolate Drop Counts information for a loss interval not covered 609 by any Dropped Packets options; such a sender MUST use the 610 corresponding loss interval's Loss Length as its Drop Count. 612 Each loss interval's Drop Count MUST by definition be less than or 613 equal to its Loss Length. A Drop Count that exceeds the 614 corresponding Loss Length MUST be treated as equal to the Loss 615 Length. 617 8.7.1. Example 619 Consider the following sequence of packets, where "-" represents a 620 safely delivered packet and "*" represents a lost or marked packet. 621 This sequence is repeated from [RFC4342]. 623 Sequence 624 Numbers: 0 10 20 30 40 44 625 | | | | | | 626 ----------*--------***-*--------*----------*- 628 Assuming that packet 43 was lost, not marked, this sequence might be 629 divided into loss intervals as follows: 631 0 10 20 30 40 44 632 | | | | | | 633 ----------*--------***-*--------*----------*- 634 \________/\_______/\___________/\_________/ 635 L0 L1 L2 L3 637 A Loss Intervals option sent on a packet with Acknowledgement Number 638 44 to acknowledge this set of loss intervals might contain the bytes 639 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 640 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15; for interpretation of this 641 option, see [RFC4342]. A Dropped Packets option sent in tandem on 642 this packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 643 0,0,0. This is interpreted as follows. 645 195 The Dropped Packets option number. 647 14 The length of the option, including option type and length bytes. 648 This option contains information about (14 - 2)/3 = 4 loss 649 intervals. Note that the two most recent sequence numbers are 650 not yet part of any loss interval -- the Loss Intervals option 651 includes them in its Skip Length -- and are thus not included in 652 the Dropped Packets option. 654 0,0,1 655 These bytes define the Drop Count for L3, which is 1. As 656 required, the Drop Count is less than or equal to L3's Loss 657 Length, which is also 1. 659 0,0,4 660 The Drop Count for L2 is 4. 662 0,0,1 663 The Drop Count for L1 is 1. 665 0,0,0 666 Finally, the Drop Count for L0 is 0. 668 9. Verifying Congestion Control Compliance With ECN 670 Verifying congestion control compliance with ECN is as discussed in 671 Section 9 of [RFC4342]. 673 9.1. Verifying the ECN Nonce Echo 675 Procedures for verifying the ECN Nonce Echo are as specified in 676 Section 9.1 of [RFC4342]. 678 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 680 Section 9.2 of [RFC4342] discusses the sender's possible verification 681 of loss intervals and loss event rate information reported by the 682 receiver. 684 10. Implementation Issues 686 10.1. Timestamp Usage 688 The use of the Timestamp option is as discussed in Section 10.1 of 689 [RFC4342]. 691 10.2. Determining Loss Events at the Receiver 693 The use of the window counter by the receiver to determine if 694 multiple lost packets belong to the same loss event is as described 695 in Section 10.2 of [RFC4342]. 697 10.3. Sending Feedback Packets 699 The procedure for sending feedback packets is as described in Section 700 10.3 of [RFC4342]. 702 11. Security Considerations 704 Security considerations include those discussed in Section 11 of 705 [RFC4342]. There are no new security considerations introduced by 706 CCID 4. 708 12. IANA Considerations 710 This specification defines the value 4 in the DCCP CCID namespace 711 managed by IANA. 713 CCID 4 also uses three sets of numbers whose values should be 714 allocated by IANA, namely CCID 4-specific Reset Codes, option types, 715 and feature numbers. This document makes no particular allocations 716 from the Reset Code range, except for experimental and testing use 717 [RFC3692]. We refer to the Standards Action policy outlined in 718 [RFC2434]. 720 12.1. Reset Codes 722 Each entry in the DCCP CCID 4 Reset Code registry contains a 723 CCID 4-specific Reset Code, which is a number in the range 128-255; a 724 short description of the Reset Code; and a reference to the RFC 725 defining the Reset Code. Reset Codes 184-190 and 248-254 are 726 permanently reserved for experimental and testing use. The remaining 727 Reset Codes -- 128-183, 191-247, and 255 -- are currently reserved, 728 and should be allocated with the Standards Action policy, which 729 requires IESG review and approval and standards-track IETF RFC 730 publication. 732 12.2. Option Types 734 Each entry in the DCCP CCID 4 option type registry contains a 735 CCID 4-specific option type, which is a number in the range 128-255; 736 the name of the option, such as "Loss Intervals"; and a reference to 737 the RFC defining the option type. The registry is initially 738 populated using the values in Table 1, in Section 8. This includes 739 the value 195 allocated for the Dropped Packets option. This 740 document allocates option types 192-195, and option types 184-190 and 741 248-254 are permanently reserved for experimental and testing use. 742 The remaining option types -- 128-183, 191, 196-247, and 255 -- are 743 currently reserved, and should be allocated with the Standards Action 744 policy, which requires IESG review and approval and standards-track 745 IETF RFC publication. 747 12.3. Feature Numbers 749 Each entry in the DCCP CCID 4 feature number registry contains a 750 CCID 4-specific feature number, which is a number in the range 751 128-255; the name of the feature, such as "Send Loss Event Rate"; and 752 a reference to the RFC defining the feature number. The registry is 753 initially populated using the values in Table 2, in Section 8. This 754 document allocates feature number 192, and feature numbers 184-190 755 and 248-254 are permanently reserved for experimental and testing 756 use. The remaining feature numbers -- 128-183, 191, 193-247, and 255 757 -- are currently reserved, and should be allocated with the Standards 758 Action policy, which requires IESG review and approval and standards- 759 track IETF RFC publication. 761 13. Thanks 763 We thank Gorry Fairhurst, Ian McDonald, Gerrit Renker, and Leandro 764 Sales for feedback on this document. 766 Normative References 768 [RFC2119] S. Bradner. Key Words For Use in RFCs to Indicate 769 Requirement Levels. RFC 2119. 771 [RFC2434] T. Narten and H. Alvestrand. Guidelines for Writing 772 an IANA Considerations Section in RFCs. RFC 2434. 774 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 775 Friendly Rate Control (TFRC): Protocol Specification, 776 RFC 3448, Proposed Standard, January 2003. 778 [RFC3448Errat] RFC Errata for RFC 3448, URL "http://www.rfc- 779 editor.org/errata.php". 781 [RFC3692] T. Narten. Assigning Experimental and Testing Numbers 782 Considered Useful. RFC 3692. 784 [RFC4340] Kohler, E., Handley, M., and S. Floyd. Datagram 785 Congestion Control Protocol (DCCP), RFC 4340, March 786 2006. 788 [RFC4342] Floyd, S., Kohler, E., and J. Padhye. Profile for 789 Datagram Congestion Control Protocol (DCCP) Congestion 790 Control ID 3: TCP-Friendly Rate Control (TFRC), RFC 791 4342, March 2006. 793 [RFC4342Errat] RFC Errata for RFC 4342, URL "http://www.rfc- 794 editor.org/errata.php". 796 [RFC4828] S. Floyd and E. Kohler. TCP Friendly Rate Control 797 (TFRC): the Small-Packet (SP) Variant. RFC 4828, 798 April 2007. 800 Informative References 802 [KFS07] Kohler, E., S. Floyd, and A. Sathiaseelan, Faster 803 Restart for TCP Friendly Rate Control (TFRC), 804 Internet-draft draft-ietf-dccp-tfrc-faster- 805 restart-04.txt, work-in-progress, September 2007. 807 [RFC3448bis] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 808 Friendly Rate Control (TFRC): Protocol Specification, 809 internet-draft draft-ietf-dccp-rfc3448bis-02.txt, 810 work-in-progress, July 2007. 812 Authors' Addresses 814 Sally Floyd 815 ICSI Center for Internet Research 816 1947 Center Street, Suite 600 817 Berkeley, CA 94704 818 USA 820 Email: floyd@icir.org 822 Eddie Kohler 823 4531C Boelter Hall 824 UCLA Computer Science Department 825 Los Angeles, CA 90095 826 USA 828 Email: kohler@cs.ucla.edu 830 Full Copyright Statement 832 Copyright (C) The IETF Trust (2007). 834 This document is subject to the rights, licenses and restrictions 835 contained in BCP 78, and except as set forth therein, the authors 836 retain all their rights. 838 This document and the information contained herein are provided on an 839 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 840 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 841 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 842 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 843 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 844 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 846 Intellectual Property 848 The IETF takes no position regarding the validity or scope of any 849 Intellectual Property Rights or other rights that might be claimed to 850 pertain to the implementation or use of the technology described in 851 this document or the extent to which any license under such rights 852 might or might not be available; nor does it represent that it has 853 made any independent effort to identify any such rights. Information 854 on the procedures with respect to rights in RFC documents can be 855 found in BCP 78 and BCP 79. 857 Copies of IPR disclosures made to the IETF Secretariat and any 858 assurances of licenses to be made available, or the result of an 859 attempt made to obtain a general license or permission for the use of 860 such proprietary rights by implementers or users of this 861 specification can be obtained from the IETF on-line IPR repository at 862 http://www.ietf.org/ipr. 864 The IETF invites any interested party to bring to its attention any 865 copyrights, patents or patent applications, or other proprietary 866 rights that may cover technology that may be required to implement 867 this standard. Please address the information to the IETF at ietf- 868 ipr@ietf.org. 870 Acknowledgement 872 Funding for the RFC Editor function is provided by the IETF 873 Administrative Support Activity (IASA).