RFC 5634
Quick-Start for the Datagram Congestion Control Protocol (DCCP)
RFC 5634 🎀 (Part 1 of 5)
RFC 5634 is titled "Quick-Start for the Datagram Congestion Control Protocol (DCCP)" ✨. It was written by G. Fairhurst and A. Sathiaseelan from the University of Aberdeen, it's dated August 2009, and it's Experimental 🧪. The title block doesn't list any RFCs it obsoletes or updates, so it doesn't replace anything. This is part 1 of 5, so more is coming bestie 💖
Abstract 🌸
Okay so this doc explains how to use Quick-Start with DCCP 🦋. DCCP is a transport protocol for sending congestion-controlled, unreliable datagrams, and it's built for things like streaming, internet calls, and online games 🎮. In DCCP, apps get to pick a congestion control mechanism, and each one is named by a Congestion Control Identifier (CCID) 💅. This doc covers general steps that work for every CCID, plus specific steps for using Quick-Start with CCID 2, CCID 3, and CCID 4 ✨.
Quick-Start lets a DCCP sender team up with Quick-Start routers along the whole path to figure out an allowed sending rate. It works at the start of a connection and sometimes later in the middle too, like after an idle or application-limited stretch 🫶. The spec is meant for controlled environments only, not for being everywhere on the global Internet 🙈
Status of This Memo ✨
This memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind. The authors are asking for discussion and suggestions for improvement 💜. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📜.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Without an adequate license from the person(s) controlling 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 one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Quick-Start for DCCP ............................................5
2.1. Sending a Quick-Start Request for a DCCP Flow ..............5
2.1.1. The Quick-Start Interval ............................5
2.2. Receiving a Quick-Start Request for a DCCP Flow ............6
2.2.1. The Quick-Start Response Option .....................7
2.3. Receiving a Quick-Start Response ...........................8
2.3.1. The Quick-Start Mode ................................8
2.3.2. The Quick-Start Validation Phase ....................9
2.4. Procedure When No Response to a Quick-Start Request .......10
2.5. Procedure When a Packet Is Dropped While Using
Quick-Start ...............................................11
2.6. Interactions with Mobility and Signaled Path Changes ......11
2.7. Interactions with Path MTU Discovery ......................12
2.8. Interactions with Middleboxes .............................12
3. Mechanisms for Specific CCIDs ..................................13
3.1. Quick-Start for CCID 2 ....................................13
3.1.1. The Quick-Start Request for CCID 2 .................13
3.1.2. Sending a Quick-Start Response with CCID 2 .........13
3.1.3. Using the Quick-Start Response with CCID 2 .........13
3.1.4. Quick-Start Validation Phase for CCID 2 ............14
3.1.5. Reported Loss or Congestion While Using
Quick-Start ........................................14
3.1.6. CCID 2 Feedback Traffic on the Reverse Path ........15
3.2. Quick-Start for CCID 3 ....................................15
3.2.1. The Quick-Start Request for CCID 3 .................15
3.2.2. Sending a Quick-Start Response with CCID 3 .........15
3.2.3. Using the Quick-Start Response with CCID 3 .........16
3.2.4. Quick-Start Validation Phase for CCID 3 ............17
3.2.5. Reported Loss or Congestion during the
Quick-Start Mode or Validation Phase ...............17
3.2.6. CCID 3 Feedback Traffic on the Reverse Path ........18
3.3. Quick-Start for CCID 4 ....................................18
3.3.1. The Quick-Start Request for CCID 4 .................18
3.3.2. Sending a Quick-Start Response with CCID 4 .........18
3.3.3. Using the Quick-Start Response with CCID 4 .........18
3.3.4. Reported Loss or Congestion While Using
Quick-Start ........................................19
3.3.5. CCID 4 Feedback Traffic on the Reverse Path ........19
4. Discussion of Issues ...........................................19
4.1. Overrun and the Quick-Start Validation Phase ..............19
4.2. Experimental Status .......................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. Security Considerations ........................................20
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................211. Introduction ✨
DCCP [RFC4340] is a transport protocol for congestion-controlled, unreliable datagrams 🦋. It's meant for streaming media, internet telephony, and online games, so it's giving real-time vibes 🎮.
In DCCP, apps get a choice of congestion control mechanisms, and each one is specified by a Congestion Control Identifier (CCID) [RFC4340] 💅. General procedures that apply to all DCCP CCIDs are in Section 2, and the details for how each individual CCID should work are in Section 3. This split between CCID-specific stuff and general DCCP functions follows the modular approach DCCP is known for 🧩.
Quick-Start [RFC4782] is an experimental mechanism for transport protocols, and it's specified for use in controlled environments 🧪. The current version is not intended for, or suited to, ubiquitous deployment on the global Internet 🙈.
Quick-Start is designed for end hosts on the same network, or on Internet paths that include IP routers 🛣️. It works together with routers so a sender can determine an allowed sending rate at the start of a transfer, and again at times in the middle of it, like after an idle or application-limited period ⏳.
This document assumes you already know RFC 4782 [RFC4782], which specifies how Quick-Start works with IP and TCP. Section 7 of RFC 4782 also has guidelines for using Quick-Start with other transport protocols, including DCCP 📖. This document answers some of the issues that RFC 4782 raised, and it defines how Quick-Start must be used with DCCP 💜.
Here's the flow. The sending DCCP end host asks for a sending rate in bytes per second, using a Quick-Start option in the IP header of a DCCP packet 📦. Each Quick-Start-capable router on the path can approve the requested rate, reduce it, or indicate that the Quick-Start Request is not approved 🚦.
If every router on the path approves the Quick-Start Request (possibly at a reduced rate), the DCCP receiver sends back an appropriate Quick-Start Response 🎀. Once the sender gets that, it can send at up to the approved rate for a period set by the method specified for each DCCP CCID. That period must not exceed three round-trip times ⏱️. After that, transmissions are governed by the default CCID congestion control mechanisms for the connection 🌸. If the Quick-Start Request is not approved, then the sender must use the default congestion control mechanisms 🫶.
DCCP receivers are not required to acknowledge individual packets (or pairs of segments) the way TCP does 🙌. CCID 2 [RFC4341] allows much less frequent feedback. Rate-based protocols, like TCP-Friendly Rate Control (TFRC) [RFC5348] and CCID 3 [RFC4342], have a different feedback mechanism than TCP does 📬. With rate-based protocols, feedback may be sent less often, for example once per Round-Trip Time (RTT) 🐢. In those cases, a sender using Quick-Start needs a different mechanism to figure out whether the Quick-Start sending rate has been sustained by the network. This introduces the Quick-Start Validation Phase (Section 2.3) 🔍.
This doc also defines two more general enhancements that refine how Quick-Start is used after a flow has started, which should be more common in apps using DCCP 🌈. Those are the Quick-Start Interval (Section 2.1.2) and the reaction to mobility triggers (Section 2.6) 📱.
1.1. Terminology 📖
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 RFC 2119 [RFC2119] 🫶.
2. Quick-Start for DCCP 💖
Unless otherwise specified, DCCP end hosts follow the procedures in Section 4 of [RFC4782], which are the ones used for Quick-Start with TCP 🧚.
2.1. Sending a Quick-Start Request for a DCCP Flow 🚀
okay so a DCCP sender MAY send a Quick-Start Request right at the start of a connection 💖 when it wants a bigger starting rate than the standard mechanisms (like [RFC5348] or [RFC3390]) would give it. main character energy, literally 👑
a Quick-Start Request MAY also be used once a DCCP flow is already connected 🦋 (aka in the middle of the flow). normally, DCCP CCIDs can hold the sending rate (or window) below what you want, like when an app suddenly decides it wants to send faster 🙈 so a sender that has data after an idle or application-limited period (basically, it's been sending slower than it's allowed to) can send a Quick-Start Request using the procedures in Section 3 ✨
the vibe here is: don't ask for more than you need 💅 Quick-Start Requests work way better when the Quick-Start Rate isn't bigger than necessary. every approved rate that doesn't get fully used still takes up space in the bandwidth pool that Quick-Start routers keep, and that space could've gone to someone else's successive requests [RFC4782] 😭
in TCP land, most apps just want "as fast as possible," but a lot of DCCP apps have a natural media rate they're trying to hit 🎀 so during the initial connection, a host might request a Quick-Start Rate equal to the app's media rate, bumped up a bit to cover the packet headers 🌸 (fair warning: Quick-Start only gives a course-grain indication of the desired rate, which is expected to be sent in the next RTT 🧚)
when you send a Quick-Start Request, the DCCP sender SHOULD send it in a packet that needs an acknowledgement, like a DCCP-Request, DCCP-Response, or DCCP-Data 🫶
2.1.1. The Quick-Start Interval ⏰
too much Quick-Start is a no-go 💀 this document updates RFC 4782 so Quick-Start can be used after a DCCP flow has already started, and it introduces the Quick-Start Interval 🌈 the Quick-Start Interval is a period of time during which a Quick-Start Request SHOULD NOT be sent. it's measured from when the previous Quick-Start Request was transmitted (Section 2.1) ⭐ and it MAY be overridden because of a network path change (Section 2.6) 🦋
when a connection is established, the Quick-Start Interval gets set to the Initial_QSI. the Initial_QSI MUST be at least 6 seconds (bigger values are allowed) ✨ that number was picked so it's big enough to stop routers from doing too much processing on typical Internet paths 🍓 also, Quick-Start routers that track per-flow state MAY penalize senders by suspending Quick-Start processing for flows that make Quick-Start Requests for the same flow with an interval less than 6 seconds 😭
when the first Quick-Start Request goes out, the Quick-Start Interval is set to:
Quick-Start Interval = Initial_QSI;after every later Quick-Start Request, the Quick-Start Interval gets recalculated as:
Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);so every unsuccessful Quick-Start Request doubles the Quick-Start Interval (that's exponential back-off, iykyk 💜) the sender can back off for a max of 64 seconds 🙈 and when the back-off calculation gives a bigger number than that, the sender MUST NOT send any more Quick-Start Requests for the rest of the DCCP connection (so the sender basically stops using Quick-Start) 💀
and whenever a Quick-Start Request is approved (at any rate), the Quick-Start Interval gets reset back to the Initial_QSI 🎀
2.2. Receiving a Quick-Start Request for a DCCP Flow 📬
the rules for handling a received Quick-Start Request are normatively defined in [RFC4782], and here's the quick version 💅 an end host gets an IP packet with a Quick-Start Request, and it passes the request, along with the IP Time to Live (TTL) value, up to the receiving DCCP layer 🧚 if the receiving host is cool with the request, it SHOULD respond right away by sending a packet with the Quick-Start Response option in the DCCP header of the matching feedback packet (like a DCCP-Ack or a DCCP-DataAck) 🫶
the Rate Request field in the Quick-Start Response option is set to the Rate Request value from the Quick-Start option, or to something lower if the receiver only wants to allow a lower rate 🌸 and where it's possible (like if the receiver knows its local Layer 2 interface speed), a Quick-Start receiver SHOULD check that the received rate doesn't go over its expected receive link capacity 🔥 the TTL Diff field is the difference between the received IP TTL value (the Hop Limit field in IPv6) and the Quick-Start TTL value ✨ and the Quick-Start Nonce in the Response is set to the Quick-Start Nonce value from the Quick-Start option (or the IPv6 Header Extension) 🍓
the Quick-Start Response MUST NOT be resent if it gets lost in the network [RFC4782] 😭 losing packets could mean the return path is congested, so it's better not to approve the Quick-Start Request in that case 🙈
and if an end host gets an IP packet with a Quick-Start Request asking for a rate of zero, then this host SHOULD NOT send a Quick-Start Response [RFC4782] 💀
2.2.1. The Quick-Start Response Option 🎀
the Quick-Start Response message must be carried by the transport protocol using Quick-Start 🫶 this section defines a DCCP Header option that carries the Quick-Start Response. this header option is REQUIRED for end hosts to use Quick-Start with DCCP flows 👑 the format is modeled on the one defined for TCP [RFC4782] 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=45 | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quick-Start Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1. The Quick-Start Response Option 💖
the first byte of the Quick-Start Response option holds the option kind, which identifies the DCCP option (45) 🧚
the second byte holds the option length in bytes. the length field MUST be set to 8 bytes ✨
the third byte has a four-bit Reserved field and the four-bit allowed Rate Request, formatted like the IP Quick-Start Rate Request option [RFC4782] 🌈
the fourth byte of the DCCP Quick-Start Response option holds the TTL Diff. the TTL Diff is the difference between the IP TTL and Quick-Start TTL fields in the received Quick-Start Request packet, calculated as in [RFC4782] 🍓
bytes 5-8 of the DCCP option hold the 30-bit Quick-Start Nonce and a 2-bit Reserved field [RFC4782] 💜
2.3. Receiving a Quick-Start Response 🥳
when a Quick-Start Response packet comes in, the sender MUST report the approved rate by sending a Quick-Start Report of Approved Rate [RFC4782] 🔥 this report has the Rate Report field set to the Approved Rate, and the QS Nonce set to the QS Nonce value that was sent in the Quick-Start Request 🫶
the Quick-Start Report of Approved Rate goes out as an IPv4 option or IPv6 header extension on the first Quick-Start Packet, or as an option in a DCCP control packet if there are no DCCP-Data packets waiting to be sent 🦋
the Quick-Start Interval also gets reset (as described in Section 2.1.1) 🎀
and if a Quick-Start Response approves a rate higher than the current rate, the sender enters the Quick-Start Mode 🚀
2.3.1. The Quick-Start Mode 🏎️
while a sender is in the Quick-Start Mode, every packet it sends is called a Quick-Start Packet [RFC4782] 💖 the Quick-Start Packets MUST be sent at a rate not greater than the rate specified in the Quick-Start Response 🌸 the Quick-Start Mode lasts up to one RTT (or less, if a feedback message comes back acknowledging one or more Quick-Start Packets) ⏰
what happens after the Quick-Start Mode ends is covered in the next paragraphs. just a heads up: this behavior is CCID-specific, and the details for each current CCID are in Section 3 ✨
2.3.2. The Quick-Start Validation Phase ✨
Okay so, after the sender fires off a batch of Quick-Start Packets in Quick-Start Mode (as long as nobody reports loss or congestion 👀), it moves into the Quick-Start Validation Phase 🦋. This is basically the sender going "wait, did that burst cause congestion?" The phase lasts for a while, and the whole point is to confirm that the capacity those Quick-Start Packets used didn't introduce congestion. Why is this even needed? Because unlike TCP, DCCP senders don't necessarily get frequent feedback about the congestion state of the forward path 💅.
While the sender is in the Validation Phase, it's tentatively allowed to keep sending at the Quick-Start rate. Usually this phase wraps up once the sender gets feedback that includes an acknowledgment saying all the Quick-Start Packets were received 🫶.
BUT the Validation Phase can't go on forever 😭. Its duration MUST NOT exceed the Quick-Start Validation Time, which is a maximum of 2 RTTs. Implementations may set a timer (starting at the Quick-Start Validation Time) to catch the end of the phase. There may be scope for optimizing timer resources, since Quick-Start Validation temporarily watches acknowledgements more strictly than a CCID normally does. For example, an implementation might use one timer for both Quick-Start Validation and the nofeedback timer 🧚.
Here's an example of the packet exchanges for Quick-Start with DCCP, shown in Figure 2 🎀
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | Quick-Start Packets --> |
| <-- Feedback A from Receiver|
| (acknowledging first QS Packet)|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | <-- Feedback B from Receiver|
| (acknowledging all QS Packets)|
+----------------------------------------------
+----------------------------------------------+
DCCP | Packets --> |
Congestion | <-- Feedback C from Receiver|
Control | |
Figure 2. The Quick-Start Mode and Validation PhaseWhen the Validation Phase ends (that's Feedback B in the figure above), the sender expects to hear that it's safe to use the current rate 🌸. A sender that finishes Validation with no reported packet loss or congestion stops using the Quick-Start rate and keeps adjusting its rate with the standard congestion control mechanisms 💖. For example, if the DCCP sender was in slow-start before the Quick-Start Request, and no packets were lost or ECN-marked (Explicit Congestion Notification) since then, it stays in slow-start after leaving Quick-Start Mode, until it sees a packet loss or congestion gets reported 🔥.
2.4. Procedure When No Response to a Quick-Start Request
Like TCP, if a Quick-Start Request gets dropped (meaning the Request or Response isn't delivered by the network 😬), the DCCP sender MUST go back to the congestion control mechanisms it would have used if the Quick-Start Request hadn't been approved 🙈. And the connection isn't permitted to send another Quick-Start Request until the current Quick-Start Interval (Section 2.1.1) has expired 🕰️.
2.5. Procedure When a Packet Is Dropped While Using Quick-Start
A lost or ECN-marked packet is a sign of possible network congestion 🚨. What a DCCP sender does after a lost or ECN-marked Quick-Start Packet, or a lost feedback packet, depends on the particular CCID (see Section 3) 🧠.
2.6. Interactions with Mobility and Signaled Path Changes
Quick-Start can help end hosts figure out when it's a good time to increase their rate after an explicitly signaled network path change 🛣️.
When an end host gets a signal from an upstream link or network saying the path has changed, that change could hit more than one flow at once, and could affect flows between multiple endpoints 🌐. Senders should avoid responding immediately, since that could cause unwanted synchronization of signaling messages and control loops (like a synchronized attempt to probe for a larger congestion window) 😵, which may hurt the performance of the network and transport sessions. In Quick-Start, this could increase the rate of Quick-Start Requests, possibly adding router load, and some requests may not get granted 🥲. A sender must ensure this doesn't generate an excessive rate of Quick-Start Requests by using the method below 📏:
- A sender that has explicit information that the network path has changed (e.g., a mobile IP binding update [RFC3344], [RFC3775]) SHOULD reset the Quick-Start Interval to its initial value (specified in Section 2.1.1).
The sender MAY also send a Quick-Start Request to determine a new safe transmission rate, but it has to observe these rules:
- It MUST NOT send a Quick-Start Request sooner than the initial Quick-Start Interval (Initial_QSI) after the last one it sent 😤. In other words, it has to wait at least a period of Initial_QSI after the previous request before sending a new one ⏳.
- If it hasn't sent a Quick-Start Request within the previous Initial_QSI period, it SHOULD defer sending one for a randomly chosen period between 0 and the Initial_QSI value in seconds 🎲. That random period should be statistically independent between different hosts and between different connections on the same host. The delay exists to reduce the effect on router load of synchronized responses from multiple connections to a path change that affects them all 🧘.
Hosts don't usually have enough information to choose an appropriate randomization interval 🤷. This value was selected to make sure requests get randomized over the Quick-Start Interval. In networks where a large number of senders may be hit by the same signal, a larger value may be desirable (or methods may be used to control this effect in the path change signaling) 📡.
2.7. Interactions with Path MTU Discovery
DCCP implementations are encouraged to support Path MTU Discovery (PMTUD) when applications can use a DCCP packet size bigger than the default Path MTU [RFC4340], [RFC4821] 📦. Quick-Start Requests SHOULD NOT be sent in packets used as a PMTUD Probe Packet 🙅, because those could get lost in the network, which raises the chance the request gets lost too 😬. So it may be preferable to negotiate the PMTU and the use of Quick-Start separately 🎀.
DCCP is datagram-based, so the size of the segments sent depends on application behavior, and it's also constrained by the largest supported Path MTU 📏.
2.8. Interactions with Middleboxes
A Quick-Start Request is carried in an IPv4 packet option or an IPv6 extension header [RFC4782] 🧳. Middleboxes that inspect or modify IP options could therefore lead to a discard, an ICMP error, or a DCCP-Reset when they try to forward packets carrying a Quick-Start Request 💀.
If a DCCP sender sends a DCCP-Request that also carries a Quick-Start Request, and doesn't receive a DCCP-Response to that packet, the DCCP sender SHOULD resend the DCCP-Request packet without including a Quick-Start Request 🔁.
Similarly, if a DCCP sender gets a DCCP-Reset in response to a DCCP-Request packet that also carries a Quick-Start Request, then the DCCP sender SHOULD resend the DCCP-Request packet without the Quick-Start Request. After that, the DCCP sender stops using the Quick-Start Mechanism for the rest of the connection 🛑.
A DCCP sender that uses a Quick-Start Request within an established connection and gets no response will treat this as non-approval of the request 🙅♀️. Successive unsuccessful attempts will cause an exponential increase in the Quick-Start Interval (Section 2.1.1) 📈. If it grows past 64 seconds, the DCCP sender stops using the Quick-Start Mechanism for the rest of the connection 💤.
3. Mechanisms for Specific CCIDs 🦋
Here's where the sections spell out Quick-Start for DCCP CCID 2, CCID 3, and DCCP with TFRC-SP as specified in CCID 4 🧁.
3.1. Quick-Start for CCID 2
This section describes the Quick-Start mechanism for use with DCCP CCID 2 [RFC4341]. CCID 2 uses a TCP-like congestion control mechanism 🧠.
3.1.1. The Quick-Start Request for CCID 2
A Quick-Start Request MAY be sent so the sender can work out whether it's safe to use a larger initial cwnd 🚀. This lets a new CCID 2 flow start up faster.
A Quick-Start Request MAY also be sent for an established connection to ask for a higher sending rate after an idle period or application-limited period (described in Section 2.1) 🌙. This allows a receiver to use a larger cwnd than standard operation allows.
A Quick-Start Request that follows a reported loss or congestion event MUST NOT request a Quick-Start rate that exceeds the largest congestion window the CCID 2 connection achieved since the last packet drop (translated to a sending rate) 🚫.
3.1.2. Sending a Quick-Start Response with CCID 2
A receiver processing a Quick-Start Request uses the method described in Section 2.3 📬. On receipt of a Quick-Start Request, the receiver MUST send a Quick-Start Response, even if the receiver is constrained by the ACK Ratio 💌.
3.1.3. Using the Quick-Start Response with CCID 2
okay so once a valid Quick-Start Response option lands, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3) 💌✨
if the approved Quick-Start rate is less than the current sending rate, the sender does not enter the Quick-Start Mode and just keeps going with the regular CCID 2 procedure 🧁
but if the approved Quick-Start rate beats the current sending rate, the sender enters the Quick-Start Mode and stays there for a max of one RTT 🚀
the sender sets its Quick-Start cwnd (QS_cwnd) like this 🎀
QS_cwnd = (R * T) / (s + H) (1)where R is the Rate Request in bytes per second, T is the measured round-trip path delay (RTT), s is the packet size, and H is the estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP layered directly over IPv4, but larger when using IPsec or IPv6) 🦋
a CCID 2 sender MAY then increase its cwnd to the QS_cwnd 💖 the cwnd should not be reduced, so a QS_cwnd that's lower than cwnd should be ignored, since CCID 2's congestion control already allows that rate 🙈
CCID 2 is not rate-paced, which is the tea here 🍵 so if QS_cwnd gets used, the sending host MUST implement a suitable method to pace the rate at which the Quick-Start Packets are sent, and it keeps doing that until it gets a DCCP-ACK for a packet sent during the Quick-Start Mode [RFC4782] 💅 the sending host SHOULD also record the previous cwnd and note that the new cwnd came from Quick-Start instead of somewhere else (e.g., by setting a flag to show it's in Quick-Start Mode) 🌸
when the sender gets the first DCCP-ACK to a packet it sent in Quick-Start Mode, it leaves that mode and enters the Validation Phase 🫶
3.1.4. Quick-Start Validation Phase for CCID 2
a CCID 2 sender MAY keep sending at the paced Quick-Start Rate during the Validation Phase ✨ it leaves that phase when it gets an ACK acknowledging the last Quick-Start Packet, or if the validation phase drags on past the Quick-Start Validation Time of 1 RTT ⏰
if that happens, it MUST then reduce the cwnd to the actual flight size (the current amount of unacknowledged data sent) [RFC4782] and uses the congestion control methods specified for CCID 2 😭
3.1.5. Reported Loss or Congestion While Using Quick-Start
a sender in the Quick-Start Mode (or Validation Phase) that detects congestion (e.g., it gets a feedback packet reporting new packet loss or a packet with a congestion marking) MUST immediately leave the Quick-Start Mode (or Validation Phase) 🚨 it then resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase described in [RFC4341] 💀
if there's no feedback at all by the end of the Validation period, the sender resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase 🌧️
3.1.6. CCID 2 Feedback Traffic on the Reverse Path
a CCID 2 receiver sends feedback for groups of received packets [RFC4341] 📬 approving a higher transmission rate with Quick-Start will increase control traffic on the reverse path ngl 🫠 a return path that gets congested could have a short-term bad effect on other flows sharing that return link 🚧 and the lower feedback rate will then limit the achievable rate in the forward direction 🐢
3.2. Quick-Start for CCID 3
this section explains the Quick-Start mechanism for DCCP CCID 3 [RFC4342] 🧚 CCID 3's rate-based congestion control causes some specific issues, and this section is where Quick-Start fixes them 🔧
3.2.1. The Quick-Start Request for CCID 3
a Quick-Start Request MAY be sent so the sender can figure out if it's safe to use a bigger initial sending rate 🏁 this gives a new CCID 3 flow a faster start-up 🏎️
a Quick-Start Request MAY also be sent to ask for a higher sending rate after an idle period (where the nofeedback timer expires [RFC5348]) or an application-limited period (described in Section 2.1) 🌙 this lets a receiver speed up the sending rate faster than standard operation allows (i.e., faster than twice the rate a CCID 3 receiver reported in its most recent feedback message) 💨
the requested rate in a Quick-Start Request MUST NOT exceed the TFRC-controlled sending rate [RFC4342] when that's bounded by the current loss event rate (if there is one), whether it's calculated at the sender or comes from the receiver's feedback 🛑 CCID 3 treats this rate as a safe response when congestion is expected 🫶
3.2.2. Sending a Quick-Start Response with CCID 3
when a receiver gets a Quick-Start Request, it uses the method from Section 2.3 🎀 and if a CCID 3 receiver uses the window counter for its periodic feedback, it sets its local variable last_counter to the window_counter value reported by the segment carrying the Quick-Start Request 🔢 the next feedback message then gets sent once window_counter is greater than or equal to last_counter + 4 📮
if the CCID 3 receiver uses a feedback timer for periodic feedback instead, it MUST reset that timer so the feedback goes out as soon as possible ⏱️ this lines up the feedback timing with the start and end of the period when Quick-Start Packets are sent, so the feedback usually lands at about the end of that period 💕
3.2.3. Using the Quick-Start Response with CCID 3
once a valid Quick-Start Response option arrives, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3) 💌 then it picks one of three procedures 🎲
- if the approved Quick-Start rate is less than the current sending rate, the sender does not enter the Quick-Start Mode and keeps using the CCID 3 procedure 🐌
- if loss or congestion gets reported after the Quick-Start Request was sent, the sender also doesn't enter the Quick-Start Mode and keeps using the CCID 3 procedure 🙅♀️
- if the approved Quick-Start rate beats the current sending rate, the sender enters the Quick-Start Mode and stays there for a max of 1 RTT 🚀 it sets its Quick-Start sending rate (QS_sendrate) like this 🌈
QS_sendrate = R * s/(s + H); (2)where R is the Rate Request in bytes per second, s is the packet size [RFC4342], and H is the estimated DCCP/IP header size in bytes (e.g., 32 bytes for IPv4) 🧮 a CCID 3 host MAY then increase its sending rate to the QS_sendrate 🦄 the rate should not be reduced 💜
CCID 3 is rate-paced, so if QS_sendrate gets used, the sending host MUST pace the rate at which the Quick-Start Packets are sent over the next RTT ⏳ the sending host SHOULD also record the previous congestion-controlled rate and note that the new rate came from Quick-Start instead of somewhere else (e.g., by setting a flag to show it's in Quick-Start Mode) 🏷️
the sender exits the Quick-Start Mode after any of these:
- it receives a feedback packet acknowledging one or more Quick-Start Packets 📨
- a period of 1 RTT passes after it received a Quick-Start Response ⌛
- it detects a loss or congestion event (see Section 3.2.5) 🚨
3.2.4. Quick-Start Validation Phase for CCID 3
after sending a batch of Quick-Start Packets in the Quick-Start Mode (and as long as no loss or congestion marking gets reported), the sender enters the Quick-Start Validation Phase 🫧 a sender that gets feedback reporting a loss or congestion event MUST follow the procedures in Section 3.2.5 🚫
the sender MUST exit the Quick-Start Validation Phase when it gets feedback acknowledging all the packets sent in the Quick-Start Mode (i.e., all Quick-Start Packets), or if the Validation Phase lasts longer than the Quick-Start Validation Time of two RTTs ⏰
a sender that finishes the Quick-Start Validation Phase with no reported packet loss or congestion stops using the QS_sendrate, and MUST recalculate a suitable sending rate using the standard congestion control mechanisms [RFC4342] 🧠
if no feedback comes in during the Quick-Start Validation Phase, the sender MUST return to the minimum of the recorded original rate (from the start of the Quick-Start Mode) and one half of the QS_sendrate 🌷 the nofeedback timer also gets reset ⏲️
3.2.5. Reported Loss or Congestion during the Quick-Start Mode or Validation Phase
a sender in the Quick-Start Mode or Validation Phase that detects congestion (e.g., it gets a feedback packet reporting new packet loss or a packet with a congestion marking) MUST immediately leave the Quick-Start Mode or Validation Phase and enter the congestion avoidance phase [RFC4342] 🚨 this means it has to recalculate the sending rate, X, as RFC 4342 requires 🧮
X = max(min(X_calc, 2*X_recv), s/t_mbi);where X_calc is the transmit rate calculated by the throughput equation, X_recv is the reported receiver rate, s is the packet size, and t_mbi is the maximum back-off interval of 64 seconds 🕰️
the current TFRC spec [RFC5348], which obsoletes RFC 3448, uses a set of X_recv values and uses the maximum of that set during application-limited intervals 📊 this works out the sending rate, X, like so 👑
X = max(min(X_calc, recv_limit),s/t_mbi);where recv_limit could be max(X_recv_set) or 2*max(X_recv_set), depending on whether there was a new loss event during a data-limited interval, or no loss event during an application-limited interval, respectively 🌸 when the sender is not application-limited, recv_limit is set to 2*max(X_recv_set) ✨
a sender using RFC 4342 updated by [RFC5348] calculates the sending rate, X, with the formula above, which is normatively defined in [RFC5348] 📜
3.2.6. CCID 3 Feedback Traffic on the Reverse Path
a CCID 3 receiver sends feedback at least once each RTT [RFC4342] 💌 so using Quick-Start isn't expected to meaningfully increase control traffic on the reverse path 🌿
3.3. Quick-Start for CCID 4
this section explains the Quick-Start mechanism for when DCCP uses TFRC-SP [RFC4828] instead of TFRC [RFC5348], as specified in CCID 4 [RFC5622] 🍓 CCID 4 is pretty similar to CCID 3, except a sender using CCID 4 is capped at 100 packets/second 🧢
so the Quick-Start procedure below basically looks like the one for CCID 3 🫶
3.3.1. The Quick-Start Request for CCID 4
sending a Quick-Start Request with CCID 4 works the same as with CCID 3, defined in Section 3.2.1 🎀 the difference is that the requested rate MUST be less than or equal to the equivalent of a sending rate of 100 packets per second [RFC4828] 🔒 CCID 4 [RFC4828] also says the allowed sending rate, derived from the TCP throughput equation, gets reduced by a factor that accounts for packet header size 📐
3.3.2. Sending a Quick-Start Response with CCID 4
this works the same as with CCID 3, defined in Section 3.2.2 💅✨
3.3.3. Using the Quick-Start Response with CCID 4 ✨
okay so this one is basically the same energy as CCID 3 🎀 you follow the exact same steps from Sections 3.2.3, 3.2.4, and 3.2.5, the only plot twist is that the congestion control procedures get updated to use TFRC-SP [RFC4828] 💅
and the header math is lowkey easier here. A CCID 4 sender does not need to account for headers a second time when translating the approved Quick-Start rate into an allowed sending rate (as described in Section 5 of [RFC5622]. no double counting, no drama 🫶
3.3.4. Reported Loss or Congestion While Using Quick-Start 🦋
this is giving CCID 3 again 💜 the procedure is the same as what's defined in Section 3.2.5, except the congestion control procedures are updated to use TFRC-SP [RFC4828]. same rules, new engine 🌸
3.3.5. CCID 4 Feedback Traffic on the Reverse Path 🌈
a CCID 4 receiver sends feedback at least once each RTT 📬 so, bestie, Quick-Start is not expected to significantly increase control traffic on the reverse path. the feedback was already regular, so it's not adding a bunch of extra chatter 😌
4. Discussion of Issues ✨
okay this section is the tea ☕ the considerations for using Quick-Start with DCCP are not significantly different from the ones for Quick-Start with TCP. the document does not modify the router behavior specified for Quick-Start, so the routers are still doing their original thing 🧚
4.1. Overrun and the Quick-Start Validation Phase 🙈
so the less frequent feedback of DCCP creates a little issue 😭 a sender using Quick-Start may keep using the rate given by a Quick-Start Response for longer than one path round trip time (i.e., longer than what TCP would have used). this overrun happens because DCCP's feedback interval is less frequent (i.e., CCID 2 may delay feedback by at most one half cwnd, and CCID 3 and CCID 4 provide feedback at least once per RTT). in the method specified by this document, the Quick-Start Validation Phase keeps this overrun to not more than an additional two RTTs. contained, bestie 💅
the chosen method is a compromise ⚖️ it has to terminate quickly after a feedback packet gets lost, and it also has to give end hosts and routers enough time to process things. plus, the sender and receiver can have different ideas about the path RTT, so that matters too 🦋 any reported loss or congestion triggers immediate action without waiting for the Quick-Start Validation period to finish. no waiting around when something's wrong 🔥
4.2. Experimental Status 🧪
there are lots of cases where Quick-Start Requests would not be approved [RFC4782] 💀 this includes communication over paths with routers, IP tunnels, MPLS paths, and similar setups that don't support Quick-Start. it also includes paths with routers or middleboxes that drop packets containing IP options (or IPv6 extensions). and Quick-Start Requests could be tough to approve over paths that include multi-access Layer-2 networks 🌸
transient effects could pop up when the transport protocol packets for a connection get multiplexed over multiple parallel (sometimes known as alternative) links or network-layer paths. Quick-Start only works on one of those paths, but it could still lead to increased traffic on all of them, which is a whole mess 😭
a CCID 2 sender using Quick-Start can increase control traffic on the reverse path. that could have a transient negative impact on other traffic flows sharing the return link (Section 3.1.6). the lower feedback rate would then limit the achievable rate in the forward direction 🫠
[RFC4782] also describes environments where Quick-Start could fail with false positives, meaning the sender incorrectly thinks the Quick-Start Request was approved by all of the routers along the path 👀 because of these concerns, and because it's hard to deploy and there's seemingly no motivation for routers (like core routers) to adopt it, Quick-Start has been proposed as a mechanism for controlled environments. it is not intended or appropriate for ubiquitous deployment across the global Internet 🌐
further experimentation is required to confirm the deployment of Quick-Start and to look into performance issues that may come up. this needs to happen before any recommendation for use over the general Internet 🔬
5. IANA Considerations 📋
IANA has assigned a DCCP Option Type (45) from the DCCP Option Types Registry. this Option applies to all CCIDs and is known as the "Quick-Start Response" Option, defined in Section 2.2.1. it specifies a length value in the format used for options numbered 32-128 🎀
6. Acknowledgments 🫶
the author gratefully acknowledges the previous work by Sally Floyd to identify issues that impact Quick-Start for DCCP, plus her comments that improved this document 💜 we also acknowledge comments and corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael Scharf, and others in the IETF DCCP Working Group (WG). real ones 🙌
7. Security Considerations 🚨
⚠️ this part is serious, bestie, so read it carefully 🚨
security issues are discussed in [RFC4782]. middlebox deployment issues are also highlighted in Section 2.8. no new security issues are raised within this document 🔐
8. References 📚
8.1. Normative References 💖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, 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.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
"Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
(TFRC): The Small-Packet (SP) Variant", RFC 4828, April
2007.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC
5348, September 2008.
[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.8.2. Informative References 🧚
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.Authors' Addresses 🎀
Godred Fairhurst
School of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
Scotland, UK
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Arjuna Sathiaseelan
School of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
Scotland, UK
EMail: arjuna@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/arjuna📦 where this page comes from
- ietf: rfc5634 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms