DCCP Working Group G. Renker Internet-Draft G. Fairhurst Updates: 4342, 5622 University of Aberdeen (if approved) December 9, 2010 Intended status: Standards Track Expires: June 12, 2011 Sender RTT Estimate Option for DCCP draft-ietf-dccp-tfrc-rtt-option-01.txt Abstract This document describes an update to CCID-3/4 that addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. The fix uses a recommendation made in the original TFRC specification. It avoids the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender. It is integrated into the feature set of DCCP as an end-to-end negotiable extension, upward and downward compatible. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 12, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Renker & Fairhurst Expires June 12, 2011 [Page 1]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems caused by sampling the RTT at the receiver . . . . . 4 2.1. List of problems encountered with a real implementation . 4 2.2. Other areas affected by the RTT sampling problems . . . . 6 2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 6 2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 7 2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 7 2.2.4. Practical Considerations . . . . . . . . . . . . . . . 7 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Options and Features . . . . . . . . . . . . . . . . . . . 8 3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 8 3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 10 3.3. Basic Usage . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Receiver Robustness Measures . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Renker & Fairhurst Expires June 12, 2011 [Page 2]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 1. Introduction This document defines a Standards Track update to both a sender and receiver that implement DCCP CCID-3/4, addressing RTT estimation problems that were observed when using a real implementation [RFC4342], [RFC5622]. To fix these problems, this document presents a solution based on a concept first recommended in [RFC5348], 3.2.1; i.e. to measure the RTT at the sender. This results in a higher reliability and frequency of samples, and avoids the inherent problems of receiver- based RTT sampling discussed below. We begin by analysing the encountered problems in the next section. The update is presented in Section 3. We then discuss security considerations in Section 4, and list the resulting IANA considerations in Section 5. Renker & Fairhurst Expires June 12, 2011 [Page 3]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 2. Problems caused by sampling the RTT at the receiver There are at least six areas that make a TFRC receiver vulnerable to inaccuracies or absence of (receiver-based) RTT samples: o the measured sending rate, X_recv ([RFC5348], 6.2); o synthesis of the first loss interval ([RFC5348], 6.3.1); o disambiguation of loss events ([RFC4342], 10.2); o validation of loss intervals ([RFC4342], 6.1); o ensuring that at least one feedback packet is sent per RTT ([RFC4342], 10.3); o determining quiescence periods ([RFC4342], 6.4). 2.1. List of problems encountered with a real implementation This section summarizes several years of experience using the Linux implementation of CCID-3 and CCID-4. It lists the problems encountered with receiver-based RTT sampling over real networks, in a variety of wired and wireless environments and under different link- layer conditions. The Linux DCCP/TFRC implementation is based on the RTT-sampling algorithm specified in [RFC4342], 8.1. This algorithm relies on a coarse-grained window-counter (units of RTT/4), and uses packet inter-arrival times to estimate the current RTT of the network. The algorithm is effective only for packets with modulo-16 CCVal differences less than 5, due to limitations noted in sections 8.1 and 10.3 of [RFC4342]. A CCVal difference less than 4 means sampling at sub-RTT scale; [RFC4342], 8.1 thus suggests differences between 2 and 4, the latter being preferable (equivalent to a full RTT). The same section limits the maximum CCVal difference between data-carrying packets to 5, in order to avoid wrap-around. As a consequence, the timing interval for adjacent packets with a CCVal difference greater than 4 can not be determined: such samples have to be discarded. A second problem arises when there are holes in the sequence space. Because the 4-bit CCVal counter may cycle around multiple times, it is not possible to determine window-counter wrap-around whenever sequence numbers of subsequent packets are not immediately adjacent. This problem occurs when packets are delayed, reordered, or lost in the network. Renker & Fairhurst Expires June 12, 2011 [Page 4]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 As a consequence, RTT sampling has to be paused during times of loss. This however aggravates the problem, since the sender now requires new feedback from the receiver, but the receiver is unable to provide accurate and up-to-date information: the receiver is unable to sample the RTT, accordingly also not able to estimate X_recv correctly, which then in turn affects X_Bps at the sender. The third limitation arises from using inter-arrival times as representatives of network inter-packet gaps. It is well known that the inter-packet gap of packets is not constant along a network path. Furthermore, modern network interface cards do not necessarily deliver each packet at the time it is received, but rather in a bunch, to avoid overly frequent interrupts [MR97]. As a result, inter-packet arrival times may converge to zero, when subsequent packets are being delivered at virtually the same time. The fourth problem is that of under-sampling and thus related to the first limitation. If loss occurs while the receiver has not yet had a chance to sample the RTT, it needs to fall back to some fixed RTT constant to plug into the equation of [RFC5348], 6.3.1. (The sender, for example, uses a fixed value of 1 second when it can not obtain an initial RTT sample, see [RFC5348], 4.2). In particular, if the loss is caused by a transient condition, this fourth problem causes a subsequent deterioration of the connection (rate reduction), further aggravated by the fact that TFRC takes longer than common window-based protocols to recover from a reduction of its allowed sending rate. The fifth and last problem is an unfortunate interaction between nofeedback timer and sampling packet inter-arrivals at the receiver. Consider an example traffic channel that is temporarily unavailable for longer than 4 RTTs. The nofeedback timer at the sender will halve X after 4*RTT. At the same time, the RTT average at the sender will either remain unchanged (if no new sample arrived); or it will change at a much slower rate, due to the averaging described in point (2) of [RFC5348], 4.3. The value of RTT/4 used by the CCVal algorithm ([RFC4342], 8.1) therefore changes much slower than X. To the receiver this condition will look as if the inter-packet gap suddenly doubled, meaning it will use samples of twice the actual RTT. Thus the RTT averaged at the receiver (which typically also has fewer usable samples than the sender) increases accordingly. This in turn leads to a lower reported value of X_recv, which then further reduces the sending rate X allowed at the sender (in the worst case doubling the perceived RTT translates into halving X_recv). The consequence is that the inter-packet gap increases even further, Renker & Fairhurst Expires June 12, 2011 [Page 5]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 causing the process to repeat itself, until the sending rate converges to 1 packet per t_mbi=64 seconds. The above behaviour was observed on an 802.11 link where short holes of interference triggered repeated halving of the sending rate, until it terminated at 1 packet per 64 seconds. Under these conditions the connection is no longer in a usable state, unless buffering of more than 64 seconds is applied - which is impossible for interactive applications, and unacceptable for many audio/video applications. Trying to smooth over these effects by imposing heavy filtering on the RTT samples did not substantially improve the situation, nor does it solve the problem of under-sampling. The TFRC sender, on the other hand, is much better equipped to estimate the RTT and can do this more accurately. This is in particular due to the use of timestamps and elapsed time information ([RFC5348], 3.2.2), which are mandatory in CCID-3 (sections 6 and 8.2 of [RFC4342]). 2.2. Other areas affected by the RTT sampling problems We here analyse the impact that unreliability of receiver-based RTT sampling has on the areas listed at the begin of this section. In addition, benefits of sender-based RTT sampling have already been pointed out in [RFC5348], and in the specification of CCID-3 [RFC4342], at the end of section 10.2. 2.2.1. Measured Receive Rate X_recv A key problem is that the reliability of X_recv [RFC4342] depends directly upon the reliability and accuracy of RTT samples. This means that failures propagate from one parameter to another. Errata IDs 610 and 611 update [RFC4342] to use the definition of the receive rate as specified in [RFC5348]. Having an explicit (rather than a coarse-grained) RTT estimate allows measurement of X_recv with greater accuracy, and isolates failure. An explicit RTT estimate also enables the receiver to more accurately perform the test in step (2) of [RFC4342], 6.2, i.e. to check whether less or more than one RTT has passed since the last feedback. Renker & Fairhurst Expires June 12, 2011 [Page 6]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 2.2.2. Disambiguation and Accuracy of Loss Intervals Since a loss event is defined as one or more lost (ECN-marked) data packets in one RTT ([RFC5348], 5.2), the receiver needs accurate RTT estimates to validate and accurately separate loss events. Moreover, [RFC5348], 5.2 expressly points out the sender RTT estimate as RECOMMENDED for this purpose. Having the sender RTT Estimate available further increases the accuracy of the information reported by the receiver. The definition of Loss Intervals in [RFC4342], 6.1 needs the RTT to separate the lossy parts; in particular, lossy parts spanning a period of more than one RTT are invalid. A similar benefit arises in the computation of the loss event rate: as discussed in section 9.2 of [RFC4342], it may happen that sender and receiver compute different loss event rates, due to differences in the available timing information. An explicit RTT estimate increases the accuracy of information available at the receiver, thus the sender may not need to recompute the (less reliable) loss event rate reported by the receiver. 2.2.3. Determining Quiescence The quiescence period is defined as max(2 * RTT, 0.2 sec) in section 6.4 of [RFC4342]. An explicit RTT estimate avoids under- and over- estimating quiescence periods. 2.2.4. Practical Considerations Using explicit RTT estimates contributes to greater robustness and can also result in simpler implementation. First, it becomes easier to separate adjacent loss events. The 4-bit counter value wraps relatively frequently, which requires additional procedures to avoid aliasing effects. Second, the receiver is better able to determine when to send feedback packets. It can perform the test described in step (2) of [RFC5348], 6.2 more accurately. Moreover, unnecessary expiration of the nofeedback timer (as described in [RFC4342], 10.3) can be avoided. Lastly, a sender-based RTT estimate option can be used by middleboxes to verify that a flow uses conforming end-to-end congestion control ([RFC4342], 10.2). Renker & Fairhurst Expires June 12, 2011 [Page 7]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 3. Specification 3.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the conventions of [RFC5348], [RFC4340], [RFC4342], and [RFC5622]. All multi-byte field descriptions presented in this documented are in network byte order (most significant byte first). 3.2. Options and Features This document defines a single TFRC-specific option, RTT Estimate, described in the next subsection. Following the guidelines in [RFC4340], section 15, the use of the RTT Estimate Option is governed by an associated feature, Send RTT Estimate Feature. This feature is described in the second subsection. 3.2.1. RTT Estimate Option The sender communicates its current RTT estimate to the receiver using a RTT Estimate Option. Renker & Fairhurst Expires June 12, 2011 [Page 8]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 ==> RFC Editor's Note: Please replace 'XX' with IANA value when published and delete this note. +------+---------------+--------------+------------+ | Type | Option Length | Meaning | DCCP Data? | +------+---------------+--------------+------------+ | XX | 3/4/5 | RTT Estimate | Y | +------+---------------+--------------+------------+ Table 1: The RTT Estimate Option defined by this document Column meanings are as per [RFC4340], section 5.8 (table 3). This option is permitted in any DCCP packet, has option number XX and a length of 3-5 bytes. A Sender RTT Estimate Option is valid if it satisfies one of the three following formats: +--------+--------+--------+ |xxxxxxxx|00000011| RTT | +--------+--------+--------+ Type=XX Length=3 Estimate +--------+--------+--------+--------+ |xxxxxxxx|00000100| RTT | +--------+--------+--------+--------+ Type=XX Length=4 Estimate +--------+--------+--------+--------+--------+ |xxxxxxxx|00000101| RTT | +--------+--------+--------+--------+--------+ Type=XX Length=5 Estimate The 1..3 value bytes of the option data carry the current RTT estimate of the sender, using a granularity of 1 microsecond. This allows values up to 16.7 seconds (corresponding to 0xFFFFFE) to be communicated. The value 0xFFFFFF is reserved to indicate significant delay spikes, larger than 16.7 seconds. This is qualitative rather than quantitative information, to alert the receiver that there is a network problem (for instance jamming on a wireless channel). The use of the RTT Estimate Option on networks with RTTs larger than Renker & Fairhurst Expires June 12, 2011 [Page 9]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 16.7 seconds is not specified by this document. A value of 0 indicates the absence of a valid RTT sample. The sender MUST set the value to 0 if it does not yet have an RTT estimate. The sender SHOULD select the smallest format suitable to carry the RTT estimate (i.e., less than 1 byte of leading zeroes). 3.2.2. Send RTT Estimate Feature The Send RTT Estimate feature lets endpoints negotiate whether the sender MUST provide RTT Estimate options on its data packets. Renker & Fairhurst Expires June 12, 2011 [Page 10]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 ==> RFC Editor's Note: Please replace 'YY' with IANA value when published and delete this note. Send RTT Estimate has feature number YY and is server-priority. It takes one-byte Boolean values. Values greater than 1 are invalid and MUST be ignored. +--------+-------------------+------------+---------------+-------+ | Number | Meaning | Rec'n Rule | Initial Value | Req'd | +--------+-------------------+------------+---------------+-------+ | YY | Send RTT Estimate | SP | 0 | N | +--------+-------------------+------------+---------------+-------+ Table 2: The Send RTT Estimate feature defined by this document The column meanings are described in [RFC4340], section 6.4. In particular, the feature is by default off (initial value of 0), and the extension is not required to be understood by every DCCP implementation (cf. [RFC4340], section 15). DCCP B sends a "Change R(Send RTT Estimate, 1)" to ask DCCP A to send RTT Estimate options as part of its data traffic. 3.3. Basic Usage When the Send RTT Estimate Feature is enabled, the sender MUST provide an RTT Estimate Option on all of its Data, DataAck, Sync, and SyncAck packets. It MAY in addition provide the RTT Estimate Option on other packet types, such as DCCP-Ack. The sender MUST implement and continue to update the CCVal window counter as specified in [RFC4342], section 8.1, even when the Send RTT Estimate Feature is on. If the receiver has requested the use of the RTT Estimate Option, it MUST use the RTT value reported by that option in all places that require a RTT (listed at the begin of Section 2). If the receiver encounters an invalid RTT Estimate Option (Section 3.2.1), it MUST reset the connection with Reset Code 5, "Option Error", where the Data 1..3 fields are set to the first 3 bytes of the offending RTT Estimate Option. The receiver SHOULD track the long-term RTT estimate using a moving average, such as the one specified in [RFC5348], 4.3. This long-term estimate is referred to as "receiver_RTT" below. Renker & Fairhurst Expires June 12, 2011 [Page 11]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously specified in [RFC4340], [RFC4342], and [RFC5622]. 3.4. Receiver Robustness Measures This subsection specifies robustness measures for the receiver when the Send RTT Estimate Feature is on. The 0-valued and 0xFFFFFF-valued RTT Estimate Options are both referred to as "no-number RTT options". RTT Estimate Options with values in the range of 1..0xFFFFFE are analogously called "numeric RTT options". Until the first numeric RTT option arrives, the receiver uses a value of 0.5 seconds for receiver_RTT (to match the initial 2 second timeout of the TFRC nofeedback timer, [RFC5348], 4.2). If the path RTT is known, e.g. from a previous connection [RFC2140], the receiver MAY reuse the previously known path RTT value to seed its long-term RTT estimate. The sender is permitted to occasionally send no-number RTT options, covering for transient changes and spurious disruptions. During these times, the receiver continues to use its long-term receiver_RTT value. To avoid that the long-term estimate at the receiver drifts in such a way that it under-estimates the RTT, a simple back-off scheme is employed: if the sender supplies no-number RTT options for longer than receiver_RTT units of time, the receiver sets receiver_RTT = MIN(2 * receiver_RTT, t_mbi) where t_mbi = 64 seconds is the maximum backoff interval ([RFC5348], Appendix A). For the next round of no-number RTT options, the updated value of receiver_RTT applies. This back-off mechanism ensures that short-term disruptions do not have a lasting impact, whereas long-term problems will result in asymptotically high receiver_RTT values. To bail out from a hanging session, the receiver MAY close the connection when receiver_RTT has reached the value MAX_RTT. Renker & Fairhurst Expires June 12, 2011 [Page 12]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 4. Security Considerations Security considerations for CCID-3 have been discussed in section 11 of [RFC4342]; for CCID-4 these have been discussed in section 13 of [RFC5622], referring back to the same section of [RFC4342]. This document introduces an extension to communicate the current RTT estimate of the sender to the receiver of a TFRC communication. By altering the value of the RTT Estimate Option, it is possible to interfere with the behaviour of a flow using TFRC. In particular, since accuracy of the RTT estimate directly influences the accuracy of the measured sending rate X_recv, it would be possible to obtain either higher or lower sending rates than are warranted by the current network conditions. This is only possible if an attacker is on the same path as the DCCP sender and receiver, and is able to guess valid sequence numbers. Therefore the considerations of section 18 in [RFC4340] apply. Renker & Fairhurst Expires June 12, 2011 [Page 13]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 5. IANA Considerations This document requests identical allocation in the dccp-ccid3- parameters and the dccp-ccid4-parameters registries. 5.1. Option Types This document defines a single CCID-specific option for communicating RTT estimates from the HC-sender to the HC-receiver. Following [RFC4340], 10.3, this requires an option number for the RTT Estimate Option in the range 128...191. Renker & Fairhurst Expires June 12, 2011 [Page 14]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 Note to IANA and the RFC editor When the IANA has allocated an option number for the `RTT Estimate' option, please replace all occurrences of the placeholder `XX' in this text with that number and delete this note. (Due to [RFC4340], 19.3 and [RFC4342], 12.2, the option number would be allocated in the range 128...183/191.) 5.2. Feature Numbers This document defines a single CCID-specific feature number for the Send RTT Estimate feature which is located at the HC-sender. Following [RFC4340], 10.3, a feature number in the range 128...191 is required. Renker & Fairhurst Expires June 12, 2011 [Page 15]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 Note to IANA and the RFC editor When the IANA has allocated an option number for the `Send RTT Estimate' feature, please replace all occurrences of the placeholder `YY' in this text with that number and delete this note. (Due to [RFC4340], 19.4 and [RFC4342], 12.3, the feature number would be allocated in the range 128...183/191.) Renker & Fairhurst Expires June 12, 2011 [Page 16]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. 6.2. Informative References [MR97] Mogul, J. and K. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-Driven Kernel", ACM Transactions on Computer Systems (TOCS), 15(3):217-252, August 1997. [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009. Renker & Fairhurst Expires June 12, 2011 [Page 17]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION The following changelog lists the changes since revision 01 of the preceding individual submissions draft-renker-dccp-tfrc-rtt-option-00/01. o General: - added detailed changelog to track comments - changed document name to reflect working group - updated date to October - made spelling of RTT Estimate Option (singular) consistent - moved reference to RFC 5622 from normative to informative, since document status is Experimental o Section 2.1: - clarified problematic cases of too small CCVal differences and CCVal differences > 4, feedback by Pasi o Section 3.1: - clarified the byte ordering used by this document, feedback by Pasi o Section 3.2: - corrected naming of Send RTT Estimate Feature, feedback by Eddie - removed superfluous remark regarding scaling to microsecond granularity in 3.2.1, feedback by Pasi - removed recommendation of preferring long-term RTT stamples, since this can not be generalized (connection may be short or path RTT may change, in both cases a long-term sample would not be useful), feedback by Pasi - made option variable-length (3/4/5 bytes), feedback by Eddie - specified condition for syntactic option validity - limited the maximum option size to 3 bytes and justified decision why not to support RTTs greater than 16 seconds, in Renker & Fairhurst Expires June 12, 2011 [Page 18]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 reply to feedback by Eddie - clarified that the sender MUST use 0 to indicate absence of a valid RTT estimate - clarified the highest path RTT value supported by this document (16.7 sec) - reserved 0xFFFFFF as special value to communicate out-of- bounds exceptions, network problems resulting in disproportionately high delay spikes (> 16.7 seconds) o Section 3.3: - corrected naming of Send RTT Estimate Feature, feedback by Eddie - specified what happens if invalid RTT Estimate options are received - specified what happens if the sender persistently sends 0-valued RTT Estimate options, feedback by Eddie - specified how the exceptional value 0xFFFFFF should be handled - added reference for reusing previously known path RTT value Changes between revision 00 and 01 of this draft: o General changes: - incremented date and revision number - various minor changes of syntax, typos, and paragraph formatting o Section 2.1: - completely rewrote the description of the fifth problem in order to more clearly/precisely identify problem causes, following feedback from Michael o Section 2.2.4: - simplified sentence referring to aliasing effects (implicitly referencing section 10.2 of RFC4342) Renker & Fairhurst Expires June 12, 2011 [Page 19]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 - clarified how middleboxes might use a sender-based RTT estimate option to verify end-to-end congestion control (suggestion and quote taken from RFC4342, section 10.2) o Section 3.3: - clarified how the receiver must behave if the Send RTT Estimate Feature is disabled, following feedback from Eddie - removed the requirement that the receiver should additionally track CCVal window counter values when the Send RTT Estimate Feature is on - removed suggestion that the receiver should take measures to improve the quality of the connection, feedback by Michael - moved all receiver robustness measures to the new section 3.4 - changed section title to reflect restructuring of content o Section 3.4: - new section, written from scratch, to address the shortcomings of the previous scheme, which were identified by Michael Welzl - specifies what to do when the sender supplies no-number RTT options for short and extended periods of time ====> END OF NOTE TO THE RFC EDITOR <==== Renker & Fairhurst Expires June 12, 2011 [Page 20]
Internet-Draft Sender RTT Estimate Option for DCCP December 2010 Authors' Addresses Gerrit Renker University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gerrit@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Renker & Fairhurst Expires June 12, 2011 [Page 21]
