idnits 2.17.1 draft-padhye-dcp-ccid3-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '... in the DCCP specification [3]. The client and the server MAY...' RFC 2119 keyword, line 221: '... ECN [6] MAY be used with CCID 3. If ECN is used, then the ECN Nonce...' RFC 2119 keyword, line 232: '...ase the receiver MUST return this opti...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (19 June 2002) is 7982 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) == Missing Reference: '0' is mentioned on line 224, but not defined -- Looks like a reference, but probably isn't: 'LE' on line 327 -- Looks like a reference, but probably isn't: 'RE' on line 327 == Outdated reference: A later version (-05) exists of draft-ietf-tsvwg-tfrc-04 -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-04) exists of draft-kohler-dcp-02 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-tcp-nonce-03 ** Downref: Normative reference to an Historic draft: draft-ietf-tsvwg-tcp-nonce (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Jitendra Padhye 3 draft-padhye-dcp-ccid3-04.txt Microsoft Research 4 Sally Floyd 5 Eddie Kohler 6 ICIR 7 19 June 2002 8 Expires: December 2002 10 Profile for DCCP Congestion Control ID 3: 11 TFRC Congestion Control 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document contains the profile for Congestion Control 37 Identifier 3, TCP-friendly rate control (TFRC), in the 38 Datagram Congestion Control Protocol (DCCP). DCCP implements 39 a congestion-controlled unreliable datagram flow suitable for 40 use by applications such as streaming media. The TFRC CCID is 41 used by applications that want a TCP-friendly send rate, 42 possibly with Explicit Congestion Notification (ECN), while 43 minimizing abrupt rate changes. 45 Table of Contents 47 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 4 49 1.2. Example Half-Connection. . . . . . . . . . . . . . . 4 50 2. Connection Establishment. . . . . . . . . . . . . . . . 5 51 3. Congestion Control on Data Packets. . . . . . . . . . . 5 52 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Congestion Control on Acknowledgments. . . . . . . . 6 54 4.2. Quiescence . . . . . . . . . . . . . . . . . . . . . 6 55 4.3. Acknowledgments of Acknowledgments . . . . . . . . . 7 56 5. Explicit Congestion Notification. . . . . . . . . . . . 7 57 6. Relevant Options and Features . . . . . . . . . . . . . 7 58 6.1. Window counter option. . . . . . . . . . . . . . . . 7 59 6.2. Elapsed time option. . . . . . . . . . . . . . . . . 8 60 6.3. Loss Event Rate Option . . . . . . . . . . . . . . . 8 61 6.4. Receive Rate Option. . . . . . . . . . . . . . . . . 8 62 6.5. ECN NONCE Option . . . . . . . . . . . . . . . . . . 9 63 7. Application Requirements. . . . . . . . . . . . . . . . 10 64 8. Design Considerations . . . . . . . . . . . . . . . . . 10 65 8.1. Determining Loss Events. . . . . . . . . . . . . . . 10 66 8.2. Sending Feedback Packets . . . . . . . . . . . . . . 11 67 9. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. References . . . . . . . . . . . . . . . . . . . . . . 12 69 11. Authors' Addresses . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 This document contains the profile for Congestion Control Identifier 74 3, TCP-friendly rate control (TFRC), in the Datagram Congestion 75 Control Protocol (DCCP). DCCP uses Congestion Control Identifiers, 76 or CCIDs, to specify the congestion control mechanism in use on a 77 half-connection. (A half-connection might consist of data packets 78 sent from DCCP A to DCCP B, plus acknowledgments sent from DCCP B to 79 DCCP A. DCCP A is the sending DCCP, and DCCP B the acknowledging 80 DCCP, for this half-connection.) 82 TFRC is a receiver-based congestion control mechanism that provides 83 a TCP-friendly send rate, while minimizing abrupt rate changes [1]. 85 The basic TFRC protocol is as follows. The sender sends a stream of 86 data packets to the receiver at some rate. The receiver sends a 87 feedback packet to the sender at least once every round-trip time. 88 Based on the information contained in the feedback packets, the 89 sender adjusts its sending rate in accordance with the TCP 90 throughput equation [2], to maintain TCP-friendliness. If no 91 feedback is received from the receiver in several round-trip times 92 (four, in the current TFRC specification), the sender halves its 93 sending rate. 95 The values of the round-trip time RTT, the loss event rate p and the 96 base timeout value TO are needed by the sender to calculate the send 97 rate using the TCP throughput equation. The sender calculates the 98 values of RTT and TO, while the receiver calculates the value of p. 100 1.1. Usage Scenario 102 DCCP with TFRC congestion control is intended to provide congestion 103 control for the flow of data packets from the server to the client 104 for applications that do not require fully reliable data 105 transmission, or that desire to implement reliability on top of 106 DCCP. TFRC congestion control is appropriate for flows that would 107 prefer to minimize abrupt changes in the sending rate. 109 1.2. Example Half-Connection 111 This example, taken from the main DCCP draft, is of a half- 112 connection using TFRC Congestion Control specified by CCID 3. The 113 "sender" is the HC-Sender, and the "receiver" is the HC-Receiver. 115 (1) The sender sends DCCP-Data packets, where the number of packets 116 sent is governed by an allowed transmit rate, as specified in 117 [1]. Each DCCP-Data packet has a sequence number and a window 118 counter option. 120 One or more of these data packets are DCCP-DataAck packets 121 acknowledging the data packet from the receiver, but for 122 simplicity we will not discuss the half-connection of data from 123 the receiver to the sender in this example. 125 (2) The receiver sends DCCP-Ack packets at least once per round-trip 126 time acknowledging the data packets, unless the sender is 127 sending at a rate of less than one packet per RTT, as indicated 128 by the TFRC specification [1]. Each DCCP-Ack packet uses a 129 sequence number and identifies the most recent packet received 130 from the sender. Each DCCP-Ack packet includes feedback about 131 the loss event rate calculated by the receiver, as specified 132 below. 134 (3) The sender continues sending DCCP-Data packets as controlled by 135 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 136 sender updates its allowed transmit rate as specified in [1]. 138 (4) The sender estimates round-trip times and calculates a TimeOut 139 value TO as specified in [1]. 141 (5) If the use of ECN has been negotiated, each DCCP-Data and DCCP- 142 DataAck packet is sent as ECN-Capable, with either the ECT(0) or 143 the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is 144 described below. 146 2. Connection Establishment 148 The connection is initiated by the client using mechanisms described 149 in the DCCP specification [3]. The client and the server MAY 150 negotiate the use of the ACK Vector option. The ACK vector option 151 is described in [3]. 153 3. Congestion Control on Data Packets 155 The sender sends DCCP-Data packets to the receiver at the rate 156 specified by the TCP throughput equation [2]. 158 Each DCCP-Data packet has a sequence number, and an acknowledgment 159 number that is the sequence number of the most recent acknowledgment 160 packet received from the receiver. Each data packet contains the 161 window counter option. The format of the window counter option is 162 described below. 164 After each feedback packet is received from the receiver, the sender 165 updates values of RTT, TO and the sending rate using procedures 166 specified in [1]. 168 If no feedback packet is received from the receiver after an 169 interval specified in [1], the sending rate is halved. However, the 170 sending rate is never reduced below one packet per 64 seconds. See 171 [1] for more details. 173 4. Acknowledgments 175 The receiver sends a DCCP-Ack packet to the sender roughly once per 176 round-trip time, if the sender is sending packets that frequently. 177 This rate is determined by details of the TFRC protocol, as 178 specified in [1]. 180 The acknowledgment number in the DCCP-Ack packet acknowledges the 181 most recent packet received from the sender. Each DCCP-Ack packet 182 from the receiver includes the following options: 184 1. An option specifying the amount of time elapsed between since 185 the receiver received the packet whose sequence number appears 186 in the acknowledgment field. 188 2. An option specifying the loss event rate p calculated by the 189 receiver as described in [1]. 191 3. An option specifying the rate at which the receiver received 192 data since the last DCCP-Ack was sent. 194 The format of these options is described below. 196 4.1. Congestion Control on Acknowledgments 198 The rate and timing for generating acknowledgments is determined by 199 the TFRC algorithm [1]. The sending rate for acknowledgements is 200 relatively low, and there is no explicit congestion control on the 201 acknowledgements. 203 4.2. Quiescence 205 This section refers to quiescence in the DCCP sense (see section 6.1 206 of [3]): How does a CCID 3 receiver determine that the corresponding 207 sender is not sending any data? 208 The receiver detects that the sender has gone quiescent after two 209 round-trip times have passed without receiving any additional data. 210 Since ACKs are not required to be reliable, the receiver needs to do 211 nothing special in this case, unlike CCID 2 [5]. 213 4.3. Acknowledgments of Acknowledgments 215 Acknowledgments in TFRC are entirely unreliable -- TFRC works even 216 if every acknowledgment is dropped -- and it is never necessary for 217 the sender to acknowledge an acknowledgment. 219 5. Explicit Congestion Notification 221 ECN [6] MAY be used with CCID 3. If ECN is used, then the ECN Nonce 222 will automatically be used for the data packets, following the 223 specification for the ECN Nonce [4] for TCP. For the data sub-flow, 224 the sender sets either the ECT[0] or ECT[1] codepoint on DCCP-Data 225 packets. 227 If the ACK vector option is being used, the ECN-NONCE information is 228 returned via the ACK vector. 230 If the ACK vector option is not being used, the information about 231 the ECN-NONCE is returned by the receiver using the ECN-NONCE option 232 described below. In this case the receiver MUST return this option 233 if it is reporting a lower packet loss rate than the one it reported 234 in the previous acknowledgment. 236 6. Relevant Options and Features 238 6.1. Window counter option 240 +--------+--------+----...--------+ 241 |10000000|00000011| Window Counter| 242 +--------+--------+----...--------+ 243 Type=128 Len=3 1 byte 245 This option is set by the data sender on all data packets. The first 246 byte gives the option type and the second gives the option length. 247 The last byte gives the value of a counter which the sender sets to 248 0 at the beginning of the transmission, and increases by 1 every 249 quarter of round trip time as described in [1]. 251 6.2. Elapsed time option 253 +--------+--------+----...------+ 254 |10000001|00000110| Elapsed Time| 255 +--------+--------+----...------+ 256 Type=129 Len=4 2 bytes 258 This option is set by the data receiver on all acknowledgment 259 packets. The first byte gives the option type and the second gives 260 the option length. The last two bytes indicate the amount of time 261 (in milliseconds) elapsed since the packet being acknowledged was 262 received. 264 6.3. Loss Event Rate Option 266 +--------+--------+----...-----+ 267 |11000000|00000110| Loss rate | 268 +--------+--------+----...-----+ 269 Type=192 Len=6 4 bytes 271 This option is set by the data receiver on all acknowledgment 272 packets. The first byte gives the option type and the second gives 273 the option length. The last four bytes indicate the inverse of the 274 loss event rate, rounded UP, as calculated by the receiver. 276 6.4. Receive Rate Option 278 +--------+--------+----...-----+ 279 |10000001|00000110| Recv rate | 280 +--------+--------+----...-----+ 281 Type=129 Len=6 4 bytes 283 This option is set by the data receiver on all acknowledgment 284 packets. The first byte gives the option type and the second gives 285 the option length. The last four bytes indicate the rate at which 286 the receiver has received data since it last sent an acknowledgment, 287 in bits per second. 289 6.5. ECN NONCE Option 291 +--------+--------+----...-----+----...-----+--------+ 292 |10000010|00001001| Left Edge | Right Edge |X0000000| 293 +--------+--------+----...-----+----...-----+--------+ 294 Type=130 Len=9 3 bytes 3 bytes 1 byte 296 If ECN is used without the ACK vector option, then the ECN Nonce 297 option is set by the data receiver on any acknowledgment packet that 298 reports a loss rate lower than the loss rate reported in the 299 previous acknowledgment packet. The first byte gives the option 300 type and the second gives the option length. The right edge (RE) 301 and the left edge (LE) are sequence numbers of data packets, such 302 that: 304 - Let LastAck be the sequence number of the data packet 305 acknowledged by the previous acknowledgment. 307 - If (LastAck + 1) was a dropped or marked packet, then RE 308 should be the highest non-dropped and non-marked packet before 309 (LastAck + 1). 311 - If (LastAck + 1) was not a dropped or marked packet, the RE 312 should be the greatest sequence number such that all data 313 packets between (LastAck + 1) and RE, inclusive, were received 314 and not ECN-marked. Clearly (RE >= LastAck + 1). 316 - LE should be the smallest sequence number such that all data 317 packets between LE and RE, inclusive, were received and not ECN- 318 marked. Clearly (LE <= RE). 320 The first bit of the final byte is the Nonce Echo. It equals the 321 base-2 modulus of the number of received ECN Nonce packets between 322 LE and RE, both included. 324 Note that the interval [LE, RE] would be the largest non-loss 325 interval containing the first packet received since the last report, 326 or, if that was a dropped packet, containing the run before this 327 drop. That is, [LE, RE] would continue to grow during non-drop and 328 non-mark periods. Thus, for every loss event, the receiver reports 329 the Nonce Echo for the consecutive sequence of packets received 330 before the beginning of that loss event. 332 7. Application Requirements 334 As described in the TFRC specifications [1], this CCID should not be 335 used by applications that change their sending rate by varying the 336 packet size, rather than varying the rate at which packets are sent. 338 As it is presently specified, this CCID should only be used by 339 senders that are willing to trust the receiver to report the correct 340 loss event rate. If ECN is used, the ECN Nonce Option allows the 341 sender to probabilistically verify the loss rate reported by the 342 receiver. However, we have not specified such a verification 343 procedure in this document. 345 8. Design Considerations 347 The data packets do not carry timestamps. The sender can store the 348 times at which recent packets were sent. When an acknowledgement 349 arrives, the acknowledgement number and the elapsed time option 350 provide sufficient information to compute the round trip time. 352 8.1. Determining Loss Events 354 The window counter option is used by the receiver to determine if 355 multiple lost packets belong to the same loss event. The sender 356 increases the window counter by 1 every quarter round trip time. To 357 determine whether two lost packets, with sequence numbers X and Y (Y 358 > X), belong to different loss events, the receiver proceeds as 359 follows: 361 - Let X_prev be the highest sequence number which was received 362 with X_prev < X. 364 - Let Y_prev be the highest sequence number which was received 365 with Y_prev < Y. 367 - Let CX_prev and CY_prev be the window counters associated with 368 packets X_prev and Y_prev respectively. Clearly, CY_prev >= 369 CX_prev. 371 - Packets X and Y belong to different loss events if (CY_prev - 372 CX_prev) > 4 374 The use of the window counter option can help the receiver to 375 disambiguate multiple losses after a sudden decrease in the actual 376 round-trip time. When the sender receives an acknowledgement 377 acknowledging a data packet with window counter i, the sender 378 increases its window counter, if necessary, so that subsequent data 379 packets are sent with window counter values of at least i+4. This 380 can help minimize errors on the part of the receiver of incorrectly 381 interpreting multiple loss events as a single loss event. 383 As an alternative to the window counter option, the sender could 384 have sent its estimate of the round-trip time to the receiver 385 directly in a round-trip time option, and the receiver should use 386 the sender's round-trip time estimate to infer when multiple lost or 387 marked packets belong in the same loss event. In some respects, a 388 round-trip time option gives a more precise encoding of the sender's 389 round-trip time estimate than does the window counter option. 390 However, the window counter option conveys information about the 391 relative *sending* times for packets, while the receiver could only 392 use the round-trip time option to distinguish between the relative 393 *receive* times (in the absence of timestamps). That is, the window 394 counter option will give more robust performance in some cases when 395 there is a large variation in delay for packets sent within a window 396 of data. As a slightly more speculative consideration, the round- 397 trip time option could possibly be used more easily by middleboxes 398 attempting to verify that a flow was using conformant end-to-end 399 congestion control. 401 8.2. Sending Feedback Packets 403 The window counter option is also used by the receiver to decide 404 when to send feedback packets. Feedback packets should normally be 405 sent at least once per round-trip time, if the sender is sending at 406 least one data packet per round-trip time. Whenever the receiver 407 sends a feedback message, the receiver sets a local variable 408 last_counter to the highest received value of the window counter 409 since the last feedback message was sent, if any data packets have 410 been received since the last feedback message was sent. If the 411 receiver receives a data packet with a window counter value greater 412 than last_counter + 4, then the receiver sends a new feedback 413 packet. 415 The TFRC protocol [1] specifies that the receiver uses a feedback 416 timer to decide when to send feedback packets. In the TFRC 417 protocol, when the feedback timer expires, the receiver resets the 418 timer to expire after R_m seconds, where R_m is the most recent 419 estimate of the round-trip time received by the receiver from the 420 sender. However, when the window counter option is used, the 421 receiver can use information from the window counter option in 422 deciding when to send feedback packets. 424 When the sender is sending less than one packet per round-trip time, 425 then the receiver sends a feedback packet after each data packet, 426 and the feedback timer is not required. Similarly, when the sender 427 is sending several packets per round-trip time, then the receiver 428 will send a feedback packet each time that a data packet arrives 429 with a window counter more than four greater than the window counter 430 when the last feedback packet was sent, and again the feedback 431 counter is not required. Similarly, the receiver always sends a 432 feedback packet after the detection of a loss event. Thus, the 433 feedback timer is not absolutely necessary when the window counter 434 is used. 436 However, the feedback timer still could be useful in some rare cases 437 to prevent the sender from unnecessarily halving its sending rate. 438 We have not considered this in detail. Consider the case when the 439 receiver receives data soon after the most recent feedback packet 440 has been sent, but has received no data packets with a window 441 counter sufficiently large to trigger sending a new feedback packet. 442 The TFRC protocol specifies that after a feedback packet is 443 received, the sender sets a nofeedback timer to at least four times 444 the round-trip time estimate. If the sender doesn't receive any 445 feedback packets before the nofeedback timer expires, then the 446 sender halves its sending rate. One could construct scenarios where 447 the use of a feedback timer at the receiver would prevent the 448 unnecessary expiration of the nofeedback timer at the sender. 450 For implementors who wish to implement a feedback timer for the data 451 receiver, we suggest estimating the round-trip time from the most 452 recent data packet as follows: Let K be the window counter from the 453 most recent data packet, and let T_k be the time that that packet 454 was received. Let J be the highest window counter received that was 455 less than K-4, and let T_j be the most recent time that such a 456 packet was received. Then the round-trip time can be very roughly 457 estimated as 4 (T_k-T_j)/(K-J). 459 9. Thanks 461 We thank Mark Handley for his help in defining CCID 3. We thank 462 Sara Karlberg and Yufei Wang for feedback on an earlier version of 463 this document. 465 10. References 467 [1] M. Handley, J. Padhye, and S. Floyd. TCP Friendly Rate Control 468 (TFRC): Protocol Specification, draft-ietf-tsvwg-tfrc-04.txt, 469 work in progress, April 2002. 471 [2] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP 472 Throughput: A Simple Model and its Empirical Validation. Proc 473 ACM SIGCOMM 1998. 475 [3] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram 476 Congestion Control Protocol, draft-kohler-dcp-02.txt, work in 477 progress, March 2002. 479 [4] Neil Spring, David Wetherall, and David Ely. Robust ECN 480 Signaling with Nonces, draft-ietf-tsvwg-tcp-nonce-03.txt, work 481 in progress, April 2002. 483 [5] S. Floyd, E. Kohler. Profile for DCCP Congestion Control ID 2: 484 TCP-like Congestion Control, draft-floyd-dcp-ccid2-03.txt, work 485 in progress, May 2002. 487 [6] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition of 488 Explicit Congestion Notification (ECN) to IP. RFC 3168. 489 September 2001. 491 11. Authors' Addresses 493 Jitendra Padhye 495 Microsoft Research 496 One Microsoft Way 497 Redmond, WA 98052 USA 499 Sally Floyd 500 Eddie Kohler 502 ICSI Center for Internet Research 503 1947 Center Street, Suite 600 504 Berkeley, CA 94704 USA