One document matched: draft-renker-dccp-tfrc-rtt-option-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:18:02 |