DCCP Working Group G. Renker Internet-Draft University of Aberdeen Updates: 4342 (if approved) June 17, 2008 Intended status: Standards Track Expires: December 19, 2008 Sender RTT Estimate Option for DCCP draft-renker-dccp-tfrc-rtt-option-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Renker Expires December 19, 2008 [Page 1]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 Abstract This document describes an optional extension for DCCP congestion- control CCIDs that are based on TCP-Friendly Rate Control (TFRC). The extension improves the accuracy of parameter estimation at the TFRC receiver, by periodically communicating the (more precise) RTT estimate available at the sender. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation and Rationale . . . . . . . . . . . . . . . . . . . 4 2.1. Results from Deployment Experience . . . . . . . . . . . . 4 2.2. Other Benefits . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 5 2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 5 2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 6 2.2.4. Benefits for the Implementation . . . . . . . . . . . 6 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Options and Features . . . . . . . . . . . . . . . . . . . 7 3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 7 3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 8 3.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Renker Expires December 19, 2008 [Page 2]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 1. Introduction This document describes an optional extension for DCCP congestion- control CCIDs [RFC4340] that are based on TFRC TCP-Friendly Rate Control [RFC3448bis]. The extension improves the accuracy of parameter estimation at the TFRC receiver, by periodically communicating the (more precise) RTT estimate available at the sender. This document is structured as follows. We present an informative description of motivations in the next section. The subsequent normative Section 3 specifies the extension. We conclude with security considerations in Section 4, and IANA considerations in Section 5. Renker Expires December 19, 2008 [Page 3]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 2. Motivation and Rationale The TFRC receiver requires an RTT estimate in several cases. These include the computation of the first loss interval ([RFC3448bis], 6.3.1) and measuring the receive rate X_recv ([RFC3448bis], 6.2). Apart from being part of the original TFRC specification (section 3.2.1 of [RFC3448bis]), we have two central motivations for suggesting the present extension. The first and main motivation results from deployment experience with currently existing algorithms and is described in the next subsection. We found that the presented extension has further benefits; these are described in the second subsection. 2.1. Results from Deployment Experience In this section we describe deployment experience of using coarse- grained timestamps to estimate the RTT at the receiver, and why this called for a better alternative. We were using the algorithm from [RFC4342], 8.1 as the basis. Observing its behaviour within an implementation of CCID-3 over the period of one year, we experienced the following drawbacks. The algorithm is based on using the coarse-grained window counter timestamp and the measured inter-arrival time of packets to estimate the network RTT. Due to its inherent limitation, only packets with modulo-16 CCVal differences between 2 and 4 (corresponding to RTT/2...RTT) can be used, as is also remarked in sections 8.1 and 10.3 of [RFC4342]. A further limitation was encountered with regard to holes in the sequence space: due to possible wrap-around of the 4-bit CCVal window counter, it is not possible to determine window-counter wrap-around if sequence numbers of subsequently received packets are not immediately adjacent. This problem occurs when packets are delayed, reordered, or lost in the network. The third limitation came from measuring the inter-packet interval at the receiver. 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, it is frequently possible that the inter-packet arrival times converge to zero, as subsequent packets are delivered virtually at the same time, served by the same interrupt routine. Renker Expires December 19, 2008 [Page 4]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 As a consequence, the accuracy of measuring the receive rate X_recv ([RFC4342], 8.3) and of disambiguating loss events ([RFC4342], 6.1) suffered considerably. Trying to tackle these effects using heavy filtering on the RTT samples did not substantially improve the situation. We are not aware of an alternative (published) algorithm to better estimate the RTT at the receiver. The TFRC sender, on the other hand, is 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 ([RFC3448bis], 3.2.2), which are mandatory in CCID-3 (sections 6 and 8.2 of [RFC4342]). 2.2. Other Benefits We found at least four more areas where using the RTT Estimate option provides benefits. 2.2.1. Measured Receive Rate X_recv The most significant benefit is an improved accuracy of measuring the receive rate X_recv. Errata IDs 610 and 611 update [RFC4342] to use the definition of the receive rate as specified in [RFC3448bis]. The definition of X_recv in [RFC3448bis], section 6.2 uses R_m, the RTT measurement that the sender sent to the receiver in packet with sequence number S_m. Having an explicit (rather than a coarse- grained) RTT estimate allows to measure X_recv with greater accuracy. Furthermore, with an explicit RTT estimate the receiver is better able to perform the test in step (2) of the above referenced section, i.e. to check whether less or more than one RTT has passed since the last feedback. 2.2.2. Disambiguation and Accuracy of Loss Intervals Since a loss event is defined as one or more lost (or ECN-marked) data packets in one RTT ([RFC3448bis], 5.2), the receiver can benefit from using the RTT Estimate to validate and more accurately separate loss events. Moreover, [RFC3448bis], 5.2 expressly recommends using the sender RTT estimate for this purpose. Having the HC-sender RTT Estimate available further increases the accuracy of the information reported by the HC-receiver. The definition of Loss Intervals in [RFC4342], 6.1 uses the RTT to Renker Expires December 19, 2008 [Page 5]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 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 (if used by the receiver): as discussed in section 9.2 of [RFC4342], it can in some cases happen that sender and receiver compute different loss event rates, due to differences in the available timing information. An explicit RTT estimate can help to reduce these differences. 2.2.3. Determining Quiescence The quiescence period is defined as min(0.2 sec, 2*RTT) in section 6.4 of [RFC4342]. An explicit RTT estimate can help avoid under- or over-estimating quiescence periods. 2.2.4. Benefits for the Implementation Using explicit RTT estimates eases implementation in several places and contributes to greater robustness. First, it becomes easier to separate adjacent loss events. The 4-bit counter value wraps relatively frequently, which requires a complex calculation to avoid aliasing effects. In section 10.2 of [RFC4342] the corresponding benefits of using an RTT Estimate option are already described, hence not repeated here. Second, the receiver is better able to determine when to send feedback packets. It can perform the test described in step (2) of [RFC3448bis], 6.2 more accurately. Moreover, unnecessary expiration of the nofeedback timer (as described in [RFC4342], 10.3) can be avoided. The last point is more speculative and from [RFC4342], 10.2: using an RTT estimate option could be used by middleboxes for verification. Renker Expires December 19, 2008 [Page 6]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 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 [RFC3448bis], [RFC4340], [RFC4342], and [CCID-4]. Please consult these documents for the relevant details. 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. 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. +------+---------------+--------------+------------+ | Type | Option Length | Meaning | DCCP Data? | +------+---------------+--------------+------------+ | XX | 6 | 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 6 bytes. +--------+--------+--------+--------+--------+--------+ |xxxxxxxx|00000110| Sender RTT Estimate | +--------+--------+--------+--------+--------+--------+ Type=XX Length=6 The four bytes of option data carry the current RTT estimate of the sender, using a granularity of 1 microsecond (senders sampling with a lower resolution can multiply their RTT estimates to achieve this granularity). Renker Expires December 19, 2008 [Page 7]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 A value of zero indicates that the sender does not have a valid RTT sample yet. Senders SHOULD send long-term RTT estimates (sampled over a longer period of time) rather than instantaneous RTT samples. 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. +--------+-------------------+------------+---------------+-------+ | 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). 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. 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. DCCP A MUST send RTT Estimate options on its data packets (Data and DataAck) when Send RTT Estimate/A is one. It MAY send RTT Estimate options on other packet types as well, and it MAY send RTT Estimate options as part of its data traffic even when Send RTT Estimate/A is zero. 3.3. Usage The receiver uses the value of the RTT Estimate option in all places that require a (precise) RTT, in particular: o the measured sending rate, X_recv ([RFC3448bis], 6.2); o computation of the first loss interval ([RFC3448bis], 6.3.1); o to disambiguate loss events ([RFC4342], 10.2); Renker Expires December 19, 2008 [Page 8]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 o to validate loss intervals ([RFC4342], 6.1); o to verify and ensure that at least one feedback packet is sent per RTT ([RFC4342], 10.3); o to determine quiescence periods ([RFC4342], 6.4). The RTT Estimate option is meant to complement, rather than replace, the use of the Window Counter Value introduced in [RFC4342], 8.1. When available, RTT values obtained via the RTT Estimate option SHOULD take precedence over RTT estimates obtained via the CCVal window counter. To increase robustness, the receiver MAY also keep a moving-average of the RTT, in the manner of [RFC3448bis], section 4.3. Renker Expires December 19, 2008 [Page 9]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 4. Security Considerations Security considerations for CCID-3 and [CCID-4] have been discussed in section 11 of [RFC4342]. This document introduces an optional 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 the flow. 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 in section 18 of [RFC4340] apply. Renker Expires December 19, 2008 [Page 10]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 5. IANA Considerations 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 Expires December 19, 2008 [Page 11]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 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 Expires December 19, 2008 [Page 12]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 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 Expires December 19, 2008 [Page 13]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 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. [RFC3448bis] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work In Progress, draft-ietf-dccp-rfc3448bis-06, April 2008. [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. 6.2. Informative References [CCID-4] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Work In Progress, draft-ietf-dccp-ccid4-02, February 2008. [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. Renker Expires December 19, 2008 [Page 14]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 Author's Address Gerrit Renker University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gerrit@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Renker Expires December 19, 2008 [Page 15]
Internet-Draft Sender RTT Estimate Option for DCCP June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Renker Expires December 19, 2008 [Page 16]