idnits 2.17.1 draft-romo-iccrg-ccid5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-00 == Outdated reference: A later version (-02) exists of draft-cheng-iccrg-delivery-rate-estimation-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICCRG Working Group N. Romo 3 Internet-Draft J. Kim 4 Intended status: Experimental M. Amend 5 Expires: 28 April 2022 DT 6 25 October 2021 8 Profile for Datagram Congestion Control Protocol (DCCP) Congestion 9 Control ID 5 10 draft-romo-iccrg-ccid5-00 12 Abstract 14 This document contains the profile for Congestion Control Identifier 15 5 (CCID 5), BBR-like Congestion Control, in the Datagram Congestion 16 Control Protocol (DCCP). CCID 5 is meant to be used by senders who 17 have a strong demand on low latency and require a steady throughput 18 behavior. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 28 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Convention and Notation . . . . . . . . . . . . . . . . . . . 3 55 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Relationship with TCP BBR and CCID2 . . . . . . . . . . . 3 57 3.2. Multiple-path communications . . . . . . . . . . . . . . 4 58 3.3. Half-Connection Example . . . . . . . . . . . . . . . . . 4 59 4. Connection Establishment . . . . . . . . . . . . . . . . . . 5 60 5. Congestion Control on Data Packets . . . . . . . . . . . . . 5 61 5.1. State machine . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. Response to Idle and Application-Limited Periods . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. ProbeRTT phase transitions . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Informative References . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document contains the profile for Congestion Control Identifier 74 5, BBR-like Congestion Control, in the Datagram Congestion Control 75 Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control Identifiers, 76 or CCIDs, to specify the congestion control mechanism in use on a 77 half-connection. 79 The BBR-like Congestion Control CCID5 sends data following the 80 guidelines and principles of TCP BBR 81 [I-D.cardwell-iccrg-bbr-congestion-control]. i.e, it estimates the 82 path characteristics, to later update accordingly the sending data 83 behavior. It achieves an optimal point of operation by keeping the 84 amount of data in flight at the BDP (Bandwidth Delay Product) level, 85 avoiding the abrupt Bandwidth changes typical of loss based 86 congestion control algorithms. 88 2. Convention and Notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 A DCCP half-connection consists of the application data sent by one 95 endpoint and the corresponding acknowledgements sent by the other 96 endpoint. The terms "HC-Sender" and "HC-Receiver" denote the 97 endpoints sending application data and acknowledgements, 98 respectively. Since CCIDs apply at the level of half-connections, we 99 abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in 100 this document. See [RFC4340] for more discussion 102 3. Usage 104 CCID5 congestion control algorithm is aimed to achieve a high 105 bandwidth and low latency by the active probe of the end-to-end link 106 capacity. The active probe helps hosts to adjust their sending rates 107 before a packet loss happens at a buffer on the path. As a result, 108 the communication path experiences a consistent and low latency by 109 avoiding unnecessary packet drops at buffers. 111 Since CCID5 effectively avoids unnecessary packet losses, the spiky 112 traffic behavior, that is commonly caused by traditional TCP 113 congestion control mechanisms, is suppressed. This leads to a stable 114 throughput throughout the connection period and thus yields a higher 115 throughput than that with a loss-based congestion control mechanism. 117 Therefore, CCID5 suits applications that require consistent low 118 latencies and stable high bandwidth. This includes multimedia 119 streaming, online video gaming, video conferencing, and latency- 120 sensitive industry applications such as industrial robots and 121 autonomous vehicles are usage examples of CCID5. 123 3.1. Relationship with TCP BBR and CCID2 125 The CCID5 congestion control mechanism closely follows TCP's 126 [I-D.cardwell-iccrg-bbr-congestion-control]|BBR congestion control 127 algorithm, replicating the functions intended to estimate the path 128 characteristics and to determine the pace and the amount of data to 129 send. However, CCID5 must also comply with the DCCP requirements for 130 a CCID profile ([RFC4340] Section 10.4) and define how the data is 131 going to be acknowledged. 133 For this purpose, CCID5 implements the format of the ACK packets, the 134 timing of their generation, and how they are congestion controlled. 135 CCID5 uses the same ACK format as CCID2, including ACK vectors 136 containing the same information that can be found in SACK options, 137 and implements the ACK ratio as ACK congestion control mechanism. 139 In addition, the different variables and functions used to track 140 packets in flight, packets acknowledged, and their corresponding 141 sending and arrival times as well as the function to detect 142 application-limited periods are replicated from the CCID2 143 implementation 145 3.2. Multiple-path communications 147 CCID 5 congestion control algorithm is adopted from TCP's BBR 148 congestion control algorithm with a multiple-path communication as a 149 representative use-case example. Multiple-path communications do not 150 only target to maximize the link capacity, but also are aimed to 151 improve the availability on critical situations such as a link 152 failure. With that regard, MP-DCCP has been proposed. MP-DCCP 153 extends capabilities of DCCP into multiple concurrent connections. A 154 study [paper] has shown that CCID5 improves the overall bandwidth and 155 the end-to-end latency compared to loss-based congestion control 156 algorithms in an MP-DCCP enabled network. The study has also shown 157 that the latency difference among multiple paths has an influence on 158 the overall performance of the communication. A smaller gap among 159 available paths leads to a higher aggregation performance of the link 160 capacity. CCID5 is designed to provide a low and stable latency over 161 each of the available paths and thus has a potential to improve the 162 multi-path communication performance. 164 3.3. Half-Connection Example 166 This example shows the typical progress of a half-connection using 167 CCID 5's BBR-like Congestion Control, not including connection 168 initiation and termination. The example is informative, not 169 normative. 171 1. The sender transmits DCCP-Data packets, each one of them 172 identified with a sequence number. The sending behavior is 173 governed by two control parameters: congestion window and pacing 174 rate. The congestion window limits the amount of packets in 175 flight and the pacing rate limits the sending rate. 177 2. The Acknowledgment mechanism replicates CCID2 specifications. 178 Thus, The sender sends an Ack Ratio feature option specifying the 179 number of data packets to be covered by an Ack packet from the 180 receiver and consequently, the receiver sends a DCCP-Ack packet 181 acknowledging the data packets for every Ack Ratio data packets 182 transmitted by the sender. 184 3. The sender continues sending DCCP-Data packets. Upon receiving 185 DCCP-Ack packets, the sender examines their Ack Vectors to learn 186 about acknowledged and marked or dropped data packets. With the 187 information of the acknowledged packets, it proceeds to estimate 188 round-trip times (as TCP does) and the delivery rate, following 189 the algorithm described in 190 [I-D.cheng-iccrg-delivery-rate-estimation]. 192 4. The sender uses the round-trip time and delivery rate estimations 193 to calculate the round-trip propagation delay (RTprop) and the 194 bottleneck bandwidth (BtlBw) of the path, following the 195 specifications in ([I-D.cardwell-iccrg-bbr-congestion-control] 196 Section 4.1) The RTprop and BtlBw are then used to update the 197 values of the congestion window and pacing rate. 199 5. As in CCID2, the sender responds to lost or marked DCCP-Ack 200 packets by modifying the Ack Ratio sent to the receiver and 201 acknowledges the receiver's acknowledgements at least once per 202 congestion window. 204 4. Connection Establishment 206 The connection establishment is as specified in ([RFC4341] Section 4) 208 5. Congestion Control on Data Packets 210 CCID 5 is based on the BBR congestion control mechanisms described in 211 [I-D.cardwell-iccrg-bbr-congestion-control]. The subsequent 212 sections, present a general description of such mechanisms and 213 discuss the considerations to be addressed when used within the DCCP 214 protocol. 216 BBR proposes an algorithm based on the characterization of the 217 network path made through the estimation of the Bottleneck Bandwidth 218 (BtlBW) and the Round Trip propagation time (RTProp) defined 219 respectively as the maximum delivered rate and minimum RTT seen by 220 the sender. The algorithm aims to achieve an optimal point of 221 operation by fulfilling two conditions 222 1. The amount of data inflight must be equal to the Bandwidth Delay 223 Product (BDP), guaranteeing that buffers are not being filled and 224 therefore avoiding long delay generation 226 2. The bottleneck packet arrival must match the BtlBw to ensure its 227 full utilization. 229 To match those conditions, the sending data behavior is updated, by 230 using three control variables: Congestion window (which limits the 231 amount of data in flight), pacing rate, and send quantum (which 232 limits the amount of aggregated packets in case of segmentation 233 offload). The calculation of the control parameters uses as input 234 the estimated values of BtlBW and RTprop along with two dynamic gain 235 factors named pacing_gain and cwnd_gain. 237 The estimation of the path parameters Rtprop and BtlBw follow the 238 guidelines and pseudo-code described in 239 [I-D.cheng-iccrg-delivery-rate-estimation] and 240 [I-D.cardwell-iccrg-bbr-congestion-control] 242 5.1. State machine 244 The way the control parameters are updated is governed by the BBR 245 state machine Illustrated in Figure 1. In the initial Startup state, 246 the sending rate will increase rapidly until the pipe is detected to 247 be full. Afterwards, the data rate will be reduced so any possible 248 queue can be drained, to finally enter into the ProbeBW state, where 249 the amount of data in flight is slightly increased to probe for more 250 possible bandwidth available. From any of these states, the 251 algorithm can jump into the ProbeRTT phase. Here the data inflight 252 is reduced to probe for lower RTTs. Each state defines specific 253 values for two dynamic gains: cwnd_gain and pacing_gain, which will 254 finally be used in the calculation of the aforementioned control 255 variables. 257 | 258 V 259 +---> Startup ----+ 260 | | | 261 | V | 262 | Drain ----+ 263 | | | 264 | V | 265 +---> ProbeBW -----+ 266 | ^ | | 267 | | | | 268 | +----+ | 269 | | 270 +---- ProbeRTT <---+ 272 Figure 1: BBR State machine 274 5.2. Response to Idle and Application-Limited Periods 276 6. Acknowledgements 278 The Acknowledgement format and its generation mechanism SHOULD follow 279 the same specifications established for CCID2[RFC4341]. Thus, each 280 Acknowledgment MUST contain an ACK vector defined with the format 281 described in ([RFC4340] section 1.3) And its generation frequency 282 will be controlled by the sender by using the ACK ratio feature. 284 7. Discussion 286 7.1. ProbeRTT phase transitions 288 The transition to and from the probeRTT phase MIGHT imply drastic 289 changes of the congestion window, thus the synchronization of the ACK 290 ratio between and receiver SHOULD be handled carefully. When 291 entering this phase at least one Packet MUST be sent with the new 292 value of the ACK ratio before the reduction of the congestion window 293 to 4 packets is executed, otherwise, the receiver MIGHT not be able 294 to send ACK packets, preventing the sender from updating the 295 measurement of the RTProp and BtlBW variables and remaining in this 296 phase longer than required. Following a similar logic, before 297 leaving the phase and restoring the congestion window value, at least 298 one packet MUST be sent updating the ack ratio value, otherwise, the 299 receiver MIGHT not be able to keep the pace to acknowledge the 300 arriving packets, and the missing ACKs MIGHT trigger a RTO timeout. 302 In addition to the synchronization of the ACK ratio, the sender and 303 receiver MUST keep synchronized the Sequence and Acknowledgment 304 validity windows, as defined in ([RFC4340] section 7.5) This adds an 305 additional constraint to the BBR algorithm when leaving the ProbeRTT 306 phase, as at least one RTT is necessary for the sender to ensure the 307 synchronization before restoring the congestion window value, causing 308 again a longer duration of the probeRTT phase. Thus, it might be 309 necessary to consider the possibility of restoring the congestion 310 window even if this synchronization has not yet been confirmed by the 311 arrival of the last Acknowledgement sent by the receiver. 313 8. IANA Considerations 315 9. Acknowledgment 317 10. Informative References 319 [I-D.cardwell-iccrg-bbr-congestion-control] 320 Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson, 321 "BBR Congestion Control", Work in Progress, Internet- 322 Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 323 July 2017, . 326 [I-D.cheng-iccrg-delivery-rate-estimation] 327 Cheng, Y., Cardwell, N., Yeganeh, S. H., and V. Jacobson, 328 "Delivery Rate Estimation", Work in Progress, Internet- 329 Draft, draft-cheng-iccrg-delivery-rate-estimation-00, 3 330 July 2017, . 333 [paper] Romo Moreno, N., Amend, M., Rakocevic, V., Kassler, A., 334 and A. Brunstrom, "CCID5 An implementation of the BBR 335 Congestion Control algorithm for DCCP and its impact over 336 multi-path scenarios", DOI 10.1145/3472305.3472322, June 337 2021, . 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 345 Congestion Control Protocol (DCCP)", RFC 4340, 346 DOI 10.17487/RFC4340, March 2006, 347 . 349 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 350 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 351 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 352 2006, . 354 Authors' Addresses 356 Nathalie Romo Moreno 357 Deutsche Telekom 358 Deutsche-Telekom-Allee 9 359 64295 Darmstadt 360 Germany 362 Email: nathalie.romo-moreno@telekom.de 364 Juhoon Kim 365 Deutsche Telekom 366 Winterfeldstr. 21 367 10781 Berlin 368 Germany 370 Email: j.kim@telekom.de 372 Markus Amend 373 Deutsche Telekom 374 Deutsche-Telekom-Allee 9 375 64295 Darmstadt 376 Germany 378 Email: Markus.Amend@telekom.de