idnits 2.17.1 draft-ietf-dccp-tfrc-rtt-option-06.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 (April 19, 2011) is 4753 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 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 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) April 19, 2011 6 Intended status: Standards Track 7 Expires: October 21, 2011 9 Sender RTT Estimate Option for DCCP 10 draft-ietf-dccp-tfrc-rtt-option-06.txt 12 Abstract 14 This document specifies an update to the round trip time (RTT) 15 estimation algorithm used for TFRC (TCP Friendly Rate Control) 16 congestion control by the Datagram Congestion Control Protocol 17 (DCCP). It updates specifications for the CCID-3 and CCID-4 18 Congestion Control IDs of DCCP. 20 The update addresses parameter-estimation problems occurring with 21 TFRC-based DCCP congestion control. It uses a recommendation made in 22 the original TFRC specification to avoid the inherent problems of 23 receiver-based RTT sampling, by utilising higher-accuracy RTT samples 24 already available at the sender. 26 It is integrated into the feature set of DCCP as an end-to-end 27 negotiable extension. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 21, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problems caused by sampling the RTT at the receiver . . . . . 4 65 2.1. List of problems encountered with a real implementation . 4 66 2.2. Other areas affected by the RTT sampling problems . . . . 5 67 2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 6 68 2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 6 69 2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 6 70 2.2.4. Practical Considerations . . . . . . . . . . . . . . . 6 71 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2. Options and Features . . . . . . . . . . . . . . . . . . . 8 74 3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 8 75 3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 11 76 3.3. Basic Usage . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.4. Receiver Robustness Measures . . . . . . . . . . . . . . . 13 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 16 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 1. Introduction 89 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 90 transport protocol for connection-oriented, unreliable, and 91 congestion-controlled datagram delivery. In DCCP, an application has 92 a choice of congestion control mechanisms, each specified by a 93 Congestion Control Identifier (CCID, [RFC4340], sec. 10). 95 This document defines a Standards Track update to the sender and 96 receiver sides of two rate-based DCCP congestion control IDs: CCID-3 97 [RFC4342] and the Experimental CCID-4 variant [RFC5622]. 99 Both CCIDs are based on the principles of TCP-Friendly Rate Control 100 (TFRC) [RFC5348], which performs rate-based congestion control. Its 101 feedback mechanism differs from that used by window-based congestion 102 control such as in TCP. As a consequence, in TFRC the feedback may 103 be sent less frequently (e.g., once per Round-Trip Time (RTT)). 104 Furthermore, a measured RTT estimate is directly used as the basis 105 for computing the (TCP-friendly) transmission rate. 107 In TFRC-based protocols packets are rate-paced over a RTT, instead of 108 allowing them to be sent back-to-back as they could be in TCP, thus 109 accurate RTT estimation is important to ensure appropriate pacing at 110 the sender. 112 The original specifications for CCID-3 and CCID-4, in [RFC4342] and 113 [RFC5622], both estimate the RTT at the receiver, using an algorithm 114 based on the cyclic 4-bit window counter of the DCCP CCVal header. 115 The method has implications that have been observed when using 116 applications over DCCP implementations, resulting in infrequent and 117 inaccurate RTT measurement. 119 This update addresses these RTT estimation problems by providing a 120 solution based on a concept first recommended in [RFC5348], 3.2.1; 121 i.e. to measure the RTT at the sender. That approach results in a 122 higher reliability and frequency of samples, and avoids the inherent 123 problems of receiver-based RTT sampling discussed below. 125 The document begins by analysing the encountered problems in the next 126 section. The update is presented in Section 3. We then discuss 127 security considerations in Section 4, and list the resulting IANA 128 considerations in Section 5. 130 2. Problems caused by sampling the RTT at the receiver 132 There are at least six areas that make a TFRC receiver vulnerable to 133 inaccuracies or absence of (receiver-based) RTT samples: 135 o the measured sending rate, X_recv ([RFC5348], 6.2); 137 o synthesis of the first loss interval ([RFC5348], 6.3.1); 139 o disambiguation of loss events ([RFC4342], 10.2); 141 o validation of loss intervals ([RFC4342], 6.1); 143 o ensuring that at least one feedback packet is sent per RTT 144 ([RFC4342], 10.3); 146 o determining quiescence periods ([RFC4342], 6.4). 148 2.1. List of problems encountered with a real implementation 150 This section summarizes several years of experience using the Linux 151 implementation of CCID-3 and CCID-4. It lists the problems 152 encountered with receiver-based RTT sampling over real networks, in a 153 variety of wired and wireless environments and under different link- 154 layer conditions. 156 The Linux DCCP/TFRC implementation is based on the RTT-sampling 157 algorithm specified in [RFC4342], 8.1. This algorithm relies on a 158 coarse-grained window-counter (units of RTT/4), and uses packet 159 inter-arrival times to estimate the current RTT of the network. 161 The algorithm is effective only for packets with modulo-16 CCVal 162 differences less than 5, due to limitations noted in sections 8.1 and 163 10.3 of [RFC4342]. A CCVal difference less than 4 means sampling at 164 sub-RTT scale; [RFC4342], 8.1 thus suggests differences between 2 and 165 4, the latter being preferable (equivalent to a full RTT). The same 166 section limits the maximum CCVal difference between data-carrying 167 packets to 5, in order to avoid wrap-around. As a consequence, it is 168 not possible to determine the timing interval for adjacent packets 169 with a CCVal difference greater than 4: such samples have to be 170 discarded. 172 A second problem arises when there are holes in the sequence space. 173 Because the 4-bit CCVal counter may cycle around multiple times, it 174 is not possible to determine window-counter wrap-around whenever 175 sequence numbers of subsequent packets are not immediately adjacent. 176 This problem occurs when packets are delayed, reordered, or lost in 177 the network. 179 As a consequence, RTT sampling has to be paused during times of loss. 180 This however aggravates the problem, since the sender now requires 181 new feedback from the receiver, but the receiver is unable to provide 182 accurate and up-to-date information: the receiver is unable to sample 183 the RTT, accordingly also not able to estimate X_recv correctly, 184 which then in turn affects X_Bps at the sender. 186 The third limitation arises from using inter-arrival times as 187 representatives of network inter-packet gaps. It is well known that 188 the inter-packet gap of packets is not constant along a network path. 189 Furthermore, modern network interface cards do not necessarily 190 deliver each packet at the time it is received, but rather in a 191 bunch, to avoid overly frequent interrupts [MR97]. As a result, 192 inter-packet arrival times may converge to zero, when subsequent 193 packets are being delivered at virtually the same time. 195 The fourth problem is that of under-sampling and thus related to the 196 first limitation. If loss occurs while the receiver has not yet had 197 a chance to sample the RTT, it needs to fall back to some fixed RTT 198 constant to plug into the equation of [RFC5348], 6.3.1. (The sender, 199 for example, uses a fixed value of 1 second when it is unable to 200 obtain an initial RTT sample, see [RFC5348], 4.2). 202 In particular, if the loss is caused by a transient condition, this 203 fourth problem causes a subsequent deterioration of the connection 204 (rate reduction), further aggravated by the fact that TFRC takes 205 longer than common window-based protocols to recover from a reduction 206 of its allowed sending rate. 208 Trying to smooth over these effects by imposing heavy filtering on 209 the RTT samples did not substantially improve the situation, nor does 210 it solve the problem of under-sampling. 212 The TFRC sender, on the other hand, is much better equipped to 213 estimate the RTT and can do this more accurately. This is in 214 particular due to the use of timestamps and elapsed time information 215 ([RFC5348], 3.2.2), which are mandatory in CCID-3 (sections 6 and 8.2 216 of [RFC4342]). 218 2.2. Other areas affected by the RTT sampling problems 220 We here analyse the impact that unreliability of receiver-based RTT 221 sampling has on the areas listed at the begin of this section. 223 In addition, benefits of sender-based RTT sampling have already been 224 pointed out in [RFC5348], and in the specification of CCID-3 225 [RFC4342], at the end of section 10.2. 227 2.2.1. Measured Receive Rate X_recv 229 A key problem is that the reliability of X_recv [RFC4342] depends 230 directly upon the reliability and accuracy of RTT samples. This 231 means that failures propagate from one parameter to another. 233 Errata IDs 610 and 611 update [RFC4342] to use the definition of the 234 receive rate as specified in [RFC5348]. 236 Having an explicit (rather than a coarse-grained) RTT estimate allows 237 measurement of X_recv with greater accuracy, and isolates failure. 239 An explicit RTT estimate also enables the receiver to more accurately 240 perform the test in step (2) of [RFC4342], 6.2, i.e. to check whether 241 less or more than one RTT has passed since the last feedback. 243 2.2.2. Disambiguation and Accuracy of Loss Intervals 245 Since a loss event is defined as one or more lost (or ECN-marked) 246 data packets in one RTT ([RFC5348], 5.2), the receiver needs accurate 247 RTT estimates to validate and accurately separate loss events. 248 Moreover, [RFC5348], 5.2 expressly points out the sender RTT estimate 249 as RECOMMENDED for this purpose. 251 Having the sender RTT Estimate available further increases the 252 accuracy of the information reported by the receiver. The definition 253 of Loss Intervals in [RFC4342], 6.1 needs the RTT to separate the 254 lossy parts; in particular, lossy parts spanning a period of more 255 than one RTT are invalid. 257 A similar benefit arises in the computation of the loss event rate: 258 as discussed in section 9.2 of [RFC4342], it may happen that sender 259 and receiver compute different loss event rates, due to differences 260 in the available timing information. An explicit RTT estimate 261 increases the accuracy of information available at the receiver, thus 262 the sender may not need to recompute the (less reliable) loss event 263 rate reported by the receiver. 265 2.2.3. Determining Quiescence 267 The quiescence period is defined as max(2 * RTT, 0.2 sec) in section 268 6.4 of [RFC4342]. An explicit RTT estimate avoids under- and over- 269 estimating quiescence periods. 271 2.2.4. Practical Considerations 273 Using explicit RTT estimates contributes to greater robustness and 274 can also result in simpler implementation. 276 First, it becomes easier to separate adjacent loss events. The 4-bit 277 counter value wraps relatively frequently, which requires additional 278 procedures to avoid aliasing effects. 280 Second, the receiver is better able to determine when to send 281 feedback packets. It can perform the test described in step (2) of 282 [RFC5348], 6.2 more accurately. Moreover, unnecessary expiration of 283 the nofeedback timer (as described in [RFC4342], 10.3) can be 284 avoided. 286 Lastly, a sender-based RTT estimate option can be used by middleboxes 287 to verify that a flow uses conforming end-to-end congestion control 288 ([RFC4342], 10.2). 290 3. Specification 292 3.1. Conventions 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in [RFC2119]. 298 This document uses the conventions of [RFC5348], [RFC4340], 299 [RFC4342], and [RFC5622]. 301 All multi-byte field descriptions presented in this documented are in 302 network byte order (most significant byte first). 304 3.2. Options and Features 306 This document defines a single TFRC-specific option, RTT Estimate, 307 described in the next subsection. 309 Following the guidelines in [RFC4340], section 15, the use of the RTT 310 Estimate Option is governed by an associated feature, Send RTT 311 Estimate Feature. This feature is described in the second 312 subsection. 314 3.2.1. RTT Estimate Option 316 The sender communicates its current RTT estimate to the receiver 317 using a RTT Estimate Option. 319 ==> RFC Editor's Note: 321 Please replace 'XX' with IANA value when published and delete this 322 note. 324 +------+---------------+--------------+------------+ 325 | Type | Option Length | Meaning | DCCP Data? | 326 +------+---------------+--------------+------------+ 327 | XX | 3/4/5 | RTT Estimate | Y | 328 +------+---------------+--------------+------------+ 330 Table 1: The RTT Estimate Option defined by this document 332 Column meanings are as per [RFC4340], section 5.8 (table 3). This 333 option MAY be placed in any DCCP packet, has option number XX and a 334 length of 3-5 bytes. 336 A Sender RTT Estimate Option is valid if it satisfies one of the 337 three following formats: 339 ==> RFC Editor's Note: 341 Please replace 'xxxxxxxx' below with the binary representation of the 342 IANA 'Type' value (indicated in decimal as 'XX') when published and 343 delete this note. 345 +--------+--------+--------+ 346 |xxxxxxxx|00000011| RTT | 347 +--------+--------+--------+ 348 Type=XX Length=3 Estimate 350 +--------+--------+--------+--------+ 351 |xxxxxxxx|00000100| RTT | 352 +--------+--------+--------+--------+ 353 Type=XX Length=4 Estimate 355 +--------+--------+--------+--------+--------+ 356 |xxxxxxxx|00000101| RTT | 357 +--------+--------+--------+--------+--------+ 358 Type=XX Length=5 Estimate 360 The 1..3 value bytes of the option data carry the current RTT 361 estimate of the sender, using a granularity of 1 microsecond. This 362 allows values up to 16.7 seconds (corresponding to 0xFFFFFE) to be 363 communicated. 365 A sender capable of sampling at sub-microsecond granularity SHOULD 366 round up RTT samples to the next microsecond, to avoid under- 367 estimating the RTT. 369 The value 0xFFFFFF is reserved to indicate significant delay spikes, 370 larger than 16.7 seconds. This is qualitative rather than 371 quantitative information, to alert the receiver that there is a 372 network problem (for instance jamming on a wireless channel). 374 The use of the RTT Estimate Option on networks with RTTs larger than 375 16.7 seconds is not specified by this document (as per Section 3.3, 376 the sender would then always report 0xFFFFFF). 378 A value of 0 indicates the absence of a valid RTT sample. The sender 379 MUST set the value to 0 if it does not yet have an RTT estimate. RTT 380 estimates of less than 1 microsecond MUST be reported as 1 381 microsecond. 383 The sender SHOULD select the smallest format suitable to carry the 384 RTT estimate (i.e., less than 1 byte of leading zeroes). 386 3.2.2. Send RTT Estimate Feature 388 The Send RTT Estimate feature lets endpoints negotiate whether the 389 sender MUST provide RTT Estimate options on its data packets. 391 ==> RFC Editor's Note: 393 Please replace 'YY' with IANA value when published and delete this 394 note. 396 Send RTT Estimate has feature number YY and is server-priority. It 397 takes one-byte Boolean values; values greater than 1 are reserved. 399 +--------+-------------------+------------+---------------+-------+ 400 | Number | Meaning | Rec'n Rule | Initial Value | Req'd | 401 +--------+-------------------+------------+---------------+-------+ 402 | YY | Send RTT Estimate | SP | 0 | N | 403 +--------+-------------------+------------+---------------+-------+ 405 Table 2: The Send RTT Estimate feature defined by this document 407 The column meanings are described in [RFC4340], section 6.4. 409 The Send RTT Estimate feature is OPTIONAL. An extension may 410 implement it, but this specification does not require the feature to 411 be understood by every DCCP implementation (see [RFC4340], section 412 15). The feature is off by default (initial value of 0). 414 DCCP B sends a "Mandatory Change R(Send RTT Estimate, 1)" to require 415 DCCP A to send RTT Estimate options as part of its data traffic (DCCP 416 A will reset the connection if it does not understand this feature). 418 3.3. Basic Usage 420 When the Send RTT Estimate Feature is enabled, the sender MUST 421 provide an RTT Estimate Option on all of its Data, DataAck, Sync, and 422 SyncAck packets. It MAY in addition provide the RTT Estimate Option 423 on other packet types, such as DCCP-Ack. If the RTT is larger than 424 the maximum representable value (0xFFFFFE), the sender MUST set the 425 value of the RTT Estimate Option to 0xFFFFFF. 427 The sender MUST implement and continue to update the CCVal window 428 counter as specified in [RFC4342], section 8.1, even when the Send 429 RTT Estimate Feature is on. 431 When the Send RTT Estimate Feature is enabled, the receiver MUST use 432 the value reported by the RTT Estimate Option in all places that 433 require a RTT (listed at the begin of Section 2). If the receiver 434 encounters an invalid RTT Estimate Option (Section 3.2.1), it MUST 435 reset the connection with Reset Code 5, "Option Error", where the 436 Data 1..3 fields are set to the first 3 bytes of the offending RTT 437 Estimate Option. 439 The receiver SHOULD track the long-term RTT estimate using a moving 440 average, such as the one specified in [RFC5348], 4.3. This long-term 441 estimate is referred to as "receiver_RTT" below. 443 When the Send RTT Estimate Feature is disabled, the receiver MUST 444 estimate the RTT as previously specified in [RFC4340], [RFC4342], and 445 [RFC5622]. 447 3.4. Receiver Robustness Measures 449 This subsection specifies robustness measures for the receiver when 450 the Send RTT Estimate Feature is on. 452 The 0-valued and 0xFFFFFF-valued RTT Estimate Options are both 453 referred to as "no-number RTT options". RTT Estimate Options with 454 values in the range of 1..0xFFFFFE are analogously called "numeric 455 RTT options". 457 Until the first numeric RTT option arrives, the receiver MUST use a 458 value of 0.5 seconds for receiver_RTT (to match the initial 2 second 459 timeout of the TFRC nofeedback timer, [RFC5348], 4.2). 461 If the path RTT is known, e.g. from a previous connection [RFC2140], 462 the receiver MAY reuse the previously known path RTT value to seed 463 its long-term RTT estimate. 465 The sender MAY occasionally send no-number RTT options, covering for 466 transient changes and spurious disruptions. During these times, the 467 receiver SHOULD continue to use its long-term receiver_RTT value. 469 To avoid under-estimating the RTT in the absence of numeric options, 470 the receiver MUST back off receiver_RTT in the following manner: if 471 the sender supplies no-number RTT options for longer than 472 receiver_RTT units of time, the receiver sets 474 receiver_RTT = MIN(2 * receiver_RTT, t_mbi) 476 where t_mbi = 64 seconds is the maximum backoff interval ([RFC5348], 477 Appendix A). For the next round of no-number RTT options, the 478 updated value of receiver_RTT applies. 480 This back-off mechanism ensures that short-term disruptions do not 481 have a lasting impact, whereas long-term problems will result in 482 asymptotically high receiver_RTT values. 484 To bail out from a hanging session, the receiver MAY close the 485 connection when receiver_RTT has reached the value MAX_RTT. 487 4. Security Considerations 489 Security considerations for CCID-3 have been discussed in section 11 490 of [RFC4342]; for CCID-4 these have been discussed in section 13 of 491 [RFC5622], referring back to the same section of [RFC4342]. 493 This document introduces an extension to communicate the current RTT 494 estimate of the sender to the receiver of a TFRC communication. 496 By altering the value of the RTT Estimate Option, it is possible to 497 interfere with the behaviour of a flow using TFRC. In particular, 498 since accuracy of the RTT estimate directly influences the accuracy 499 of the measured sending rate X_recv, it would be possible to obtain 500 either higher or lower sending rates than are warranted by the 501 current network conditions. 503 This is only possible if an attacker is on the same path as the DCCP 504 sender and receiver, and is able to guess valid sequence numbers. 505 Therefore the considerations of section 18 in [RFC4340] apply. 507 5. IANA Considerations 509 This document requests identical allocation in the dccp-ccid3- 510 parameters and the dccp-ccid4-parameters registries. 512 5.1. Option Types 514 This document defines a single CCID-specific option for communicating 515 RTT estimates from the HC-sender to the HC-receiver. Following 516 [RFC4340], 10.3, this requires an option number for the RTT Estimate 517 Option in the range 128...191. 519 Note to IANA and the RFC editor 521 When the IANA has allocated an option number for the `RTT Estimate' 522 option, please replace all occurrences of the placeholder `XX' in 523 this text with that number and delete this note. (Due to [RFC4340], 524 19.3 and [RFC4342], 12.2, the option number would be allocated in the 525 range 128...183/191.) 527 5.2. Feature Numbers 529 This document defines a single CCID-specific feature number for the 530 Send RTT Estimate feature which is located at the HC-sender. 531 Following [RFC4340], 10.3, a feature number in the range 128...191 is 532 required. 534 Note to IANA and the RFC editor 536 When the IANA has allocated an option number for the `Send RTT 537 Estimate' feature, please replace all occurrences of the placeholder 538 `YY' in this text with that number and delete this note. (Due to 539 [RFC4340], 19.4 and [RFC4342], 12.3, the feature number would be 540 allocated in the range 128...183/191.) 542 6. References 544 6.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 550 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 552 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 553 Datagram Congestion Control Protocol (DCCP) Congestion 554 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 555 March 2006. 557 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 558 Friendly Rate Control (TFRC): Protocol Specification", 559 RFC 5348, September 2008. 561 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 562 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 563 Control for Small Packets (TFRC-SP)", RFC 5622, 564 August 2009. 566 6.2. Informative References 568 [MR97] Mogul, J. and K. Ramakrishnan, "Eliminating Receive 569 Livelock in an Interrupt-Driven Kernel", ACM Transactions 570 on Computer Systems (TOCS), 15(3):217-252, August 1997. 572 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 573 April 1997. 575 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION 577 The following changelog lists the changes since revision 01 of the 578 preceding individual submission draft-renker-dccp-tfrc-rtt-option. 580 o General: 582 - added detailed changelog to track comments 584 - changed document name to reflect working group 586 - updated date to October 588 - made spelling of RTT Estimate Option (singular) consistent 590 - moved reference to RFC 5622 from normative to informative, 591 since document status is Experimental 593 o Section 2.1: 595 - clarified problematic cases of too small CCVal differences 596 and CCVal differences > 4, feedback by Pasi 598 o Section 3.1: 600 - clarified the byte ordering used by this document, feedback 601 by Pasi 603 o Section 3.2: 605 - corrected naming of Send RTT Estimate Feature, feedback by 606 Eddie 608 - removed superfluous remark regarding scaling to microsecond 609 granularity in 3.2.1, feedback by Pasi 611 - removed recommendation of preferring long-term RTT samples, 612 since this can not be generalized (connection may be short or 613 path RTT may change, in both cases a long-term sample would not 614 be useful), feedback by Pasi 616 - made option variable-length (3/4/5 bytes), feedback by Eddie 618 - specified condition for syntactic option validity 620 - limited the maximum option size to 3 bytes and justified 621 decision why not to support RTTs greater than 16 seconds, in 622 reply to feedback by Eddie 623 - clarified that the sender MUST use 0 to indicate absence of a 624 valid RTT estimate 626 - clarified the highest path RTT value supported by this 627 document (16.7 sec) 629 - reserved 0xFFFFFF as special value to communicate out-of- 630 bounds exceptions, network problems resulting in 631 disproportionately high delay spikes (> 16.7 seconds) 633 o Section 3.3: 635 - corrected naming of Send RTT Estimate Feature, feedback by 636 Eddie 638 - specified what happens if invalid RTT Estimate options are 639 received 641 - specified what happens if the sender persistently sends 642 0-valued RTT Estimate options, feedback by Eddie 644 - specified how the exceptional value 0xFFFFFF should be 645 handled 647 - added reference for reusing previously known path RTT value 649 Changes between revision 00 and 01 of this draft: 651 o General changes: 653 - incremented date and revision number 655 - various minor changes of syntax, typos, and paragraph 656 formatting 658 o Section 2.1: 660 - completely rewrote the description of the fifth problem in 661 order to more clearly/precisely identify problem causes, 662 following feedback from Michael 664 o Section 2.2.4: 666 - simplified sentence referring to aliasing effects (implicitly 667 referencing section 10.2 of RFC4342) 669 - clarified how middleboxes might use a sender-based RTT 670 estimate option to verify end-to-end congestion control 671 (suggestion and quote taken from RFC4342, section 10.2) 673 o Section 3.3: 675 - clarified how the receiver must behave if the Send RTT 676 Estimate Feature is disabled, following feedback from Eddie 678 - removed the requirement that the receiver should additionally 679 track CCVal window counter values when the Send RTT Estimate 680 Feature is on 682 - removed suggestion that the receiver should take measures to 683 improve the quality of the connection, feedback by Michael 685 - moved all receiver robustness measures to the new section 3.4 687 - changed section title to reflect restructuring of content 689 o Section 3.4: 691 - new section, written from scratch, to address the 692 shortcomings of the previous scheme, which were identified by 693 Michael Welzl 695 - specifies what to do when the sender supplies no-number RTT 696 options for short and extended periods of time 698 Changes between revision 01 and 02 of this draft: 700 o General: 702 - incremented date and revision number 704 - removed compatibility clause in abstract 706 o Section 1: 708 - corrected placement of references, feedback from Eddie 710 o Section 2.1: 712 - removed description of a problem observed with CCID-3 over an 713 802.11 link (reduction of sending rate towards zero after a 714 short channel outage), since causes of the problem were not 715 conclusively understood 717 o Section 3.2.2: 719 - clarified that values of 2 of the Send RTT Estimate feature 720 are reserved, feedback from Eddie 722 - fixed the issue of handling invalid values of the Send RTT 723 Estimate feature by using mandatory feature negotiation 724 ([RFC4340], sec. 6.6.9), thanks to a suggestion by Eddie 726 o Section 3.3: 728 - clarified receiver behaviour when the Send RTT Estimate 729 feature is enabled, feedback from Eddie 731 Changes between revision 02 and 03 of this draft: 733 o Section 3.2.2: 735 - clarified the use of Mandatory Feature Negotiation, feedback 736 from Eddie 738 Changes between revision 03 and 04 of this draft: 740 o Abstract: 742 - clarified that the document updates the specifications of 743 CCID-3 and CCID-4, AD review 745 - changed wording so that all abbreviations are defined 747 - Changelog: fixed typos, AD review 749 o Section 2: 751 - fixed grammatical nits in section 2.1, AD review 753 - clarified meaning of lost vs ECN-marked packets in section 754 2.2.2, AD review 756 o Section 3: 758 - clarified normative applicability of option for packet types 759 in section 3.2.1, AD review 761 - added a note to the RFC editor to also update the binary 762 representation of the Type value for the RTT Estimate Option in 763 section 3.2.1 764 - clarified optional nature of Send RTT Estimate feature in 765 section 3.2.2, AD review 767 - clarified normative use of initial value of receiver_RTT in 768 section 3.4, AD review 770 - clarified normative applicability of no-number RTT options in 771 section 3.4, AD review 773 - clarified normative applicability of receiver_RTT back-off 774 scheme in section 3.4, AD review 776 o Changelog: 778 - fixed typos, AD review 780 Changes between revision 04 and 05 of this draft: 782 o Section 3.2.1: 784 - added an explanation to indicate what happens in the 785 pathological case of a network having an RTT larger than 16.7 786 seconds, feedback from Brian Carpenter 788 o Section 3.3: 790 - clarified that the sender MUST use the no-number RTT Estimate 791 Option of value 0xFFFFFF if the RTT is larger than the maximum 792 representable value, feedback from Brian Carpenter 794 Changes between revision 05 and 06 of this draft: 796 o General: 798 - made RFC 5622 normative (rather than informative) reference, 799 since it is being updated by this document 801 o Section 1: 803 - added introductory description of problem background, 804 rationale, and relevant document references, feedback from Mark 805 Allman 807 - clarified that the referenced CCID-4 profile (RFC 5622) has 808 Experimental status, feedback from Gonzalo Camarillo 810 o Section 3.2.1: 812 - specified that, where possible, sub-microsecond RTT samples 813 should be rounded up to the next microsecond value, feedback 814 from Adrian Farrel 816 - clarified how RTTs of less than 1 microsecond should be 817 reported, in response to feedback from Adrian Farrel 819 ====> END OF NOTE TO THE RFC EDITOR <==== 821 Authors' Addresses 823 Gerrit Renker 824 University of Aberdeen 825 School of Engineering 826 Fraser Noble Building 827 Aberdeen AB24 3UE 828 Scotland 830 Email: gerrit@erg.abdn.ac.uk 831 URI: http://www.erg.abdn.ac.uk 833 Godred Fairhurst 834 University of Aberdeen 835 School of Engineering 836 Fraser Noble Building 837 Aberdeen AB24 3UE 838 Scotland 840 Email: gorry@erg.abdn.ac.uk 841 URI: http://www.erg.abdn.ac.uk