One document matched: draft-ietf-dccp-tfrc-rtt-option-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!-- BIBREFS -->
<!ENTITY rfc2119 PUBLIC '' 'bib/reference.RFC.2119.xml'>
<!ENTITY rfc2140 PUBLIC '' 'bib/reference.RFC.2140.xml'>
<!ENTITY rfc3448 PUBLIC '' 'bib/reference.RFC.3448.xml'>
<!ENTITY rfc4340 PUBLIC '' 'bib/reference.RFC.4340.xml'>
<!ENTITY rfc4342 PUBLIC '' 'bib/reference.RFC.4342.xml'>
<!ENTITY rfc5348 PUBLIC '' 'bib/reference.RFC.5348.xml'>
<!ENTITY rfc5622 PUBLIC '' 'bib/reference.RFC.5622.xml'>
] >
<rfc category="std" ipr="trust200902"
docName="draft-ietf-dccp-tfrc-rtt-option-04.txt"
updates="4342, 5622"> <!-- $Revision: 1.5 $ -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>
<!--
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
-->
<front>
<title abbrev="Sender RTT Estimate Option for DCCP">Sender RTT Estimate Option for DCCP</title>
<author initials="G." surname="Renker" fullname="Gerrit Renker">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>gerrit@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk</uri>
</address>
</author>
<author initials="G." surname="Fairhurst" fullname="Godred Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
> <uri>http://www.erg.abdn.ac.uk</uri>
</address>
</author>
<date month="March" year="2011" />
<area>Transport</area>
<workgroup>DCCP Working Group</workgroup>
<keyword>DCCP</keyword>
<keyword>TFRC</keyword>
<keyword>CCID-3</keyword>
<keyword>CCID-4</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an update to the round trip time (RTT) estimation algorithm
used for TFRC (TCP Friendly Rate Control) congestion control by the Datagram
Congestion Control Protocol (DCCP). It updates specifications for the CCID-3
and CCID-4 Congestion Control IDs of DCCP.</t>
<t>The update addresses parameter-estimation problems occurring with TFRC-based DCCP
congestion control. It uses a recommendation made in the original TFRC specification
to avoid the inherent problems of receiver-based RTT sampling, by utilising
higher-accuracy RTT samples already available at the sender.</t>
<t>It is integrated into the feature set of DCCP as an end-to-end negotiable extension.</t>
</abstract>
</front>
<middle> <!-- text starts here -->
<section anchor="INTRO" title="Introduction">
<t>This document defines a Standards Track update to both a sender and receiver that implement DCCP
CCID-3 <xref target="RFC4342"/> or CCID-4 <xref target="RFC5622"/>, addressing RTT estimation
problems that were observed when using a real implementation.</t>
<t>To fix these problems, this document presents a solution based on a concept first recommended in
<xref target="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.</t>
<t>We begin by analysing the encountered problems in the next section. The update is presented in
<xref target="SPECIFICATION"/>. We then discuss security considerations in <xref target="SECURITY"/>,
and list the resulting IANA considerations in <xref target="IANA"/>.</t>
</section>
<section anchor="RATIONALE" title="Problems caused by sampling the RTT at the receiver">
<t>There are at least six areas that make a TFRC receiver vulnerable to inaccuracies or absence
of (receiver-based) RTT samples:
<list style='symbols'>
<t>the measured sending rate, X_recv (<xref target="RFC5348"/>, 6.2);</t>
<t>synthesis of the first loss interval (<xref target="RFC5348"/>, 6.3.1);</t>
<t>disambiguation of loss events (<xref target="RFC4342"/>, 10.2);</t>
<t>validation of loss intervals (<xref target="RFC4342"/>, 6.1);</t>
<t>ensuring that at least one feedback packet is sent per RTT (<xref target="RFC4342"/>, 10.3);</t>
<t>determining quiescence periods (<xref target="RFC4342"/>, 6.4).</t>
</list>
</t>
<section title="List of problems encountered with a real implementation">
<t>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.</t>
<t>The Linux DCCP/TFRC implementation is based on the RTT-sampling algorithm specified in <xref target="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.</t>
<t>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 <xref target="RFC4342"/>. A CCVal difference less than 4 means sampling at
sub-RTT scale; <xref target="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, it is not possible to determine the timing
interval for adjacent packets with a CCVal difference greater than 4: such samples have to be discarded.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="MR97"/>. As a result, inter-packet arrival
times may converge to zero, when subsequent packets are being delivered at virtually the same time.</t>
<t>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 <xref target="RFC5348"/>, 6.3.1. (The sender, for example, uses a fixed value of 1 second when it
is unable to obtain an initial RTT sample, see <xref target="RFC5348"/>, 4.2).</t>
<t>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.</t>
<t>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.</t>
<t>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 (<xref target="RFC5348"/>, 3.2.2),
which are mandatory in CCID-3 (sections 6 and 8.2 of <xref target="RFC4342"/>).</t>
</section> <!-- List of problems -->
<section title="Other areas affected by the RTT sampling problems">
<t>We here analyse the impact that unreliability of receiver-based RTT sampling has on the areas listed
at the begin of this section.</t>
<t>In addition, benefits of sender-based RTT sampling have already been pointed out in <xref target="RFC5348"/>,
and in the specification of CCID-3 <xref target="RFC4342"/>, at the end of section 10.2.</t>
<section title="Measured Receive Rate X_recv" > <!-- X_recv -->
<t>A key problem is that the reliability of X_recv <xref target="RFC4342"/> depends directly upon the
reliability and accuracy of RTT samples. This means that failures propagate from one parameter to another.</t>
<t>Errata IDs 610 and 611 update <xref target="RFC4342"/> to use the definition of the receive rate as specified
in <xref target="RFC5348"/>.</t>
<t>Having an explicit (rather than a coarse-grained) RTT estimate allows measurement of X_recv with greater
accuracy, and isolates failure.</t>
<t>An explicit RTT estimate also enables the receiver to more accurately perform the test in step (2) of
<xref target="RFC4342"/>, 6.2, i.e. to check whether less or more than one RTT has passed since
the last feedback.</t>
</section>
<section title="Disambiguation and Accuracy of Loss Intervals"> <!-- Loss intervals/events -->
<t>Since a loss event is defined as one or more lost (or ECN-marked) data packets in one RTT (<xref target="RFC5348"/>, 5.2),
the receiver needs accurate RTT estimates to validate and accurately separate loss events.
Moreover, <xref target="RFC5348"/>, 5.2 expressly points out the sender RTT estimate as RECOMMENDED for this purpose.</t>
<t>Having the sender RTT Estimate available further increases the accuracy of the information reported by the receiver.
The definition of Loss Intervals in <xref target="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.</t>
<t>A similar benefit arises in the computation of the loss event rate: as discussed in section 9.2 of <xref target="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.</t>
</section>
<section title="Determining Quiescence">
<t>The quiescence period is defined as max(2 * RTT, 0.2 sec) in section 6.4 of <xref target="RFC4342"/>.
An explicit RTT estimate avoids under- and over-estimating quiescence periods.</t>
</section>
<section title="Practical Considerations">
<t>Using explicit RTT estimates contributes to greater robustness and can also result in simpler implementation.</t>
<t>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.</t>
<t>Second, the receiver is better able to determine when to send feedback packets. It can perform the test described in
step (2) of <xref target="RFC5348"/>, 6.2 more accurately. Moreover, unnecessary expiration of the nofeedback timer
(as described in <xref target="RFC4342"/>, 10.3) can be avoided.</t>
<t>Lastly, a sender-based RTT estimate option can be used by middleboxes to verify that a flow uses conforming
end-to-end congestion control (<xref target="RFC4342"/>, 10.2).</t>
</section>
</section>
</section> <!-- Motivation and Rationale -->
<section anchor="SPECIFICATION" title="Specification">
<section title="Conventions">
<t>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 <xref target="RFC2119"/>.</t>
<t>This document uses the conventions of <xref target="RFC5348"/>,
<xref target="RFC4340"/>, <xref target="RFC4342"/>, and <xref target="RFC5622"/>.</t>
<t> All multi-byte field descriptions presented in this documented are in network byte order
(most significant byte first).</t>
</section>
<section title="Options and Features">
<t>This document defines a single TFRC-specific option, RTT Estimate, described in the next subsection.</t>
<t>Following the guidelines in <xref target="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.</t>
<section anchor="option" title="RTT Estimate Option">
<t>The sender communicates its current RTT estimate to the receiver
using a RTT Estimate Option.</t>
<!-- XXX NOTE TO THE RFC EDITOR XXX -->
<note title="==> RFC Editor's Note:">
<t>Please replace 'XX' with IANA value when published and delete this note.</t>
</note>
<!-- XXX END OF NOTE TO THE RFC EDITOR XXX -->
<texttable anchor='option_table' title='The RTT Estimate Option defined by this document' >
<ttcol align='center'>Type</ttcol>
<ttcol align='center'>Option Length</ttcol>
<ttcol align='center'>Meaning</ttcol>
<ttcol align='center'>DCCP Data?</ttcol>
<c>XX</c>
<c>3/4/5</c>
<c>RTT Estimate</c>
<c>Y</c>
</texttable>
<t>Column meanings are as per <xref target="RFC4340"/>, section 5.8 (table 3).
This option MAY be placed in any DCCP packet, has option number XX and a length
of 3-5 bytes.</t>
<t>A Sender RTT Estimate Option is valid if it satisfies one of the
three following formats:</t>
<!-- XXX NOTE TO THE RFC EDITOR XXX -->
<note title="==> RFC Editor's Note:">
<t>Please replace 'xxxxxxxx' below with the binary representation of the IANA 'Type' value
(indicated in decimal as 'XX') when published and delete this note.</t>
</note>
<!-- XXX END OF NOTE TO THE RFC EDITOR XXX -->
<figure><artwork>
+--------+--------+--------+
|xxxxxxxx|00000011| RTT |
+--------+--------+--------+
Type=XX Length=3 Estimate
</artwork></figure>
<figure><artwork>
+--------+--------+--------+--------+
|xxxxxxxx|00000100| RTT |
+--------+--------+--------+--------+
Type=XX Length=4 Estimate
</artwork></figure>
<figure><artwork>
+--------+--------+--------+--------+--------+
|xxxxxxxx|00000101| RTT |
+--------+--------+--------+--------+--------+
Type=XX Length=5 Estimate
</artwork></figure>
<t>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.</t>
<t>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).</t>
<t>The use of the RTT Estimate Option on networks with RTTs larger than 16.7
seconds is not specified by this document.</t>
<t>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.</t>
<t>The sender SHOULD select the smallest format suitable to carry the RTT
estimate (i.e., less than 1 byte of leading zeroes).</t>
</section>
<section anchor="feature" title="Send RTT Estimate Feature">
<t>The Send RTT Estimate feature lets endpoints negotiate whether the sender
MUST provide RTT Estimate options on its data packets.</t>
<!-- XXX NOTE TO THE RFC EDITOR XXX -->
<note title="==> RFC Editor's Note:">
<t>Please replace 'YY' with IANA value when published and delete this note.</t>
</note>
<!-- XXX END OF NOTE TO THE RFC EDITOR XXX -->
<t>Send RTT Estimate has feature number YY and is server-priority.
It takes one-byte Boolean values; values greater than 1 are reserved.</t>
<texttable anchor='feat_table' title='The Send RTT Estimate feature defined by this document' >
<ttcol align='center'>Number</ttcol>
<ttcol align='center'>Meaning</ttcol>
<ttcol align='center'>Rec'n Rule</ttcol>
<ttcol align='center'>Initial Value</ttcol>
<ttcol align='center'>Req'd</ttcol>
<c>YY</c>
<c>Send RTT Estimate</c>
<c>SP</c>
<c>0</c>
<c>N</c>
</texttable>
<t>The column meanings are described in <xref target="RFC4340"/>, section 6.4.</t>
<t>The Send RTT Estimate feature is OPTIONAL. An extension may implement it, but this specification
does not require the feature to be understood by every DCCP implementation (see [RFC4340], section 15).
The feature is off by default (initial value of 0).</t>
<t>DCCP B sends a "Mandatory Change R(Send RTT Estimate, 1)" to require DCCP A to send RTT Estimate
options as part of its data traffic (DCCP A will reset the connection if it does not understand
this feature).</t>
</section>
</section> <!-- Options and Features -->
<section anchor="usage" title="Basic Usage">
<t>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.</t>
<t>The sender MUST implement and continue to update the CCVal window counter as specified in
<xref target="RFC4342"/>, section 8.1, even when the Send RTT Estimate Feature is on.</t>
<t>When the Send RTT Estimate Feature is enabled, the receiver MUST use the value reported by the RTT
Estimate Option in all places that require a RTT (listed at the begin of <xref target="RATIONALE"/>).
If the receiver encounters an invalid RTT Estimate Option (<xref target="option"/>), 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.</t>
<t>The receiver SHOULD track the long-term RTT estimate using a moving average, such as the one
specified in <xref target="RFC5348"/>, 4.3. This long-term estimate is referred to as
"receiver_RTT" below.</t>
<t>When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously
specified in <xref target="RFC4340"/>, <xref target="RFC4342"/>, and <xref target="RFC5622"/>.</t>
</section>
<section anchor="robustness" title="Receiver Robustness Measures">
<t>This subsection specifies robustness measures for the receiver when the Send RTT Estimate
Feature is on.</t>
<t>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".</t>
<t>Until the first numeric RTT option arrives, the receiver MUST use a value of 0.5 seconds for
receiver_RTT (to match the initial 2 second timeout of the TFRC nofeedback timer,
<xref target="RFC5348"/>, 4.2).</t>
<t>If the path RTT is known, e.g. from a previous connection <xref target="RFC2140"/>, the
receiver MAY reuse the previously known path RTT value to seed its long-term RTT estimate.</t>
<t>The sender MAY occasionally send no-number RTT options, covering for transient changes and
spurious disruptions. During these times, the receiver SHOULD continue to use its long-term
receiver_RTT value.</t>
<t>To avoid under-estimating the RTT in the absence of numeric options, the receiver MUST
back off receiver_RTT in the following manner: if the sender supplies no-number RTT
options for longer than receiver_RTT units of time, the receiver sets
<figure><artwork>
receiver_RTT = MIN(2 * receiver_RTT, t_mbi)
</artwork></figure>
where t_mbi = 64 seconds is the maximum backoff interval (<xref target="RFC5348"/>,
Appendix A). For the next round of no-number RTT options, the updated value of
receiver_RTT applies.</t>
<t>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.</t>
<t>To bail out from a hanging session, the receiver MAY close the connection when receiver_RTT
has reached the value MAX_RTT.</t>
</section>
</section> <!-- Specification -->
<section anchor="SECURITY" title="Security Considerations">
<t>Security considerations for CCID-3 have been discussed in section 11 of <xref target="RFC4342"/>;
for CCID-4 these have been discussed in section 13 of <xref target="RFC5622"/>, referring back
to the same section of <xref target="RFC4342"/>.</t>
<t>This document introduces an extension to communicate the current RTT estimate of
the sender to the receiver of a TFRC communication.</t>
<t>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.</t>
<t>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 <xref target="RFC4340"/> apply.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests identical allocation in the dccp-ccid3-parameters
and the dccp-ccid4-parameters registries.</t>
<section title="Option Types">
<t>This document defines a single CCID-specific option for communicating RTT estimates from the HC-sender
to the HC-receiver. Following <xref target="RFC4340"/>, 10.3, this requires an option number for
the RTT Estimate Option in the range 128...191.</t>
<!-- XXX NOTE TO THE IANA AND RFC EDITOR XXX -->
<note title='Note to IANA and the RFC editor'>
<t>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 <xref target="RFC4340"/>, 19.3 and <xref target="RFC4342"/>,
12.2, the option number would be allocated in the range 128...183/191.)</t>
</note>
<!-- XXX END OF NOTE TO THE IANA AND RFC EDITOR XXX -->
</section>
<section title="Feature Numbers">
<t>This document defines a single CCID-specific feature number for the Send RTT Estimate feature
which is located at the HC-sender. Following <xref target="RFC4340"/>, 10.3, a feature number
in the range 128...191 is required.</t>
<!-- XXX NOTE TO THE IANA AND RFC EDITOR XXX -->
<note title='Note to IANA and the RFC editor'>
<t>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 <xref target="RFC4340"/>, 19.4 and <xref target="RFC4342"/>, 12.3,
the feature number would be allocated in the range 128...183/191.)</t>
</note>
<!-- XXX END OF NOTE TO THE IANA AND RFC EDITOR XXX -->
</section>
</section>
</middle>
<back>
<references title='Normative References' >
&rfc2119;
&rfc4340;
&rfc4342;
&rfc5348;
</references>
<references title='Informative References'>
&rfc2140;
&rfc5622;
<reference anchor='MR97'> <front>
<title>Eliminating Receive Livelock in an Interrupt-Driven Kernel</title>
<author initials='J. C.' surname='Mogul'></author>
<author initials='K. K.' surname='Ramakrishnan'></author>
<date month='August' year='1997' /></front>
<seriesInfo name='ACM Transactions on Computer Systems (TOCS),' value='15(3):217-252'/>
<format type='TXT'/>
</reference>
</references>
<!-- XXX NOTE TO THE RFC EDITOR XXX -->
<note title="==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION">
<t>The following changelog lists the changes since revision 01 of the preceding individual
submission draft-renker-dccp-tfrc-rtt-option.</t>
<list style="symbols">
<t>General:
<list style="empty">
<t>- added detailed changelog to track comments</t>
<t>- changed document name to reflect working group</t>
<t>- updated date to October</t>
<t>- made spelling of RTT Estimate Option (singular) consistent</t>
<t>- moved reference to RFC 5622 from normative to informative, since
document status is Experimental</t>
</list></t>
<t>Section 2.1:
<list style="empty">
<t>- clarified problematic cases of too small CCVal differences and CCVal differences > 4,
feedback by Pasi</t>
</list></t>
<t>Section 3.1:
<list style="empty">
<t>- clarified the byte ordering used by this document, feedback by Pasi</t>
</list></t>
<t>Section 3.2:
<list style="empty">
<t>- corrected naming of Send RTT Estimate Feature, feedback by Eddie</t>
<t>- removed superfluous remark regarding scaling to microsecond granularity
in 3.2.1, feedback by Pasi</t>
<t>- removed recommendation of preferring long-term RTT samples, 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</t>
<t>- made option variable-length (3/4/5 bytes), feedback by Eddie</t>
<t>- specified condition for syntactic option validity</t>
<t>- limited the maximum option size to 3 bytes and justified decision why not to
support RTTs greater than 16 seconds, in reply to feedback by Eddie</t>
<t>- clarified that the sender MUST use 0 to indicate absence of a valid RTT
estimate</t>
<t>- clarified the highest path RTT value supported by this document (16.7 sec)</t>
<t>- reserved 0xFFFFFF as special value to communicate out-of-bounds exceptions,
network problems resulting in disproportionately high delay spikes
(> 16.7 seconds)</t>
</list></t>
<t>Section 3.3:
<list style="empty">
<t>- corrected naming of Send RTT Estimate Feature, feedback by Eddie</t>
<t>- specified what happens if invalid RTT Estimate options are received</t>
<t>- specified what happens if the sender persistently sends 0-valued RTT
Estimate options, feedback by Eddie</t>
<t>- specified how the exceptional value 0xFFFFFF should be handled</t>
<t>- added reference for reusing previously known path RTT value</t>
</list></t>
</list> <!-- changes preceding revision 00 -->
<t>Changes between revision 00 and 01 of this draft:</t>
<list style="symbols">
<t>General changes:
<list style="empty">
<t>- incremented date and revision number</t>
<t>- various minor changes of syntax, typos, and paragraph formatting</t>
</list></t>
<t>Section 2.1:
<list style="empty">
<t>- completely rewrote the description of the fifth problem in order
to more clearly/precisely identify problem causes, following
feedback from Michael</t>
</list></t>
<t>Section 2.2.4:
<list style="empty">
<t>- simplified sentence referring to aliasing effects (implicitly
referencing section 10.2 of RFC4342)</t>
<t>- 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)</t>
</list></t>
<t>Section 3.3:
<list style="empty">
<t>- clarified how the receiver must behave if the Send RTT Estimate Feature is
disabled, following feedback from Eddie</t>
<t>- removed the requirement that the receiver should additionally track CCVal
window counter values when the Send RTT Estimate Feature is on</t>
<t>- removed suggestion that the receiver should take measures to improve the
quality of the connection, feedback by Michael</t>
<t>- moved all receiver robustness measures to the new section 3.4</t>
<t>- changed section title to reflect restructuring of content</t>
</list></t>
<t>Section 3.4:
<list style="empty">
<t>- new section, written from scratch, to address the shortcomings of the
previous scheme, which were identified by Michael Welzl</t>
<t>- specifies what to do when the sender supplies no-number RTT options for
short and extended periods of time</t>
</list></t>
</list>
<t>Changes between revision 01 and 02 of this draft:</t>
<list style="symbols">
<t>General:
<list style="empty">
<t>- incremented date and revision number</t>
<t>- removed compatibility clause in abstract</t>
</list></t>
<t>Section 1:
<list style="empty">
<t>- corrected placement of references, feedback from Eddie</t>
</list></t>
<t>Section 2.1:
<list style="empty">
<t>- removed description of a problem observed with CCID-3 over an 802.11
link (reduction of sending rate towards zero after a short channel
outage), since causes of the problem were not conclusively understood</t>
</list></t>
<t>Section 3.2.2:
<list style="empty">
<t>- clarified that values of 2 of the Send RTT Estimate feature are
reserved, feedback from Eddie</t>
<t>- fixed the issue of handling invalid values of the Send RTT Estimate
feature by using mandatory feature negotiation (<xref target="RFC4340"/>,
sec. 6.6.9), thanks to a suggestion by Eddie</t>
</list></t>
<t>Section 3.3:
<list style="empty">
<t>- clarified receiver behaviour when the Send RTT Estimate feature is
enabled, feedback from Eddie</t>
</list></t>
</list>
<t>Changes between revision 02 and 03 of this draft:</t>
<list style="symbols">
<t>Section 3.2.2:
<list style="empty">
<t>- clarified the use of Mandatory Feature Negotiation, feedback from Eddie</t>
</list></t>
</list>
<t>Changes between revision 03 and 04 of this draft:</t>
<list style="symbols">
<t>Abstract:
<list style="empty">
<t>- clarified that the document updates the specifications of CCID-3 and CCID-4,
AD review</t>
<t>- changed wording so that all abbreviations are defined</t> <t>- Changelog: fixed typos, AD review</t>
</list></t>
<t>Section 2:
<list style="empty">
<t>- fixed grammatical nits in section 2.1, AD review</t>
<t>- clarified meaning of lost vs ECN-marked packets in section 2.2.2, AD review</t>
</list></t>
<t>Section 3:
<list style="empty">
<t>- clarified normative applicability of option for packet types in section 3.2.1,
AD review</t>
<t>- added a note to the RFC editor to also update the binary representation of the
Type value for the RTT Estimate Option in section 3.2.1</t>
<t>- clarified optional nature of Send RTT Estimate feature in section 3.2.2,
AD review</t>
<t>- clarified normative use of initial value of receiver_RTT in section 3.4,
AD review</t>
<t>- clarified normative applicability of no-number RTT options in section 3.4,
AD review</t>
<t>- clarified normative applicability of receiver_RTT back-off scheme in section 3.4,
AD review</t>
</list></t>
<t>Changelog:
<list style="empty">
<t>- fixed typos, AD review</t>
</list></t>
</list>
<t>====> END OF NOTE TO THE RFC EDITOR <====</t>
</note>
<!-- XXX END OF NOTE TO THE RFC EDITOR XXX -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:41:19 |