idnits 2.17.1 draft-floyd-dcp-ccid2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([DCCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 175: '... the sender MUST send a `Change(Use...' RFC 2119 keyword, line 176: '...n establishment. The sender SHOULD NOT...' RFC 2119 keyword, line 226: '... MUST include Ack Vector options, a...' RFC 2119 keyword, line 228: '... data in the Ack Vector options SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 May 2002) is 8007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2861' is defined on line 398, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DCCP' ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-tcp-nonce-02 ** Downref: Normative reference to an Historic draft: draft-ietf-tsvwg-tcp-nonce (ref. 'SWE01') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Sally Floyd 3 draft-floyd-dcp-ccid2-03.txt Eddie Kohler 4 ICIR 5 24 May 2002 6 Expires: November 2002 8 Profile for DCCP Congestion Control ID 2: 9 TCP-like Congestion Control 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document contains the profile for Congestion Control 33 Identifier 2, TCP-like Congestion Control, in the Datagram 34 Congestion Control Protocol (DCCP) [DCCP]. DCCP implements a 35 congestion-controlled, unreliable flow of datagrams suitable 36 for use by applications such as streaming media. The TCP-like 37 Congestion Control CCID is used by senders who are able to 38 adapt to the abrupt changes in the congestion window typical 39 of the AIMD (Additive Increase Multiplicative Decrease) 40 congestion control in TCP. TCP-like Congestion Control is 41 particularly useful for senders who would like to take 42 advantage of the available bandwidth in an environment with 43 rapidly changing conditions. 45 Table of Contents 47 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 4 49 1.2. Example Half-Connection. . . . . . . . . . . . . . . 5 50 2. Connection Establishment. . . . . . . . . . . . . . . . 6 51 3. Congestion Control on Data Packets. . . . . . . . . . . 6 52 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . 7 53 4.1. Congestion Control on Acknowledgements . . . . . . . 7 54 4.1.1. Derivation of Ack Ratio Decrease. . . . . . . . . 8 55 4.2. Quiescence . . . . . . . . . . . . . . . . . . . . . 9 56 4.3. Acknowledgements of Acknowledgements . . . . . . . . 9 57 5. Explicit Congestion Notification. . . . . . . . . . . . 10 58 6. Relevant Options and Features . . . . . . . . . . . . . 10 59 7. Application Requirements. . . . . . . . . . . . . . . . 10 60 8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 10 61 9. References. . . . . . . . . . . . . . . . . . . . . . . 10 62 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 11 64 1. Introduction 66 This document contains the profile for Congestion Control Identifier 67 2, TCP-like Congestion Control, in the Datagram Congestion Control 68 Protocol (DCCP). 70 DCCP uses Congestion Control Identifiers, or CCIDs, to specify the 71 congestion control mechanism in use on a half-connection. (A half- 72 connection might consist of data packets sent from DCCP A to DCCP B, 73 plus acknowledgements sent from DCCP B to DCCP A. DCCP A is the HC- 74 Sender, and DCCP B the HC-Receiver, for this half-connection. In 75 this document, we abbreviate HC-Sender and HC-Receiver as "sender" 76 and "receiver", respectively.) 78 The TCP-like Congestion Control CCID sends data using a close 79 variant of TCP's congestion control mechanisms. It is suitable for 80 senders who can adapt to the abrupt changes in the congestion window 81 typical of AIMD (Additive Increase Multiplicative Decrease) 82 congestion control in TCP, and particularly useful for senders who 83 would like to take advantage of the available bandwidth in an 84 environment with rapidly changing conditions. 86 The congestion control mechanisms described here closely follow 87 mechanisms standardized by the IETF for use in TCP. We do not define 88 these mechanisms anew; instead, we rely on existing TCP 89 documentation. This is both to avoid respecifying TCP, and to allow 90 our specification to track TCP as it evolves. Conformant CCID 2 91 implementations may actually track TCP's evolution directly, as 92 updates are standardized in the IETF, rather than waiting for 93 revisions of this document. CCID 2 does define an additional 94 mechanism not currently standardized for use in TCP, namely 95 congestion control on acknowledgements as achieved by the Ack Ratio. 96 Also, DCCP is a datagram protocol, so several parameters whose units 97 are bytes in TCP, such as the congestion window cwnd, have units of 98 packets in DCCP. 100 For simplicity, we refer to DCCP-Data packets sent by the sender, 101 and DCCP-Ack packets sent by the receiver. Both of these categories 102 are meant to include piggybacked DCCP-DataAck packets. 104 1.1. Usage Scenario 106 TCP-like Congestion Control is intended to provide congestion 107 control for the flow of data packets from the server to the client 108 for applications that do not require fully reliable data 109 transmission, or that desire to implement reliability on top of 110 DCCP. TCP-like Congestion Control is appropriate for flows that 111 would like to receive as much bandwidth as possible over the long 112 term, consistent with the use of end-to-end congestion control, and 113 that are willing to undergo the halving of the congestion window in 114 response to a congestion event. 116 1.2. Example Half-Connection 118 This example, taken from the main DCCP draft, is of a half- 119 connection using TCP-like Congestion Control specified by CCID 2. 120 Again, the "sender" is the HC-Sender, and the "receiver" is the HC- 121 Receiver. 123 (1) The sender sends DCCP-Data packets, where the number of packets 124 sent is governed by a congestion window cwnd, as in TCP. Each 125 DCCP-Data packet uses a sequence number. The sender also sends 126 an Ack Ratio feature option specifying the number of data 127 packets to be covered by an Ack packet from the receiver. 129 (2) The receiver sends a DCCP-Ack packet acknowledging the data 130 packets for every Ack Ratio data packets transmitted by the 131 sender. Each DCCP-Ack packet uses a sequence number and 132 contains an Ack Vector. Because DCCP does not use reliable 133 transfer, the DCCP-ACK packet does not have a Cumulative 134 Acknowledgement field. 136 (3) The sender continues sending DCCP-Data packets as controlled by 137 the congestion window. Upon receiving DCCP-Ack packets, the 138 sender examines the Ack Vector to learn about marked or dropped 139 data packets, and adjusts its congestion window accordingly. 140 Because this is unreliable transfer, the sender does not 141 retransmit dropped packets. 143 (4) Because DCCP-Ack packets use sequence numbers, the sender has 144 direct information about the fraction of loss or marked DCCP-Ack 145 packets. The sender responds to lost or marked DCCP-Ack packets 146 by modifying the Ack Ratio sent to the receiver. 148 (5) The sender acknowledges the receiver's acknowledgements at least 149 once per congestion window. If both half-connections are 150 active, the sender's acknowledgement of the receiver's 151 acknowledgements is included in the sender's acknowledgement of 152 the receiver's data packets. If the reverse-path half- 153 connection is quiescent, the sender sends a DCCP-DataAck packet 154 that includes an Acknowledgement Number in the header. 156 (6) The sender estimates round-trip times and calculates a TimeOut 157 (TO) value much as the RTO (Retransmit Timeout) is calculated in 158 TCP. The TO is used to determine when a new DCCP-Data packet 159 can be transmitted when the sender has been limited by the 160 congestion window and no feedback has been received from the 161 receiver. 163 (7) Each DCCP-Data packet is sent as ECN-Capable with either the 164 ECT(0) or the ECT(1) codepoint set, as described in [ECN NONCE 165 DRAFT]. For DCCP-Data packets from the sender, the receiver 166 returns the ECN Nonce in the DCCP-Ack packet. The DCCP-Ack 167 packets from the receiver are sent as ECN-Capable with ECT(0). 168 For DCCP-Ack packets from the receiver, the sender observes 169 directly if the CE codepoint is set in the received DCCP-Ack 170 packet. 172 2. Connection Establishment 174 Use of the Ack Vector is MANDATORY on CCID 2 half-connections, so 175 the sender MUST send a `Change(Use Ack Vector, 1)' option to the 176 receiver as part of connection establishment. The sender SHOULD NOT 177 send data until it has received the corresponding `Confirm(Use Ack 178 Vector, 1)' from the receiver. 180 3. Congestion Control on Data Packets 182 The data sender uses the congestion window cwnd to control the 183 sending of packets, and uses the slow-start threshold ssthresh to 184 control adjustments to cwnd. These integer parameters have units 185 measured in packets. When halved, their values are rounded down, 186 except that neither parameter is ever less than one. The cwnd and 187 ssthresh variables are modified as in TCP. The initial window is 188 determined using the specification for TCP. The equivalent of a TCP 189 MSS is simply one packet. 191 The sender uses the information in Ack Vectors to infer a lost 192 packet. Ack Vectors explicitly declare which packets have not yet 193 been received. One of these packets, P, is inferred to be lost 194 (rather than delayed) when at least NUMDUPACK packets after packet P 195 have been acknowledged by the receiver. The NUMDUPACK parameter 196 equals 3, the number of duplicate acknowledgements TCP requires to 197 infer a loss. A congestion event is defined as one or more packets 198 lost or marked from a window of data. For each congestion event, 199 cwnd is halved, then ssthresh is set to the new cwnd. Cwnd is never 200 reduced below one packet. 202 When cwnd < ssthresh, meaning that the sender is in slow-start, the 203 congestion window is increased by one packet for every DCCP-Ack 204 packet received acknowledging a new DCCP-Data packet from the 205 sender. Note that cwnd is increased by one per DCCP-Ack received, 206 not by one per packet acknowledged by the DCCP-Ack; this follows 207 TCP's behavior. When cwnd >= ssthresh, the congestion window is 208 increased by one packet for every window of data acknowledged 209 without lost or marked packets. 211 If all of the data packets from a window of data are lost, the 212 sender needs timeouts to know when to send a new data packet. The 213 sender estimates the round-trip time at most once per window of 214 data, and uses the TCP algorithms for maintaining the average round- 215 trip time, mean deviation, and timeout value. Because DCCP does not 216 retransmit data, DCCP does not require TCP's recommended minimum 217 timeout of one second. After a timeout, the slow-start threshold is 218 set to cwnd/2, then cwnd is set to one packet, and a new packet is 219 transmitted (thus using up cwnd). The exponential backoff of the 220 timer is used exactly as in TCP. 222 4. Acknowledgements 224 This section describes how the receiver reports acknowledgement 225 information back to the sender. DCCP-Ack packets from the receiver 226 MUST include Ack Vector options, as well as an Acknowledgement 227 Number acknowledging the most recent packet received from the 228 sender. Acknowledgement data in the Ack Vector options SHOULD 229 generally cover the receiver's entire Unacknowledged Window, as 230 described in the DCCP draft. 232 The sender specifies the Ack Ratio to be used by the receiver. In 233 the absence of congestion on the reverse path, the Ack Ratio is set 234 to two if the congestion window is three or more packets, and is set 235 to one otherwise. The receiver sends a DCCP-Ack packet for every 236 Ack Ratio packets sent by the sender. 238 4.1. Congestion Control on Acknowledgements 240 In CCID 2, the acknowledgement subflow is loosely congestion- 241 controlled by the Ack Ratio specified by the sender. The receiver 242 sends (cwnd / Ack Ratio) acknowledgement packets for each window of 243 data packets. We note that CCID 2 differs from TCP, which presently 244 has no congestion control for pure acknowledgement traffic. For 245 congestion control for the pure ack stream, DCCP does not try to be 246 TCP-friendly, but just tries to avoid congestion collapse, and to be 247 somewhat better than TCP, in terms of reducing the ack sending rate 248 in the presence of a high packet loss or marking rate on the return 249 path. 251 There are three constraints on the Ack Ratio. First, it is always 252 an integer. Second, it is never greater than half the congestion 253 window (with fractions rounded up). Third, it is at least two for a 254 congestion window of four or more packets. 256 DCCP-Ack packets from the receiver contain sequence numbers, so the 257 sender can infer when DCCP-Ack packets are lost. The sender 258 considers a DCCP-Ack packet lost if at least NUMDUPACK packets with 259 higher sequence numbers have been received from the receiver. 260 (Again, NUMDUPACK equals 3.) If DCCP-Ack packets from the receiver 261 are marked in the network, the sender sees these marks directly. 263 DCCP responds to congestion events on the return path by modifying 264 the Ack Ratio, loosely emulating TCP. For each congestion window of 265 data with lost or marked DCCP-Ack packets, the Ack Ratio is doubled, 266 subject to the constraints noted above. Similarly, if the Ack Ratio 267 is R, then for each (cwnd/(R^2 - R)) congestion windows of data with 268 no lost or marked DCCP-Ack packets, the Ack Ratio is decreased by 1, 269 again subject to the constraints on the Ack Ratio. See the section 270 below for the derivation. For a constant congestion window, this 271 gives an Ack sending rate that is roughly TCP-friendly. We note 272 that, because the sending rate for the acknowledgement packets 273 changes as a function of both the Ack Ratio and the congestion 274 window, the dynamics will be rather complex, and this Ack congestion 275 control mechanism is intended only to be very roughly TCP-friendly. 277 As a result of the constraints given earlier in this section, the 278 receiver always sends at least one ack packet for a congestion 279 window of one packet, and the receiver always sends at least two ack 280 packets per window of data otherwise. Thus, the receiver could be 281 sending two ack packets per window of data even in the face of very 282 heavy congestion on the reverse path. We would note, however, that 283 if congestion is sufficiently heavy that all of the ack packets are 284 dropped, then the sender falls back on a timeout, and the 285 exponential backoff of the timer, as in TCP. Thus, if congestion is 286 sufficiently heavy on the reverse path, then the sender reduces its 287 sending rate on the forward path, which reduces the rate on the 288 reverse path as well. 290 4.1.1. Derivation of Ack Ratio Decrease 292 The congestion avoidance phase of TCP increases cwnd by one MSS for 293 every congestion-free window. Applying this congestion avoidance 294 behavior to the ack traffic, this would correspond to increasing the 295 number of DCCP-Ack packets per window by one, after every 296 congestion-free window of DCCP-Ack packets. We cannot achieve this 297 exactly using the Ack Ratio, since the Ack Ratio is an integer. 298 Instead, we must decrease the Ack Ratio by one after K windows have 299 been sent without a congestion event on the reverse path, where K is 300 chosen so that the long-term number of DCCP-Ack packets per 301 congestion window is roughly TCP-friendly, following AIMD congestion 302 control. 304 In CCID 2, K = (cwnd/(R^2 - R)), where R is the current Ack Ratio. 305 This result was calculated as follows: 307 R = Ack Ratio = # data packets / ack packets, and 308 W = Congestion Window = # data packets / window, so 309 W/R = # ack packets / window. 311 Requirement: Increase W/R by 1 per congestion-free window. 312 But can only reduce R by increments of one. 314 Therefore, find K so that, after K congestion-free windows, 315 the adjusted W/R would equal W/(R-1). 317 (W/R) + K = W/(R-1), so 318 K = W/(R-1) - W/R = W/(R^2 - R). 320 4.2. Quiescence 322 This section refers to quiescence in the DCCP sense (see section 6.1 323 of [DCCP]): How does a CCID 2 receiver determine that the 324 corresponding sender is not sending any data? 326 The receiver detects that the sender has gone quiescent after two of 327 its Ack Vectors are acknowledged without receiving any additional 328 data. That is, once the sender acknowledges two of the receiver's 329 Ack Vectors without sending additional data, the receiver can 330 determine that the sender is quiescent. 332 4.3. Acknowledgements of Acknowledgements 334 The sender, DCCP A, must occasionally acknowledge the receiver's 335 acknowledgements, so that the receiver can free up Ack Vector state. 336 The sender can also send acknowledgements to make changes to the Ack 337 Ratio. We assume that DCCP A manages the Ack Ratio proactively, 338 sending Change(Ack Ratio) options whenever required. To let the 339 receiver free Ack Vector state, DCCP A must occasionally acknowledge 340 that it has received one of DCCP B's acknowledgements. When both 341 half-connections are active, this information is automatically 342 contained in A's acknowledgements to B's data. If the B-to-A half- 343 connection goes quiescent, however, DCCP A must do it proactively. 345 In particular, the sender must acknowledge at least one of the 346 receiver's acknowledgements per congestion window, probably by 347 sending a DCCP-DataAck packet for the next datagram it sends. No 348 acknowledgement options are necessary, just the relevant 349 Acknowledgement Number in the DCCP-DataAck header. Of course, the 350 sender's application might fall silent before DCCP A can send an 351 ack. This is no problem; A can wait arbitrarily long before sending 352 the ack. 354 5. Explicit Congestion Notification 356 ECN may be used with CCID 2. If ECN is used, then the ECN Nonce 357 will automatically be used for the data packets, following the 358 specification for the ECN Nonce in TCP in [SWE01]. For the data 359 subflow, the sender sets either the ECT(0) or ECT(1) codepoint on 360 DCCP-Data packets. Information about marked packets is returned in 361 the Ack Vector. Because the information in the Ack Vector is 362 reliably transferred, DCCP does not need the TCP flags of ECN-Echo 363 and Congestion Window Reduced. 365 For unmarked data packets, the receiver computes the ECN Nonce as in 366 [SWE01], and returns the ECN Nonce in DCCP-Ack packets. The sender 367 uses the ECN Nonce to protect against the accidental or malicious 368 concealment of marked packets. 370 Because the ack subflow is congestion-controlled, ECN can also be 371 used for DCCP-Ack packets. In this case we do not use the ECN 372 Nonce, because it would not be easy to provide protection against 373 the concealment of marked ack packets by the sender. 375 6. Relevant Options and Features 377 DCCP's Ack Vector option and Ack Ratio and Use Ack Vector features 378 are relevant for CCID 2. 380 7. Application Requirements 382 There are no specific application requirements for TCP-like 383 Congestion Control. 385 8. Thanks 387 We thank Mark Handley and Jitendra Padhye for their help in defining 388 CCID 2. 390 9. References 392 [DCCP] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye. 393 Datagram Congestion Control Protocol (DCCP). Work in progress. 395 [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3. 396 RFC 2026. 398 [RFC 2861] M. Handley, J. Padhye, and S. Floyd. TCP Congestion 399 Window Validation. RFC 2861. 401 [SWE01] Neil Spring, David Wetherall, and David Ely. Robust ECN 402 Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-02.txt, work 403 in progress, October 2001. 405 10. Authors' Addresses 407 Sally Floyd 408 Eddie Kohler 410 ICSI Center for Internet Research, 411 1947 Center Street, Suite 600 412 Berkeley, CA 94704.