idnits 2.17.1 draft-ietf-dccp-ccid4-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 July 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Duplicate reference: RFC5348, mentioned in 'RFC5348', was also mentioned in 'RFC3448'. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: 2 January 2010 UCLA 6 2 July 2009 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-05.txt 12 Status of This Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 19 10, 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on 2 January 2010. 47 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document specifies a profile for Congestion Control Identifier 61 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in 62 the Datagram Congestion Control Protocol (DCCP). CCID 4 is for 63 experimental use, and uses TFRC-SP [RFC4828], a variant of TFRC 64 designed for applications that send small packets. CCID 4 is 65 considered experimental because TFRC-SP is itself experimental, and 66 is not proposed for widespread deployment in the global Internet at 67 this time. The goal for TFRC-SP is to achieve roughly the same 68 bandwidth in bits per second (bps) as a TCP flow using packets of up 69 to 1500 bytes but experiencing the same level of congestion. CCID 4 70 is for use for senders that send small packets and would like a TCP- 71 friendly sending rate, possibly with Explicit Congestion Notification 72 (ECN), while minimizing abrupt rate changes. 74 Table of Contents 76 1. Introduction ....................................................6 77 2. Conventions .....................................................7 78 3. Usage ...........................................................7 79 3.1. Relationship with TFRC and TFRC-SP .........................7 80 3.2. Example Half-Connection ....................................7 81 4. Connection Establishment ........................................8 82 5. Congestion Control on Data Packets ..............................8 83 5.1. Response to Idle and Application-limited Periods ..........10 84 5.2. Response to Data Dropped and Slow Receiver ................10 85 5.3. Packet Sizes ..............................................10 86 6. Acknowledgements ...............................................10 87 6.1. Loss Interval Definition ..................................10 88 6.2. Congestion Control on Acknowledgements ....................11 89 6.3. Acknowledgements of Acknowledgements ......................11 90 6.4. Quiescence ................................................11 91 7. Explicit Congestion Notification ...............................11 92 8. Options and Features ...........................................11 93 8.1. Window Counter Value ......................................12 94 8.2. Elapsed Time Options ......................................12 95 8.3. Receive Rate Option .......................................13 96 8.4. Send Loss Event Rate Feature ..............................13 97 8.5. Loss Event Rate Option ....................................13 98 8.6. Loss Intervals Option .....................................13 99 8.7. Dropped Packets Option ....................................14 100 8.7.1. Example ............................................15 101 9. Verifying Congestion Control Compliance With ECN ...............16 102 9.1. Verifying the ECN Nonce Echo ..............................17 103 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 104 ................................................................17 105 10. Implementation Issues .........................................17 106 10.1. Timestamp Usage ..........................................17 107 10.2. Determining Loss Events at the Receiver ..................17 108 10.3. Sending Feedback Packets .................................17 109 11. Design Considerations .........................................17 110 11.1. The Field Size in the Loss Intervals Option ..............17 111 11.2. The Field Size in the Dropped Packets Option .............18 112 12. Experimental Status of this Document ..........................19 113 13. Security Considerations .......................................19 114 14. IANA Considerations ...........................................19 115 14.1. Reset Codes ..............................................20 116 14.2. Option Types .............................................20 117 14.3. Feature Numbers ..........................................20 118 15. Thanks ........................................................20 119 Normative References ..............................................21 120 Informative References ............................................21 121 Authors' Addresses ................................................22 122 Acknowledgement ...................................................22 124 List of Tables 126 Table 1: DCCP CCID 4 Options ......................................11 127 Table 2: DCCP CCID 4 Feature Numbers ..............................12 128 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 130 Changes from draft-ietf-dccp-ccid4-04.txt: 132 * Added captions to figures. IESG General Area review 133 by Miguel Garcia. 135 * Added a sentence about the need for a ccid codepoint 136 for experimentation across the Internet with different 137 codebases. Feedback from Miguel Garcia and Adrian Farrel 138 from IESG review. 140 Changes from draft-ietf-dccp-ccid4-03.txt: 142 * Minor editing from Working Group Last Call. This includes 143 clarification of the use of RFC 5348 instead of RFC 3448. Feedback 144 from Arjuna Sathiaseelan and Gorry Fairhurst. 146 Changes from draft-ietf-dccp-ccid4-02.txt: 148 * Updated boilerplates. 150 * Updated to refer to RFC 5348 instead of RFC 3448. RFC 5348 is now 151 required, instead of RFC 3448. 153 * Added a section on "Experimental Status of this Document." 154 Feedback from Gorry Fairhurst. 156 * Minor editing changes. Feedback from Gorry Fairhurst. 158 * Minor editing, from feedback from Alfred Hoenes. 160 Changes from draft-ietf-dccp-ccid4-01.txt: 162 * Added a Design Considerations section with a discussion on the 163 length of the Drop Count field in the Dropped Packets option, and on 164 the lengths of the fields in the Loss Intervals option. From 165 feedback in the Working Group. 167 Changes from draft-ietf-dccp-ccid4-00.txt: 169 * Added that the RFC 4342 errata applies to CCID 4 as well. From 170 email from Leandro Sales. 172 * Added the phrase "If the sender is calculating the loss event rate 173 itself" to a non-normative description in Section 5. Feedback from 174 Gerrit Renker. 176 * Deleted the Send Dropped Packets feature, since it is not used in 177 CCID 4. In CCID 4, the Dropped Packets option is mandatory. 179 Changes from draft-floyd-dccp-ccid4-01.txt: 181 * Title changed to draft-ietf-dccp-ccid4-00.txt. 183 * Incorporated material from draft-kohler-dccp-ccid3-drops-01.txt. 185 * Added a reference to RFC3448bis. 187 * Added a sentence saying that this is Experimental because TFRC-SP 188 is Experimental. 190 * General editing in response to feedback from Gorry. 192 Changes from draft-floyd-dccp-ccid4-00.txt: 194 * Added a subsection describing calculation of the average loss 195 interval in TFRC-SP. 197 * Changed the assumed DCCP-Data header size from 12 bytes to 16 198 bytes, for 48-bit sequence numbers. Feedback from Ian McDonald. 200 * Added that the CCID 4 sender can send two packets in a burst, if 201 limited by OS granularity. From Ian McDonald. 203 * Added that the implementor may track Faster Restart and implement 204 it before an explicit update to the CCID4 RFC. From Ian McDonald. 206 * Added an example to Section 8.4 of when errors can occur in using 207 the Window Counter to detect loss intervals of at most two round-trip 208 times. 210 Changes from draft-floyd-ccid4-00.txt: 212 * Added the Dropped Packets option for reporting the number of 213 packets dropped in a loss interval. 215 * Added examples to Section 8.4 of the receiver incorrectly inferring 216 whether a loss interval was short or not. 218 END OF SECTION TO BE DELETED. 220 1. Introduction 222 This document specifies an experimental profile for Congestion 223 Control Identifier 4, TCP-Friendly Rate Control for Small Packets 224 (TFRC-SP), in the Datagram Congestion Control Protocol (DCCP) 225 [RFC4340]. CCID 4 is a modified version of Congestion Control 226 Identifier 3, CCID 3, which has been specified in [RFC4342]. This 227 document assumes that the reader is familiar with CCID 3, instead of 228 repeating from that document unnecessarily. 230 CCID 3 uses TCP Friendly Rate Control (TFRC), which is now specified 231 in RFC 5348 [RFC5348]. CCID 4 differs from CCID 3 in that CCID 4 232 uses TFRC-SP [RFC4828], an experimental, small-packet variant of 233 TFRC. The original specification of TFRC, RFC 3448 [RFC3448], has 234 been obsoleted by RFC 5348. The CCID 3 and TFRC-SP documents both 235 predate RFC 5348 and refer instead to RFC 3448 for the specification 236 of TFRC. However, this document assumes that RFC 5348 will be used 237 instead of RFC 3448 for the specification of TFRC. 239 CCID 4 differs from CCID 3 only in the following respects: 241 o Header size: For TFRC-SP, the allowed transmit rate in bytes per 242 second is reduced by a factor that accounts for packet header 243 size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], 244 and described for CCID 4 in Section 5 below. 246 o Maximum sending rate: TFRC-SP enforces a minimum interval of 247 10 milliseconds between data packets. This is specified for TFRC- 248 SP in Section 4.3 of [RFC4828], and described for CCID 4 in 249 Section 5 below. 251 o Loss rates for short loss intervals: For short loss intervals of 252 at most two round-trip times, the loss rate is computed by 253 counting the actual number of packets lost or marked. For such a 254 short loss interval with N data packets, including K lost or 255 marked data packets, the loss interval length is calculated as 256 N/K, instead of as N. This is specified for TFRC-SP in Section 257 4.4 of [RFC4828]. If the sender is computing the loss event rate, 258 the Dropped Packets option specified in Section 8.7 is required, 259 in addition to the default CCID 3's Loss Intervals option. 260 Section 8.7 describes the use of the Dropped Packets option in 261 calculating the loss event rate. The computation of the loss rate 262 by the receiver for the Loss Event Rate option is described for 263 CCID 4 in Section 8.4 below. 265 o The nominal segment size: In TFRC-SP, the nominal segment size 266 used by the TCP throughput equation is set to 1460 bytes. This is 267 specified for TFRC-SP in Section 4.5 of [RFC4828], and described 268 for CCID 4 in Section 5 below. 270 2. Conventions 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in [RFC2119]. 276 Additional terminology is described in Section 2 of [RFC4342]. 278 3. Usage 280 Like CCID 3, CCID 4's congestion control is appropriate for flows 281 that would prefer to minimize abrupt changes in the sending rate, 282 including streaming media applications with small or moderate 283 receiver buffering before playback. 285 CCID 4 is designed to be used either by applications that use a small 286 fixed segment size, or by applications that change their sending rate 287 by varying the segment size. If CCID 4 is used by an application 288 that varies its segment size in response to changes in the allowed 289 sending rate in bps, we note that CCID 4 doesn't dictate the segment 290 size to be used by the application; this is done by the application 291 itself. The CCID 4 sender determines the allowed sending rate in 292 bps, in response to on-going feedback from the CCID 4 receiver, and 293 the application can use information about the current allowed sending 294 rate to decide whether to change the current segment size. 296 We note that in some environments there will be a feedback loop, with 297 changes in the packet size or in the sending rate in bps affecting 298 congestion along the path, therefore affecting the allowed sending 299 rate in the future. 301 3.1. Relationship with TFRC and TFRC-SP 303 The congestion control mechanisms described here follow the TFRC-SP 304 mechanism specified in [RFC4828]. As with CCID 3, conformant CCID 4 305 implementations MAY track updates to the TCP throughput equation 306 directly, as updates are standardized in the IETF, rather than 307 waiting for revisions of this document. This document is based on 308 CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC, RFC 3448 [RFC3448] 309 has been obsoleted by RFC 5348 [RFC5348]. 311 3.2. Example Half-Connection 313 This example shows the typical progress of a half-connection using 314 CCID 4's TFRC Congestion Control, not including connection initiation 315 and termination. The example is informative, not normative. This 316 example differs from that for CCID 3 in [RFC4342] only in one 317 respect; with CCID 4 the allowed transmit rate is determined by 318 [RFC4828] as well as by [RFC5348]. 320 1. The sender transmits DCCP-Data packets, where the sending rate is 321 governed by the allowed transmit rate as specified in [RFC4828]. 322 Each DCCP-Data packet has a sequence number, and the DCCP header's 323 CCVal field contains the window counter value, used by the 324 receiver in determining when multiple losses belong in a single 325 loss event. 327 In the typical case of an ECN-capable half-connection, each DCCP- 328 Data and DCCP-DataAck packet is sent as ECN-Capable, with either 329 the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce 330 with TFRC is described in Section 9. 332 2. The receiver sends DCCP-Ack packets acknowledging the data packets 333 at least once per round-trip time, unless the sender is sending at 334 a rate of less than one packet per round-trip time [RFC5348] 335 (Section 6). Each DCCP-Ack packet uses a sequence number, 336 identifying the most recent packet received from the sender, and 337 includes feedback about the recent loss intervals experienced by 338 the receiver. 340 3. The sender continues sending DCCP-Data packets as controlled by 341 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 342 sender updates its allowed transmit rate as specified in [RFC5348] 343 (Section 4.3) and [RFC4828]. This update is based upon a loss 344 event rate calculated by the sender, based on the receiver's loss 345 intervals feedback. If it prefers, the sender can also use a loss 346 event rate calculated and reported by the receiver. 348 4. The sender estimates round-trip times and calculates a nofeedback 349 time, as specified in [RFC5348] (Section 4.4). If no feedback is 350 received from the receiver in that time (at least four round-trip 351 times), the sender halves its sending rate. 353 4. Connection Establishment 355 The connection establishment is as specified in Section 4 of 356 [RFC4342]. 358 5. Congestion Control on Data Packets 360 CCID 4 uses the congestion control mechanisms of TFRC [RFC5348] and 361 TFRC-SP [RFC4828]. [RFC4828] MUST be considered normative except 362 where specifically indicated. 364 Loss Event Rate 366 As with CCID 3, the basic operation of CCID 4 centers around the 367 calculation of a loss event rate: the number of loss events as a 368 fraction of the number of packets transmitted, weighted over the last 369 several loss intervals. For CCID 4, this loss event rate, a round- 370 trip time estimate, and a nominal packet size of 1460 bytes are 371 plugged into the TCP throughput equation, as specified in RFC 5348 372 (Section 3.1) and [RFC4828]. 374 Because CCID 4 is intended for applications that send small packets, 375 the allowed transmit rate derived from the TCP throughput equation is 376 reduced by a factor that accounts for packet header size, as 377 specified in Section 4.2 of [RFC4828]. The header size on data 378 packets is estimated as 36 bytes (20 bytes for the IPv4 header, and 379 16 bytes for the DCCP-Data header with 48-bit sequence numbers). If 380 the DCCP sender is sending N-byte data packets, the allowed transmit 381 rate is reduced by N/(N+36). CCID 4 senders are limited to this fair 382 rate. The header size would be 32 bytes instead of 36 bytes when 383 24-bit sequence numbers were used in the DCCP-Data header. 385 As explained in Section 4.2 of [RFC4828], the actual header could be 386 larger or smaller than the assumed value, due to IP or DCCP options, 387 IPv6, IP tunnels, header compression, and the like. Because we are 388 only aiming at rough fairness, and at a rough incentive for 389 applications, the default use of a 32-byte or 36-byte header in the 390 calculations of the header bandwidth is sufficient for both IPv4 and 391 IPv6. 393 If the sender is calculating the loss event rate itself, the loss 394 event rate can be calculated using recent loss interval lengths 395 reported by the receiver. Loss intervals are precisely defined in 396 Section 6.1 of [RFC4342], with the modification in [RFC4828] 397 (Section 3) for loss intervals of at most two round-trip times. In 398 summary, a loss interval is up to 1 RTT of possibly lost or ECN- 399 marked data packets, followed by an arbitrary number of non-dropped, 400 non-marked data packets. The CCID 3 Loss Intervals option is used to 401 report loss interval lengths; see Section 8.6. 403 For loss intervals of at most two round-trip times, CCID 4 calculates 404 the loss event rate for that interval by counting the number of 405 packets lost or marked, as described in Section 4.4 of [RFC4828]. 406 Thus, for such a short loss interval with N data packets, including K 407 lost or marked data packets, the loss interval length is calculated 408 as N/K, instead as N. The Dropped Packets option is used to report 409 K, the count of lost or marked data packets. 411 Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms 412 between data packets, regardless of the allowed transmit rate. If 413 operating system scheduling granularity makes this impractical, up to 414 one additional packet MAY be sent per timeslice, providing that no 415 more than three packets are sent in any 30 ms interval. 417 Other Congestion Control Mechanisms 419 The other congestion control mechanisms such as slow-start and 420 feedback packets are exactly as in CCID 3, and are described in the 421 subsection on "Other Congestion Control Mechanisms" of Section 5 in 422 [RFC4342]. 424 5.1. Response to Idle and Application-limited Periods 426 This is described in Section 5.1 of [RFC4342]. If Faster Restart is 427 standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be 428 implemented in CCID4 without having to wait for an explicit update to 429 this document. 431 5.2. Response to Data Dropped and Slow Receiver 433 This is described in Section 5.2 of [RFC4342]. 435 5.3. Packet Sizes 437 CCID 4 is intended for applications that use a fixed small segment 438 size, or that vary their segment size in response to congestion. 440 The CCID 4 sender uses a segment size of 1460 bytes in the TCP 441 throughput equation. This gives the CCID 4 sender roughly the same 442 sending rate in bytes per second as a TFRC flow using 1460-byte 443 segments but experiencing the same packet drop rate. 445 6. Acknowledgements 447 The acknowledgements are as specified in Section 6 of [RFC4342] with 448 the exception of the Loss Interval lengths specified below. 450 6.1. Loss Interval Definition 452 The loss interval definition is as defined in Section 6.1 of 453 [RFC4342], except as specified below. Section 6.1.1 of RFC 4342 454 specifies that for all loss intervals except the first one, the data 455 length equals the sequence length minus the number of non-data 456 packets the sender transmitted during the loss interval, with a 457 minimum data length of one packet. For short loss intervals of at 458 most two round-trip times, TFRC-SP computes the loss interval length 459 as the data length divided by the number of dropped or marked data 460 packets (rather than as the data length of the loss interval). 462 Section 5.4 of RFC 4342 describes when to use the most recent loss 463 interval in the calculation of the average loss interval. [RFC4828] 464 adds to this procedure the restriction that the most recent loss 465 interval is only used in the calculation of the average loss interval 466 if the most recent loss interval is greater than two round-trip 467 times. The pseudocode is given in Section 3 of [RFC4828]. 469 6.2. Congestion Control on Acknowledgements 471 The congestion control on acknowledgements is as specified in Section 472 6.2 of [RFC4342]. 474 6.3. Acknowledgements of Acknowledgements 476 Procedures for the acknowledgement of acknowledgements are as 477 specified in Section 6.3 of [RFC4342]. 479 6.4. Quiescence 481 The procedure for detecting that the sender has gone quiescent is as 482 specified in Section 6.4 of [RFC4342]. 484 7. Explicit Congestion Notification 486 Procedures for the use of Explicit Congestion Notification (ECN) are 487 as specified in Section 7 of [RFC4342]. 489 8. Options and Features 491 CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, 492 and Elapsed Time options, and its Send Ack Vector and ECN Incapable 493 features. CCID 4 also imports the currently defined CCID-3-specific 494 options and features [RFC4342], augmented by the Dropped Packets 495 option specified in this document. Each CCID-4-specific option and 496 feature contains the same data as the corresponding CCID 3 option or 497 feature, and is interpreted in the same way, except as specified 498 elsewhere in this document (or in a subsequent IETF standards-track 499 RFC that updates or obsoletes this specification). 501 Option DCCP- Section 502 Type Length Meaning Data? Reference 503 ----- ------ ------- ----- --------- 504 128-191 Reserved 505 192 6 Loss Event Rate N 8.5 506 193 variable Loss Intervals N 8.6 507 194 6 Receive Rate N 8.3 508 195 variable Dropped Packets N 8.7 509 196-255 Reserved 511 Table 1: DCCP CCID 4 Options 513 The "DCCP-Data?" column indicates that all currently defined 514 CCID-4-specific options MUST be ignored when they occur on DCCP-Data 515 packets. 517 As with CCID 3, the following CCID-specific features are also 518 defined. 520 Rec'n Initial Section 521 Number Meaning Rule Value Req'd Reference 522 ------ ------- ----- ----- ----- --------- 523 128-191 Reserved 524 192 Send Loss Event Rate SP 0 N 8.4 525 193-255 Reserved 527 Table 2: DCCP CCID 4 Feature Numbers 529 More information is available in Section 8 of [RFC4342]. 531 8.1. Window Counter Value 533 The use of the Window Counter Value in the DCCP generic header's 534 CCVal field is as specified in Section 8.1 of [RFC4342]. In addition 535 to their use described in CCID 3, the CCVal counters are used by the 536 receiver in CCID 4 to determine when the length of a loss interval is 537 at most two round-trip times. None of these procedures require the 538 receiver to maintain an explicit estimate of the round-trip time. 539 However, Section 8.1 of [RFC4342] gives a procedure that implementors 540 may use if they wish to keep such an RTT estimate using CCVal. 542 8.2. Elapsed Time Options 544 The use of the Elapsed Time option is defined in Section 8.2 of 545 [RFC4342]. 547 8.3. Receive Rate Option 549 The Receive Rate option is as specified in Section 8.3 of [RFC4342]. 551 8.4. Send Loss Event Rate Feature 553 The Send Loss Event Rate feature is as defined in Section 8.4 of 554 [RFC4342]. 556 See [RFC5348], Section 5 and [RFC4828], Section 4.4 for a normative 557 calculation of the loss event rate. Section 4.4 of [RFC4828] 558 modifies the calculation of the loss interval size for loss intervals 559 of at most two round-trip times. 561 If the CCID 4 receiver is using the Loss Event Rate option, the 562 receiver needs to be able to determine if a loss interval is short, 563 of at most two round-trip times. The receiver can heuristically 564 detect a short loss interval by using the Window Counter in arriving 565 data packets. The sender increases the Window Counter by 1 every 566 quarter of a round-trip time, with the caveat that the Window Counter 567 is never increased by more than five, modulo 16, from one data packet 568 to the next. Using the Window Counter to detect loss intervals of at 569 most two round-trip times could result in some false positives, with 570 some longer loss intervals incorrectly identified as short ones. For 571 example, if the loss interval contained data packets with only two 572 Window Counter values, say, k and k+5, then the receiver could not 573 tell if the loss interval was at most two round-trip times long or 574 not. Similarly, if the sender sent data packets with Window Counter 575 values of 4, 8, 12, 0, 5, but the packets with Window Counter values 576 of 8, 12, and 0 were lost in the network, then the receiver would 577 only receive data packets with Window Counter values of 4 and 5, and 578 would incorrectly infer that the loss interval was at most two round- 579 trip times. 581 8.5. Loss Event Rate Option 583 The Loss Event Rate option is as specified in Section 8.5 of 584 [RFC4342]. 586 See [RFC5348] (Section 5) and [RFC4828] for a normative calculation 587 of the loss event rate. 589 8.6. Loss Intervals Option 591 The Loss Intervals option is as specified in Section 8.6 of 592 [RFC4342]. 594 8.7. Dropped Packets Option 596 This section describes the Dropped Packets option, a mechanism for 597 reporting the number of lost and marked packets per loss interval. 598 By reporting both the Loss Intervals and Dropped Packets options on 599 the feedback packets, the receiver gives the sender sufficient 600 information to calculate the loss event rate, or to verify the 601 calculation of the reported loss event rate, if the sender so 602 desires. 604 The core information reported by CCID 4 receivers is a list of recent 605 loss intervals, where a loss interval begins with a lost or ECN- 606 marked data packet; continues with at most one round-trip time's 607 worth of packets that may or may not be lost or marked; and completes 608 with an arbitrarily long series of non-dropped, non-marked data 609 packets. Loss intervals model the congestion behavior of TCP NewReno 610 senders, which reduce their sending rate at most once per window of 611 data packets. Consequently, the number of packets lost in a loss 612 interval is not important for either TCP's or TFRC's congestion 613 response. CCID 3's Loss Intervals option reports the length of each 614 loss interval's lossy part, not the number of packets that were 615 actually lost or marked in that lossy part. 617 However, for computing the loss event rate for periods that include 618 short loss intervals the TFRC-SP sender needs to know the number of 619 packets lost or marked in a loss interval, over and above the length 620 of the loss interval in packets. The Dropped Packets option, a 621 CCID-4-specific option, reports this information. Together with the 622 existing Loss Intervals option, the Dropped Packets option allows the 623 CCID 4 sender to discover exactly how many packets were dropped from 624 each loss interval. The receiver reports the number of lost or 625 marked packets in its recently observed loss intervals using the 626 Dropped Packets option. 628 The Dropped Packets Option is specified as follows: 630 +--------+--------+-------...-------+--------+------- 631 |11000011| Length | Drop Count | More Drop Counts... 632 +--------+--------+-------...-------+--------+------- 633 Type=195 3 bytes 635 Figure 1: Dropped Packets Option 637 The Dropped Packets option contains information about one to 84 638 consecutive loss intervals, always including the most recent loss 639 interval. As with the Loss Intervals option, intervals are listed in 640 reverse chronological order. Should more than 84 loss intervals need 641 to be reported, multiple Dropped Packets options can be sent; the 642 second option begins where the first left off, and so forth. 644 One Drop Count is specified per loss interval. Drop Count is a 645 24-bit number that equals the number of packets lost or received ECN- 646 marked during the corresponding loss interval. By definition, this 647 number MUST NOT exceed the corresponding loss interval's Loss Length. 649 CCID 4 receivers MUST report Dropped Packets options with every 650 feedback packet. Any packet containing a Loss Intervals option MUST 651 also contain a Dropped Packets option covering the same loss 652 intervals. If a feedback packet does not include a relevant Dropped 653 Packets option, and the CCID 4 sender is computing the loss event 654 rate itself, the sender MUST treat the relevant loss intervals' Drop 655 Counts as equal to the corresponding Loss Lengths, as specified 656 below. 658 Consider a CCID 4 receiver. As specified in Section 8.6.1 of 659 RFC 4342, the receiver sends the Loss Intervals option for all 660 intervals that have not been acknowledged by the sender. When this 661 receiver sends a feedback packet containing information about the N 662 most recent loss intervals (packaged in one or more Loss Intervals 663 options), then the receiver includes on the same feedback packet one 664 or more Dropped Packets options covering exactly those N loss 665 intervals. CCID 4 senders MUST ignore Drop Counts information for 666 loss intervals not covered by a Loss Intervals option on the same 667 feedback packet. Conversely, a CCID 4 sender might want to 668 interpolate Drop Counts information for a loss interval not covered 669 by any Dropped Packets options; such a sender MUST use the 670 corresponding loss interval's Loss Length as its Drop Count. 672 Each loss interval's Drop Count MUST by definition be less than or 673 equal to its Loss Length. A Drop Count that exceeds the 674 corresponding Loss Length MUST be treated as equal to the Loss 675 Length. 677 8.7.1. Example 679 Consider the following sequence of packets, where "-" represents a 680 safely delivered packet and "*" represents a lost or marked packet. 681 This sequence is repeated from [RFC4342]. 683 Sequence 684 Numbers: 0 10 20 30 40 44 685 | | | | | | 686 ----------*--------***-*--------*----------*- 688 Figure 2: Sequence of Delivered (-) and Lost (*) Packets 690 Assuming that packet 43 was lost, not marked, this sequence might be 691 divided into loss intervals as follows: 693 0 10 20 30 40 44 694 | | | | | | 695 ----------*--------***-*--------*----------*- 696 \________/\_______/\___________/\_________/ 697 L0 L1 L2 L3 699 Figure 3: Loss Intervals for the Packet Sequence 701 A Loss Intervals option sent on a packet with Acknowledgement Number 702 44 to acknowledge this set of loss intervals might contain the bytes 703 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 704 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15; for interpretation of this 705 option, see [RFC4342]. A Dropped Packets option sent in tandem on 706 this packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 707 0,0,0. This is interpreted as follows. 709 195 The Dropped Packets option number. 711 14 The length of the option, including option type and length bytes. 712 This option contains information about (14 - 2)/3 = 4 loss 713 intervals. Note that the two most recent sequence numbers are 714 not yet part of any loss interval -- the Loss Intervals option 715 includes them in its Skip Length -- and are thus not included in 716 the Dropped Packets option. 718 0,0,1 719 These bytes define the Drop Count for L3, which is 1. As 720 required, the Drop Count is less than or equal to L3's Loss 721 Length, which is also 1. 723 0,0,4 724 The Drop Count for L2 is 4. 726 0,0,1 727 The Drop Count for L1 is 1. 729 0,0,0 730 Finally, the Drop Count for L0 is 0. 732 9. Verifying Congestion Control Compliance With ECN 734 Verifying congestion control compliance with ECN is as discussed in 735 Section 9 of [RFC4342]. 737 9.1. Verifying the ECN Nonce Echo 739 Procedures for verifying the ECN Nonce Echo are as specified in 740 Section 9.1 of [RFC4342]. 742 9.2. Verifying the Reported Loss Intervals and Loss Event Rate 744 Section 9.2 of [RFC4342] discusses the sender's possible verification 745 of loss intervals and loss event rate information reported by the 746 receiver. 748 10. Implementation Issues 750 10.1. Timestamp Usage 752 The use of the Timestamp option is as discussed in Section 10.1 of 753 [RFC4342]. 755 10.2. Determining Loss Events at the Receiver 757 The use of the window counter by the receiver to determine if 758 multiple lost packets belong to the same loss event is as described 759 in Section 10.2 of [RFC4342]. 761 10.3. Sending Feedback Packets 763 The procedure for sending feedback packets is as described in Section 764 10.3 of [RFC4342]. 766 11. Design Considerations 768 This section discusses design considerations for the field sizes in 769 the Loss Intervals and Dropped Packets Options. 771 11.1. The Field Size in the Loss Intervals Option 773 Section 8.6 of RFC 4342 specifies a Loss Intervals Option with three 774 fields for each loss interval, for reporting the Lossless Length, 775 Loss Length, and Data Length. Each field is specified to be three 776 bytes. Section 8.6 of this document specifies that CCID 4 use the 777 same Loss Intervals Option as CCID 3, with the same field sizes. 778 This has the significant advantage of minimizing the implementation 779 differences between CCID 3 and CCID 4. However, it has been 780 suggested that CCID 4 *could* use a Loss Intervals Option with 781 smaller field sizes, since a CCID 4 sender enforces a minimum 782 interval of 10 ms between data packets. This section explains the 783 reason for CCID 4 to use the same Loss Intervals option as specified 784 for CCID 3. 786 The Lossless Length field reports the number of packets in the loss 787 intervals' lossless part, and the Loss Length field reports the 788 number of packets in the loss interval's lossy part. The Data Length 789 field reports the number of packets in the loss interval's data 790 length (excluding non-data packets). A two-byte Data Length field 791 can report a data length of 65,536 packets, corresponding to a loss 792 event rate of 0.00002; this is enough to give the CCID 4 sender an 793 allowed sending rate of roughly 250 packets per RTT, which is enough 794 for a connection with a round-trip time of at most 2.5 seconds. For 795 a CCID 4 connection with a larger round-trip time, the three-byte 796 Lossless Length and Data Length fields would be needed. 798 For the Loss Length field in the Loss Intervals Option, reporting the 799 number of packets in the one-RTT lossy part of the loss interval, a 800 one-byte field would not be sufficient for a CCID 4 connection with a 801 long RTT (three seconds or longer). For the Loss Length field, a 802 two-byte field should be sufficient for CCID 4. However, our 803 judgement is that the advantages of using the same Loss Intervals 804 Option as in CCID 3 outweigh any advantages of using a CCID 4 Loss 805 Intervals Option that uses eight bytes instead of nine bytes for 806 reporting the fields for each loss interval. 808 11.2. The Field Size in the Dropped Packets Option 810 Section 8.7 specifies the Dropped Packets Option for reporting the 811 number of lost or marked packets per loss interval, allocating three 812 bytes for the drop count field for each loss interval reported. The 813 three-byte field is partly for simplicity, to give the same field 814 size as the fields in the Loss Intervals option specified in 815 RFC 4342. It has been suggested that CCID 4 *could* use a smaller 816 field size for the Dropped Packets option. This section discusses 817 the issue of the size of the drop count field in the Dropped Packets 818 Option. 820 It is not necessary to specify a three-byte field for the Dropped 821 Packets Option. A one-byte field would allow a reported drop count 822 of 255, and a two-byte field would allow a reported drop count of 823 65,535. A two-byte field would clearly be sufficient for the drop 824 count field for CCID 4. 826 In fact, a one-byte field would *probably* be adequate for reporting 827 the drop count for a loss interval in a CCID 4 connection. Because a 828 CCID 4 sender enforces a minimum interval of 10 ms between data 829 packets, a sender would need a round-trip time of over 2.55 seconds 830 to have more than 255 packets lost or marked in a single loss 831 interval; round-trip times of greater than three seconds are not 832 unusual for some flows traversing satellite links. The drop count 833 field is used in CCID 4 to compute the actual loss rate for short 834 loss intervals, rather than using the loss event rate that is used 835 for longer loss intervals. If a loss interval of at most two round- 836 trip times included N packets sent, with more than 255 of those 837 packets lost or marked, a drop count field of one byte would allow a 838 drop count of at most 255 to be reported, resulting in a computed 839 loss rate for that interval of 255/N. This loss rate might be less 840 than the actual loss rate, but it is significantly higher than the 841 loss event rate of 1/N, and should be sufficient to prevent a steady- 842 state condition of a CCID 4 connection with multiple packets dropped 843 each round-trip time. Thus, a one-byte field would probably be 844 adequate for reporting the drop count for a loss interval in a CCID 4 845 connection. However, at the moment this document specifies a three- 846 byte field, for consistency with the field size in the Loss Intervals 847 Option. 849 12. Experimental Status of this Document 851 TFRC-SP is a congestion control mechanism defined in RFC 4828. 852 Section 10 of [RFC4828] describes why TFRC-SP is currently specified 853 as experimental and why it is not intended for widespread deployment 854 at this time in the global Internet. Since TFRC-SP is experimental, 855 CCID 4 is therefore also considered experimental. If the IETF 856 publishes a standards-track RFC that changes the status of TFRC-SP, 857 then CCID 4 should then be updated to reflect the change of status. 859 13. Security Considerations 861 Security considerations include those discussed in Section 11 of 862 [RFC4342]. There are no new security considerations introduced by 863 CCID 4. 865 14. IANA Considerations 867 This specification defines the value 4 in the DCCP CCID namespace 868 managed by IANA. This is a permanent codepoint, as is needed for 869 experimentation across the Internet using different codebases. 871 CCID 4 also uses three sets of numbers whose values should be 872 allocated by IANA, namely CCID-4-specific Reset Codes, option types, 873 and feature numbers. This document makes no particular allocations 874 from the Reset Code range, except for experimental and testing use 875 [RFC3692]. We refer to the Standards Action policy outlined in 876 [RFC5226]. 878 14.1. Reset Codes 880 Each entry in the DCCP CCID 4 Reset Code registry contains a 881 CCID-4-specific Reset Code, which is a number in the range 128-255; a 882 short description of the Reset Code; and a reference to the RFC 883 defining the Reset Code. Reset Codes 184-190 and 248-254 are 884 permanently reserved for experimental and testing use. The remaining 885 Reset Codes -- 128-183, 191-247, and 255 -- are currently reserved, 886 and should be allocated with the Standards Action policy, which 887 requires IESG review and approval and standards-track IETF RFC 888 publication. 890 14.2. Option Types 892 Each entry in the DCCP CCID 4 option type registry contains a 893 CCID-4-specific option type, which is a number in the range 128-255; 894 the name of the option, such as "Loss Intervals"; and a reference to 895 the RFC defining the option type. The registry is initially 896 populated using the values in Table 1, in Section 8. This includes 897 the value 195 allocated for the Dropped Packets option. This 898 document allocates option types 192-195, and option types 184-190 and 899 248-254 are permanently reserved for experimental and testing use. 900 The remaining option types -- 128-183, 191, 196-247, and 255 -- are 901 currently reserved, and should be allocated with the Standards Action 902 policy, which requires IESG review and approval and standards-track 903 IETF RFC publication. 905 14.3. Feature Numbers 907 Each entry in the DCCP CCID 4 feature number registry contains a 908 CCID-4-specific feature number, which is a number in the range 909 128-255; the name of the feature, such as "Send Loss Event Rate"; and 910 a reference to the RFC defining the feature number. The registry is 911 initially populated using the values in Table 2, in Section 8. This 912 document allocates feature number 192, and feature numbers 184-190 913 and 248-254 are permanently reserved for experimental and testing 914 use. The remaining feature numbers -- 128-183, 191, 193-247, and 255 915 -- are currently reserved, and should be allocated with the Standards 916 Action policy, which requires IESG review and approval and standards- 917 track IETF RFC publication. 919 15. Thanks 921 We thank Gorry Fairhurst, Alfred Hoenes, Ian McDonald, Gerrit Renker, 922 and Leandro Sales for feedback on this document. 924 Normative References 926 [RFC2119] S. Bradner. Key Words For Use in RFCs to Indicate 927 Requirement Levels. RFC 2119. 929 [RFC5226] T. Narten and H. Alvestrand. Guidelines for Writing 930 an IANA Considerations Section in RFCs. RFC 5226. 932 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 933 Friendly Rate Control (TFRC): Protocol Specification, 934 RFC 3448, Proposed Standard, January 2003. Obsoleted 935 by RFC 5348. 937 [RFC3692] T. Narten. Assigning Experimental and Testing Numbers 938 Considered Useful. RFC 3692. 940 [RFC4340] Kohler, E., Handley, M., and S. Floyd. Datagram 941 Congestion Control Protocol (DCCP), RFC 4340, March 942 2006. 944 [RFC4342] Floyd, S., Kohler, E., and J. Padhye. Profile for 945 Datagram Congestion Control Protocol (DCCP) Congestion 946 Control ID 3: TCP-Friendly Rate Control (TFRC), 947 RFC 4342, March 2006. 949 [RFC4828] S. Floyd and E. Kohler. TCP Friendly Rate Control 950 (TFRC): the Small-Packet (SP) Variant. RFC 4828, 951 April 2007. 953 [RFC5348] S. Floyd, M. Handley, J. Padhye, and J. Widmer, TCP 954 Friendly Rate Control (TFRC): Protocol Specification, 955 RFC 5348, Proposed Standard, September 2008. 957 Informative References 959 [KFS07] Kohler, E., S. Floyd, and A. Sathiaseelan, Faster 960 Restart for TCP Friendly Rate Control (TFRC), 961 Internet-draft draft-ietf-dccp-tfrc-faster- 962 restart-06.txt, work-in-progress, July 2008. 964 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 965 Friendly Rate Control (TFRC): Protocol Specification, 966 RFC 3448, Proposed Standard, January 2003. Obsoleted 967 by RFC 5348. 969 Authors' Addresses 971 Sally Floyd 972 ICSI Center for Internet Research 973 1947 Center Street, Suite 600 974 Berkeley, CA 94704 975 USA 977 Email: floyd@icir.org 979 Eddie Kohler 980 4531C Boelter Hall 981 UCLA Computer Science Department 982 Los Angeles, CA 90095 983 USA 985 Email: kohler@cs.ucla.edu 987 Acknowledgement 989 Funding for the RFC Editor function is provided by the IETF 990 Administrative Support Activity (IASA).