idnits 2.17.1 draft-renker-dccp-tfrc-rtt-option-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC4342, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5622, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4342, updated by this document, for RFC5378 checks: 2002-10-24) -- 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 (August 18, 2010) is 4998 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) ** Downref: Normative reference to an Experimental RFC: RFC 5622 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DCCP Working Group G. Renker 3 Internet-Draft G. Fairhurst 4 Updates: 4342, 5622 University of Aberdeen 5 (if approved) August 18, 2010 6 Intended status: Standards Track 7 Expires: February 16, 2011 9 Sender RTT Estimate Option for DCCP 10 draft-renker-dccp-tfrc-rtt-option-01 12 Abstract 14 This document describes an update to CCID-3/4 that addresses 15 parameter-estimation problems occurring with TFRC-based DCCP 16 congestion control. 18 The fix uses a recommendation made in the original TFRC 19 specification. It avoids the inherent problems of receiver-based RTT 20 sampling, by utilising higher-accuracy RTT samples already available 21 at the sender. It is integrated into the feature set of DCCP as an 22 end-to-end negotiable extension, upward and downward compatible. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 16, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problems caused by sampling the RTT at the receiver . . . . . 4 60 2.1. List of problems encountered with a real implementation . 4 61 2.2. Other areas affected by the RTT sampling problems . . . . 6 62 2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 6 63 2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 6 64 2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 7 65 2.2.4. Practical Considerations . . . . . . . . . . . . . . . 7 66 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Options and Features . . . . . . . . . . . . . . . . . . . 8 69 3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 8 70 3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 9 71 3.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 13 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 This document lists and analyses problems observed with receiver- 85 based RTT sampling in the actual implementation of TFRC congestion 86 control [RFC4342], [RFC5622]. 88 To fix these problems, this document presents a solution based on a 89 concept first recommended in [RFC5348], 3.2.1; i.e. to measure the 90 RTT at the sender. This results in a higher reliability and 91 frequency of samples, and avoids the inherent problems of receiver- 92 based RTT sampling discussed below. 94 We begin by listing the encountered problems in the next section. 95 The proposed solution is presented in in Section 3. We then discuss 96 security considerations in Section 4 and list the resulting IANA 97 considerations in Section 5. 99 2. Problems caused by sampling the RTT at the receiver 101 There are at least six areas that make a TFRC receiver vulnerable to 102 inaccuracies or absence of (receiver-based) RTT samples: 104 o the measured sending rate, X_recv ([RFC5348], 6.2); 106 o synthesis of the first loss interval ([RFC5348], 6.3.1); 108 o disambiguation of loss events ([RFC4342], 10.2); 110 o validation of loss intervals ([RFC4342], 6.1); 112 o ensuring that at least one feedback packet is sent per RTT 113 ([RFC4342], 10.3); 115 o determining quiescence periods ([RFC4342], 6.4). 117 2.1. List of problems encountered with a real implementation 119 This section summarizes several years of experience using the Linux 120 implementation of CCID-3 and CCID-4. It lists the problems 121 encountered with receiver-based RTT sampling over real networks, in a 122 variety of wired and wireless environments and under different link- 123 layer conditions. 125 The Linux DCCP/TFRC implementation is based on the RTT-sampling 126 algorithm specified in [RFC4342], 8.1. This algorithm relies on a 127 coarse-grained window-counter (units of RTT/4), and uses packet 128 inter-arrival times to estimate the current RTT of the network. 130 The algorithm is effective only for packets with modulo-16 CCVal 131 differences between 2 and 4 (corresponding to RTT/2, 3/4RTT, and 132 RTT). This limitation is noted in sections 8.1 and 10.3 of 133 [RFC4342]. 135 A second problem arises when there are holes in the sequence space. 136 Because there may be wrap-around of the 4-bit CCVal window counter, 137 it is not possible to determine window-counter wrap-around whenever 138 sequence numbers of subsequent packets are not immediately adjacent. 139 This problem occurs when packets are delayed, reordered, or lost in 140 the network. 142 As a consequence, RTT sampling has to be paused during times of loss. 143 This however aggravates the problem, since the sender now requires 144 new feedback from the receiver, but the receiver is unable to provide 145 accurate and up-to-date information: the receiver is unable to sample 146 the RTT, accordingly also not able to estimate X_recv correctly, 147 which then in turn affects X_Bps at the sender. 149 The third limitation arises from using inter-arrival times as 150 representatives of network inter-packet gaps. It is well known that 151 the inter-packet gap is not constant along a network path. 152 Furthermore, modern network interface cards do not necessarily 153 deliver each packet at the time it is received, but rather in a 154 bunch, to avoid overly frequent interrupts [MR97]. As a result, 155 inter-packet arrival times may converge to zero, when subsequent 156 packets are delivered at virtually the same time, served by the same 157 interrupt routine. 159 The fourth problem is that of under-sampling and thus related to the 160 first limitation. If loss occurs while the receiver has not yet had 161 a chance to sample the RTT, it needs to fall back to some fixed RTT 162 constant to plug into the equation of [RFC5348], 6.3.1. (The sender, 163 for example, uses a fixed value of 1 second when it can not obtain an 164 initial RTT sample, compare [RFC5348], 4.2). 166 In particular, if the loss is caused by a transient condition, this 167 fourth problem causes a subsequent deterioration of the connection 168 (rate reduction), further aggravated by the fact that TFRC takes 169 longer than common window-based protocols to recover from a reduction 170 of its allowed sending rate. 172 The fifth and last problem is starvation under burst loss, caused for 173 instance by a sudden interference in a wireless transmission. The 174 resulting burst loss sets off a vicious circle, where link-layer 175 retransmissions and transmitter-backoff procedures and/or reverse- 176 path loss eventually cause the nofeedback timer to be triggered at 177 the sender. This in turn halves the sending rate, thereby doubling 178 the inter-packet gap. Which in turn decreases X_recv sampled via RTT 179 at the receiver. These factors contribute to an accelerated 180 reduction of the sending rate towards zero, or rather 1 packet per 64 181 seconds (t_mbi). Under these conditions the connection is no longer 182 in a usable state, unless buffering of more than 64 seconds (more is 183 required because the sending rate is low) can be applied, which is 184 impossible for interactive applications, and unacceptable for many 185 audio/video applications. 187 Trying to smooth over these effects by imposing heavy filtering on 188 the RTT samples did not substantially improve the situation, nor does 189 it solve the problem of under-sampling. 191 We are not aware of an alternative (published) algorithm to better 192 estimate the RTT at the receiver. 194 The TFRC sender, on the other hand, is much better equipped to 195 estimate the RTT and can do this more accurately. This is in 196 particular due to the use of timestamps and elapsed time information 197 ([RFC5348], 3.2.2), which are mandatory in CCID-3 (sections 6 and 8.2 198 of [RFC4342]). 200 2.2. Other areas affected by the RTT sampling problems 202 We here analyse the impact that unreliability of receiver-based RTT 203 sampling has on the areas listed at the begin of this section. 205 In addition, benefits of sender-based RTT sampling have already been 206 pointed out in [RFC5348], and in the specification of CCID-3 207 [RFC4342], at the end of section 10.2. 209 2.2.1. Measured Receive Rate X_recv 211 A key problem is that the reliability of X_recv [RFC4342] depends 212 directly upon the reliability and accuracy of RTT samples. This 213 means that failures propagate from one parameter to another. 215 Errata IDs 610 and 611 update [RFC4342] to use the definition of the 216 receive rate as specified in [RFC5348]. 218 Having an explicit (rather than a coarse-grained) RTT estimate allows 219 measurement of X_recv with greater accuracy, and isolates failure. 221 An explicit RTT estimate also enables the receiver to more accurately 222 perform the test in step (2) of [RFC4342], 6.2, i.e. to check whether 223 less or more than one RTT has passed since the last feedback. 225 2.2.2. Disambiguation and Accuracy of Loss Intervals 227 Since a loss event is defined as one or more lost (ECN-marked) data 228 packets in one RTT ([RFC5348], 5.2), the receiver needs accurate RTT 229 estimates to validate and accurately separate loss events. Moreover, 230 [RFC5348], 5.2 expressly points out the sender RTT estimate as 231 RECOMMENDED for this purpose. 233 Having the sender RTT Estimate available further increases the 234 accuracy of the information reported by the receiver. The definition 235 of Loss Intervals in [RFC4342], 6.1 needs the RTT to separate the 236 lossy parts; in particular, lossy parts spanning a period of more 237 than one RTT are invalid. 239 A similar benefit arises in the computation of the loss event rate: 240 as discussed in section 9.2 of [RFC4342], it may happen that sender 241 and receiver compute different loss event rates, due to differences 242 in the available timing information. An explicit RTT estimate 243 increases the accuracy of information available at the receiver, thus 244 the sender may not need to recompute the (less reliable) loss event 245 rate reported by the receiver. 247 2.2.3. Determining Quiescence 249 The quiescence period is defined as max(2 * RTT, 0.2 sec) in section 250 6.4 of [RFC4342]. An explicit RTT estimate avoids under- and over- 251 estimating quiescence periods. 253 2.2.4. Practical Considerations 255 Using explicit RTT estimates contributes to greater robustness and 256 can also result in simpler implementation: 258 First, it becomes easier to separate adjacent loss events. The 4-bit 259 counter value wraps relatively frequently, which requires complex 260 computations to avoid aliasing effects. 262 Second, the receiver is better able to determine when to send 263 feedback packets. It can perform the test described in step (2) of 264 [RFC5348], 6.2 more accurately. Moreover, unnecessary expiration of 265 the nofeedback timer (as described in [RFC4342], 10.3) can be 266 avoided. 268 Lastly, a sender-based RTT estimate option can be used by middleboxes 269 for verification [RFC4342], 10.2. 271 3. Specification 273 3.1. Conventions 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 277 document are to be interpreted as described in [RFC2119]. 279 This document uses the conventions of [RFC5348], [RFC4340], 280 [RFC4342], and [RFC5622]. 282 3.2. Options and Features 284 This document defines a single TFRC-specific option, RTT Estimate, 285 described in the next subsection. 287 Following the guidelines in [RFC4340], section 15, the use of the RTT 288 Estimate option is governed by an associated feature, Send RTT 289 Estimate. This feature is described in the second subsection. 291 3.2.1. RTT Estimate Option 293 The sender communicates its current RTT estimate to the receiver 294 using a RTT Estimate option. 296 ==> RFC Editor's Note: 298 Please replace 'XX' with IANA value when published and delete this 299 note. 301 +------+---------------+--------------+------------+ 302 | Type | Option Length | Meaning | DCCP Data? | 303 +------+---------------+--------------+------------+ 304 | XX | 6 | RTT Estimate | Y | 305 +------+---------------+--------------+------------+ 307 Table 1: The RTT Estimate option defined by this document 309 Column meanings are as per [RFC4340], section 5.8 (table 3). This 310 option is permitted in any DCCP packet, has option number XX and a 311 length of 6 bytes. 313 +--------+--------+--------+--------+--------+--------+ 314 |xxxxxxxx|00000110| Sender RTT Estimate | 315 +--------+--------+--------+--------+--------+--------+ 316 Type=XX Length=6 318 The four bytes of option data carry the current RTT estimate of the 319 sender, using a granularity of 1 microsecond (senders sampling with a 320 lower resolution can multiply their RTT estimates to achieve this 321 granularity). 323 A value of zero indicates that the sender does not have a valid RTT 324 sample yet. 326 Senders SHOULD send long-term RTT estimates (sampled over a longer 327 period of time) rather than instantaneous RTT samples. 329 3.2.2. Send RTT Estimate Feature 331 The Send RTT Estimate feature lets endpoints negotiate whether the 332 sender MUST provide RTT Estimate options on its data packets. 334 ==> RFC Editor's Note: 336 Please replace 'YY' with IANA value when published and delete this 337 note. 339 Send RTT Estimate has feature number YY and is server-priority. It 340 takes one-byte Boolean values. Values greater than 1 are invalid and 341 MUST be ignored. 343 +--------+-------------------+------------+---------------+-------+ 344 | Number | Meaning | Rec'n Rule | Initial Value | Req'd | 345 +--------+-------------------+------------+---------------+-------+ 346 | YY | Send RTT Estimate | SP | 0 | N | 347 +--------+-------------------+------------+---------------+-------+ 349 Table 2: The Send RTT Estimate feature defined by this document 351 The column meanings are described in [RFC4340], section 6.4. In 352 particular, the feature is by default off (initial value of 0), and 353 the extension is not required to be understood by every DCCP 354 implementation (cf. [RFC4340], section 15). 356 DCCP B sends a "Change R(Send RTT Estimate, 1)" to ask DCCP A to send 357 RTT Estimate options as part of its data traffic. 359 3.3. Usage 361 When the Send RTT Estimate Feature is enabled, the sender MUST 362 provide an RTT Estimate Option on all of its Data, DataAck, Sync, and 363 SyncAck packets. It MAY in addition provide the RTT Estimate Option 364 on other packet types, such as DCCP-Ack. 366 When the receiver has requested the use of the RTT Estimate Option, 367 it MUST use the RTT value reported by that option in all places that 368 require a RTT (listed at the begin of Section 2), and MUST NOT 369 estimate the RTT based on CCVal window counter values. The receiver 370 MAY keep a moving-average of these sender-based RTT estimates, in the 371 manner of [RFC5348], section 4.3. 373 When the Send RTT Estimate is disabled, the sender MUST NOT send RTT 374 Estimate options on any of its packets, the receiver MUST ignore the 375 RTT Estimate option on all incoming packets, and MUST try to estimate 376 the RTT in some other way (not specified by this document). 378 The sender MUST implement and continue to update CCVal window counter 379 RTT values as specified in [RFC4342], section 8.1, even when the Send 380 RTT Estimate Feature is on. 382 4. Security Considerations 384 Security considerations for CCID-3 have been discussed in section 11 385 of [RFC4342]; for CCID-4 these have been discussed in section 13 of 386 [RFC5622], referring back to the same section of [RFC4342]. 388 This document introduces an extension to communicate the current RTT 389 estimate of the sender to the receiver of a TFRC communication. 391 By altering the value of the RTT Estimate option, it is possible to 392 interfere with the behaviour of the flow. In particular, since 393 accuracy of the RTT estimate directly influences the accuracy of the 394 measured sending rate X_recv, it would be possible to obtain either 395 higher or lower sending rates than are warranted by the current 396 network conditions. 398 This is only possible if an attacker is on the same path as the DCCP 399 sender and receiver, and is able to guess valid sequence numbers. 400 Therefore the considerations in section 18 of [RFC4340] apply. 402 5. IANA Considerations 404 This document requests identical allocation in the dccp-ccid3- 405 parameters and the dccp-ccid4-parameters registries. 407 5.1. Option Types 409 This document defines a single CCID-specific option for communicating 410 RTT estimates from the HC-sender to the HC-receiver. Following 411 [RFC4340], 10.3, this requires an option number for the RTT Estimate 412 option in the range 128...191. 414 Note to IANA and the RFC editor 416 When the IANA has allocated an option number for the `RTT Estimate' 417 option, please replace all occurrences of the placeholder `XX' in 418 this text with that number and delete this note. 420 (Due to [RFC4340], 19.3 and [RFC4342], 12.2, the option number would 421 be allocated in the range 128...183/191.) 423 5.2. Feature Numbers 425 This document defines a single CCID-specific feature number for the 426 Send RTT Estimate feature which is located at the HC-sender. 427 Following [RFC4340], 10.3, a feature number in the range 128...191 is 428 required. 430 Note to IANA and the RFC editor 432 When the IANA has allocated an option number for the `Send RTT 433 Estimate' feature, please replace all occurrences of the placeholder 434 `YY' in this text with that number and delete this note. 436 (Due to [RFC4340], 19.4 and [RFC4342], 12.3, the feature number would 437 be allocated in the range 128...183/191.) 439 6. References 441 6.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 447 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 449 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 450 Datagram Congestion Control Protocol (DCCP) Congestion 451 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 452 March 2006. 454 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 455 Friendly Rate Control (TFRC): Protocol Specification", 456 RFC 5348, September 2008. 458 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 459 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 460 Control for Small Packets (TFRC-SP)", RFC 5622, 461 August 2009. 463 6.2. Informative References 465 [MR97] Mogul, J. and K. Ramakrishnan, "Eliminating Receive 466 Livelock in an Interrupt-Driven Kernel", ACM Transactions 467 on Computer Systems (TOCS), 15(3):217-252, August 1997. 469 Note to the RFC Editor: 471 Please remove the following Change Log when published, and delete 472 this note. 474 Appendix A. Change Log 476 This document is a rewrite of Revision 00. The wording has changed, 477 and as a result of more experience with CCID-3/4, the list of 478 problems has been added to. The specification itself remains 479 unchanged from Revision 00. 481 Authors' Addresses 483 Gerrit Renker 484 University of Aberdeen 485 Department of Engineering 486 Fraser Noble Building 487 Aberdeen AB24 3UE 488 Scotland 490 Email: gerrit@erg.abdn.ac.uk 491 URI: http://www.erg.abdn.ac.uk 493 Godred Fairhurst 494 University of Aberdeen 495 Department of Engineering 496 Fraser Noble Building 497 Aberdeen AB24 3UE 498 Scotland 500 Email: gorry@erg.abdn.ac.uk 501 URI: http://www.erg.abdn.ac.uk