RFC 6323

Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)

📅 published July 2011, from ietf

RFC 6323: Sender RTT Estimate Option for DCCP ✨

RFC 6323 💖 is titled Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP). It was written by G. Renker and G. Fairhurst from the University of Aberdeen, and it went out in July 2011. It's a Standards Track doc with ISSN 2070-1721, and it updates RFC 4342 and RFC 5622. It doesn't list anything it obsoletes. 🎀

Abstract

okay bestie, the abstract is the "here's what this is about" part 🦋 This doc updates how round-trip time (RTT) gets estimated for TFRC (TCP-Friendly Rate Control) congestion control in DCCP. It changes the specs for the CCID-3 and CCID-4 Congestion Control IDs.

The update fixes parameter-estimation problems that show up with TFRC-based DCCP congestion control. It takes a recommendation from the original TFRC spec, which is to avoid the built-in problems of receiver-based RTT sampling by using the higher-accuracy RTT samples the sender already has. 🧚

It's also added to DCCP's feature set as an end-to-end negotiable extension. iconic 💅

Status of This Memo

This is an Internet Standards Track document. 📜

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc6323. 🌸

Copyright (c) 2011 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) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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  . . . .  5
    2.2.1.  Measured Receive Rate X_recv . . . . . . . . . . . . .  6
    2.2.2.  Disambiguation and Accuracy of Loss Intervals  . . . .  6
    2.2.3.  Determining Quiescence . . . . . . . . . . . . . . . .  6
    2.2.4.  Practical Considerations . . . . . . . . . . . . . . .  7
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  . . . . . . . . . . . . . .  9
  3.3.  Basic Usage  . . . . . . . . . . . . . . . . . . . . . . .  9
  3.4.  Receiver Robustness Measures . . . . . . . . . . . . . . . 10
4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
  5.1.  Option Types . . . . . . . . . . . . . . . . . . . . . . . 11
  5.2.  Feature Numbers  . . . . . . . . . . . . . . . . . . . . . 12
6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
  6.2.  Informative References . . . . . . . . . . . . . . . . . . 12

1. Introduction 🌈

okay so DCCP [RFC4340] is a transport protocol for connection-oriented, unreliable, and congestion-controlled datagram delivery. 🦋 Apps get to pick a congestion control mechanism, and each one is named by a Congestion Control Identifier (CCID; [RFC4340], Section 10). main character energy 👑

This doc defines a Standards-Track update to the sender and receiver sides of two rate-based DCCP CCIDs: CCID-3 [RFC4342] and the Experimental CCID-4 variant [RFC5622]. 💜

Both are based on TFRC [RFC5348], which does rate-based congestion control. Its feedback works differently from window-based congestion control like TCP's. So in TFRC the feedback can be sent less often (e.g., once per round-trip time). Also, a measured RTT estimate is used directly to work out the (TCP-friendly) transmission rate. 🍓

In TFRC-based protocols, packets get rate-paced over an RTT, instead of being sent back-to-back like TCP can do. So accurate RTT estimation really matters for good pacing at the sender. 💅

The original CCID-3 and CCID-4 specs, in [RFC4342] and [RFC5622], both estimate the RTT at the receiver. They use an algorithm based on the cyclic 4-bit window counter of the DCCP CCVal header. The method has effects that people have seen when running apps over DCCP implementations, which means infrequent and inaccurate RTT measurement. 😭

This update fixes those RTT estimation problems with a fix based on an idea first recommended in [RFC5348], Section 3.2.1: measure the RTT at the sender. That gives more reliable and more frequent samples, and avoids the built-in problems of receiver-based RTT sampling discussed below. ✨

Here's the plan: Section 2 analyses the problems we ran into, Section 3 presents the update, Section 4 covers security considerations, and Section 5 lists the resulting IANA considerations. 🎀

2. Problems Caused by Sampling the RTT at the Receiver 🫧

There are at least six areas where a TFRC receiver is vulnerable to inaccurate or missing (receiver-based) RTT samples. Lowkey a lot, honestly 🙈

  • the measured sending rate, X_recv ([RFC5348], Section 6.2);
  • synthesis of the first loss interval ([RFC5348], Section 6.3.1);
  • disambiguation of loss events ([RFC4342], Section 10.2);
  • validation of loss intervals ([RFC4342], Section 6.1);
  • ensuring that at least one feedback packet is sent per RTT ([RFC4342], Section 10.3);
  • determining quiescence periods ([RFC4342], Section 6.4).

2.1. List of Problems Encountered with a Real Implementation 🧪

This section sums up several years of experience using the Linux implementation of CCID-3 and CCID-4. It lists the problems people ran into with receiver-based RTT sampling over real networks, in a bunch of wired and wireless environments and under different link-layer conditions. the receipts are in 🧾

The Linux DCCP/TFRC implementation is based on the RTT-sampling algorithm specified in [RFC4342], Section 8.1. This algorithm uses a coarse-grained window counter (units of RTT/4), and it uses packet inter-arrival times to estimate the current RTT of the network. 🔥

The algorithm only works for packets with modulo-16 CCVal differences less than 5, because of limitations noted in Sections 8.1 and 10.3 of [RFC4342]. A CCVal difference less than 4 means sampling at sub-RTT scale, so [RFC4342], Section 8.1 suggests differences between 2 and 4, with 4 being preferable (equivalent to a full RTT). That same section caps the maximum CCVal difference between data-carrying packets at 5, to avoid wrap-around. As a result, it's not possible to work out the timing interval for adjacent packets with a CCVal difference greater than 4, so those samples have to be thrown out. 🗑️

Problem number two shows up when there are holes in the sequence space. The 4-bit CCVal counter can cycle around multiple times, so it's not possible to tell about window-counter wrap-around whenever the sequence numbers of later packets aren't right next to each other. This happens when packets get delayed, reordered, or lost in the network. 🌀

So RTT sampling has to pause during times of loss. That makes things worse, though, because the sender now needs new feedback from the receiver, but the receiver can't give accurate, up-to-date info. It can't sample the RTT, so it also can't estimate X_recv correctly, and that then messes with X_Bps at the sender. 😩

The third limitation comes from using inter-arrival times as stand-ins for network inter-packet gaps. It's well known that the inter-packet gap isn't constant along a network path. On top of that, modern network interface cards don't always deliver each packet at the moment it's received. They deliver in bunches, to avoid overly frequent interrupts [MR97]. So inter-packet arrival times can converge to zero, when later packets are delivered at basically the same time. 🫨

The fourth problem is under-sampling, which ties back to the first limitation. If loss happens before the receiver has had a chance to sample the RTT, it has to fall back on some fixed RTT constant to plug into the equation of [RFC5348], Section 6.3.1. (The sender, for example, uses a fixed value of 1 second when it can't get an initial RTT sample; see [RFC5348], Section 4.2.) 🥲

This fourth problem is especially painful when the loss was caused by a transient condition. It leads to a later drop in connection quality (a rate reduction), and it's made worse by the fact that TFRC takes longer than common window-based protocols to recover from a cut in its allowed sending rate. 📉

Trying to smooth these effects out by putting heavy filtering on the RTT samples didn't really improve things, and it doesn't fix the under-sampling problem either. 🙃

The TFRC sender, on the other hand, is way better equipped to estimate the RTT and can do it more accurately. This is mainly thanks to the use of timestamps and elapsed time information ([RFC5348], Section 3.2.2), which are mandatory in CCID-3 (Sections 6 and 8.2 of [RFC4342]). the sender really said "I got this" 💪

2.2. Other Areas Affected by the RTT Sampling Problems 🌷

Here we look at the impact that unreliable receiver-based RTT sampling has on the areas listed at the beginning of Section 2.

Benefits of sender-based RTT sampling were already pointed out in [RFC5348] and in the specification of CCID-3 at the end of Section 10.2 of [RFC4342], so this isn't a brand-new idea. 💖

2.2.1. Measured Receive Rate X_recv 📊

The key problem is that the reliability of X_recv [RFC4342] depends directly on the reliability and accuracy of RTT samples. So failures spread from one parameter to another. it's giving domino effect 🫠

Errata IDs 610 [Err610] and 611 [Err611] update [RFC4342] to use the definition of the receive rate given in [RFC5348].

Having an explicit (rather than coarse-grained) RTT estimate lets you measure X_recv with greater accuracy, and it isolates failures. 🎯

An explicit RTT estimate also lets the receiver more accurately perform the test in step (2) of [RFC4342], Section 6.2. That's the check for whether less or more than one RTT has passed since the last feedback. ⏱️

2.2.2. Disambiguation and Accuracy of Loss Intervals

Okay so a loss event is one or more data packets in one RTT that get lost or marked with Explicit Congestion Notification (ECN; [RFC5348], Section 5.2). That means the receiver needs accurate RTT estimates to validate and separate loss events 💅. Section 5.2 of [RFC5348] even says the sender RTT estimate is RECOMMENDED for this 🫶.

Having the sender RTT estimate around makes the receiver's info way more accurate ✨. The definition of Loss Intervals in [RFC4342], Section 6.1 needs the RTT to split up the lossy parts, and lossy parts that stretch over more than one RTT are invalid 🙈.

It's also a win for the loss event rate 📈. As Section 9.2 of [RFC4342] explains, the sender and receiver can end up computing different loss event rates because they have different timing info 💀. An explicit RTT estimate makes the receiver's info more accurate, so the sender may not need to recompute the (less reliable) loss event rate the receiver reports 🌸.

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 stops you from under- and over-estimating quiescence periods, which is so important 😭✨.

2.2.4. Practical Considerations

Using explicit RTT estimates makes things more robust and can also lead to simpler implementations 🎀.

First, it gets easier to separate adjacent loss events 🧚. The 4-bit counter value wraps around pretty often, which means you need extra procedures to avoid aliasing effects 🌀.

Second, the receiver is better at deciding when to send feedback packets 🦋. It can do the test described in step (2) of [RFC5348], Section 6.2 more accurately. Plus, unnecessary expiration of the nofeedback timer (as described in [RFC4342], Section 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], Section 10.2) 👑.

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 in this document are in network byte order (most significant byte first) 💜.

3.2. Options and Features

This document defines a single TFRC-specific option, RTT Estimate, which we'll get into 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. That feature is described in Section 3.2.2 🫧.

3.2.1. RTT Estimate Option

The sender tells the receiver its current RTT estimate using an RTT Estimate Option 💌.

        +------+---------------+--------------+------------+
        | Type | Option Length |    Meaning   | DCCP Data? |
        +------+---------------+--------------+------------+
        |  128 |     3/4/5     | RTT Estimate |      Y     |
        +------+---------------+--------------+------------+

      Table 1: The RTT Estimate Option Defined by This Document

The column meanings come from [RFC4340], Section 5.8 (Table 3). This option MAY be placed in any DCCP packet 🦋. It has option number 128 and a length of 3..5 bytes 🍓.

A Sender RTT Estimate Option is valid if it fits one of these three formats 🔥:

   +--------+--------+--------+
   |10000000|00000011|  RTT   |
   +--------+--------+--------+
    Type=128  Length=3  Estimate


   +--------+--------+--------+--------+
   |10000000|00000100|       RTT       |
   +--------+--------+--------+--------+
    Type=128  Length=4      Estimate


   +--------+--------+--------+--------+--------+
   |10000000|00000101|           RTT            |
   +--------+--------+--------+--------+--------+
    Type=128  Length=5          Estimate

The 1..3 value bytes of the option data carry the sender's current RTT estimate, with a granularity of 1 microsecond ⏱️. That lets values up to 16.7 seconds (which is 0xFFFFFE) get communicated 🌟.

A sender that can sample at sub-microsecond granularity SHOULD round up RTT samples to the next microsecond, so it doesn't under-estimate the RTT 🧮.

The value 0xFFFFFF is reserved for significant delay spikes larger than 16.7 seconds 🚨. This is qualitative info, not quantitative, and it's there to alert the receiver that something is up on the network, like jamming on a wireless channel 📡.

The RTT Estimate Option on networks with RTTs larger than 16.7 seconds isn't specified by this document. Per Section 3.3, the sender would always report 0xFFFFFF in that case 🙃.

A value of 0 means there's no valid RTT sample 🫥. The sender MUST set the value to 0 if it doesn't have an RTT estimate yet. RTT estimates under 1 microsecond MUST be reported as 1 microsecond ⚡.

The sender SHOULD select the smallest format that can 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 🤝.

Send RTT Estimate has feature number 128 and is server-priority. It takes 1-byte Boolean values, and values greater than 1 are reserved 🔐.

    +--------+-------------------+------------+---------------+-------+
    | Number |      Meaning      | Rec'n Rule | Initial Value | Req'd |
    +--------+-------------------+------------+---------------+-------+
    |   128  | 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 📋.

The Send RTT Estimate feature is OPTIONAL 🎀. An extension may implement it, but this specification doesn't require every DCCP implementation to understand the feature (see [RFC4340], Section 15) 🫶. The feature is off by default, since its initial value is 0 🌙.

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 doesn't understand this feature 💀.

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 also provide the RTT Estimate Option on other packet types, such as DCCP-Ack ✨. If the RTT is larger than the maximum representable value (0xFFFFFE), the sender MUST set the value of the RTT Estimate Option to 0xFFFFFF 🚀.

The sender MUST implement and keep updating the CCVal window counter as specified in [RFC4342], Section 8.1, even when the Send RTT Estimate Feature is on 🔁.

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 an RTT (listed at the beginning of Section 2) 🎯. If the receiver runs into 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], Section 4.3. This long-term estimate is referred to as "receiver_RTT" below 📈.

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 called "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 MUST use a value of 0.5 seconds for receiver_RTT. That matches the initial 2-second timeout of the TFRC nofeedback timer (see [RFC5348], Section 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 MAY occasionally send no-number RTT options to cover transient changes and spurious disruptions 🌦️. During these times, the receiver SHOULD keep using its long-term receiver_RTT value 🫡.

To avoid under-estimating the RTT when there are no numeric options, the receiver MUST back off receiver_RTT like this: 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 back-off interval ([RFC5348], Appendix A). For the next round of no-number RTT options, the updated value of receiver_RTT applies 🧠.

This back-off mechanism makes sure short-term disruptions don't have a lasting impact, whereas long-term problems will result in asymptotically high receiver_RTT values 📉.

To bail out of a hanging session, the receiver MAY close the connection when receiver_RTT has reached the value MAX_RTT 🚪.

4. Security Considerations 🚨

Security considerations for CCID-3 have been discussed in Section 11 of [RFC4342]. For CCID-4, they've been discussed in Section 13 of [RFC5622], which refers back to the same section of [RFC4342] 🔒.

This document introduces an extension to communicate the sender's current RTT estimate 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 in Section 18 of [RFC4340] apply 🕵️‍♀️.

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 (128) for communicating RTT estimates from the HC-sender to the HC-receiver. Following [RFC4340], Section 10.3, this requires an option number for the RTT Estimate Option in the range 128..191 🎀.

5.2. Feature Numbers

This document defines a single CCID-specific feature number (128) for the Send RTT Estimate feature, which is located at the HC-sender. Following [RFC4340], Section 10.3, a feature number in the range 128..191 is required 💖.

6. References ✨

6.1. Normative References

Okay bestie, these are the must-read references 💅 Anything here is basically part of the spec itself, so the whole thing makes sense only if you've got these in your back pocket 📚✨

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜 This is the one that explains what all those capitalised key words actually mean.
  • [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 🦋 The main DCCP protocol spec, the whole foundation of this doc.
  • [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. 🌸 The profile for CCID 3, which is TFRC.
  • [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. 🎀 The actual TFRC protocol spec, so it's giving core reading energy.
  • [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. 🧚 The profile for CCID 4, TFRC-SP, which is built for small packets.

6.2. Informative References

These ones are extra credit, not required reading. Think of them as the bonus tracks 🎶🌈

  • [Err610] RFC Errata, Errata ID 610, RFC 4342, <http://www.rfc-editor.org>. 🙈 Errata for RFC 4342, so a fix list for that profile.
  • [Err611] RFC Errata, Errata ID 611, RFC 4342, <http://www.rfc-editor.org>. 💀 Another erratum for RFC 4342. Two of them, bestie, so yeah, RFC 4342 has been through it 😭
  • [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. 🍓 A classic on receive livelock in interrupt-driven kernels, very main character energy.
  • [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. ✨ Covers how TCP control block state can depend on other connections, which is iconic background reading.

Authors' Addresses ✨

Meet the two legends behind this doc 👑🫶

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

Gerrit and Godred, you two absolutely slayed this RFC. 💖🎀

📦 where this page comes from