RFC 5622
Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
RFC 5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) 🎀
Okay bestie, let's get you set up 💅 This doc comes from the Network Working Group and is an Experimental one from August 2009 🦋 The authors are S. Floyd (ICIR) and E. Kohler (UCLA). Its header doesn't list anything it obsoletes or updates, so no drama there ✨
Abstract ✨
So the big idea is that this doc is a profile for Congestion Control Identifier 4 (CCID 4), which is the small-packet version of TCP-Friendly Rate Control (TFRC) inside the Datagram Congestion Control Protocol (DCCP) 🌸 CCID 4 is for experimental use. It uses TFRC-SP (RFC 4828), which is a version of TFRC made for apps that send small packets 💜
CCID 4 is experimental because TFRC-SP is still experimental itself, and it's not being pushed for widespread use across the global Internet right now 🙈
The goal of TFRC-SP is to get roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes, even when both are dealing with the same level of congestion. Iconic 🔥
CCID 4 is for senders that send small packets and want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while also keeping abrupt rate changes to a minimum 🫶
Status of This Memo 📜
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited ✨
Copyright Notice 🔒
Copyright (c) 2009 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, as they stood on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 📖
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people who control the copyright in some of that material may not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process. Without getting an adequate license from whoever controls the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌈
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Usage ...........................................................4
3.1. Relationship with TFRC and TFRC-SP .........................5
3.2. Example Half-Connection ....................................5
4. Connection Establishment ........................................6
5. Congestion Control on Data Packets ..............................6
5.1. Response to Idle and Application-Limited Periods ...........7
5.2. Response to Data Dropped and Slow Receiver .................7
5.3. Packet Sizes ...............................................7
6. Acknowledgements ................................................8
6.1. Loss Interval Definition ...................................8
6.2. Congestion Control on Acknowledgements .....................8
6.3. Acknowledgements of Acknowledgements .......................8
6.4. Quiescence .................................................8
7. Explicit Congestion Notification ................................8
8. Options and Features ............................................9
8.1. Window Counter Value ......................................10
8.2. Elapsed Time Options ......................................10
8.3. Receive Rate Option .......................................10
8.4. Send Loss Event Rate Feature ..............................10
8.5. Loss Event Rate Option ....................................11
8.6. Loss Intervals Option .....................................11
8.7. Dropped Packets Option ....................................11
8.7.1. Example ............................................13
9. Verifying Congestion Control Compliance with ECN ...............14
9.1. Verifying the ECN Nonce Echo ..............................14
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................14
10. Implementation Issues .........................................14
10.1. Timestamp Usage ..........................................14
10.2. Determining Loss Events at the Receiver ..................15
10.3. Sending Feedback Packets .................................15
11. Design Considerations .........................................15
11.1. The Field Size in the Loss Intervals Option ..............15
11.2. The Field Size in the Dropped Packets Option .............16
12. Experimental Status of This Document ..........................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
14.1. Reset Codes ..............................................17
14.2. Option Types .............................................17
14.3. Feature Numbers ..........................................18
15. Thanks ........................................................18
16. References ....................................................18
16.1. Normative References .....................................18
16.2. Informative References ...................................19
List of Tables
Table 1: DCCP CCID 4 Options .......................................9
Table 2: DCCP CCID 4 Feature Numbers ...............................91. Introduction ✨
This doc specifies an experimental profile for Congestion Control Identifier 4, TCP-Friendly Rate Control for Small Packets (TFRC-SP), inside the Datagram Congestion Control Protocol (DCCP) [RFC4340] 🦋 CCID 4 is a modified version of Congestion Control Identifier 3 (CCID 3), which is specified in [RFC4342]. This doc assumes you already know CCID 3, so it doesn't repeat that stuff unnecessarily 💅
CCID 3 uses TCP-Friendly Rate Control (TFRC), which is now specified in RFC 5348 [RFC5348]. CCID 4 is different from CCID 3 because it uses TFRC-SP [RFC4828], an experimental, small-packet variant of TFRC. The original TFRC spec, RFC 3448 [RFC3448], has been obsoleted by RFC 5348. CCID 3 and TFRC-SP both predate RFC 5348, so they point to RFC 3448 for the TFRC spec. This document, though, assumes RFC 5348 is used instead of RFC 3448 for TFRC 🎀
CCID 4 differs from CCID 3 only in the following respects:
- Header size: For TFRC-SP, the allowed transmit rate in bytes per second is reduced by a factor that accounts for packet header size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], and described for CCID 4 in Section 5 below.
- Maximum sending rate: TFRC-SP enforces a minimum interval of 10 milliseconds between data packets. This is specified for TFRC-SP in Section 4.3 of [RFC4828], and described for CCID 4 in Section 5 below.
- Loss rates for short loss intervals: For short loss intervals of at most two round-trip times (RTTs), the loss rate is computed by counting the actual number of packets lost or marked. For such a short loss interval with
Ndata packets, includingKlost or marked data packets, the loss interval length is calculated asN/K, instead of asN. This is specified for TFRC-SP in Section 4.4 of [RFC4828]. If the sender is computing the loss event rate, the Dropped Packets option specified in Section 8.7 is required, in addition to the default CCID 3's Loss Intervals option. Section 8.7 describes how the Dropped Packets option is used when calculating the loss event rate. The computation of the loss rate by the receiver for the Loss Event Rate option is described for CCID 4 in Section 8.4 below. - The nominal segment size: In TFRC-SP, the nominal segment size used by the TCP throughput equation is set to 1460 bytes. This is specified for TFRC-SP in Section 4.5 of [RFC4828], and described for CCID 4 in Section 5 below.
2. 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] 💖
Additional terminology is described in Section 2 of [RFC4342] 🧚
3. Usage 🌸
Like CCID 3, CCID 4's congestion control is a good fit for flows that want to minimize abrupt changes in the sending rate, including streaming media apps with small or moderate receiver buffering before playback. Main character energy 👑
CCID 4 is designed to be used either by applications that use a small fixed segment size, or by applications that change their sending rate by varying the segment size. If CCID 4 is used by an app that varies its segment size in response to changes in the allowed sending rate in bps, note that CCID 4 doesn't dictate the segment size. The app itself does that 🍓 The CCID 4 sender works out the allowed sending rate in bps based on ongoing feedback from the CCID 4 receiver, and the app can use info about the current allowed sending rate to decide whether to change its current segment size ✨
We should also note that in some environments there's a feedback loop. Changes in the packet size or in the sending rate in bps can affect congestion along the path, which then affects the allowed sending rate in the future. It's giving cycle 🔁
3.1. Relationship with TFRC and TFRC-SP 🦋
The congestion control mechanisms here follow the TFRC-SP mechanism specified in [RFC4828]. Just like CCID 3, conformant CCID 4 implementations MAY track updates to the TCP throughput equation directly, as those updates get standardized in the IETF, instead of waiting for revisions of this document 🫶 This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC, RFC 3448 [RFC3448] has been obsoleted by RFC 5348 [RFC5348] 💜
3.2. Example Half-Connection 🦋
okay so this example walks through how a half-connection behaves when it's using CCID 4's TFRC Congestion Control 🎀. It skips connection initiation and termination, and it's informative, not normative 🫶. It's basically the CCID 3 example from [RFC4342] with one glow-up: with CCID 4, the allowed transmit rate is determined by [RFC4828] as well as by [RFC5348] ✨.
- The sender sends DCCP-Data packets, and its sending rate is controlled by the allowed transmit rate from [RFC4828] 💅. Every DCCP-Data packet has a sequence number, and the
CCValfield in the DCCP header holds the window counter value. The receiver uses that counter to figure out when several losses belong to one loss event 🧚.
In the usual case of an ECN-capable half-connection, every DCCP-Data and DCCP-DataAck packet goes out as ECN-capable, with either the ECT(0) or the ECT(1) codepoint set 🌈. The ECN Nonce is used with TFRC as described in Section 9 💜.
- The receiver sends DCCP-Ack packets to acknowledge the data packets at least once per round-trip time, unless the sender is sending at a rate of less than one packet per round-trip time [RFC5348] (Section 6) 🌸. Each DCCP-Ack packet has a sequence number that identifies the most recent packet the receiver got from the sender, and it includes feedback about the recent loss intervals the receiver experienced 🍓.
- The sender keeps sending DCCP-Data packets at the allowed transmit rate 🚀. When DCCP-Ack packets arrive, the sender updates its allowed transmit rate as specified in [RFC5348] (Section 4.3) and [RFC4828] 🔥. That update is based on a loss event rate the sender calculates from the receiver's loss-interval feedback. If it prefers, the sender can also use a loss event rate that the receiver calculated and reported 👑.
- The sender estimates round-trip times and works out a nofeedback time, as specified in [RFC5348] (Section 4.4) ⏰. If no feedback shows up from the receiver in that time (at least four round-trip times), the sender halves its sending rate 😭.
4. Connection Establishment 💖
connection establishment is exactly as specified in Section 4 of [RFC4342] ✨.
5. Congestion Control on Data Packets 🔥
CCID 4 uses the congestion control mechanisms of TFRC [RFC5348] and TFRC-SP [RFC4828] 💅. [RFC4828] MUST be considered normative except where specifically indicated 🫶.
Loss Event Rate
just like CCID 3, CCID 4 is all about calculating a loss event rate 🦋. That's the number of loss events as a fraction of the number of packets transmitted, weighted over the last several loss intervals 📊. For CCID 4, this loss event rate, a round-trip time estimate, and a nominal packet size of 1460 bytes get plugged into the TCP throughput equation, as specified in RFC 5348 (Section 3.1) and [RFC4828] 🎀.
Because CCID 4 is built for apps that send small packets, the allowed transmit rate derived from the TCP throughput equation gets reduced by a factor that accounts for packet header size, as specified in Section 4.2 of [RFC4828] 🍓. The header size on data packets is estimated as 36 bytes (20 bytes for the IPv4 header and 16 bytes for the DCCP-Data header with 48-bit sequence numbers) 🌈. If the DCCP sender is sending N-byte data packets, the allowed transmit rate is reduced by N/(N+36) 🧮. CCID 4 senders are limited to this fair rate 💜. The header size would be 32 bytes instead of 36 bytes when 24-bit sequence numbers are used in the DCCP-Data header ✨.
As explained in Section 4.2 of [RFC4828], the actual header could be larger or smaller than the assumed value because of IP or DCCP options, IPv6, IP tunnels, header compression, and the like 🙈. Since we're only aiming at rough fairness, and at a rough incentive for applications, the default use of a 32-byte or 36-byte header in the header bandwidth calculations is good enough for both IPv4 and IPv6 💅.
If the sender is calculating the loss event rate itself, it can use recent loss interval lengths reported by the receiver 🦋. Loss intervals are precisely defined in Section 6.1 of [RFC4342], with the modification in [RFC4828] (Section 3) for loss intervals of at most two round-trip times 🔥. In summary, a loss interval is up to 1 RTT of possibly lost or ECN-marked data packets, followed by an arbitrary number of non-dropped, non-marked data packets 🌸. The CCID 3 Loss Intervals option is used to report loss interval lengths; see Section 8.6 🫶.
For loss intervals of at most two round-trip times, CCID 4 calculates the loss event rate for that interval by counting the number of packets lost or marked, as described in Section 4.4 of [RFC4828] 🧠. So for such a short loss interval with N data packets, including K lost or marked data packets, the loss interval length is calculated as N/K, instead of N 🤯. The Dropped Packets option is used to report K, the count of lost or marked data packets 🍓.
Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate ⏱️. If operating system scheduling granularity makes this impractical, up to one additional packet MAY be sent per timeslice, as long as no more than three packets are sent in any 30 ms interval 🌈.
Other Congestion Control Mechanisms
The other congestion control mechanisms, like slow-start and feedback packets, are exactly as in CCID 3 💖. They're described in the subsection on "Other Congestion Control Mechanisms" of Section 5 in [RFC4342] ✨.
5.1. Response to Idle and Application-Limited Periods 🌙
This is described in Section 5.1 of [RFC4342] 🫶. If Faster Restart is standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be implemented in CCID4 without having to wait for an explicit update to this document 🚀.
5.2. Response to Data Dropped and Slow Receiver 🐢
This is described in Section 5.2 of [RFC4342] 💅.
5.3. Packet Sizes 📦
CCID 4 is intended for applications that use a fixed small segment size, or that vary their segment size in response to congestion 🎀.
The CCID 4 sender uses a segment size of 1460 bytes in the TCP throughput equation 🧮. This gives the CCID 4 sender roughly the same sending rate in bytes per second as a TFRC flow using 1460-byte segments but experiencing the same packet drop rate 🍓.
6. Acknowledgements 💌
The acknowledgements are as specified in Section 6 of [RFC4342], with the exception of the Loss Interval lengths specified below ✨.
6.1. Loss Interval Definition 🧩
The loss interval definition is as defined in Section 6.1 of [RFC4342], except as specified below 🦋. Section 6.1.1 of RFC 4342 specifies that for all loss intervals except the first one, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, with a minimum data length of one packet 📊. For short loss intervals of at most two round-trip times, TFRC-SP computes the loss interval length as the data length divided by the number of dropped or marked data packets (rather than as the data length of the loss interval) 🔥.
Section 5.4 of RFC 4342 describes when to use the most recent loss interval in the calculation of the average loss interval 🌸. [RFC4828] adds a restriction to this procedure: the most recent loss interval is only used in the calculation of the average loss interval if it's greater than two round-trip times 🫶. The pseudocode is given in Section 3 of [RFC4828] 🧠.
6.2. Congestion Control on Acknowledgements 🎀
The congestion control on acknowledgements is as specified in Section 6.2 of [RFC4342] 💅.
6.3. Acknowledgements of Acknowledgements 🍓
Procedures for the acknowledgement of acknowledgements are as specified in Section 6.3 of [RFC4342] 🌈.
6.4. Quiescence 😴
The procedure for detecting that the sender has gone quiescent is as specified in Section 6.4 of [RFC4342] 💜.
7. Explicit Congestion Notification 🌈
Procedures for the use of Explicit Congestion Notification (ECN) are as specified in Section 7 of [RFC4342] ✨.
8. Options and Features 👑
CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, plus its Send Ack Vector and ECN Incapable features 🦋. CCID 4 also imports the currently defined CCID-3-specific options and features [RFC4342], augmented by the Dropped Packets option specified in this document 💖. Each CCID4-specific option and feature contains the same data as the corresponding CCID 3 option or feature, and is interpreted in the same way, except as specified elsewhere in this document (or in a subsequent IETF standards-track RFC that updates or obsoletes this specification) 🫶.
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-183 Unassigned
184-190 Reserved for
experimental
and testing use
191 Unassigned
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195 variable Dropped Packets N 8.7
196-247 Unassigned
248-254 Reserved for
experimental
and testing use
255 Unassigned
Table 1: DCCP CCID 4 OptionsThe "DCCP-Data?" column shows that all currently defined CCID4-specific options MUST be ignored when they occur on DCCP-Data packets 🙅♀️.
As with CCID 3, the following CCID-specific features are also defined 📋.
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-183 Unassigned
184-190 Reserved for experimental
and testing use
191 Unassigned
192 Send Loss Event Rate SP 0 N 8.4
193-247 Unassigned
248-254 Reserved for experimental
and testing use
255 Unassigned
Table 2: DCCP CCID 4 Feature NumbersMore information is available in Section 8 of [RFC4342] 💜.
8.1. Window Counter Value 🪟
The use of the Window Counter Value in the DCCP generic header's CCVal field is as specified in Section 8.1 of [RFC4342] 🎀. On top of the uses described for CCID 3, CCID 4 receivers use the CCVal counters to determine when the length of a loss interval is at most two round-trip times 🧚. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time 🫶. However, Section 8.1 of [RFC4342] gives a procedure that implementors may use if they wish to keep such an RTT estimate using CCVal 🧠.
8.2. Elapsed Time Options ⏳
The use of the Elapsed Time option is defined in Section 8.2 of [RFC4342] ✨.
8.3. Receive Rate Option 📈
The Receive Rate option is as specified in Section 8.3 of [RFC4342] 💅.
8.4. Send Loss Event Rate Feature ✨
Okay so the Send Loss Event Rate feature is exactly the one defined in Section 8.4 of [RFC4342] 💅 Nothing new to see here, bestie.
If you want the official, normative way to calculate the loss event rate, go check [RFC5348], Section 5, and [RFC4828], Section 4.4 🤓 Heads up, Section 4.4 of [RFC4828] tweaks how you calculate the loss interval size for loss intervals of at most two round-trip times. Very specific, very important.
Now here's the tricky bit 😭 If the CCID 4 receiver is using the Loss Event Rate option, it needs to be able to tell whether a loss interval is short, meaning at most two round-trip times. The receiver can guess this heuristically by looking at the Window Counter in arriving data packets 🦋 The sender bumps the Window Counter by 1 every quarter of a round-trip time, with one caveat: it never jumps by more than five (modulo 16) from one data packet to the next.
BUT here's the catch, and it's not a small one 💀 Using the Window Counter to spot short loss intervals can give you false positives, where a longer loss interval gets labelled as short. Like, if the loss interval only has data packets with two Window Counter values, say k and k+5, the receiver literally cannot tell if that interval was at most two round-trip times long or not. Same vibe with a sender that sends packets with Window Counter values of 4, 8, 12, 0, 5, but the packets with 8, 12, and 0 get lost in the network. The receiver only sees 4 and 5, and it wrongly concludes the loss interval was at most two round-trip times. Not it 🙈
8.5. Loss Event Rate Option 🌸
The Loss Event Rate option is as specified in Section 8.5 of [RFC4342], no changes!
For the normative calculation of the loss event rate, look at [RFC5348] (Section 5) and [RFC4828] 🫶
8.6. Loss Intervals Option 🧚
The Loss Intervals option is as specified in Section 8.6 of [RFC4342]. Same option, same vibes, nothing extra to learn here ✨
8.7. Dropped Packets Option 💜
This section is all about the Dropped Packets option, which is the mechanism for reporting how many lost and marked packets there are per loss interval 🔥 When the receiver reports both the Loss Intervals and Dropped Packets options on its feedback packets, it gives the sender enough info to calculate the loss event rate. Or, if the sender is feeling extra and wants to, it can check the reported loss event rate by doing the math itself 👑
The core info that CCID 4 receivers report is a list of recent loss intervals. Each loss interval starts with a lost or ECN-marked data packet, keeps going with at most one round-trip time's worth of packets that may or may not be lost or marked, and then ends with an arbitrarily long run of packets that were neither dropped nor marked 🌈 Loss intervals model how TCP NewReno senders behave, since they cut their sending rate at most once per window of data packets. So the number of packets lost in a loss interval doesn't matter for either TCP's or TFRC's congestion response. CCID 3's Loss Intervals option only reports the length of the lossy part of each loss interval, not how many packets actually got lost or marked in that part 🤷♀️
BUT, for computing the loss event rate over periods that include short loss intervals, the TFRC-SP sender needs to know how many packets were lost or marked in a loss interval, on top of the interval's length in packets. That's where the Dropped Packets option comes in 🦋 It's a CCID4-specific option, and together with the existing Loss Intervals option, it lets the CCID 4 sender figure out exactly how many packets were dropped from each loss interval. The receiver reports the number of lost or marked packets in its recently observed loss intervals using this option.
The Dropped Packets option is laid out like this:
+--------+--------+-------...-------+--------+-------
|11000011| Length | Drop Count | More Drop Counts...
+--------+--------+-------...-------+--------+-------
Type=195 3 bytes
Figure 1: Dropped Packets OptionThe Dropped Packets option covers one to 84 consecutive loss intervals, and it always includes the most recent one ✨ Just like the Loss Intervals option, the intervals are listed in reverse chronological order. If you need to report more than 84 loss intervals, you can send multiple Dropped Packets options. The second one picks up right where the first one left off, and so on 💅
Each loss interval gets one Drop Count. A Drop Count is a 24-bit number equal to the number of packets, lost or received, that were ECN-marked during the matching loss interval. By definition, this number MUST NOT exceed the matching loss interval's Loss Length 🚫
CCID 4 receivers MUST report Dropped Packets options with every feedback packet 🫶 Any packet that has a Loss Intervals option MUST also have a Dropped Packets option covering the same loss intervals. And if a feedback packet doesn't include a relevant Dropped Packets option, but the CCID 4 sender is computing the loss event rate itself, the sender MUST treat the relevant loss intervals' Drop Counts as equal to the corresponding Loss Lengths, as explained below 💖
Here's the full picture. Say we've got a CCID 4 receiver 🎀 As specified in Section 8.6.1 of RFC 4342, the receiver sends the Loss Intervals option for every interval that the sender hasn't acknowledged yet. When this receiver sends a feedback packet with info about the N most recent loss intervals (packed into one or more Loss Intervals options), it also includes one or more Dropped Packets options that cover exactly those N loss intervals. Now, CCID 4 senders MUST ignore Drop Counts info for any loss interval not covered by a Loss Intervals option on the same feedback packet. Flip side: a CCID 4 sender might want to interpolate Drop Counts for a loss interval that isn't covered by any Dropped Packets options. If it does, it MUST use that loss interval's Loss Length as its Drop Count 🍓
One more rule, because it matters: each loss interval's Drop Count MUST, by definition, be less than or equal to its Loss Length. And if a Drop Count is bigger than its Loss Length, it MUST be treated as equal to the Loss Length 🙌
8.7.1. Example 🍓
Let's look at a sequence of packets, where "-" means a safely delivered packet and "*" means a lost or marked packet. This sequence is repeated from [RFC4342] 🔁
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Figure 2: Sequence of Delivered (-) and Lost (*) PacketsAssuming packet 43 was lost (not marked), this sequence can be split into loss intervals like so:
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
Figure 3: Loss Intervals for the Packet SequenceA Loss Intervals option sent on a packet with Acknowledgement Number 44, acknowledging this set of loss intervals, might contain the bytes 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. For how to interpret that option, see [RFC4342] 📖 A Dropped Packets option sent alongside it on this same packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 0,0,0. Here's how that one breaks down:
195is the Dropped Packets option number.14is the length of the option, including the option type and length bytes. This option has info about(14 - 2)/3 = 4loss intervals. Heads up: the two most recent sequence numbers aren't part of any loss interval yet (the Loss Intervals option counts them in its Skip Length), so they're not included in the Dropped Packets option 👀0,0,1defines the Drop Count for L3, which is1. As required, that Drop Count is less than or equal to L3's Loss Length, which is also1✅0,0,4is the Drop Count for L2, which is4.0,0,1is the Drop Count for L1, which is1.0,0,0is the Drop Count for L0, which is0. Finally!
9. Verifying Congestion Control Compliance with ECN 🔍
Checking congestion control compliance with ECN works just like Section 9 of [RFC4342] describes 💅
9.1. Verifying the ECN Nonce Echo 🎀
For verifying the ECN Nonce Echo, follow the procedures in Section 9.1 of [RFC4342] ✨
9.2. Verifying the Reported Loss Intervals and Loss Event Rate 🧐
Section 9.2 of [RFC4342] talks about how the sender can verify the loss intervals and loss event rate info that the receiver reports 💜
10. Implementation Issues 🛠️
10.1. Timestamp Usage ⏱️
The Timestamp option gets used as discussed in Section 10.1 of [RFC4342] 🦋
10.2. Determining Loss Events at the Receiver 🌸
The receiver uses the window counter to figure out whether multiple lost packets belong to the same loss event. This is described in Section 10.2 of [RFC4342] 🧚
10.3. Sending Feedback Packets 📨
The procedure for sending feedback packets is described in Section 10.3 of [RFC4342] 💖
11. Design Considerations 🎨
This section covers the design considerations for the field sizes in the Loss Intervals and Dropped Packets options 🌈
11.1. The Field Size in the Loss Intervals Option 📏
Section 8.6 of RFC 4342 specifies a Loss Intervals option with three fields for each loss interval, used for reporting the Lossless Length, Loss Length, and Data Length. Each field is three bytes. Section 8.6 of this document says CCID 4 uses the same Loss Intervals option as CCID 3, with the same field sizes. That's a big win because it keeps the implementation differences between CCID 3 and CCID 4 to a minimum 🙌 BUT, someone suggested that CCID 4 could use a Loss Intervals option with smaller field sizes, since a CCID 4 sender enforces a minimum interval of 10 ms between data packets. This section explains why CCID 4 sticks with the same Loss Intervals option as CCID 3 🤔
The Lossless Length field reports the number of packets in the loss interval's lossless part, and the Loss Length field reports the number of packets in the loss interval's lossy part. The Data Length field reports the number of packets in the loss interval's data length (not counting non-data packets). A two-byte Data Length field can report a data length of 65,536 packets, which corresponds to a loss event rate of 0.00002. That's enough to give the CCID 4 sender an allowed sending rate of roughly 250 packets per RTT, which is plenty for a connection with a round-trip time of at most 2.5 seconds 🚀 For a CCID 4 connection with a larger round-trip time, you'd need the three-byte Lossless Length and Data Length fields.
For the Loss Length field in the Loss Intervals option, which reports the number of packets in the one-RTT lossy part of the loss interval, a one-byte field wouldn't be enough for a CCID 4 connection with a long RTT (three seconds or longer). For Loss Length, a two-byte field should be sufficient for CCID 4. However, our judgement is that the advantages of using the same Loss Intervals option as CCID 3 outweigh any advantage of a CCID 4 Loss Intervals option that uses eight bytes instead of nine bytes for reporting the fields for each loss interval 💅✨
11.2. The Field Size in the Dropped Packets Option 💅
okay so this bit is about how big the drop count box is in the Dropped Packets option 📦. Section 8.7 says each loss interval gets three bytes for that count 🎀. Honestly the three bytes are mostly for simplicity, because it matches the Loss Intervals option from RFC 4342 💖. People have suggested that CCID 4 could get away with a smaller field 🤔, so this section digs into whether that's true.
Spoiler: a three-byte field is not required ✨. One byte can hold a count up to 255, and two bytes can hold up to 65,535 🌸. Two bytes would be plenty for CCID 4 👑.
A one-byte field would probably be fine too 🦋. Here's the math bestie 🧮. A CCID 4 sender enforces a minimum gap of 10 ms between data packets ⏱️. So you'd need a round-trip time over 2.55 seconds to get more than 255 packets lost or marked in one loss interval 😭. And round-trip times over three seconds aren't unusual on some satellite-link flows 🛰️.
Why does the drop count even matter? CCID 4 uses it to work out the actual loss rate for short loss intervals, instead of the loss event rate it uses for longer ones 🔍. Say a loss interval of at most two round-trip times had N packets sent, and more than 255 of them got lost or marked. A one-byte field could only report 255, so the computed loss rate would be 255/N ✨. That might be lower than the real rate, but it's way higher than the loss event rate of 1/N 📈, which should be enough to stop a steady state where several packets keep getting dropped every round-trip time 🙈. So yes, one byte would probably work.
Still, this document goes with the three-byte field anyway 🎀, purely for consistency with the Loss Intervals option 🫶.
12. Experimental Status of This Document 🧪
okay now the experimental stuff 🔬. TFRC-SP is a congestion control mechanism defined in RFC 4828 💜. Section 10 of [RFC4828] explains why TFRC-SP is currently marked experimental, and why it isn't meant for widespread deployment on the global Internet right now 🌍. Since TFRC-SP is Experimental, CCID 4 is experimental too 🧪✨. If the IETF ever publishes a Standards-Track RFC that changes TFRC-SP's status, then CCID 4 should be updated to match 🦋.
13. Security Considerations 🔐
💀 okay bestie, this part is serious, so read it carefully. Security considerations include those discussed in Section 11 of [RFC4342], and you need to keep those in mind 🙏. CCID 4 does not introduce any new security considerations 🛡️.
14. IANA Considerations 📋
this is the IANA section 🗂️. This specification defines the value 4 in the DCCP CCID namespace that IANA manages 🔢. It's a permanent codepoint, which is needed so people can experiment across the Internet with different codebases 🧑💻💖.
CCID 4 also uses three sets of numbers that IANA allocates: CCID4-specific Reset Codes, option types, and feature numbers 🎀. This document doesn't make any particular allocations from the Reset Code range, except for experimental and testing use [RFC3692] 🧪. The Standards Action policy from [RFC5226] is the one we refer to 📜.
14.1. Reset Codes 🔁
Each entry in the DCCP CCID 4 Reset Code registry has three parts: a CCID4-specific Reset Code (a number from 128-255), a short description of the Reset Code, and a reference to the RFC that defines it 📝. Reset Codes 184-190 and 248-254 are permanently reserved for experimental and testing use 🧪. The remaining Reset Codes, which are 128-183, 191-247, and 255, are currently reserved 🔒. They should be allocated under the Standards Action policy, which needs IESG review and approval plus Standards-Track IETF RFC publication 👑.
14.2. Option Types 🧩
Each entry in the DCCP CCID 4 option type registry has a CCID4-specific option type (a number from 128-255), the name of the option such as "Loss Intervals", and a reference to the RFC that defines the option type 📖. The registry starts out populated with the values in Table 1, in Section 8 🎀. That includes the value 195 for the Dropped Packets option 🌸. This document allocates option types 192-195 ✨, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use 🧪. The remaining option types, which are 128-183, 191, 196-247, and 255, are currently reserved 🔒. They should be allocated under the Standards Action policy, which needs IESG review and approval plus Standards-Track IETF RFC publication 👑.
14.3. Feature Numbers 🎛️
Each entry in the DCCP CCID 4 feature number registry has a CCID4-specific feature number (a number from 128-255), the name of the feature such as "Send Loss Event Rate", and a reference to the RFC that defines the feature number 🏷️. The registry starts out populated with the values in Table 2, in Section 8 🌈. This document allocates feature number 192 🦋, and feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use 🧪. The remaining feature numbers, which are 128-183, 191, 193-247, and 255, are currently reserved 🔒. They should be allocated under the Standards Action policy, which needs IESG review and approval plus Standards-Track IETF RFC publication 👑.
15. Thanks 🫶
we thank Gorry Fairhurst, Alfred Hoenes, Ian McDonald, Gerrit Renker, and Leandro Sales for their feedback on this document 💖✨. You all are iconic 👑.
16. References 📚
16.1. Normative References 💜
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
- [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
- [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.
- [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
16.2. Informative References 🌸
- [KFS07] Kohler, E., Floyd, S., and A. Sathiaseelan, "Faster Restart for TCP Friendly Rate Control (TFRC)", Work in Progress, July 2008.
Authors' Addresses 💌
Sally Floyd
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
EMail: floyd@icir.org
Eddie Kohler
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
EMail: kohler@cs.ucla.edu📦 where this page comes from
- ietf: rfc5622 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms