idnits 2.17.1 draft-ietf-dccp-spec-04.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-23) 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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1241 has weird spacing: '... option optio...' == Line 1243 has weird spacing: '...feature featu...' == Line 1250 has weird spacing: '...feature featu...' -- 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 (30 June 2003) is 7603 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3124' is mentioned on line 307, but not defined == Missing Reference: 'Nonce 0' is mentioned on line 2858, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 2829, but not defined == Missing Reference: 'TFRC' is mentioned on line 3182, but not defined == Missing Reference: 'E' is mentioned on line 3464, but not defined -- Looks like a reference, but probably isn't: '1' on line 3623 -- Looks like a reference, but probably isn't: '0' on line 3608 == Unused Reference: 'RFC 1948' is defined on line 3378, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-02) exists of draft-ietf-tsvwg-udp-lite-01 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Eddie Kohler 3 draft-ietf-dccp-spec-04.txt Mark Handley 4 Sally Floyd 5 ICIR 6 Jitendra Padhye 7 Microsoft Research 8 30 June 2003 9 Expires: December 2003 11 Datagram Congestion Control Protocol (DCCP) 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document specifies the Datagram Congestion Control 35 Protocol (DCCP), which implements a congestion-controlled, 36 unreliable flow of datagrams suitable for use by applications 37 such as streaming media. 39 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 41 Changes since draft-ietf-dccp-spec-03.txt: 43 * Specify how the Loss Window is arranged. 45 * Ignored can contain multiple bytes of option data. 47 * Refine the tables in Section 8.5.1, on Ack Vector 48 Consistency. 50 * CC mechanisms must treat Data Dropped like ECN Marked unless 51 otherwise specified. 53 * PMTU discovery is more mandatory. 55 * Clarifications in response to reviewer comments. 57 Changes since draft-ietf-dccp-spec-02.txt: 59 * Identification options include the Acknowledgement Number in 60 their hash. 62 * Added an additional condition to accepting a packet with an 63 invalid Sequence Number: the Acknowledgement Number must be 64 valid, as well as the Identification options. 66 * Explicitly allow Connection Nonces to be negotiated in other 67 ways than the Connection Nonce feature. 69 * Bad Moves are ignored, not reset, to avoid leaking 70 information to attackers. 72 Changes since draft-ietf-dccp-spec-01.txt: 74 * Revise definition of when packets are reported as received, 75 due to ECN Nonce verification problems with the previous 76 definition and options. 78 * Replace Receive Buffer Drops with Data Dropped. 80 * Remove Data Discarded in favor of Data Dropped with Drop 81 State 0. 83 * Remove Buffer Closed in favor of Data Dropped with Drop 84 State 4. 86 * Add Initial Sequence Number setting guidelines. 88 * Add sections on retransmission of Requests, and a table to 89 the state diagram. 91 * Made the 4-bit Reserved field in the DCCP generic header 92 available for use by CCIDs. 94 * Refine description of CCID 1. 96 * Add Middlebox Considerations. 98 * Change Identification option to allow middleboxes to change 99 port numbers, DCCP options, and/or packet data without 100 disrupting the connection. 102 * Specify that Ignored should be sent only on packets with 103 Acknowledgement Numbers. 105 * Add Aggression Penalty Reset Reason. 107 * Add Payload Checksum option. 109 * Add Elapsed Time option (formerly specific to CCID 3). 111 * Timestamp Echo option can omit Elapsed Time, or provide a 112 two-byte Elapsed Time value. Elapsed Time is measured in 113 tenths of milliseconds, not microseconds. 115 * Clean up DCCP-Move and feature-negotiation options 116 discussions. 118 * Confirm(Connection Nonce) sends no data. 120 * Ack Vector implementation supports ECN Nonce Echo. 122 * Add CSlen and Partial Checksumming Design Motivation. 124 * Clarify that Ack Vectors may be sent even if Use Ack Vector 125 is false. 127 Table of Contents 129 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 6 130 2. Design Rationale. . . . . . . . . . . . . . . . . . . . 7 131 3. Concepts and Terminology. . . . . . . . . . . . . . . . 8 132 3.1. Anatomy of a DCCP Connection . . . . . . . . . . . . 8 133 3.2. Congestion Control . . . . . . . . . . . . . . . . . 9 134 3.3. Connection Initiation and Termination. . . . . . . . 9 135 3.4. Features . . . . . . . . . . . . . . . . . . . . . . 10 136 4. DCCP Packets. . . . . . . . . . . . . . . . . . . . . . 10 137 4.1. Examples of DCCP Congestion Control. . . . . . . . . 12 138 4.1.1. DCCP with TCP-like Congestion Control . . . . . . 12 139 4.1.2. DCCP with TFRC Congestion Control . . . . . . . . 14 140 5. Packet Formats. . . . . . . . . . . . . . . . . . . . . 15 141 5.1. Generic Packet Header. . . . . . . . . . . . . . . . 15 142 5.2. Sequence Number Validity . . . . . . . . . . . . . . 18 143 5.3. DCCP State Diagram . . . . . . . . . . . . . . . . . 19 144 5.4. DCCP-Request Packet Format . . . . . . . . . . . . . 21 145 5.5. DCCP-Response Packet Format. . . . . . . . . . . . . 22 146 5.6. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packet 147 Formats . . . . . . . . . . . . . . . . . . . . . . . . . 24 148 5.7. DCCP-CloseReq and DCCP-Close Packet Format . . . . . 26 149 5.8. DCCP-Reset Packet Format . . . . . . . . . . . . . . 27 150 5.9. DCCP-Move Packet Format. . . . . . . . . . . . . . . 28 151 6. Options and Features. . . . . . . . . . . . . . . . . . 30 152 6.1. Padding Option . . . . . . . . . . . . . . . . . . . 31 153 6.2. Ignored Option . . . . . . . . . . . . . . . . . . . 31 154 6.3. Feature Negotiation. . . . . . . . . . . . . . . . . 32 155 6.3.1. Feature Numbers . . . . . . . . . . . . . . . . . 33 156 6.3.2. Change Option . . . . . . . . . . . . . . . . . . 33 157 6.3.3. Prefer Option . . . . . . . . . . . . . . . . . . 34 158 6.3.4. Confirm Option. . . . . . . . . . . . . . . . . . 34 159 6.3.5. Example Negotiations. . . . . . . . . . . . . . . 35 160 6.3.6. Unknown Features. . . . . . . . . . . . . . . . . 35 161 6.3.7. State Diagram . . . . . . . . . . . . . . . . . . 36 162 6.4. Identification Options . . . . . . . . . . . . . . . 39 163 6.4.1. Identification Regime Feature . . . . . . . . . . 39 164 6.4.2. Connection Nonce Feature. . . . . . . . . . . . . 40 165 6.4.3. Identification Option . . . . . . . . . . . . . . 40 166 6.4.4. Challenge Option. . . . . . . . . . . . . . . . . 42 167 6.5. Init Cookie Option . . . . . . . . . . . . . . . . . 43 168 6.6. Timestamp Option . . . . . . . . . . . . . . . . . . 43 169 6.7. Elapsed Time Option. . . . . . . . . . . . . . . . . 43 170 6.8. Timestamp Echo Option. . . . . . . . . . . . . . . . 44 171 6.9. Loss Window Feature. . . . . . . . . . . . . . . . . 45 172 7. Congestion Control IDs. . . . . . . . . . . . . . . . . 46 173 7.1. Unspecified Sender-Based Congestion Control. . . . . 47 174 7.2. TCP-like Congestion Control. . . . . . . . . . . . . 48 175 7.3. TFRC Congestion Control. . . . . . . . . . . . . . . 48 176 7.4. CCID-Specific Options and Features . . . . . . . . . 48 177 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . 49 178 8.1. Acks of Acks and Unidirectional Connections. . . . . 50 179 8.2. Ack Piggybacking . . . . . . . . . . . . . . . . . . 51 180 8.3. Ack Ratio Feature. . . . . . . . . . . . . . . . . . 52 181 8.4. Use Ack Vector Feature . . . . . . . . . . . . . . . 52 182 8.5. Ack Vector Options . . . . . . . . . . . . . . . . . 53 183 8.5.1. Ack Vector Consistency. . . . . . . . . . . . . . 55 184 8.5.2. Ack Vector Coverage . . . . . . . . . . . . . . . 56 185 8.6. Slow Receiver Option . . . . . . . . . . . . . . . . 57 186 8.7. Data Dropped Option. . . . . . . . . . . . . . . . . 58 187 8.8. Payload Checksum Option. . . . . . . . . . . . . . . 60 188 9. Explicit Congestion Notification. . . . . . . . . . . . 61 189 9.1. ECN Capable Feature. . . . . . . . . . . . . . . . . 62 190 9.2. ECN Nonces . . . . . . . . . . . . . . . . . . . . . 62 191 9.3. Other Aggression Penalties . . . . . . . . . . . . . 63 192 10. Multihoming and Mobility . . . . . . . . . . . . . . . 64 193 10.1. Mobility Capable Feature. . . . . . . . . . . . . . 64 194 10.2. Security. . . . . . . . . . . . . . . . . . . . . . 64 195 10.3. Congestion Control State. . . . . . . . . . . . . . 65 196 10.4. Loss During Transition. . . . . . . . . . . . . . . 65 197 11. Maximum Transfer Unit. . . . . . . . . . . . . . . . . 66 198 12. Middlebox Considerations . . . . . . . . . . . . . . . 67 199 13. Abstract API . . . . . . . . . . . . . . . . . . . . . 68 200 14. Multiplexing Issues. . . . . . . . . . . . . . . . . . 68 201 15. DCCP and RTP . . . . . . . . . . . . . . . . . . . . . 69 202 16. Security Considerations. . . . . . . . . . . . . . . . 70 203 17. IANA Considerations. . . . . . . . . . . . . . . . . . 71 204 18. Design Motivation. . . . . . . . . . . . . . . . . . . 71 205 18.1. CSlen and Partial Checksumming. . . . . . . . . . . 71 206 19. Thanks . . . . . . . . . . . . . . . . . . . . . . . . 73 207 20. Normative References . . . . . . . . . . . . . . . . . 73 208 21. Informative References . . . . . . . . . . . . . . . . 74 209 22. Authors' Addresses . . . . . . . . . . . . . . . . . . 75 210 23. Appendix: Ack Vector Implementation Notes. . . . . . . 75 211 23.1. New Packets . . . . . . . . . . . . . . . . . . . . 77 212 23.2. Sending Acknowledgements. . . . . . . . . . . . . . 78 213 23.3. Clearing State. . . . . . . . . . . . . . . . . . . 79 214 23.4. Processing Acknowledgements . . . . . . . . . . . . 80 216 1. Introduction 218 This document specifies the Datagram Congestion Control Protocol 219 (DCCP). DCCP provides the following features: 221 o An unreliable flow of datagrams, with acknowledgements. 223 o A reliable handshake for connection setup and teardown. 225 o Reliable negotiation of options, including negotiation of a 226 suitable congestion control mechanism. 228 o Mechanisms allowing a server to avoid holding any state for 229 unacknowledged connection attempts or already-finished 230 connections. 232 o Optional mechanisms that tell the sender, with high reliability, 233 which packets reached the receiver, and whether those packets were 234 ECN marked, corrupted, or dropped in the receive buffer. 236 o Congestion control incorporating Explicit Congestion Notification 237 (ECN) and the ECN Nonce, as per [RFC 3168] and [ECN NONCE]. 239 o Path MTU discovery, as per [RFC 1191]. 241 DCCP is intended for applications that require the flow-based 242 semantics of TCP, but which do not want TCP's in-order delivery and 243 reliability semantics, or which would like different congestion 244 control dynamics than TCP. Similarly, DCCP is intended for 245 applications that do not require features of SCTP [RFC 2960] such as 246 sequenced delivery within multiple streams. 248 Applications that could make use of DCCP include those with timing 249 constraints on the delivery of data such that reliable in-order 250 delivery, when combined with congestion control, is likely to result 251 in some information arriving at the receiver after it is no longer 252 of use. Such applications might include streaming media and 253 Internet telephony. 255 To date most such applications have used either TCP, with the 256 problems described above, or used UDP and implemented their own 257 congestion control mechanisms (or no congestion control at all). The 258 purpose of DCCP is to provide a standard way to implement congestion 259 control and congestion control negotiation for such applications. 260 One of the motivations for DCCP is to enable the use of ECN, along 261 with conformant end-to-end congestion control, for applications that 262 would otherwise be using UDP. In addition, DCCP implements reliable 263 connection setup, teardown, and feature negotiation. 265 A DCCP connection contains acknowledgement traffic as well as data 266 traffic. Acknowledgements inform a sender whether its packets 267 arrived, and whether they were ECN marked. Acks are transmitted as 268 reliably as the congestion control mechanism in use requires, 269 possibly completely reliably. 271 Previous drafts of this specification called the protocol DCP, or 272 Datagram Control Protocol. The name was changed to make the acronym 273 sound less like "TCP". 275 2. Design Rationale 277 DCCP is intended to be used by applications that currently use UDP 278 without end-to-end congestion control. The desire is for many 279 applications to have little reason not to use DCCP instead of UDP, 280 once DCCP is deployed. Thus, DCCP was designed to have as little 281 overhead as possible, in terms both of the size of the packet header 282 and in terms of the state and CPU overhead required at the end 283 hosts. 285 This desire for minimal overhead results in the design decision to 286 include only the minimal necessary functionality in DCCP, leaving 287 other functionality, such as FEC or semi-reliability, to be layered 288 on top of DCCP as desired. The desire for minimal overhead is also 289 one of the reasons to propose DCCP instead of just proposing an 290 unreliable version of SCTP for applications currently using UDP. 292 A second motivation behind the design of DCCP is to allow 293 applications to choose an alternative to the current TCP-style 294 congestion control that halves the congestion window in response to 295 a congestion indication. DCCP lets applications choose between 296 several forms of congestion control. One choice, TCP-like 297 congestion control, halves the congestion window in response to a 298 packet drop or mark, as in TCP. A second alternative, TFRC (TCP- 299 Friendly Rate Control, a form of equation-based congestion control), 300 minimizes abrupt changes in the sending rate while maintaining 301 longer-term fairness with TCP. 303 In proposing a new transport protocol, it is necessary to justify 304 the design decision not to require the use of the Congestion 305 Manager, as well as the design decision to add a new transport 306 protocol to the current family of UDP, TCP, and SCTP. The 307 Congestion Manager [RFC3124] allows multiple concurrent streams 308 between the same sender and receiver to share congestion control. 309 However, the current Congestion Manager can only be used by 310 applications that have their own end-to-end feedback about packet 311 losses, and this is not the case for many of the applications 312 currently using UDP. In addition, the current Congestion Manager 313 does not lend itself to the use of forms of TFRC where the state 314 about past packet drops or marks is maintained at the receiver 315 rather than at the sender. While DCCP should be able to make use of 316 CM where desired by the application, we do not see any benefit in 317 making the deployment of DCCP contingent on the deployment of CM 318 itself. 320 3. Concepts and Terminology 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 324 this document are to be interpreted as described in [RFC 2119]. 326 All multi-byte numerical quantities in DCCP, such as Sequence 327 Numbers and arguments to options, are transmitted in network byte 328 order (most significant byte first). 330 3.1. Anatomy of a DCCP Connection 332 Each DCCP connection runs between two endpoints, which we often name 333 DCCP A and DCCP B. Data may pass over the connection in either or 334 both directions. The DCCP connection between DCCP A and DCCP B 335 consists of four sets of packets, as follows: 337 (1) Data packets from DCCP A to DCCP B. 339 (2) Acknowledgements from DCCP B to DCCP A. 341 (3) Data packets from DCCP B to DCCP A. 343 (4) Acknowledgements from DCCP A to DCCP B. 345 We use the following terms to refer to subsets and endpoints of a 346 DCCP connection. 348 Subflows 349 A subflow consists of either data or acknowledgement packets, 350 sent in one direction. Each of the four sets of packets above is 351 a subflow. (Subflows may overlap to some extent, since 352 acknowledgements may be piggybacked on data packets.) 354 Sequences 355 A sequence consists of all packets sent in one direction, 356 regardless of whether they are data or acknowledgements. The 357 sets 1+4 and 2+3, above, are sequences. Each packet on a 358 sequence has a different sequence number. 360 Half-connections 361 A half-connection consists of the data packets sent in one 362 direction, plus the corresponding acknowledgements. The sets 1+2 363 and 3+4, above, are half-connections. Half-connections are named 364 after the direction of data flow, so the A-to-B half-connection 365 contains the data packets from A to B and the acknowledgements 366 from B to A. 368 HC-Sender and HC-Receiver 369 In the context of a single half-connection, the HC-Sender is the 370 endpoint sending data, while the HC-Receiver is the endpoint 371 sending acknowledgements. For example, in the A-to-B half- 372 connection, DCCP A is the HC-Sender and DCCP B is the HC- 373 Receiver. 375 3.2. Congestion Control 377 Each half-connection is managed by a congestion control mechanism. 378 The endpoints negotiate these mechanisms at connection setup; the 379 mechanisms for the two half-connections need not be the same. 381 Conformant congestion control mechanisms correspond to single-byte 382 congestion control identifiers, or CCIDs. The CCID for a half- 383 connection describes how the HC-Sender limits data packet rates; how 384 it maintains necessary parameters, such as congestion windows; how 385 the HC-Receiver sends congestion feedback via acknowledgements; and 386 how it manages the acknowledgement rate. Section 7 introduces the 387 currently allocated CCIDs, which are defined in separate profile 388 documents. 390 3.3. Connection Initiation and Termination 392 Every DCCP connection is actively initiated by one DCCP, which 393 connects to a DCCP socket in the passive listening state. We refer 394 to the active endpoint as "the client" and the passive endpoint as 395 "the server". Most of the DCCP specification is indifferent to 396 whether a DCCP is client or server. However, only the server may 397 generate a DCCP-CloseReq packet. (A DCCP-CloseReq packet forces the 398 receiving DCCP to close the connection and maintain connection state 399 for a reasonable time, allowing old packets to clear the network.) 400 This means that the client cannot force the server to maintain 401 connection state after the connection is closed. 403 DCCP does not support TCP-style simultaneous open. In particular, a 404 host MUST NOT respond to a DCCP-Request packet with a DCCP-Response 405 packet unless the destination port specified in the DCCP-Request 406 corresponds to a local socket opened for listening. This preserves 407 the invariant that every connection has one client and one server. 409 DCCP shuts down both half-connections as a unit; it has no states 410 analogous to TCP's FINWAIT and CLOSEWAIT states, where one TCP 411 "half-connection" is closed and the other remains open. However, 412 DCCP implementations SHOULD allow applications to declare that they 413 are no longer interested in receiving data. This would allow DCCP 414 implementations to streamline state for certain half-connections. 415 See Section 8.7, on the Data Dropped option---and particularly its 416 Drop State 4---for more information. 418 3.4. Features 420 DCCP uses a generic mechanism to negotiate connection properties, 421 such as the CCIDs active on the two half-connections. These 422 properties are called features. (We reserve the term "option" for a 423 collection of bytes in some DCCP header.) Each feature type, such as 424 "CCID", corresponds to two independent features, one per half- 425 connection. For instance, there are two CCIDs per connection. The 426 endpoint in charge of a particular feature is called its feature 427 location. 429 The Change, Prefer, and Confirm options negotiate feature values. 430 Change is sent to a feature location, asking it to change its value 431 for the feature. The feature location may respond with Prefer, which 432 asks the other endpoint to Change again with different values, or it 433 may change the feature value and acknowledge the request with 434 Confirm. Retransmissions make feature negotiation reliable. Section 435 6.3 describes these options further. 437 4. DCCP Packets 439 DCCP has nine different packet types: 441 o DCCP-Request 443 o DCCP-Response 445 o DCCP-Data 447 o DCCP-Ack 449 o DCCP-DataAck 451 o DCCP-CloseReq 453 o DCCP-Close 455 o DCCP-Reset 456 o DCCP-Move 458 Only the first eight types commonly occur. The DCCP-Move packet is 459 used to support multihoming and mobility. 461 The progress of a typical DCCP connection is as follows. (This 462 description is informative, not normative.) 464 (1) The client sends the server a DCCP-Request packet specifying the 465 client and server ports, the service being requested, and any 466 features being negotiated, including the CCID that the client 467 would like the server to use. The client may optionally 468 piggyback some data on the DCCP-Request packet---an application- 469 level request, say---which the server may ignore. 471 (2) The server sends the client a DCCP-Response packet indicating 472 that it is willing to communicate with the client. The response 473 indicates any features and options that the server agrees to, 474 begins or continues other feature negotiations if desired, and 475 optionally includes an Init Cookie that wraps up all this 476 information and which must be returned by the client for the 477 connection to complete. 479 (3) The client sends the server a DCCP-Ack packet that acknowledges 480 the DCCP-Response packet. This acknowledges the server's initial 481 sequence number and returns the Init Cookie if there was one in 482 the DCCP-Response. It may also continue feature negotiation. 484 (4) Next comes zero or more DCCP-Ack exchanges as required to 485 finalize feature negotiation. The client may piggyback an 486 application-level request on its final ack, producing a DCCP- 487 DataAck packet. 489 (5) The server and client then exchange DCCP-Data packets, DCCP-Ack 490 packets acknowledging that data, and, optionally, DCCP-DataAck 491 packets containing piggybacked data and acknowledgements. If the 492 client has no data to send, then the server will send DCCP-Data 493 and DCCP-DataAck packets, while the client will send DCCP-Acks 494 exclusively. 496 (6) The server sends a DCCP-CloseReq packet requesting a close. 498 (7) The client sends a DCCP-Close packet acknowledging the close. 500 (8) The server sends a DCCP-Reset packet whose Reason field is set 501 to "Closed", and clears its connection state. In DCCP, unlike 502 TCP, Resets are part of normal connection termination; see 503 Section 5.8. 505 (9) The client receives the DCCP-Reset packet and holds state for a 506 reasonable interval of time to allow any remaining packets to 507 clear the network. 509 An alternative connection closedown sequence is initiated by the 510 client: 512 (6) The client sends a DCCP-Close packet closing the connection. 514 (7) The server sends a DCCP-Reset packet with Reason field set to 515 "Closed" and clears its connection state. 517 (8) The client receives the DCCP-Reset packet and holds state for a 518 reasonable interval of time to allow any remaining packets to 519 clear the network. 521 This arrangement of setup and teardown handshakes permits the server 522 to decline to hold any state until the handshake with the client has 523 completed, and ensures that the client must hold the Time-Wait state 524 at connection closedown. 526 4.1. Examples of DCCP Congestion Control 528 Before giving the detailed specifications of DCCP, we present two 529 more detailed examples showing DCCP congestion control in operation. 530 Again, these examples are informative, not normative. 532 4.1.1. DCCP with TCP-like Congestion Control 534 The first example is of a connection where both half-connections use 535 TCP-like Congestion Control, specified by CCID 2 [CCID 2 PROFILE]. 536 In this example, the client sends an application-level request to 537 the server, and the server responds with a stream of data packets. 538 This example is of a connection using ECN. 540 (1) The client sends the DCCP-Request, which includes a Change 541 option asking the server to use CCID 2 for the server's data 542 packets, and a Prefer option informing the server that the 543 client would like to use CCID 2 for the its data packets. 545 (2) The server sends a DCCP-Response, including a Confirm option 546 indicating that the server agrees to use CCID 2 for its data 547 packets, and a Change option indicating that the server agrees 548 to the client's suggestion of CCID 2 for the client's data 549 packets. 551 (3) The client responds with a DCCP-DataAck acknowledging the 552 server's initial sequence number, and including a Confirm option 553 finalizing the negotiation of the client-to-server CCID, and an 554 application-level request for data. We will not discuss the 555 client-to-server half-connection further in this example. 557 (4) The server sends DCCP-Data packets, where the number of packets 558 sent is governed by a congestion window, as in TCP. The details 559 of the congestion window are defined in the profile for CCID 2, 560 which is a separate document [CCID 2 PROFILE]. The server also 561 sends Ack Ratio feature options specifying the number of server 562 data packets to be covered by an Ack packet from the client. 564 Each DCCP-Data packet is sent as ECN-Capable, with either the 565 ECT(0) or the ECT(1) codepoint set, as described in [ECN NONCE]. 567 (5) The client sends a DCCP-Ack packet acknowledging the data 568 packets for every Ack Ratio data packets transmitted by the 569 server. Each DCCP-Ack packet uses a sequence number and 570 contains an Ack Vector, as defined in Section 8 on 571 Acknowledgements. These packets also include Confirm options 572 answering any Ack Ratio requests from the server. 574 The DCCP-Acks are also sent as ECN-Capable, with either ECT(0) 575 or ECT(1). The client's Ack Vector echoes the accumulated ECN 576 Nonce for the server's packets. 578 (6) The server must occasionally acknowledge the client's 579 acknowledgements, so the client can clean its acknowledgement 580 state. It can do so by sending separate DCCP-Acks as allowed by 581 CCID 2, or by piggybacking acknowledgement information on its 582 data packets with the DCCP-DataAck packet type. The 583 acknowledgement information may contain detailed Ack Vectors, 584 like the client's acknowledgements; but if the client is sending 585 nothing but acknowledgements, the server's acks-of-acks can be 586 more lightweight. See Section 8.1 for more information. 588 Like the server's DCCP-Data packets, the server's DCCP-DataAck 589 and DCCP-Ack packets are sent as ECN-Capable. 591 (7) The server continues sending DCCP-Data packets as controlled by 592 the congestion window. Upon receiving DCCP-Ack packets, the 593 server examines the Ack Vector to learn about marked or dropped 594 data packets, and adjusts its congestion window accordingly, as 595 described in [CCID 2 PROFILE]. Because this is unreliable 596 transfer, the server does not retransmit dropped packets. 598 (8) Because DCCP-Ack packets use sequence numbers, the server has 599 direct information about the fraction of loss or marked DCCP-Ack 600 packets. [CCID 2 PROFILE] defines how the server modifies the 601 client's Ack Ratio in response to any congestion on the 602 acknowledgement stream. 604 (9) The server estimates round-trip times and calculates a TimeOut 605 (TO) value much as the RTO (Retransmit Timeout) is calculated in 606 TCP. Again, the specification for this is in [CCID 2 PROFILE]. 607 The TO is used to determine when a new DCCP-Data packet can be 608 transmitted when the server has been limited by the congestion 609 window and no feedback has been received from the client. 611 (10) 612 The DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets to close 613 the connection are as in the example above. 615 4.1.2. DCCP with TFRC Congestion Control 617 This example is of a connection where both half-connections use TFRC 618 Congestion Control, specified by CCID 3 [CCID 3 PROFILE]. 620 (1) The DCCP-Request and DCCP-Response packets specifying the use of 621 CCID 3 and the initial DCCP-DataAck packet are similar to those 622 in the CCID 2 example above. 624 (2) The server sends DCCP-Data packets, where the number of packets 625 sent is governed by an allowed transmit rate, as in TFRC. The 626 details of the allowed transmit rate are defined in the profile 627 for CCID 3, which is a separate document [CCID 3 PROFILE]. Each 628 DCCP-Data packet has a sequence number and a window counter 629 value. 631 Some of these data packets are DCCP-DataAck packets 632 acknowledging packets from the client, but for simplicity we 633 will not discuss the half-connection of data from the client to 634 the server in this example. 636 The use of ECN follows TCP-like Congestion Control, above, and 637 is described further in [CCID 3 PROFILE]. 639 (3) The receiver sends DCCP-Ack packets at least once per round-trip 640 time acknowledging the data packets, unless the server is 641 sending at a rate of less than one packet per RTT, as specified 642 by [CCID 3 PROFILE]. These acknowledgements may be piggybacked 643 on data packets, producing DCCP-DataAck packets. Each DCCP-Ack 644 packet uses a sequence number and identifies the most recent 645 packet received from the server. Each DCCP-Ack packet includes 646 feedback about the loss event rate calculated by the client, as 647 specified by [CCID 3 PROFILE]. 649 (4) The server continues sending DCCP-Data packets as controlled by 650 the allowed transmit rate. Upon receiving DCCP-Ack packets, the 651 server updates its allowed transmit rate as specified by [CCID 3 652 PROFILE]. 654 (5) The server estimates round-trip times and calculates a TimeOut 655 (TO) value much as the RTO (Retransmit Timeout) is calculated in 656 TCP. Again, the specification for this is in [CCID 3 PROFILE]. 658 (6) The DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets to close 659 the connection are as in the examples above. 661 5. Packet Formats 663 5.1. Generic Packet Header 665 All DCCP packets begin with a generic DCCP packet header: 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Source Port | Dest Port | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type | CCval | Sequence Number | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Data Offset | # NDP | Cslen | Checksum | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Source and Destination Ports: 16 bits each 678 These fields identify the connection, similar to the 679 corresponding fields in TCP and UDP. The Source Port represents 680 the relevant port on the endpoint that sent this packet, the 681 Destination Port the relevant port on the other endpoint. 683 Type: 4 bits 684 The type field specifies the type of the DCCP message. The 685 following values are defined: 687 0 DCCP-Request packet. 689 1 DCCP-Response packet. 691 2 DCCP-Data packet. 693 3 DCCP-Ack packet. 695 4 DCCP-DataAck packet. 697 5 DCCP-CloseReq packet. 699 6 DCCP-Close packet. 701 7 DCCP-Reset packet. 703 8 DCCP-Move packet. 705 CCval: 4 bits 706 This field is reserved for use by the sending CCID. In 707 particular, the A-to-B CCID's sender, which is active at DCCP A, 708 MAY send information to the receiver at DCCP B by encoding that 709 information in CCval. DCCP proper MUST ignore the field. If the 710 relevant CCID does not specify its value, it SHOULD be set to 711 zero. 713 Sequence Number: 24 bits 714 The sequence number field is initialized by a DCCP-Request or 715 DCCP-Response packet, and increases by one (modulo 16777216) 716 with every packet sent. The receiver uses this information to 717 determine whether packet losses have occurred. Even packets 718 containing no data update the sequence number. Sequence numbers 719 also provide some protection against old and malicious packets; 720 see Section 5.2 on sequence number validity. 722 Very-high-rate DCCPs may need protection against wrapped 723 sequence numbers. For example, a 10 Gb/s flow of 1500-byte DCCP 724 packets will send 2^24 packets in about 20 seconds. This is a 725 long time, in terms of likely round-trip times that could 726 possibly achieve such a sustained rate, but it is not without 727 risk. DCCP's current congestion control mechanisms are designed 728 for congestion windows (or equivalents) of at most a few hundred 729 thousand packets, leaving at least 32 RTTs before sequence 730 numbers wrap. We leave the design of protection against wrapped 731 sequence numbers for the future, when DCCP's congestion control 732 mechanisms can handle larger congestion windows. 734 The two subflows' initial sequence numbers are set by the first 735 DCCP-Request and DCCP-Response packets sent, and SHOULD be 736 chosen as for TCP. In particular, initial sequence number choice 737 MUST include a random or pseudorandom component to make it 738 harder for attackers to complete sequence number attacks [RFC 739 1948]. The initial sequence number chosen for a given connection 740 identifier (source address and port plus destination address and 741 port) SHOULD increase over time, as TCP suggests [RFC 793], to 742 prevent inappropriate delivery of old packets. 744 Data Offset: 8 bits 745 The offset from the start of the DCCP header to the beginning of 746 the packet's payload, measured in 32-bit words. 748 Number of Non-Data Packets (# NDP): 4 bits 749 DCCP sets this field to the number of non-data packets it has 750 sent so far on its sequence, modulo 16. A non-data packet is 751 simply any packet not containing user data; DCCP-Ack, DCCP- 752 Close, DCCP-CloseReq, and DCCP-Reset are always non-data 753 packets, while DCCP-Request, DCCP-Response, and DCCP-Move might 754 or might not be. When sending a non-data packet, DCCP increments 755 the # NDP counter before storing its value in the packet header. 757 This field can help the receiving DCCP decide whether a lost 758 packet contained any user data. (An application may want to know 759 when it has lost data. DCCP could report every packet loss as a 760 potential data loss, but that would cause false loss reports 761 when non-data packets were lost.) For example, say that packet 762 10 had # NDP set to 5; packet 11 was lost; and packet 12 had # 763 NDP set to 5. Then the receiving DCCP could deduce that packet 764 11 contained data, since # NDP did not change. Likewise, if # 765 NDP had gone up to 6 (and packet 12 contained user data), then 766 packet 11 must not have contained any data. 768 # NDP can overflow, causing ambiguities. For example, if 16 packets 769 are dropped in a row but # NDP does not change, the receiver will 770 not be able to tell whether or not any of the lost packets contained 771 data. DCCP proper does not depend on # NDP's value in any 772 significant way. 774 Checksum Length (Cslen): 4 bits 775 The checksum length field specifies what parts of the packet are 776 covered by the checksum field. The checksum always covers at 777 least the DCCP header, DCCP options, and a pseudoheader taken 778 from the network-layer header (described under Checksum below). 779 If the checksum length field is zero, that is all the checksum 780 covers. If the field is 15, the checksum covers the packet's 781 payload as well, possibly with 8 bits of zero padding on the 782 right to pad the payload to an even number of bytes. Values 783 between 1 and 14, inclusive, indicate that the checksum covers 784 the DCCP header, DCCP options, the pseudoheader, and that number 785 of initial 32-bit words of the packet's payload, padded on the 786 right with zeros as necessary. 788 Values other than 15 specify that corruption is acceptable in 789 some or all of the DCCP packet's payload. In fact, DCCP cannot 790 even detect corruption there, unless the Payload Checksum option 791 is used (Section 8.8). The meaning of values other than 0 and 15 792 should be considered experimental. 794 Section 18.1 further discusses the motivation of, and issues 795 related to, partial checksums. The checksum length field was 796 inspired by UDP-Lite [UDP-LITE]. 798 Checksum: 16 bits 799 DCCP uses the TCP/IP checksum algorithm. The checksum field 800 equals the 16 bit one's complement of the one's complement sum 801 of all 16 bit words in the DCCP header, DCCP options, a 802 pseudoheader taken from the network-layer header, and, depending 803 on the value of the checksum length field, some or all of the 804 payload. When calculating the checksum, the checksum field 805 itself is treated as 0. If a packet contains an odd number of 806 header and text bytes to be checksummed, 8 zero bits are added 807 on the right to form a 16 bit word for checksum purposes. The 808 pad byte is not transmitted as part of the packet. 810 The pseudoheader is calculated as for TCP. For IPv4, it is 96 811 bits long, and consists of the IPv4 source and destination 812 addresses, the IP protocol number for DCCP (padded on the left 813 with 8 zero bits), and the DCCP length as a 16-bit quantity (the 814 length of the DCCP header with options, plus the length of any 815 data); see Section 3.1 of [RFC 793]. For IPv6, it is 320 bits 816 long, and consists of the IPv6 source and destination addresses, 817 the DCCP length as a 32-bit quantity, and the IP protocol number 818 for DCCP (padded on the left with 24 zero bits); see Section 8.1 819 of [RFC 2460]. 821 Packets with invalid checksums MUST be ignored. In particular, 822 their options MUST NOT be processed. 824 5.2. Sequence Number Validity 826 DCCP endpoints SHOULD ignore packets with invalid sequence numbers, 827 which may arise if the network delivers a very old packet or an 828 attacker attempts to hijack a connection. TCP solves this problem 829 with its window. In DCCP, however, sequence numbers change with each 830 packet sent, even pure acknowledgements. Thus, a loss event that 831 dropped many consecutive packets could cause two DCCPs to get out of 832 sync relative to any window. 834 DCCP uses Loss Window and Identification mechanisms to determine 835 whether a given packet's sequence number is valid. Each HC-Sender 836 gives the corresponding HC-Receiver a loss window width W; see 837 Section 6.9. W defaults to 1000, but a proper value should reflect 838 how many packets the sender expects to be in flight. One good 839 guideline is to set it to about 3 or 4 times the maximum number of 840 packets the sender expects to send in a round-trip time. Only the 841 sender can anticipate this number. (Its value may not be available 842 at connection initiation, when the round-trip time is unknown, but 843 the sender can always send updates as the connection progresses.) 844 Too-small values increase the risk of the endpoints getting out sync 845 after bursts of loss; too-large values increase the risk of 846 connection hijacking. The Identification mechanism is used to get 847 back into sync when more than W consecutive packets are lost. 849 The HC-Receiver sets up a loss window of W consecutive sequence 850 numbers containing GSN, the Greatest Sequence Number it has received 851 on any valid packet from the sender. ("Consecutive" and "greatest" 852 are measured in circular sequence space.) One-third of the loss 853 window, rounded down, is placed at and before the GSN, with two- 854 thirds after the GSN. Sequence numbers outside this loss window are 855 invalid. Packets with invalid sequence numbers are themselves 856 invalid, unless both of the following conditions are true: 858 (1) No valid packet has been received recently (for instance, within 859 at least one round-trip time), AND 861 (2) The packet includes a correct Identification or Challenge option 862 (see Section 6.4.3), and a valid Acknowledgement Number (meaning 863 the Acknowledgement Number is within the corresponding Loss 864 Window). 866 The receiving DCCP SHOULD ignore invalid packets. In particular, it 867 SHOULD NOT pass any enclosed data to the application, update its 868 congestion control or feature state, or close the connection. 869 However, the receiving DCCP MAY send a DCCP-Ack packet to the 870 sender, as allowed by the congestion control mechanism in use. This 871 packet SHOULD acknowledge the last received valid sequence number 872 and contain a Challenge option (Section 6.4.4). The other DCCP will 873 send an Identification option to resync. 875 A DCCP endpoint MAY implement rate limits to reduce the likelihood 876 of denial-of-service attack. In particular, it MAY ignore all 877 packets with bad sequence numbers---even those containing 878 Identification or Challenge options---for some amount of time, on 879 the order of one round-trip time, after receiving a packet with an 880 invalid Identification or Challenge option; and it MAY rate-limit 881 the Challenge options it sends. 883 5.3. DCCP State Diagram 885 In this section we present a DCCP state diagram showing how a DCCP 886 connection should progress, and the proper responses for packets or 887 timeout events in various connection states. The state diagram is 888 illustrative; the text should be considered definitive. 890 +----------------------------------+ 891 | Figure omitted from text version | 892 +----------------------------------+ 894 All receive events on the diagram represent receipt of valid 895 packets. For example, receiving a Reset with a bad Acknowledgement 896 Number SHOULD NOT cause DCCP to transition to the Time-Wait state. 897 DCCP implementations MAY send Acks as described above, or "Invalid 898 Packet" Resets, in response to invalid packets; any such responses 899 SHOULD be rate-limited. 901 Otherwise-valid packets without explicit transitions in the state 902 diagram SHOULD be treated according to the table below. Particular 903 actions are "OK", meaning the packet MUST be processed according to 904 this document; "Rst", meaning the receiver SHOULD either ignore the 905 packet or respond with a (rate-limited) Reset; and "-", meaning the 906 packet SHOULD be ignored. Entries may take the form "Old/New", 907 where "Old" applies to old packets and "New" to new packets (whose 908 sequence numbers are greater than the largest sequence number seen 909 so far). 911 Data/Ack/ 912 DataAck/ 913 State Request Response Move CloseReq Close Reset 914 ------------- -------- -------- -------- -------- -------- -------- 915 CLOSED Rst Rst Rst Rst Rst OK 916 LISTEN OK Rst Rst(1) Rst Rst OK 917 REQUEST Rst OK Rst Rst Rst OK 918 RESPOND -/OK Rst Rst/OK Rst OK OK 919 OPEN (server) -/Rst Rst OK Rst OK OK 920 OPEN (client) Rst -/Rst OK OK OK OK 921 SERVER-CLOSE -/Rst Rst OK Rst OK OK 922 CLIENT-CLOSE Rst -/Rst OK OK OK OK 923 TIME-WAIT Rst Rst Rst Rst Rst OK 925 The table respecifies some transitions listed in the state 926 diagram---for instance, those for receiving packets in the TIME-WAIT 927 state. In these cases, prefer the action listed in the diagram. For 928 example, in the TIME-WAIT case, prefer sending rate-limited Resets 929 when valid packets are received; the table would allow ignoring 930 them. However, either action would be acceptable. 932 A DCCP endpoint that implements the Init Cookie option (Section 6.5) 933 may change the Reset action marked (1). Init Cookie lets the server 934 package all state for a requested connection into a DCCP option that 935 the client will echo. A server with Init Cookie need not implement 936 the RESPOND state. Instead, it may reply to each DCCP-Request 937 packet with a DCCP-Response containing an Init Cookie. When a DCCP- 938 Data, Ack, or DataAck packet carrying a valid Init Cookie arrives 939 from the client, the server will move directly from LISTEN to OPEN. 940 Like TCP SYN cookies [SYNCOOKIES], Init Cookies let servers avoid 941 keeping any state for clients whose addresses have not been 942 verified. 944 A DCCP endpoint in the CLOSED or LISTEN state may not have a proper 945 sequence number available to send a Reset. In these cases, it MUST 946 set Sequence Number to zero. 948 The Open state does not signify that a DCCP connection is ready for 949 data transfer. In particular, incomplete feature negotiations might 950 prevent data transfer. Feature negotiation takes place in parallel 951 with the state transitions on this diagram. 953 Only the server may take the transition from the OPEN state to the 954 SERVER-CLOSE state. (The server is the DCCP endpoint that began in 955 the LISTEN state.) Similarly, only the client must transition to 956 CLIENT-CLOSE after receiving a CloseReq packet. 958 5.4. DCCP-Request Packet Format 960 A DCCP connection is initiated by sending a DCCP-Request packet. The 961 format of a DCCP request packet is: 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 / Generic DCCP Header (12 bytes) / 967 / with Type=0 (DCCP-Request) / 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Service Name | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Options / [padding] | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | data | 974 | ... | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Service Name: 32 bits 978 The Service Name field describes the service to which the sender 979 is trying to connect. Service Names are 32-bit numbers allocated 980 by IANA; they are meant to correspond to application services 981 and protocols, such as FTP and HTTP, and are not intended to be 982 DCCP-specific. With Service Names, stateful middleboxes, such as 983 firewalls, can identify the application running on a nonstandard 984 port (assuming the DCCP header has not been encrypted). A 985 Service Name of zero is a wildcard, matching any service. The 986 host operating system MAY force every DCCP socket, both actively 987 and passively opened, to specify a nonzero Service Name. 988 Connection requests MUST fail if the Destination Port on the 989 receiver has a different Service Name from that given in the 990 packet, and both Service Names are nonzero. In this case, the 991 receiver will respond with a DCCP-Reset packet (with Reason set 992 to "Bad Service Name"). A server or stateful middlebox MAY also 993 send a "Bad Service Name" DCCP-Reset in response to packets with 994 Service Name value 0. 996 Options 997 DCCP-Request packets will usually include a "Change(Connection 998 Nonce)" option, to inform the server of the client's connection 999 nonce; see Section 6.4. 1001 The client MAY send new DCCP-Request packets if no response is 1002 received after some timeout. Each retransmission MUST increment the 1003 Sequence Number, and possibly # NDP, by one. The retransmission 1004 strategy SHOULD be similar to that for retransmitting TCP SYNs. 1006 A client MAY decide to give up after some number of DCCP-Requests. 1007 If so, it MAY send a DCCP-Reset packet to the server, to clean up 1008 state in case one or more of the Requests actually arrived. The 1009 DCCP-Reset SHOULD have Reason set to "Closed". 1011 5.5. DCCP-Response Packet Format 1013 In the second phase of the three-way handshake, the server sends a 1014 DCCP-Response message to the client. In this phase, a server will 1015 often specify the options it would like to use, either from among 1016 those the client requested, or in addition to those. Among these 1017 options is the congestion control mechanism the server expects to 1018 use. 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 / Generic DCCP Header (12 bytes) / 1024 / with Type=1 (DCCP-Response) / 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Reserved | Acknowledgement Number | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Options / [padding] | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | data | 1031 | ... | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Acknowledgement Number: 24 bits 1035 The Acknowledgement Number field, which appears in several 1036 packet types, acknowledges the greatest valid sequence number 1037 received so far on this connection. ("Greatest" is, of course, 1038 measured in circular sequence space.) In the case of a DCCP- 1039 Response packet, the acknowledgement number field will equal the 1040 sequence number from the DCCP-Request. Acknowledgement numbers 1041 make no attempt to provide precise information about which 1042 packets have arrived; options such as the Ack Vector do this. 1044 The Acknowledgement Number MUST correspond to a "received" 1045 packet, where a packet is classified as "received" if and only 1046 if its options were processed by the receiving DCCP. (This 1047 means, for example, that received packets' header checksums must 1048 have been valid.) Even "received" packets may have their 1049 payloads dropped, due to receive buffer overflow or payload 1050 corruption, for instance. The receiver will send Data Dropped 1051 options when this happens (see Section 8.7); the sender will 1052 reduce its sending rate or congestion window as appropriate. 1053 This issue is discussed further in Sections 8.5 and 8.7. 1055 Reserved: 8 bits 1056 The version of DCCP specified here SHOULD set this field to all 1057 zeroes on generated packets, and ignore its value on received 1058 packets. 1060 Options 1061 The Data Dropped and Init Cookie options are particularly useful 1062 for DCCP-Response packets (Sections 8.7 and 6.5). In addition, 1063 DCCP-Response, or early DCCP-Data or DCCP-Ack packets, may 1064 include "Confirm(Connection Nonce)" and "Change(Connection 1065 Nonce)" options, to negotiate connection nonces (Section 6.4), 1066 as well as options to negotiate CCIDs and other relevant 1067 features. 1069 The receiver MAY respond to a DCCP-Request packet with a DCCP-Reset 1070 packet to refuse the connection. Relevant Reset Reasons for refusing 1071 a connection include "Connection Refused", when the DCCP-Request's 1072 Destination Port did not correspond to a DCCP port open for 1073 listening; "Bad Service Name", when the DCCP-Request's Service Name 1074 did not correspond to the service name registered with the 1075 Destination Port; and "Too Busy", when the server is currently too 1076 busy to respond to requests. The server SHOULD limit the rate at 1077 which it generates these resets. 1079 The receiver SHOULD NOT retransmit DCCP-Response packets; the sender 1080 will retransmit the DCCP-Request if necessary. (Note that the 1081 "retransmitted" DCCP-Request will have, at least, a different 1082 sequence number from the "original" DCCP-Request; the receiver can 1083 thus distinguish true retransmissions from network duplicates.) The 1084 responder will detect that the retransmitted DCCP-Request applies to 1085 an existing connection because of its Source and Destination Ports. 1086 Every valid DCCP-Request received MUST elicit a new DCCP-Response, 1087 unless the responder can guarantee that the requestor has received 1088 at least one Response already. (For instance, if the responder has 1089 received a valid DCCP-Data or DCCP-Ack packet from the requestor, 1090 then it knows the newly received Request is old, and SHOULD be 1091 ignored.) Each new DCCP-Response MUST increment the responder's 1092 Sequence Number, and possibly # NDP, by one. 1094 The responder SHOULD NOT accept any data accompanying a 1095 retransmitted DCCP-Request. In particular, the DCCP-Response sent in 1096 reply to a retransmitted DCCP-Request with data SHOULD contain a 1097 Data Dropped option, in which the retransmitted DCCP-Request is 1098 reported as "data dropped due to protocol constraints" (Drop State 1099 0). The original DCCP-Request SHOULD also be reported in the Data 1100 Dropped option, either in a Normal Block (if the responder accepted 1101 the data, or there was no data), or in a Drop State 0 Drop Block (if 1102 the responder refused the data the first time as well). 1104 5.6. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packet Formats 1106 The payload of a DCCP connection is sent in DCCP-Data and DCCP- 1107 DataAck packets, while DCCP-Ack packets are used for 1108 acknowledgements when there is no payload to be sent. DCCP-Data 1109 packets look like this: 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 / Generic DCCP Header (12 bytes) / 1115 / with Type=2 (DCCP-Data) / 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Options / [padding] | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | data | 1120 | ... | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 DCCP-Ack packets dispense with the data, but contain an 1124 acknowledgement number: 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 / Generic DCCP Header (12 bytes) / 1130 / with Type=3 (DCCP-Ack) / 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Reserved | Acknowledgement Number | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Options / [padding] | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 DCCP-DataAck packets contain both data and an acknowledgement 1138 number: acknowledgement information is piggybacked on a data packet. 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 / Generic DCCP Header (12 bytes) / 1144 / with Type=4 (DCCP-DataAck) / 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Reserved | Acknowledgement Number | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Options / [padding] | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | data | 1151 | ... | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 DCCP-Ack and DCCP-DataAck packets often include additional 1155 acknowledgement options, such as Ack Vector, as required by the 1156 congestion control mechanism in use. 1158 DCCP A sends DCCP-Data and DCCP-DataAck packets to DCCP B due to 1159 application events on host A. These packets are congestion- 1160 controlled by the CCID for the A-to-B half-connection. In contrast, 1161 DCCP-Ack packets sent by DCCP A are controlled by the CCID for the 1162 B-to-A half-connection. Generally, DCCP A will piggyback 1163 acknowledgement information on data packets when acceptable, 1164 creating DCCP-DataAck packets. DCCP-Ack packets are used when there 1165 is no data to send from DCCP A to DCCP B, or when the link from A to 1166 B is so congested that sending data would be inappropriate. 1168 Section 8, below, describes acknowledgements in DCCP. 1170 A DCCP-Data or DCCP-DataAck packet may contain no data bytes if the 1171 application sends a zero-length datagram. 1173 5.7. DCCP-CloseReq and DCCP-Close Packet Format 1175 The DCCP-CloseReq and DCCP-Close packets have the same format. 1176 However, only the server can send a DCCP-CloseReq packet. Either 1177 client or server may send a DCCP-Close packet. The receiver of a 1178 valid DCCP-Close packet SHOULD respond with a DCCP-Reset packet, 1179 with Reason set to "Closed"; the endpoint that originally sent the 1180 DCCP-Close will hold Time-Wait state. The receiver of a valid DCCP- 1181 CloseReq packet SHOULD respond with a DCCP-Close packet; that 1182 receiving endpoint will expect to hold Time-Wait state after later 1183 receiving a DCCP-Reset. See the state diagram in 5.3 for more 1184 information. 1186 0 1 2 3 1187 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 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 / Generic DCCP Header (12 bytes) / 1190 / with Type=5 or 6 (DCCP-Close or CloseReq) / 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Reserved | Acknowledgement Number | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Options / [padding] | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 5.8. DCCP-Reset Packet Format 1199 DCCP-Reset packets unconditionally shut down a connection. Every 1200 normal connection ends with a DCCP-Reset, but resets may be sent for 1201 other reasons, including bad port numbers, bad option behavior, 1202 incorrect ECN Nonce Echoes, and so forth. The reason for a reset is 1203 represented by an eight-bit number, the Reason field, and 24 bits of 1204 additional data. The endpoint that receives a valid DCCP-Reset 1205 packet will hold Time-Wait state for the connection. 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 / Generic DCCP Header (12 bytes) / 1211 / with Type=7 (DCCP-Reset) / 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Reserved | Acknowledgement Number | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Reason | Data 1 | Data 2 | Data 3 | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Options / [padding] | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Reason: 8 bits 1221 The Reason field represents the reason that the sender reset the 1222 DCCP connection. 1224 Data 1, Data 2, and Data 3: 8 bits each 1225 The Data fields provide additional information about why the 1226 sender reset the DCCP connection. The meanings of these fields 1227 depend on the value of Reason. 1229 The following Reasons are currently defined. The "Data" columns 1230 describe what the Data fields should contain for a given Reason. In 1231 those columns, N/A means the Data field SHOULD be set to 0 by the 1232 sender of the DCCP-Reset, and ignored by its receiver. 1234 Section 1235 Reason Name Data 1 Data 2 Data 3 Reference 1236 ------ ---- ------ ------ ------ --------- 1237 0 Unspecified N/A N/A N/A 1238 1 Closed N/A N/A N/A 4 1239 2 Invalid Packet packet N/A N/A 5.3 1240 type 1241 3 Option Error option option data 1242 number (if any) 1243 4 Feature Error feature feature data 1244 number (if any) 1245 5 Connection Refused N/A N/A N/A 5.5 1246 6 Bad Service Name N/A N/A N/A 5.4 1247 7 Too Busy N/A N/A N/A 5.5 1248 8 Bad Init Cookie N/A N/A N/A 6.5 1249 10 Unanswered Challenge N/A N/A N/A 6.4.4 1250 11 Fruitless Negotiation feature feature data 6.3.7 1251 number (optional) 1252 12 Aggression Penalty N/A N/A N/A 9.2 1254 A DCCP-Reset packet finishes off every terminated DCCP connection, 1255 whether clean (due to application close and usual connection 1256 termination; Reset Reason "Closed") or unclean. This differs from 1257 TCP, which has two distinct termination mechanisms, FIN and RST. 1258 Some responses to connection close must be the same, whether or not 1259 the connection terminated cleanly: for instance, the endpoint that 1260 receives a valid DCCP-Reset should hold Time-Wait state for the 1261 connection. Processors that must distinguish between clean and 1262 unclean termination can examine the Reset Reason. 1264 5.9. DCCP-Move Packet Format 1266 The DCCP-Move packet type is part of DCCP's support for multihoming 1267 and mobility, which is described further in Section 10. DCCP A sends 1268 a DCCP-Move packet to DCCP B after changing its address and/or port 1269 number. The DCCP-Move packet requests that DCCP B start sending 1270 packets to the new address and port number. The old address and port 1271 are stored explicitly in the DCCP-Move header; the new address and 1272 port come from the packet's network header and generic DCCP header. 1273 The old address's type is indicated explicitly by an Old Address 1274 Family field. The Sequence Number and Acknowledgement Number fields 1275 and a mandatory Identification option provide some protection 1276 against hijacked connections. See Section 10 for more on security 1277 and DCCP's mobility support. 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 / Generic DCCP Header (12 bytes) / 1283 / with Type=8 (DCCP-Move) / 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Reserved | Acknowledgement Number | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Old Address Family | Old Port | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 / Old Address / 1290 / / [padding] / 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Options, including Identification / [padding] | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | data | 1295 | ... | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Old Address Family: 16 bits 1299 The Old Address Family field indicates the address family 1300 formerly used for this connection, and takes values from the 1301 Address Family Numbers registry administered by IANA. Particular 1302 values include 1 for IPv4 and 2 for IPv6. An endpoint MUST 1303 discard DCCP-Move packets with unrecognized Old Address Family 1304 values. 1306 Old Port: 16 bits 1307 The former port number used by DCCP A's endpoint. 1309 Old Address: at least 32 bits 1310 The former address used by DCCP A's endpoint, padded on the 1311 right to a multiple of 32 bits. The form and size of the address 1312 are determined by the Old Address Family field. For instance, if 1313 Old Address Family is 1, then Old Address contains an IPv4 1314 address and takes 32 bits; if it is 2, then Old Address contains 1315 an IPv6 address and takes 128 bits. 1317 Options 1318 Every DCCP-Move packet MUST include a valid Identification 1319 option (see Section 6.4). 1321 DCCP B SHOULD ignore the DCCP-Move if any of the following 1322 conditions holds: 1324 (1) Neither the Old Address/Old Port combination nor the network 1325 address/Source Port combination refers to a currently active 1326 DCCP connection. 1328 (2) The Identification option is not present or invalid. 1330 (3) DCCP B does not support mobility, or its Mobility Capable 1331 feature is off. 1333 DCCP B SHOULD NOT respond to such invalid Moves with DCCP-Reset 1334 packets, since any such resets would leak information about the 1335 connection, such as the current sequence number, to a possibly 1336 malicious host. After receiving such an invalid DCCP-Move, DCCP B 1337 MAY ignore subsequent DCCP-Move packets, valid or not, for a short 1338 period of time, such as one second or one round-trip time. This 1339 protects DCCP B against denial-of-service attacks from floods of 1340 invalid DCCP-Moves. 1342 DCCP B SHOULD acknowledge valid DCCP-Move packets with DCCP-Ack or 1343 DCCP-DataAck packets. If DCCP B accepts the move, it MUST send this 1344 acknowledgement to the packet's network source address and DCCP 1345 Source Port; if it rejects the move, which it MAY do for any reason, 1346 it MUST send this acknowledgement to the Old Address and Old Port. 1347 The moving endpoint, DCCP A, can determine whether or not its move 1348 was accepted by checking the acknowledgement's destination address 1349 and Port. 1351 If the acknowledgement is lost, DCCP A might resend the DCCP-Move 1352 packet (using a new sequence number). DCCP B will detect this case 1353 because the network source address and Source Port correspond to a 1354 valid connection, for which the Sequence Number and Acknowledgement 1355 Number fields are valid; the Identification option is valid for that 1356 connection; and the Old Address and Old Port no longer refer to a 1357 valid DCCP connection. It SHOULD respond by sending another 1358 acknowledgement, as allowed by the congestion control mechanism in 1359 use. 1361 We note that DCCP mobility, as provided by DCCP-Move, may not be 1362 useful in the context of IPv6, with its mandatory support for Mobile 1363 IP. 1365 6. Options and Features 1367 All DCCP packets may contain options, which occupy space at the end 1368 of the DCCP header and are a multiple of 8 bits in length. All 1369 options are always included in the checksum. An option may begin on 1370 any byte boundary. 1372 The first byte of an option is the option type. Options with types 0 1373 through 31 are single-byte options. Other options are followed by a 1374 byte indicating the option's length. This length value includes the 1375 two bytes of option-type and option-length as well as any option- 1376 data bytes, and MUST therefore be greater than or equal to two. 1378 The following options are currently defined: 1380 Option Section 1381 Type Length Meaning Reference 1382 ---- ------ ------- --------- 1383 0 1 Padding 6.1 1384 2 1 Slow Receiver 8.6 1385 32 variable Ignored 6.2 1386 33 variable Change 6.3 1387 34 variable Prefer 6.3 1388 35 variable Confirm 6.3 1389 36 variable Init Cookie 6.5 1390 37 variable Ack Vector [Nonce 0] 8.5 1391 38 variable Ack Vector [Nonce 1] 8.5 1392 39 variable Data Dropped 8.7 1393 40 6 Timestamp 6.6 1394 41 6-10 Timestamp Echo 6.8 1395 42 variable Identification 6.4.3 1396 44 variable Challenge 6.4.4 1397 45 4 Payload Checksum 8.8 1398 46 4-6 Elapsed Time 6.7 1399 128-255 variable CCID-specific options 7.4 1401 6.1. Padding Option 1403 The padding option, with type 0, is a single byte option used to pad 1404 between or after options. It either ensures the payload begins on a 1405 32-bit boundary (as required), or ensures alignment of following 1406 options (not mandatory). 1408 +--------+ 1409 |00000000| 1410 +--------+ 1411 Type=0 1413 6.2. Ignored Option 1415 The Ignored option, with type 32, signals that a DCCP did not 1416 understand some option. This can happen, for example, when a 1417 conventional DCCP converses with an extended DCCP. Each Ignored 1418 option has one or more bytes of data. The first byte contains the 1419 offending option type; the second and subsequent, if present, 1420 contains the first byte of the offending option's data. If the 1421 offending option had no data, the Ignored option MAY still supply 1422 two bytes of data, with the second byte set to 0. If the offending 1423 option had data, the Ignored option MUST include at least one byte 1424 of that data. 1426 Ignored options SHOULD be sent only on packets that contain 1427 Acknowledgement Numbers (that is, DCCP-Reponse, DCCP-Ack, DCCP- 1428 DataAck, DCCP-Close, DCCP-CloseReq, DCCP-Reset, and DCCP-Move), and 1429 SHOULD concern options sent on the packet acknowledged by the 1430 Acknowledgement Number. 1432 +--------+--------+--------+ 1433 |00100000|00000011|Opt Type| 1434 +--------+--------+--------+ 1435 Type=32 Length=3 1437 +--------+--------+--------+--------+--------+ 1438 |00100000| Length |Opt Type| Opt Data ... 1439 +--------+--------+--------+--------+--------+ 1440 Type=32 1442 6.3. Feature Negotiation 1444 DCCP contains a mechanism for reliably negotiating features, notably 1445 the congestion control mechanism in use on each half-connection. The 1446 motivation is to implement reliable feature negotiation once, so 1447 that different options need not reinvent that wheel. 1449 Three options, Change, Prefer, and Confirm, implement feature 1450 negotiation. Change is sent to a feature's location, asking it to 1451 change the feature's value. The feature location may respond with 1452 Prefer, which asks the other endpoint to Change again with different 1453 values, or it may change the feature value and acknowledge the 1454 request with Confirm. 1456 Feature values MUST NOT change apart from feature negotiation, and 1457 enforced retransmissions make feature negotiation reliable. This 1458 ensures that both endpoints eventually agree on every feature's 1459 value. 1461 Some features are non-negotiable, meaning that the feature location 1462 MUST set its value to whatever the other endpoint requests. For non- 1463 negotiable features, the feature location MUST respond to Change 1464 options with Confirm; Prefer is not useful. These features use the 1465 feature framework simply to achieve reliability. 1467 Negotiations for multiple features may take place simultaneously. 1468 For instance, a packet may contain multiple Change options that 1469 refer to different features. 1471 Feature negotiation generally takes place using packet types that 1472 carry no user data, such as DCCP-Ack, particularly when the relevant 1473 feature may affect how data will be treated. 1475 6.3.1. Feature Numbers 1477 The first data byte of every Change, Prefer, or Confirm option is a 1478 feature number, defining the type of feature being negotiated. The 1479 remainder of the data gives one or more values for the feature, and 1480 is interpreted according to the feature. The current set of feature 1481 numbers is as follows: 1483 Section 1484 Number Meaning Neg.? Reference 1485 ------ ------- ----- --------- 1486 1 Congestion Control (CC) Y 7 1487 2 ECN Capable Y 9.1 1488 3 Ack Ratio N 8.3 1489 4 Use Ack Vector Y 8.4 1490 5 Mobility Capable Y 10.1 1491 6 Loss Window N 6.9 1492 7 Connection Nonce N 6.4.2 1493 8 Identification Regime Y 6.4.1 1494 128-255 CCID-Specific Features ? 7.4 1496 The "Neg[otiable]?" column is "Y" for normal features and "N" for 1497 non-negotiable features. 1499 6.3.2. Change Option 1501 DCCP A sends a Change option to DCCP B to ask it to change the value 1502 of some feature located at DCCP B. DCCP B SHOULD respond to a Change 1503 option for a known feature with either Prefer or Confirm. In 1504 special circumstances, such as a Change option whose value is 1505 inappropriate for the listed feature number or a negotiation that 1506 seems to be going on forever, DCCP B MAY respond instead by ignoring 1507 the Change (with or without sending an Ignored option), or by 1508 resetting the connection with Reason set to "Fruitless Negotiation" 1509 or "Feature Error". DCCP A SHOULD retransmit the Change option 1510 until it receives some relevant response---by sending at least one 1511 option per round-trip time, for instance, or by adding the Change 1512 option to every Kth packet. DCCP A will generate a Change option in 1513 response to a valid Prefer option; it may also generate a Change 1514 option due to some application event. 1516 +--------+--------+--------+--------+--------+-------- 1517 |00100001| Length |Feature#| Value or Values ... 1518 +--------+--------+--------+--------+--------+-------- 1519 Type=33 1521 6.3.3. Prefer Option 1523 DCCP A sends a Prefer option to DCCP B to ask it to choose another 1524 value for some feature located at DCCP B. DCCP B SHOULD respond to a 1525 valid Prefer option with a Change; other possible responses include 1526 ignoring the option, sending an Ignored option, or resetting the 1527 connection, as described above. DCCP A SHOULD retransmit the Prefer 1528 option until it receives some relevant response, using the same 1529 guidelines as Change. DCCP A may generate a Prefer option in 1530 response to some Change option, or in response to some application 1531 event. Prefer options are not useful for non-negotiable features. 1533 +--------+--------+--------+--------+--------+-------- 1534 |00100010| Length |Feature#| Value or Values ... 1535 +--------+--------+--------+--------+--------+-------- 1536 Type=34 1538 6.3.4. Confirm Option 1540 DCCP A sends a Confirm option to DCCP B to inform it that a Change 1541 option for some feature located at DCCP A has been accepted. 1542 Generally the Confirm option will include the feature's accepted 1543 value. For some special features, such as Connection Nonce, a 1544 Confirm option contains no data; these features are identified 1545 explicitly. DCCP A MUST generate Confirm options only in response 1546 to valid Change options. DCCP A SHOULD NOT retransmit Confirm 1547 options: DCCP B will retransmit the relevant Changes as necessary. 1548 The receipt of a valid Confirm option ends the negotiation over a 1549 feature's value. 1551 +--------+--------+--------+--------+--------+-------- 1552 |00100011| Length |Feature#| Value ... 1553 +--------+--------+--------+--------+--------+-------- 1554 Type=35 1556 6.3.5. Example Negotiations 1558 This section demonstrates several negotiations of the congestion 1559 control feature for the A-to-B half-connection. (This feature is 1560 located at DCCP A.) In this sequence of packets, DCCP A is happy 1561 with DCCP B's suggestion of CC mechanism 2: 1563 B > A Change(CC, 2) 1564 A > B Confirm(CC, 2) 1566 Here, A and B jointly settle on CC mechanism 5: 1568 B > A Change(CC, 3, 4) 1569 A > B Prefer(CC, 1, 2, 5) 1570 B > A Change(CC, 5) 1571 A > B Confirm(CC, 5) 1573 In this sequence, A refuses to use CC mechanism 5. If this sequence 1574 continued, one or the other endpoint would eventually abort the 1575 connection via a DCCP-Reset packet with Reason set to "Fruitless 1576 Negotiation": 1578 B > A Change(CC, 3, 4, 5) 1579 A > B Prefer(CC, 1, 2) 1580 B > A Change(CC, 5) 1581 A > B Prefer(CC, 1, 2) 1583 Here, A elicits agreement from B that it is satisfied with 1584 congestion control mechanism 2: 1586 A > B Prefer(CC, 1, 2) 1587 B > A Change(CC, 2) 1588 A > B Confirm(CC, 2) 1590 6.3.6. Unknown Features 1592 If a DCCP receives a Change or Prefer option referring to a feature 1593 number it does not understand, it MUST respond with an Ignored 1594 option. This informs the remote DCCP that the local DCCP does not 1595 implement the feature. No other action need be taken. (Ignored may 1596 also indicate that the DCCP endpoint could not respond to a CCID- 1597 specific feature request because the CCID was in flux; see Section 1598 7.4.) 1600 6.3.7. State Diagram 1602 These state diagrams present the legal transitions in a DCCP feature 1603 negotiation. They define DCCP's states and transitions with respect 1604 to the negotiation of a single feature it understands. There are two 1605 diagrams, corresponding to the two endpoints: the feature location 1606 DCCP A, and what we call the "feature requester", DCCP B. 1608 Transitions between states are triggered by receiving a packet 1609 ("RECV") or by an application event ("APP"). Received packets are 1610 further distinguished by any options relevant to the feature being 1611 negotiated. "RECV -" means the packet contained no relevant option. 1612 "RECV Chg" denotes a Change option, "RECV Pr" a Prefer option, and 1613 "RECV Cfm" a Confirm option. The data contained in an option is 1614 given in parentheses when necessary. The "SEND" action indicates 1615 which option the DCCP will send next. Finally, the "SET-VALUE" 1616 action causes the DCCP to change its value for the relevant feature. 1618 "SEND" does not force DCCP to immediately generate a packet; rather, 1619 it says which feature option SHOULD be sent on the next packet 1620 generated. A DCCP MAY choose to generate a packet, such as a DCCP- 1621 Ack, in response to some "SEND" action, rather than piggyback on 1622 another packet. (In some cases, this may be required---if adding an 1623 option would bump a packet over the PMTU, for instance.) However, 1624 it MUST NOT generate a packet if doing so would violate the 1625 congestion control mechanism in use. 1627 The requester, DCCP B, has four states: Known, Unknown, Failed, and 1628 Changing. Similarly, the feature location, DCCP A, has four states: 1629 Known, Unknown, Failed, and Confirming. In both cases, Known denotes 1630 a state where the DCCP knows the feature's current value, and 1631 believes that the other DCCP agrees. Changing and Confirming denote 1632 states where the DCCPs are in the process of negotiating a new value 1633 for the feature. The Unknown state can occur only at connection 1634 setup time. It denotes a state where the DCCP does not know any 1635 value for the feature, and has not yet entered a negotiation to 1636 determine its value. Finally, the Failed state represents a state 1637 where the other DCCP does not implement the feature under 1638 negotiation. 1640 Retransmissions of Change and Prefer options happen on the "RECV -" 1641 arcs from the Changing and Confirming states. 1643 A DCCP may start in either the Unknown or Known state, depending on 1644 the feature in question. In particular, some features have a well- 1645 known value for new connections, in which case the DCCPs begin the 1646 connection in the Known states. 1648 REQUESTER STATE DIAGRAM (DCCP B) 1650 +-----------+ 1651 | Unknown | 1652 +-----------+ 1653 +----------+ | +-----------+ 1654 | |RECV - |RECV -/Pr | APP | |RECV Pr/Cfm 1655 V |SEND - |SEND Chg V |SEND Chg 1656 +-----------+ | | +------------+ | 1657 | |----+ +------------>| |-----+ 1658 | Known |------------------------------>| Changing | 1659 | | RECV Pr | APP | |-----+ 1660 +-----------+ SEND Chg +------------+ |RECV - 1661 ^ | | ^ |SEND -/Chg 1662 | | | | | 1663 +------------------------------------------+ | +---------+ 1664 RECV Cfm(O) | +----------+ 1665 SEND - +--------->| Failed | 1666 SET-VALUE O RECV Ign +----------+ 1667 SEND - 1669 FEATURE LOCATION STATE DIAGRAM (DCCP A) 1670 (O represents any feature value acceptable to DCCP A; X is not acceptable.) 1672 RECV Chg(O) 1673 SEND Cfm(O) RECV - | APP 1674 SET-VALUE O +-----------+ SEND Pr(O) 1675 +--------------------| Unknown |------------+ 1676 | +-----------+ | 1677 | +-------+ | | +-----------+ 1678 | | |RECV - |RECV Chg(X) | | |RECV Chg(X) 1679 V V |SEND - |SEND Pr(O) V V |SEND Pr(O) 1680 +-----------+ | | +------------+ | (need not be 1681 | |----+ +------------>| |-----+ the same O) 1682 | Known |------------------------------>| Confirming | 1683 | |----+ RECV Chg | APP | |-----+ 1684 +-----------+ | SEND Pr(O) +------------+ |RECV - 1685 ^ ^ | | | ^ |SEND -/Pr(O) 1686 | | |RECV Chg(O) | | | | 1687 | | |SEND Cfm(O) | | +---------+ 1688 | | |SET-VALUE O | | 1689 | +-------+ | | +----------+ 1690 +---------------------------------------------+ +-------->| Failed | 1691 RECV Chg(O) RECV Ign +----------+ 1692 SEND Cfm(O) SEND - 1693 SET-VALUE O 1695 This specification allows several choices of action in certain 1696 states. The implementation will generally use feature-specific 1697 information to decide how to respond. For example, DCCP A in the 1698 Known state may respond to a Change option with either Confirm or 1699 Prefer. If DCCP A is willing to set the feature to the value 1700 specified by Change, it will generally send Confirm; but if it would 1701 like to negotiate further, it will send Prefer. 1703 DCCP B retransmits Change options, and DCCP A retransmits Prefer 1704 options, until receiving a relevant response. However, they need not 1705 retransmit the option on every packet, as shown by the "RECV - / 1706 SEND -" transitions in the Changing and Confirming states. 1708 These state diagrams guarantee safety, but not liveness. Namely, no 1709 unexpected or erroneous options will be sent, but option negotiation 1710 might not terminate. For example, the following infinite negotiation 1711 is legal according to this specification. 1713 A > B Prefer(1) 1714 B > A Change(2) 1715 A > B Prefer(1) 1716 B > A Change(2)... 1718 Implementations MAY choose to enforce a maximum length on any 1719 negotiation---for example, by resetting the connection when any 1720 negotiation lasts more than some maximum time. The DCCP-Reset Reason 1721 "Fruitless Negotiation" SHOULD be used to signal that a connection 1722 was aborted because of a negotiation that took too long. 1724 In the Changing and Confirming states, the value of the 1725 corresponding feature is in flux. DCCP MAY change its behavior in 1726 these states---for example, by refusing to send data until 1727 reentering a Known state. 1729 6.4. Identification Options 1731 The Identification options provide a way for DCCP endpoints to 1732 confirm each others' identities, even after changes of address 1733 (Section 10) or long bursts of loss that get the endpoints out of 1734 sync (Section 5.2). Again, DCCP as specified here does not provide 1735 cryptographic security guarantees, and attackers that can see every 1736 packet are still capable of manipulating DCCP connections 1737 inappropriately, but the Identification options make it more 1738 difficult for some kinds of attacks to succeed. 1740 The Identification option is used to prove an endpoint's identity, 1741 while a Challenge option elicits an Identification from the other 1742 endpoint. An Identification Regime determines how the 1743 Identifications are calculated. In the default MD5 Regime, the 1744 calculation involves an MD5 hash over packet data and two Connection 1745 Nonces, either exchanged at the beginning of the connection or 1746 implicitly agreed upon. 1748 6.4.1. Identification Regime Feature 1750 Identification Regime has feature number 8. The ID Regime feature 1751 located at DCCP B specifies the algorithm that DCCP A will use for 1752 its Identification options. Each endpoint must keep track of both 1753 its ID regime and, via the ID Regime feature, the regime used by the 1754 other endpoint. 1756 The value of ID Regime is a two-byte number, so a valid Confirm(ID 1757 Regime) option takes exactly four bytes. Change or Prefer options 1758 MAY list multiple ID Regimes in descending order of preference. ID 1759 Regime defaults to 0, the MD5 Regime. Applications preferring 1760 different security guarantees, particularly around mobility issues, 1761 may prefer to implement another identification algorithm and assign 1762 it a different ID Regime value. 1764 The ID Regime feature is negotiable, so an endpoint can request that 1765 the other endpoint use a particular ID Regime, or one of a set of 1766 Regimes, by sending a Prefer option. If the endpoints cannot agree 1767 on mutually acceptable ID Regimes, the connection SHOULD be reset 1768 due to "Fruitless Negotiation". 1770 6.4.2. Connection Nonce Feature 1772 Connection Nonce has feature number 7. The Connection Nonce feature 1773 located at DCCP B is the value of DCCP A's connection nonce. Each 1774 endpoint SHOULD keep track of both its nonce and the other 1775 endpoint's nonce. Connection Nonces are used by Identification 1776 Regime 0. 1778 The Connection Nonce feature takes arbitrary values of at least 4 1779 bytes long. A Change(Connection Nonce) option therefore takes at 1780 least 6 bytes. Confirm(Connection Nonce) options MUST NOT contain 1781 the relevant value, so a Confirm(Connection Nonce) option takes 1782 exactly 2 bytes. 1784 Connection Nonce defaults to a random 8-byte string. To prevent 1785 spoofing, this string MUST NOT have any trivially predictable value. 1786 For example, it MUST NOT be set deterministically to zero, and it 1787 SHOULD change on every connection. DCCP endpoints MAY, however, 1788 exchange Connection Nonces via some mechanism other than the 1789 plaintext, snoopable Connection Nonce option. 1791 This feature is non-negotiable. 1793 6.4.3. Identification Option 1795 The Identification option serves as confirmation that a packet was 1796 sent by an endpoint involved in the initiation of the DCCP 1797 connection. It is permitted in any DCCP packet, but it might not be 1798 useful until the endpoints have exchanged security information such 1799 as connection nonces. The option takes the following form: 1801 +--------+--------+--------+--------+--------+-------- 1802 |00101010| Length | Identification Data ... 1803 +--------+--------+--------+--------+--------+-------- 1804 Type=42 1806 The particular data included in an Identification option sent by 1807 DCCP A depends on the ID Regime in force for the A-to-B sequence, 1808 which is the value of the ID Regime feature located at DCCP B. The 1809 remainder of this section describes ID Regime 0, the default MD5 1810 Regime. 1812 The Identification data provided for the MD5 Regime consists of a 1813 16-byte MD5 digest of: the second and fourth 32-bit words in the 1814 generic DCCP header, including the Sequence and Acknowledgement 1815 Numbers; the value of the sender's Connection Nonce; and the value 1816 of the other endpoint's Connection Nonce, in that order. The total 1817 length of the option is therefore 18 bytes, and the option may only 1818 be provided on packets that contain Acknowledgement Numbers, such as 1819 DCCP-Ack. Inclusion of the two Connection Nonces ensures that 1820 attackers cannot fake an Identification Option, unless they snooped 1821 on the beginning of the connection when nonces are exchanged. (No 1822 mechanism protects against snoopers who know Connection Nonces, 1823 since DCCP as specified here does not provide strong cryptographic 1824 security guarantees; see Section 16.) Inclusion of the Sequence and 1825 Acknowledgement Numbers protects against replay attacks within the 1826 connection. 1828 To check an Identification option's value, the receiver simply 1829 calculates the MD5 digest itself and compares that against the 1830 option data. The MD5 calculation can be expensive, so an attacker 1831 could conceivably disable a DCCP endpoint by sending it a flood of 1832 invalid packets with bad Identification options. Rate limits 1833 described in Sections 5.2 and 10 mitigate this issue. The receiver 1834 MAY ignore an Identification option if it occurs on a packet that 1835 would otherwise be considered valid. 1837 Example C code for constructing the option's value before 1838 transmitting a packet follows. 1840 unsigned char *packet_data; 1841 int packet_length; 1842 int id_option_offset; /* offset of option in packet_data */ 1844 const unsigned char *my_nonce, *other_nonce; 1845 int my_nonce_length, other_nonce_length; 1847 MD5_CTX md5_context; 1849 MD5_Init(&md5_context); 1850 MD5_Update(&md5_context, packet_data + 4, 4); 1851 MD5_Update(&md5_context, packet_data + 12, 4); 1852 MD5_Update(&md5_context, my_nonce, my_nonce_length); 1853 MD5_Update(&md5_context, other_nonce, other_nonce_length); 1854 packet_data[id_option_offset] = 42; /* option value */ 1855 packet_data[id_option_offset+1] = 18; /* option length */ 1856 MD5_Final(packet_data + id_option_offset + 2, &md5_context); 1858 6.4.4. Challenge Option 1860 This option informs the receiving DCCP that one of its packets was 1861 ignored, and that succeeding packets will be ignored until the 1862 endpoint sends a correct Identification option. The receiving DCCP 1863 SHOULD include an Identification option on the next packet it sends. 1864 The option takes the following form: 1866 +--------+--------+--------+--------+--------+-------- 1867 |00101100| Length | Identification Data ... 1868 +--------+--------+--------+--------+--------+-------- 1869 Type=44 1871 The Identification Data on a packet sent by DCCP B is the same as 1872 that for an Identification option sent by DCCP B. The receiver 1873 SHOULD ignore a Challenge option, and the packet the Challenge 1874 option contains, if the Identification Data is incorrect. The 1875 purpose of this mechanism is to prevent denial-of-service attacks 1876 where an attacker could cause the receiver to send many packets with 1877 expensive-to-compute Identification options, since the receiver MAY 1878 ignore Challenge options for some time after receiving an invalid 1879 Challenge. 1881 If, after several Challenge options, a DCCP is unable to elicit a 1882 valid Identification from its partner, it MAY reset the connection 1883 with Reason "Unanswered Challenge". 1885 6.5. Init Cookie Option 1887 This option is permitted in DCCP-Response, DCCP-Data, and DCCP- 1888 DataAck messages. The option MAY be returned by the server in a 1889 DCCP-Response. If so, then the client MUST echo the same Init 1890 Cookie option in its ensuing DCCP-Data or DCCP-DataAck message. The 1891 server SHOULD respond to an invalid Init Cookie option by resetting 1892 the connection with Reason set to "Bad Init Cookie". 1894 The purpose of this option is to allow a DCCP server to avoid having 1895 to hold any state until the three-way connection setup handshake has 1896 completed. The server wraps up the service name, server port, and 1897 any options it cares about from both the DCCP-Request and DCCP- 1898 Response in an opaque cookie. Typically the cookie will be 1899 encrypted using a secret known only to the server and include a 1900 cryptographic checksum or magic value so that correct decryption can 1901 be verified. When the server receives the cookie back in the 1902 response, it can decrypt the cookie and instantiate all the state it 1903 avoided keeping. 1905 The precise implementation of the Init Cookie does not need to be 1906 specified here; since Init Cookies are opaque to the client, there 1907 are no interoperability concerns. 1909 +--------+--------+--------+--------+--------+-------- 1910 |00100100| Length | Init Cookie Value ... 1911 +--------+--------+--------+--------+--------+-------- 1912 Type=36 1914 6.6. Timestamp Option 1916 This option is permitted in any DCCP packet. The length of the 1917 option is 6 bytes. 1919 +--------+--------+--------+--------+--------+--------+ 1920 |00101000|00000110| Timestamp Value | 1921 +--------+--------+--------+--------+--------+--------+ 1922 Type=40 Length=6 1924 The four bytes of option data carry the timestamp of this packet in 1925 some undetermined form. A DCCP receiving a Timestamp option SHOULD 1926 respond with a Timestamp Echo option on the next packet it sends. 1928 6.7. Elapsed Time Option 1930 This option is permitted in any DCCP packet that contains an 1931 Acknowledgement Number. It indicates how much time, in milliseconds, 1932 has elapsed since the packet being acknowledged---the packet with 1933 the given Acknowledgement Number---was received. The option may take 1934 4 or 6 bytes, depending on how large Elapsed Time is. 1936 +--------+--------+--------+--------+ 1937 |00101110|00000100| Elapsed Time | 1938 +--------+--------+--------+--------+ 1939 Type=46 Len=4 1941 +--------+--------+--------+--------+--------+--------+ 1942 |00101110|00000110| Elapsed Time | 1943 +--------+--------+--------+--------+--------+--------+ 1944 Type=46 Len=6 1946 The option data, Elapsed Time, represents an estimated upper bound 1947 on the amount of time elapsed since the packet being acknowledged 1948 was received, with units of tenths of milliseconds. If Elapsed Time 1949 is less than a second, the first, more parsimonious form of the 1950 option SHOULD be used. Elapsed Times of more than 6.5535 seconds 1951 MUST be sent using the second form of the option. DCCP endpoints 1952 MUST NOT report Elapsed Times that are significantly larger than the 1953 true elapsed times. 1955 Elapsed Time is measured in tenths of milliseconds as a compromise 1956 between two conflicting goals: first, to provide enough granularity 1957 to reduce aliasing noise when measuring elapsed time over fast LANs; 1958 and second, to allow most reasonable elapsed times to fit into two 1959 bytes of data. 1961 Elapsed Time may help correct round-trip time estimates when the gap 1962 between receiving a packet and acknowledging that packet may be 1963 long---in CCID 3, for example, where acknowledgements are sent 1964 infrequently. 1966 6.8. Timestamp Echo Option 1968 This option is permitted in any DCCP packet, as long as at least one 1969 packet carrying the Timestamp option has been received. Generally, a 1970 DCCP endpoint should send one Timestamp Echo option for each 1971 Timestamp option it receives; and it should send that option as soon 1972 as is convenient. The length of the option is between 6 and 10 1973 bytes, depending on whether Elapsed Time is included and how large 1974 it is. 1976 +--------+--------+--------+--------+--------+--------+ 1977 |00101001|00000110| Timestamp Echo | 1978 +--------+--------+--------+--------+--------+--------+ 1979 Type=41 Len=6 1981 +--------+--------+------- ... -------+--------+--------+ 1982 |00101001|00001000| Timestamp Echo | Elapsed Time | 1983 +--------+--------+------- ... -------+--------+--------+ 1984 Type=41 Len=8 (4 bytes) 1986 +--------+--------+------- ... -------+------- ... -------+ 1987 |00101001|00001010| Timestamp Echo | Elapsed Time | 1988 +--------+--------+------- ... -------+------- ... -------+ 1989 Type=41 Len=10 (4 bytes) (4 bytes) 1991 The first four bytes of option data, Timestamp Echo, carry a 1992 Timestamp Value taken from a preceding received Timestamp option. 1993 Usually, this will be the last packet that was received---the packet 1994 indicated by the Acknowledgement Number, if any---but it might be a 1995 preceding packet. 1997 The Elapsed Time field is similar to the value stored in the Elapsed 1998 Time option. If present, it indicates the amount of time elapsed 1999 since receiving the packet whose timestamp is being echoed. This 2000 time MUST be in tenths of milliseconds. Elapsed Time is meant to 2001 help the Timestamp sender separate the network round-trip time from 2002 the Timestamp receiver's processing time. This may be particularly 2003 important for CCIDs where acknowledgements are sent infrequently, so 2004 that there might be considerable delay between receiving a Timestamp 2005 option and sending the corresponding Timestamp Echo. A missing 2006 Elapsed Time field is equivalent to an Elapsed Time of zero. The 2007 smallest version of the option SHOULD be used that can hold the 2008 relevant Elapsed Time value. 2010 6.9. Loss Window Feature 2012 Loss Window has feature number 6. The Loss Window feature located at 2013 DCCP B is the width of the window DCCP B uses to determine whether 2014 packets from DCCP A are valid. Packets outside this window will be 2015 dropped by DCCP B as old duplicates or spoofing attempts; see 2016 Section 5.2 for more information. DCCP A sends a "Change(Loss 2017 Window, W)" option to DCCP B to set DCCP B's Loss Window to W. 2019 The Loss Window feature takes 3-byte integer values, like DCCP 2020 sequence numbers. Change and Confirm options for Loss Window are 2021 therefore 6 bytes long. 2023 Loss Window defaults to 1000 for new connections. The Loss Window 2024 value is the total width of the loss window. The receiver positions 2025 the loss window asymmetrically around GSN, the greatest sequence 2026 number seen, with one-third of the loss window width (rounded down) 2027 reserved for GSN and older sequence numbers and two-thirds reserved 2028 for newer sequence numbers, as follows: 2030 invalid | valid sequence numbers | invalid 2031 <---------|============+========================|----------> 2032 GSN -|GSN + 1 - GSN GSN +|GSN + 1 + 2033 floor(W/3)|floor(W/3) ceil(2W/3)|ceil(2W/3) 2035 This feature is non-negotiable. 2037 7. Congestion Control IDs 2039 Each congestion control mechanism supported by DCCP is assigned a 2040 congestion control identifier, or CCID: a number from 0 to 255. 2041 During connection setup, and optionally thereafter, the endpoints 2042 negotiate their congestion control mechanisms by negotiating the 2043 values for their Congestion Control features. Congestion Control has 2044 feature number 1. The feature located at DCCP A is the CCID in use 2045 for the A-to-B half-connection. DCCP B sends an "Change(CC, K)" 2046 option to DCCP A to ask A to use CCID K for its data packets. 2048 The data byte of Congestion Control feature negotiation options form 2049 a list of acceptable CCIDs, sorted in descending order of priority. 2050 For example, the option "Change(CC 1, 2, 3)" asks the sender to use 2051 CCID 1, although CCIDs 2 and 3 are also acceptable. (This 2052 corresponds to the bytes "33, 6, 1, 1, 2, 3": Change option (33), 2053 option length (6), feature ID (1), CCIDs (1, 2, 3).) Similarly, 2054 "Confirm(CC 1, 2, 3)" tells the receiver that the sender is using 2055 CCID 1, but that CCIDs 2 or 3 might also be acceptable. 2057 The CCIDs defined by this document are: 2059 CCID Meaning 2060 ---- ------- 2061 0 Reserved 2062 1 Unspecified Sender-Based Congestion Control 2063 2 TCP-like Congestion Control 2064 3 TFRC Congestion Control 2066 A new connection starts with CCID 2 for both DCCPs. If this is 2067 unacceptable for a DCCP endpoint, that endpoint's Congestion Control 2068 feature will start in the Unknown state, and the endpoint will send 2069 "Prefer(CC)" options on its first packets. A DCCP endpoint MUST NOT 2070 send data when its Congestion Control feature is in the Unknown 2071 state, with the possible exception of the data included on a DCCP- 2072 Request. It MUST also limit the rate at which it sends unsolicited 2073 DCCP-Ack packets until its Congestion Control feature is known. 2074 (This does not affect acknowledgements on the other half-connection, 2075 which are controlled by the other endpoint's Congestion Control 2076 feature; see Section 8.1.) 2078 All CCIDs standardized for use with DCCP will correspond to 2079 congestion control mechanisms previously standardized by the IETF. 2080 We expect that for quite some time, all such mechanisms will be TCP- 2081 friendly, but TCP-friendliness is not an explicit DCCP requirement. 2083 A DCCP implementation intended for general use---in a general- 2084 purpose operating system kernel, for example---SHOULD implement at 2085 least CCIDs 1 and 2. The intent is to make these CCIDs broadly 2086 available for interoperability, although any given application might 2087 disallow their use via the feature negotiation process. 2089 7.1. Unspecified Sender-Based Congestion Control 2091 CCID 1 denotes an unspecified sender-based congestion control 2092 mechanism. Separate features negotiate the corresponding congestion 2093 acknowledgement options---for example, Ack Vector. This provides a 2094 limited, controlled form of interoperability for new IETF-approved 2095 CCIDs. 2097 Implementors MUST NOT use CCID 1 in production environments as a 2098 proxy for congestion control mechanisms that have not entered the 2099 IETF standards process. We intend that any production use of CCID 1 2100 would have to be explicitly approved first by the IETF. Middleboxes 2101 MAY choose to treat the use of CCID 1 as experimental or 2102 unacceptable. 2104 For example, say that CCID 98, a new sender-based congestion control 2105 mechanism using Ack Vector for acknowledgements, has entered the 2106 IETF standards process, and the IETF has approved the use of CCID 1 2107 as a backup for CCID 98. Now, DCCP A, which understands and would 2108 like to use CCID 98, is trying to communicate with DCCP B, which 2109 doesn't yet know about CCID 98. DCCP A can simply negotiate use of 2110 CCID 1 and, separately, negotiate Use Ack Vector. DCCP B will 2111 provide the feedback DCCP A requires for CCID 98, namely Ack Vector, 2112 without needing to understand the congestion control mechanism in 2113 use. 2115 CCID 1 has no sender implementation; it is exclusively meaningful at 2116 the receiver to support forward compatibility. The sender always 2117 uses a specific congestion control mechanism whose CCID is not 1. 2118 However, the code implementing a CCID that requires only generic 2119 feedback, such as Ack Vector, MAY add CCID 1 to the list of 2120 acceptable CCIDs sent to the receiver (following the actual CCID), 2121 facilitating communication with receivers that do not understand the 2122 actual CCID. 2124 Any CCID feature negotiation in which the sender proposes the use of 2125 CCID 1 without any other CCID is considered erroneous, and SHOULD 2126 result in connection reset, with Reason set to "Fruitless 2127 Negotiation". 2129 DCCP implementations MAY provide APIs that allow applications to 2130 suggest preferred CCIDs for sending and receiving data. Any such API 2131 MUST NOT allow sending applications to suggest CCID 1; again, CCID 1 2132 will be suggested when appropriate by the code implementing the 2133 preferred CCID. In contrast, APIs SHOULD let applications allow or 2134 prevent the use of CCID 1 for receiving. 2136 7.2. TCP-like Congestion Control 2138 CCID 2 denotes Additive Increase, Multiplicative Decrease (AIMD) 2139 congestion control with behavior modelled directly on TCP, including 2140 congestion window, slow start, timeouts, and so forth. CCID 2 is 2141 further described in [CCID 2 PROFILE]. 2143 7.3. TFRC Congestion Control 2145 CCID 3 denotes TCP-Friendly Rate Control, an equation-based rate- 2146 controlled congestion control mechanism. CCID 3 is further described 2147 in [CCID 3 PROFILE]. 2149 7.4. CCID-Specific Options and Features 2151 Option and feature numbers 128 through 255 are available for CCID- 2152 specific use. CCIDs may often need new option types---for 2153 communicating acknowledgement or rate information, for example. 2154 CCID-specific option types let them create options at will without 2155 polluting the global option space. Option 128 might have different 2156 meanings on a half-connection using CCID 4 and a half-connection 2157 using CCID 8. CCID-specific options and features will never conflict 2158 with global options introduced by later versions of this 2159 specification. 2161 Any packet may contain information meant for either half-connection, 2162 so CCID-specific option and feature numbers explicitly signal the 2163 half-connection to which they apply. Option numbers 128 through 191 2164 are for options sent from the HC-Sender to the HC-Receiver; option 2165 numbers 192 through 255 are for options sent from the HC-Receiver to 2166 the HC-Sender. Similarly, feature numbers 128 through 191 are for 2167 features located at the HC-Sender; feature numbers 192 through 255 2168 are for features located at the HC-Receiver. (Change options for a 2169 feature are sent to the feature location; Prefer and Confirm options 2170 are sent from the feature location. Thus, Change(128) options are 2171 sent by the HC-Receiver by definition, while Change(192) options are 2172 sent by the HC-Sender.) 2174 For example, consider a DCCP connection where the A-to-B half- 2175 connection uses CCID 4 and the B-to-A half-connection uses CCID 5. 2176 Here is how a sampling of CCID-specific options and features are 2177 assigned to half-connections: 2179 Relevant Relevant 2180 Packet Option Half-conn. CCID 2181 ------ ------ ---------- ---- 2182 A > B 128 A-to-B 4 2183 A > B 192 B-to-A 5 2184 A > B Change(128, ...) B-to-A 5 2185 A > B Prefer(128, ...) A-to-B 4 2186 A > B Confirm(128, ...) A-to-B 4 2187 A > B Change(192, ...) A-to-B 4 2188 A > B Prefer(192, ...) B-to-A 5 2189 A > B Confirm(192, ...) B-to-A 5 2191 B > A 128 B-to-A 5 2192 B > A 192 A-to-B 4 2193 B > A Change(128, ...) A-to-B 4 2194 B > A Prefer(128, ...) B-to-A 5 2195 B > A Confirm(128, ...) B-to-A 5 2196 B > A Change(192, ...) B-to-A 5 2197 B > A Prefer(192, ...) A-to-B 4 2198 B > A Confirm(192, ...) A-to-B 4 2200 CCID-specific options and features have no clear meaning when the 2201 relevant CCID is in flux. A DCCP SHOULD respond to CCID-specific 2202 options and features with Ignored options during those times. 2204 8. Acknowledgements 2206 Congestion control requires receivers to transmit information about 2207 packet losses and ECN marks to senders. DCCP receivers MUST report 2208 all congestion they see, as defined by the relevant CCID profile. 2209 Each CCID says when acknowledgements should be sent, what options 2210 they must use, how they should be congestion controlled, and so on. 2212 Most acknowledgements use DCCP options. For example, on a half- 2213 connection with CCID 2 (TCP-like), the receiver reports 2214 acknowledgement information using the Ack Vector option. This 2215 section describes common acknowledgement options and shows how acks 2216 using those options will commonly work. Full descriptions of the 2217 acknowledgement mechanisms used for each CCID are laid out in the 2218 CCID profile specifications. 2220 Acknowledgement options, such as Ack Vector, generally depend on the 2221 DCCP Acknowledgement Number, and are thus only allowed on packet 2222 types that carry that number (all packets except DCCP-Request and 2223 DCCP-Data). However, detailed acknowledgement options are not 2224 generally necessary on DCCP-Resets. 2226 8.1. Acks of Acks and Unidirectional Connections 2228 DCCP was designed to work well for both bidirectional and 2229 unidirectional flows of data, and for connections that transition 2230 between these states. However, acknowledgements required for a 2231 unidirectional connection are very different from those required for 2232 a bidirectional connection. In particular, unidirectional 2233 connections need to worry about acks of acks. 2235 The ack-of-acks problem arises because some acknowledgement 2236 mechanisms are reliable. For example, an HC-Receiver using CCID 2, 2237 TCP-like Congestion Control, sends Ack Vectors containing completely 2238 reliable acknowledgement information. The HC-Sender should 2239 occasionally inform the HC-Receiver that it has received an ack. If 2240 it did not, the HC-Receiver might resend complete Ack Vector 2241 information, going back to the start of the connection, with every 2242 DCCP-Ack packet! However, note that acks-of-acks need not be 2243 reliable themselves: when an ack-of-acks is lost, the HC-Receiver 2244 will simply maintain, and periodically retransmit, old 2245 acknowledgement-related state for a little longer. Therefore, there 2246 is no need for acks-of-acks-of-acks. 2248 When communication is bidirectional, any required acks-of-acks are 2249 automatically contained in normal acknowledgements for data packets. 2250 On a unidirectional connection, however, the receiver DCCP sends no 2251 data, so the sender would not normally send acknowledgements. 2252 Therefore, the CCID in force on that half-connection must explicitly 2253 say whether, when, and how the HC-Sender should generate acks-of- 2254 acks. 2256 For example, consider a bidirectional connection where both half- 2257 connections use the same CCID (either 2 or 3), and where DCCP B goes 2258 "quiescent". This means that the connection becomes unidirectional: 2259 DCCP B stops sending data, and sends only sends DCCP-Ack packets to 2260 DCCP A. For CCID 2, TCP-like Congestion Control, DCCP B uses Ack 2261 Vector to reliably communicate which packets it has received. As 2262 described above, DCCP A must occasionally acknowledge a pure 2263 acknowledgement from DCCP B, so that DCCP B can free old Ack Vector 2264 state. For instance, DCCP A might send a DCCP-DataAck packet every 2265 now and then, instead of DCCP-Data. In contrast, for CCID 3, TFRC 2266 Congestion Control, DCCP B's acknowledgements generally need not be 2267 reliable, since they contain cumulative loss rates; TFRC works even 2268 if every DCCP-Ack is lost. Therefore, DCCP A need never acknowledge 2269 an acknowledgement. 2271 When communication is unidirectional, a single CCID---in the 2272 example, the A-to-B CCID---controls both DCCPs' acknowledgements, in 2273 terms of their content, their frequency, and so forth. For 2274 bidirectional connections, the A-to-B CCID governs DCCP B's 2275 acknowledgements (including its acks of DCCP A's acks), while the B- 2276 to-A CCID governs DCCP A's acknowledgements. 2278 DCCP A switches its ack pattern from bidirectional to unidirectional 2279 when it notices that DCCP B has gone quiescent. It switches from 2280 unidirectional to bidirectional when it must acknowledge even a 2281 single DCCP-Data or DCCP-DataAck packet from DCCP B. (This includes 2282 the case where a single DCCP-Data or DCCP-DataAck packet was lost in 2283 transit, which is detectable using the # NDP field in the DCCP 2284 packet header.) 2286 Each CCID defines how to detect quiescence on that CCID, and how 2287 that CCID handles acks-of-acks on unidirectional connections. The B- 2288 to-A CCID defines when DCCP B has gone quiescent. Usually, this 2289 happens when a period has passed without B sending any data packets. 2290 For CCID 2, this period is roughly two round-trip times. The A-to-B 2291 CCID defines how DCCP A handles acks-of-acks once DCCP B has gone 2292 quiescent. 2294 8.2. Ack Piggybacking 2296 Acknowledgements of A-to-B data MAY be piggybacked on data sent by 2297 DCCP B, as long as that does not delay the acknowledgement longer 2298 than the A-to-B CCID would find acceptable. However, data 2299 acknowledgements often require more than 4 bytes to express. A large 2300 set of acknowledgements prepended to a large data packet might 2301 exceed the path's MTU. In this case, DCCP B SHOULD send separate 2302 DCCP-Data and DCCP-Ack packets, or wait, but not too long, for a 2303 smaller datagram. 2305 Piggybacking is particularly common at DCCP A when the B-to-A half- 2306 connection is quiescent---that is, when DCCP A is just acknowledging 2307 DCCP B's acknowledgements, as described above. There are three 2308 reasons to acknowledge DCCP B's acknowledgements: to allow DCCP B to 2309 free up information about previously acknowledged data packets from 2310 A; to shrink the size of future acknowledgements; and to manipulate 2311 the rate future acknowledgements are sent. Since these are secondary 2312 concerns, DCCP A can generally afford to wait indefinitely for a 2313 data packet to piggyback its acknowledgement onto. 2315 Any restrictions on ack piggybacking are described in the relevant 2316 CCID's profile. 2318 8.3. Ack Ratio Feature 2320 Ack Ratio provides a common mechanism by which CCIDs that clock 2321 acknowledgements off of data packets can perform rudimentary 2322 congestion control on the acknowledgement stream. CCID 2, TCP-like 2323 Congestion Control, uses Ack Ratio to limit the rate of its 2324 acknowledgement stream, for example. Some CCIDs ignore Ack Ratio, 2325 performing congestion control on acknowledgements in some other way. 2327 Ack Ratio has feature number 3. The Ack Ratio feature located at 2328 DCCP B equals the ratio of data packets sent by DCCP A to 2329 acknowledgement packets sent back by DCCP B. For example, if it is 2330 set to four, then DCCP B will send at least one acknowledgement 2331 packet for every four data packets DCCP A sends. DCCP A sends a 2332 "Change(Ack Ratio)" option to DCCP B to change DCCP B's ack ratio. 2334 An Ack Ratio option contains two bytes of data: a sixteen-bit 2335 integer representing the ratio. A new connection starts with Ack 2336 Ratio 2 for both DCCPs. 2338 This feature is non-negotiable. 2340 8.4. Use Ack Vector Feature 2342 The Use Ack Vector feature lets DCCPs negotiate whether they should 2343 use Ack Vector options to report congestion. Ack Vector provides 2344 detailed loss information, and lets senders report back to their 2345 applications whether particular packets were dropped. Use Ack Vector 2346 is mandatory for some CCIDs, and optional for others. 2348 Use Ack Vector has feature number 4. The Use Ack Vector feature 2349 located at DCCP B specifies whether DCCP B MUST use Ack Vector 2350 options on its acknowledgements to DCCP A, although DCCP B MAY send 2351 Ack Vector options even when Use Ack Vector is false. DCCP A sends a 2352 "Change(Use Ack Vector, 1)" option to DCCP B to ask B to send Ack 2353 Vector options as part of its acknowledgement traffic. 2355 Use Ack Vector feature values are a single byte long. The receiver 2356 MUST send Ack Vector options if this byte is nonzero. A new 2357 connection starts with Use Ack Vector 0 for both DCCPs. 2359 8.5. Ack Vector Options 2361 The Ack Vector gives a run-length encoded history of data packets 2362 received at the client. Each byte of the vector gives the state of 2363 that data packet in the loss history, and the number of preceding 2364 packets with the same state. The option's data looks like this: 2366 +--------+--------+--------+--------+--------+-------- 2367 |001001??| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL| ... 2368 +--------+--------+--------+--------+--------+-------- 2369 Type=37/38 \___________ Vector ___________... 2371 The two Ack Vector options (option types 37 and 38) differ only in 2372 the values they imply for ECN Nonce Echo. Section 9.2 describes this 2373 further. 2375 The vector itself consists of a series of bytes, each of whose 2376 encoding is: 2378 0 1 2 3 4 5 6 7 2379 +-+-+-+-+-+-+-+-+ 2380 |St | Run Length| 2381 +-+-+-+-+-+-+-+-+ 2383 St[ate]: 2 bits 2385 Run Length: 6 bits 2387 State occupies the most significant two bits of each byte, and can 2388 have one of four values: 2390 0 Packet received (and not ECN marked). 2392 1 Packet received ECN marked. 2394 2 Reserved. 2396 3 Packet not yet received. 2398 The first byte in the first Ack Vector option refers to the packet 2399 indicated in the Acknowledgement Number; subsequent bytes refer to 2400 older packets. (Ack Vector MUST NOT be sent on DCCP-Data and DCCP- 2401 Request packets, which lack an Acknowledgement Number.) If an Ack 2402 Vector contains the decimal values 0,192,3,64,5 and the 2403 Acknowledgement Number is decimal 100, then: 2405 Packet 100 was received (Acknowledgement Number 100, State 0, 2406 Run Length 0). 2408 Packet 99 was lost (State 3, Run Length 0). 2410 Packets 98, 97, 96 and 95 were received (State 0, Run Length 3). 2412 Packet 94 was ECN marked (State 1, Run Length 0). 2414 Packets 93, 92, 91, 90, 89, and 88 were received (State 0, Run 2415 Length 5). 2417 Run lengths of more than 64 must be encoded in multiple bytes. A 2418 single Ack Vector option can acknowledge up to 16192 data packets. 2419 Should more packets need to be acknowledged than can fit in 253 2420 bytes of Ack Vector, then multiple Ack Vector options can be sent. 2421 The second Ack Vector option will begin where the first Ack Vector 2422 option left off, and so forth. 2424 Ack Vector states are subject to two general constraints. (These 2425 principles SHOULD also be followed for other acknowledgement 2426 mechanisms; referring to Ack Vector states simplifies their 2427 explanation.) 2429 (1) Packets reported as State 0 or State 1 MUST have been processed 2430 by the receiving DCCP stack. In particular, their options must 2431 have been processed. Any data on the packet need not have been 2432 delivered to the receiving application; in fact, the data may 2433 have been dropped. 2435 (2) Packets reported as State 3 MUST NOT have been received by DCCP. 2436 Feature negotiations and options on such packets MUST NOT have 2437 been processed, and the Acknowledgement Number MUST NOT 2438 correspond to such a packet. 2440 Packets dropped in the application's receive buffer SHOULD be 2441 reported as Received or Received ECN Marked (States 0 and 1), 2442 depending on their ECN state; such packets' ECN Nonces MUST be 2443 included in the Nonce Echo. The Data Dropped option informs the 2444 sender that some packets reported as received actually had their 2445 payloads dropped. 2447 One or more Ack Vector options that, together, report the status of 2448 more packets than have actually been sent SHOULD be considered 2449 invalid. The receiving DCCP SHOULD either ignore the options or 2450 reset the connection with Reason set to "Option Error". Packets 2451 whose status has not reported by any Ack Vector option SHOULD be 2452 treated as "not yet received" (State 3) by the sender. 2454 8.5.1. Ack Vector Consistency 2456 A DCCP sender will commonly receive multiple acknowledgements for 2457 some of its data packets. For instance, an HC-Sender might receive 2458 two DCCP-Acks with Ack Vectors, both of which contained information 2459 about sequence number 24. (Because of cumulative acking, 2460 information about a sequence number is repeated in every ack until 2461 the HC-Sender acknowledges an ack. Perhaps the HC-Receiver is 2462 sending acks faster than the HC-Sender is acknowledging them.) In a 2463 perfect world, the two Ack Vectors would always be consistent. 2464 However, there are many reasons why they might not be: 2466 o The HC-Receiver received packet 24 between sending its acks, so 2467 the first ack said 24 was not received (State 3) and the second 2468 said it was received or ECN marked (State 0 or 1). 2470 o The HC-Receiver received packet 24 between sending its acks, and 2471 the network reordered the acks. In this case, the packet will 2472 appear to transition from State 0 or 1 to State 3. 2474 o The network duplicated packet 24, and one of the duplicates was 2475 ECN marked. This might show up as a transition between States 0 2476 and 1. 2478 To cope with these situations, HC-Sender DCCP implementations SHOULD 2479 combine multiple received Ack Vector states according to this table: 2481 Received State 2482 0 1 3 2483 +---+---+---+ 2484 0 | 0 |0/1| 0 | 2485 Old +---+---+---+ 2486 1 | 1 | 1 | 1 | 2487 State +---+---+---+ 2488 3 | 0 | 1 | 3 | 2489 +---+---+---+ 2491 To read the table, choose the row corresponding to the packet's old 2492 state and the column corresponding to the packet's state in the 2493 newly received Ack Vector, then read the packet's new state off the 2494 table. For an old state of 0 (received non-marked) and received 2495 state of 1 (received ECN marked), the packet's new state may be set 2496 to either 0 or 1. The HC-Sender implementation will be indifferent 2497 to ack reordering if it chooses new state 1 for that cell. 2499 The HC-Receiver should collect information about received packets, 2500 which it will eventually report to the HC-Sender on one or more 2501 acknowledgements, according to the following table: 2503 Received Packet 2504 0 1 3 2505 +---+---+---+ 2506 0 | 0 |0/1| 0 | 2507 Stored +---+---+---+ 2508 1 |0/1| 1 | 1 | 2509 State +---+---+---+ 2510 3 | 0 | 1 | 3 | 2511 +---+---+---+ 2513 This table equals the sender's table, except that when the stored 2514 state is 1 and the received state is 0, the receiver is allowed to 2515 switch its stored state to 0. 2517 A HC-Sender MAY choose to throw away old information gleaned from 2518 the HC-Receiver's Ack Vectors, in which case it MUST ignore newly 2519 received acknowledgements from the HC-Receiver for those old 2520 packets. It is often kinder to save recent Ack Vector information 2521 for a while, so that the HC-Sender can undo its reaction to presumed 2522 congestion when a "lost" packet unexpectedly shows up (the 2523 transition from State 3 to State 0). 2525 8.5.2. Ack Vector Coverage 2527 We can divide the packets that have been sent from an HC-Sender to 2528 an HC-Receiver into four roughly contiguous groups. From oldest to 2529 youngest, these are: 2531 (1) Packets already acknowledged by the HC-Receiver, where the HC- 2532 Receiver knows that the HC-Sender has definitely received the 2533 acknowledgements. 2535 (2) Packets already acknowledged by the HC-Receiver, where the HC- 2536 Receiver cannot be sure that the HC-Sender has received the 2537 acknowledgements. 2539 (3) Packets not yet acknowledged by the HC-Receiver. 2541 (4) Packets not yet received by the HC-Receiver. 2543 The union of groups 2 and 3 is called the Acknowledgement Window. 2544 Generally, every Ack Vector generated by the HC-Receiver will cover 2545 the whole Acknowledgement Window: Ack Vector acknowledgements are 2546 cumulative. (This simplifies Ack Vector maintenance at the HC- 2547 Receiver; see Section 23, below.) As packets are received, this 2548 window both grows on the right and shrinks on the left. It grows 2549 because there are more packets, and shrinks because the data 2550 packets' Acknowledgement Numbers will acknowledge previous 2551 acknowledgements, moving packets from group 2 into group 1. 2553 8.6. Slow Receiver Option 2555 An HC-Receiver sends the Slow Receiver option to its sender to 2556 indicate that it is having trouble keeping up with the sender's 2557 data. The HC-Sender SHOULD NOT increase its sending rate for 2558 approximately one round-trip time after seeing a packet with a Slow 2559 Receiver option. However, the Slow Receiver option does not indicate 2560 congestion, and the HC-Sender need not reduce its sending rate. (If 2561 necessary, the receiver can force the sender to slow down by 2562 dropping packets or reporting false ECN marks.) APIs SHOULD let 2563 receiver applications set Slow Receiver, and sending applications 2564 determine whether or not their receivers are Slow. 2566 The Slow Receiver option takes just one byte: 2568 +--------+ 2569 |00000010| 2570 +--------+ 2571 Type=2 2573 Slow Receiver does not specify why the receiver is having trouble 2574 keeping up with the sender. Possible reasons include lack of buffer 2575 space, CPU overload, and application quotas. A sending application 2576 might react to Slow Receiver by reducing its sending rate or by 2577 switching to a lossier compression algorithm. However, a smart 2578 sender might actually *increase* its sending rate in response to 2579 Slow Receiver, by switching to a less-compressed sending format. (A 2580 highly-compressed data format might overwhelm a slow CPU more 2581 seriously than the higher memory requirements of a less-compressed 2582 data format.) This tension between transfer size (less compression 2583 means more congestion) and processing speed (less compression means 2584 less processing) cannot be resolved in general. 2586 Slow Receiver implements a portion of TCP's receive window 2587 functionality. We believe receiver operating systems and 2588 applications will find it much easier to send Slow Receiver when 2589 appropriate than they currently find it to correctly set a TCP 2590 receive window. 2592 8.7. Data Dropped Option 2594 The Data Dropped option indicates that some packets reported as 2595 received actually had their data dropped before it reached the 2596 application. The sender's congestion control mechanism may respond 2597 to data-dropped packets less severely than to lost or marked 2598 packets. For instance, a windowed mechanism might subtract a 2599 constant value from its congestion window, rather than cut it in 2600 half. 2602 Data Dropped lets a sender differentiate between different kinds of 2603 loss (network and endpoint), but it does not allow total freedom in 2604 how to react. The congestion control response to a Data Dropped 2605 packet MUST be approved by the IETF. In particular, a congestion 2606 control mechanism MUST react to a Data Dropped packet as if the 2607 packet were ECN marked, unless specified otherwise in the relevant 2608 CCID profile. 2610 In any case, when ECN-marked packets are included in Data Dropped, 2611 the sender's congestion control mechanism MUST react to the ECN 2612 mark. 2614 If a received packet's payload is dropped for one of the reasons 2615 listed below, this SHOULD be reported using a Data Dropped option. 2616 Alternatively, the receiver MAY choose to report as "received" only 2617 those packets whose payloads were not dropped, subject to the 2618 constraint that packets not reported as received MUST NOT have had 2619 their options processed. 2621 The option's data looks like this: 2623 +--------+--------+--------+--------+--------+-------- 2624 |00100111| Length | Block | Block | Block | ... 2625 +--------+--------+--------+--------+--------+-------- 2626 Type=39 \___________ Vector ___________ ... 2628 The vector itself consists of a series of bytes, called Blocks, 2629 each of whose encoding corresponds to one of these choices: 2631 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 2632 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2633 |0| Run Length | or |1|Dr St|Run Len| 2634 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2635 Normal Block Drop Block 2637 The first byte in the first Data Dropped option refers to the packet 2638 indicated in the Acknowledgement Number; subsequent bytes refer to 2639 older packets. (Data Dropped MUST NOT be sent on DCCP-Data or DCCP- 2640 Request packets, which lack an Acknowledgement Number.) Normal 2641 Blocks, which have high bit 0, indicate that any received packets in 2642 the Run Length had their data delivered to the application. Drop 2643 Blocks, which have high bit 1, indicate that received packets in the 2644 Run Len[gth] were not delivered as usual. The 3-bit Dr[op] St[ate] 2645 field says what happened; generally, no data from that packet 2646 reached the application. Packets reported as "not yet received" MUST 2647 be included in Normal Blocks; packets not covered by any Data 2648 Dropped option are treated as if they were in a Normal Block. 2649 Defined Drop States for Drop Blocks are: 2651 0 Packet data dropped due to protocol constraints. For 2652 example, the data was included on a DCCP-Request packet, and 2653 the receiving application does not allow that piggybacking; 2654 or the data was sent during an important feature 2655 negotiation. 2657 1 Packet data dropped in the receive buffer. 2659 2 Packet data dropped due to corruption. 2661 3 Packet data corrupted, but delivered to the application 2662 anyway. 2664 4 Packet data dropped because the application is no longer 2665 listening. 2667 5-7 Reserved. 2669 For example, if a Data Dropped option contains the decimal values 2670 0,144,3,146, the Acknowledgement Number is 100, and an Ack Vector 2671 reported all packets as received, then: 2673 Packet 100 was received (Acknowledgement Number 100, Normal 2674 Block, Run Length 0). 2676 Packet 99 was dropped in the receive buffer (Drop Block, Drop 2677 State 1, Run Length 0). 2679 Packets 98, 97, 96, and 95 were received (Normal Block, Run 2680 Length 3). 2682 Packets 95, 94, and 93 were dropped in the receive buffer (Drop 2683 Block, Drop State 1, Run Length 2). 2685 Run lengths of more than 128 (for Normal Blocks) or 16 (for Drop 2686 Blocks) must be encoded in multiple Blocks. A single Data Dropped 2687 option can acknowledge up to 32384 Normal Block data packets, 2688 although the receiver SHOULD NOT send a Data Dropped option when all 2689 relevant packets fit into Normal Blocks. Should more packets need to 2690 be acknowledged than can fit in 253 bytes of Data Dropped, then 2691 multiple Data Dropped options can be sent. The second option will 2692 begin where the first option left off, and so forth. 2694 One or more Data Dropped options that, together, report the status 2695 of more packets than have been sent, or that change the status of a 2696 packet, or that disagree with Ack Vector or equivalent options (by 2697 reporting a "not yet received" packet as "dropped in the receive 2698 buffer", for example), SHOULD be considered invalid. The receiving 2699 DCCP SHOULD respond to invalid Data Dropped options by ignoring them 2700 or by resetting the connection with Reason set to "Option Error". 2702 Drop State 4 ("application no longer listening") means the 2703 application running at the endpoint that sent the option is no 2704 longer listening for data. For example, a server might close its 2705 receiving half-connection to new data after receiving a complete 2706 request from the client. This would limit the amount of state the 2707 server would expend on incoming data, and thus reduce the potential 2708 damage from certain denial-of-service attacks. A Data Dropped option 2709 containing Drop State 4 SHOULD be sent whenever received data is 2710 ignored due to a non-listening application. Once a DCCP reports Drop 2711 State 4 for a packet, it SHOULD report Drop State 4 for every 2712 succeeding data packet on that half-connection; once a DCCP receives 2713 a Drop State 4 report, it SHOULD expect that no more data will ever 2714 be delivered to the other endpoint's application. A DCCP receiving 2715 Drop State 4 MAY report this event to the application. (Previous 2716 versions of this specification used a "Buffer Closed" option instead 2717 of Drop State 4.) 2719 8.8. Payload Checksum Option 2721 The Payload Checksum option holds the 16 bit one's complement of the 2722 one's complement sum of all 16 bit words in the DCCP payload (the 2723 data contained in a DCCP-Request, DCCP-Response, DCCP-Data, DCCP- 2724 DataAck, or DCCP-Move packet). When combined with a Checksum Length 2725 of less than 15, this lets DCCP distinguish between corruption in a 2726 packet's payload and corruption in its header. Corrupted-header 2727 packets MUST be treated as dropped by the network, while corrupted- 2728 payload packets MAY be treated differently; for example, the 2729 sender's response to corruption might be less stringent than its 2730 response to congestion. A low Checksum Length lets DCCP process 2731 packets with valid headers, even if the payload is corrupt, avoiding 2732 the congestion response to corruption. The Payload Checksum option 2733 then lets DCCP detect payload corruption, and therefore avoid 2734 delivering bad data to the application. 2736 The option's data looks like this: 2738 +--------+--------+--------+--------+ 2739 |00101101|00000100| Checksum | 2740 +--------+--------+--------+--------+ 2741 Type=45 Length=4 2743 The receiving DCCP MUST check the Payload Checksum's value against 2744 the actual payload checksum. If the values differ, the packet's data 2745 SHOULD be dropped, and reported as dropped due to corruption (Drop 2746 State 2) using a Data Dropped option (Section 8.7). Optionally, DCCP 2747 MAY provide an API through which the receiving application could 2748 request delivery of known-corrupt data. When that API is active, the 2749 packet's data SHOULD be delivered, but reported as delivered corrupt 2750 (Drop State 3) using a Data Dropped option. In either case, the 2751 packet will be reported as Received or Received ECN Marked by Ack 2752 Vector or equivalent options. 2754 See Section 18.1 for a discussion of the issues related to the use 2755 of this option. 2757 9. Explicit Congestion Notification 2759 The DCCP protocol is fully ECN-aware. Each CCID specifies how its 2760 endpoints respond to ECN marks. Furthermore, DCCP, unlike TCP, 2761 allows senders to control the rate at which acknowledgements are 2762 generated (with options like Ack Ratio); this means that 2763 acknowledgements are generally congestion-controlled, and may have 2764 ECN-Capable Transport set. 2766 A CCID profile describes how that CCID interacts with ECN, both for 2767 data traffic and pure-acknowledgement traffic. A sender SHOULD set 2768 ECN-Capable Transport on its packets whenever the receiver has its 2769 ECN Capable feature turned on and the relevant CCID allows it, 2770 unless the sending application indicates that ECN should not be 2771 used. 2773 The rest of this section describes the ECN Capable feature and the 2774 interaction of the ECN Nonce with acknowledgement options such as 2775 Ack Vector. 2777 9.1. ECN Capable Feature 2779 The ECN Capable feature lets a DCCP inform its partner that it 2780 cannot read ECN bits from received IP headers, so the partner must 2781 not set ECN-Capable Transport on its packets. 2783 ECN Capable has feature number 2. The ECN Capable feature located at 2784 DCCP A indicates whether or not A can successfully read ECN bits 2785 from received frames' IP headers. (This is independent of whether it 2786 can set ECN bits on sent frames.) DCCP A sends a "Prefer(ECN 2787 Capable, 0)" option to DCCP B to inform B that A cannot read ECN 2788 bits. 2790 An ECN Capable feature contains a single byte of data. ECN 2791 capability is on if and only if this byte is nonzero. 2793 A new connection starts with ECN Capable 1 (that is, ECN capable) 2794 for both DCCPs. If a DCCP is not ECN capable, it MUST send 2795 "Prefer(ECN Capable, 0)" options to the other endpoint until 2796 acknowledged (by "Change(ECN Capable, 0)") or the connection closes. 2797 Furthermore, it MUST NOT accept any data until the other endpoint 2798 sends "Change(ECN Capable, 0)". It SHOULD send Data Dropped options 2799 on its acknowledgements, with Drop State 0 ("protocol constraints"), 2800 if the other endpoint does send data inappropriately. 2802 9.2. ECN Nonces 2804 Congestion avoidance will not occur, and the receiver will sometimes 2805 get its data faster, when the sender is not told about any 2806 congestion events. Thus, the receiver has some incentive to falsify 2807 acknowledgement information, reporting that marked or dropped 2808 packets were actually received unmarked. This problem is more 2809 serious with DCCP than with TCP, since TCP provides reliable 2810 transport: it is more difficult with TCP to lie about lost packets 2811 without breaking the application. 2813 ECN Nonces are a general mechanism to prevent ECN cheating (or loss 2814 cheating). Two values for the two-bit ECN header field indicate ECN- 2815 Capable Transport, 01 and 10. The second code point, 10, is the ECN 2816 Nonce. In general, a protocol sender chooses between these code 2817 points randomly on its output packets, remembering the sequence it 2818 chose. The protocol receiver reports, on every acknowledgement, the 2819 number of ECN Nonces it has received thus far. This is called the 2820 ECN Nonce Echo. Since ECN marking and packet dropping both destroy 2821 the ECN Nonce, a receiver that lies about an ECN mark or packet drop 2822 has a 50% chance of guessing right and avoiding discipline. The 2823 sender may react punitively to an ECN Nonce mismatch, possibly up to 2824 dropping the connection. The ECN Nonce Echo field need not be an 2825 integer; one bit is enough to catch 50% of infractions. 2827 In DCCP, the ECN Nonce Echo field is encoded in acknowledgement 2828 options. For example, the Ack Vector option comes in two forms, Ack 2829 Vector [Nonce 0] (option 37) and Ack Vector [Nonce 1] (option 38), 2830 corresponding to the two values for a one-bit ECN Nonce Echo. The 2831 Nonce Echo for a given Ack Vector equals the one-bit sum (exclusive- 2832 or, or parity) of ECN nonces for packets reported by that Ack Vector 2833 as received and not ECN marked. Thus, only packets marked as State 2834 0 matter for this calculation (that is, valid received packets that 2835 were not ECN marked). Every Ack Vector option is detailed enough 2836 for the sender to determine what the Nonce Echo should have been. It 2837 can check this calculation against the actual Nonce Echo, and 2838 complain if there is a mismatch. 2840 (The Ack Vector could conceivably report every packet's ECN Nonce 2841 state, but this would severely limit Ack Vector's compressibility 2842 without providing much extra protection.) 2844 Consider a half-connection from DCCP A to DCCP B. DCCP A SHOULD set 2845 ECN Nonces on its packets, and remember which packets had nonces, 2846 whenever DCCP B reports that it is ECN Capable. An ECN-capable 2847 endpoint MUST calculate and use the correct value for ECN Nonce Echo 2848 when sending acknowledgement options. An ECN-incapable endpoint, 2849 however, SHOULD treat the ECN Nonce Echo as always zero. When a 2850 sender detects an ECN Nonce Echo mismatch, it SHOULD behave as if 2851 the receiver had reported one or more packets as ECN-marked (instead 2852 of unmarked). It MAY take more punitive action, such as resetting 2853 the connection. The Reason for such DCCP-Reset packets SHOULD be set 2854 to "Aggression Penalty". 2856 An ECN-incapable DCCP SHOULD ignore received ECN nonces and generate 2857 ECN nonces of zero. For instance, out of the two Ack Vector options, 2858 an ECN-incapable DCCP SHOULD generate Ack Vector [Nonce 0] (option 2859 37) exclusively. (Again, the ECN Capable feature MUST be set to zero 2860 in this case.) 2862 9.3. Other Aggression Penalties 2864 The ECN Nonce provides one way for a DCCP sender to discover that a 2865 receiver is misbehaving. There may be other mechanisms, and a 2866 receiver or middlebox may also discover that a sender is 2867 misbehaving---sending more data than it should. In any of these 2868 cases, the entity that discovers the misbehavior MAY react by 2869 resetting the connection, with Reason set to "Aggression Penalty". A 2870 receiver that detects marginal (meaning possibly spurious) sender 2871 misbehavior MAY instead react with a Slow Receiver option, or by 2872 reporting some packets as ECN marked that were not, in fact, marked. 2874 10. Multihoming and Mobility 2876 DCCP provides primitive support for multihoming and mobility via a 2877 mechanism for transferring a connection endpoint from one address to 2878 another. The moving endpoint must negotiate mobility support 2879 beforehand, and both endpoints must share their Connection Nonces. 2880 When the moving endpoint gets a new address, it sends a DCCP-Move 2881 packet from that address to the stationary endpoint. The stationary 2882 endpoint then changes its connection state to use the new address. 2884 DCCP's support for mobility is intended to solve only the simplest 2885 multihoming and mobility problems. For instance, DCCP has no support 2886 for simultaneous moves. Applications requiring more complex mobility 2887 semantics, or more stringent security guarantees, should use an 2888 existing solution like Mobile IP or [SB00]. 2890 10.1. Mobility Capable Feature 2892 A DCCP uses the Mobility Capable feature to inform its partner that 2893 it would like to be able to change its address and/or port during 2894 the course of the connection. 2896 Mobility Capable has feature number 5. The Mobility Capable feature 2897 located at DCCP A indicates whether or not A will accept a DCCP-Move 2898 packet sent by B. DCCP B sends a "Change(Mobility Capable, 1)" 2899 option to DCCP A to inform it that B might like to move later. 2901 A Mobility Capable feature contains a single byte of data. Mobility 2902 is allowed if and only if this byte is nonzero. A DCCP MUST reject a 2903 DCCP-Move packet referring to a connection when Mobility Capable is 2904 0; however, it MAY reject a valid DCCP-Move packet even when 2905 Mobility Capable is 1. 2907 A new connection starts with Mobility Capable 0 (that is, mobility 2908 is not allowed) for both DCCPs. 2910 10.2. Security 2912 The DCCP mobility mechanism, like DCCP in general, does not provide 2913 cryptographic security guarantees. Nevertheless, mobile hosts must 2914 use valid sequence numbers and include valid Identifications in 2915 their DCCP-Move packets, providing protection against some classes 2916 of attackers. Specifically, an attacker cannot move a DCCP 2917 connection to a new address unless they know valid sequence numbers 2918 and how to generate valid Identifications. Even with the default MD5 2919 Identification Regime, this means that an attacker must have snooped 2920 on every packet in the connection to get a reasonable probability of 2921 success, assuming that initial sequence numbers and Connection 2922 Nonces are chosen well (that is, randomly). Section 16 further 2923 describes DCCP security considerations. 2925 10.3. Congestion Control State 2927 Once an endpoint has transitioned to a new address, the connection 2928 is effectively a new connection in terms of its congestion control 2929 state: the accumulated information about congestion between the old 2930 endpoints no longer applies. Both DCCPs MUST initialize their 2931 congestion control state (windows, rates, and so forth) to that of a 2932 new connection---that is, they must "slow start"---unless they have 2933 high-quality information about actual network conditions between the 2934 two new endpoints. Normally, the only way to get this information 2935 would be by running a DCCP connection between the new addresses. 2937 Similarly, the endpoints' configured MTUs (see 11) SHOULD be 2938 reinitialized, and PMTU discovery performed again, following an 2939 address change. 2941 10.4. Loss During Transition 2943 Several loss and delay events may affect the transition of a DCCP 2944 connection from one address to another. The DCCP-Move packet itself 2945 might be lost; the acknowledgement to that packet might be lost, 2946 leaving the mobile endpoint unsure of whether the transition has 2947 completed; and data from the old endpoint might continue to arrive 2948 at the receiver even after the transition. 2950 To protect against lost DCCP-Move packets, the mobile host SHOULD 2951 retransmit a DCCP-Move packet if it does not receive an 2952 acknowledgement within a reasonable time period. Section 5.9 2953 describes the mechanism used to protect against duplicate DCCP-Move 2954 packets. 2956 A receiver MAY drop all data received from the old address/port pair 2957 once a DCCP-Move has successfully completed. Alternately, it MAY 2958 accept one Loss Window's worth of this data. Congestion and loss 2959 events on this data SHOULD NOT affect the new connection's 2960 congestion control state. The receiver MUST NOT accept data with the 2961 old address/port pair past one Loss Window, and SHOULD send DCCP- 2962 Resets in response to those packets. 2964 During some transition period, acknowledgements from the receiver to 2965 the mobile host will contain information about packets sent both 2966 from the old address/port pair, and from the new address/port pair. 2967 The mobile DCCP should not let loss events on packets from the old 2968 address/port pair affect the new congestion control state. 2970 11. Maximum Transfer Unit 2972 A DCCP implementation MUST maintain its idea of the current maximum 2973 transfer unit (MTU) for each active DCCP session. The particular MTU 2974 may be influenced by congestion control mechanisms, as well as Path 2975 MTU (PMTU) discovery [RFC 1191]. 2977 Any API to DCCP MUST allow the application to discover DCCP's 2978 current MTU. DCCP applications SHOULD use the API to discover the 2979 MTU, and SHOULD NOT send datagrams that are greater than the MTU. A 2980 DCCP API MAY choose to let applications indicate that large packets 2981 should be fragmented; if an application not using that API tries to 2982 send a packet bigger than the MTU, the DCCP implementation MUST drop 2983 the packet and return an appropriate error. 2985 The PMTU SHOULD be initialized from the interface MTU that will be 2986 used to send packets. The MTU will be initialized with the minimum 2987 of the PMTU and any MTU set by the relevant CCID. 2989 To perform PMTU discovery, the DCCP sender sets the IP Don't 2990 Fragment (DF) bit. However, it is undersirable for MTU discovery to 2991 occur on the initial connection setup handshake, as the connection 2992 setup process may not be representative of packet sizes used during 2993 the connection, and performing MTU discovery on the initial 2994 handshake might unnecessarily delay connection establishment. Thus, 2995 DF SHOULD NOT be set on DCCP-Request and DCCP-Response packets. In 2996 addition DF SHOULD NOT be set on DCCP-Reset packets, although 2997 typically these would be small enough to not be a problem. On all 2998 other DCCP packets, DF SHOULD be set. 3000 As specified in [RFC 1191], when a router receives a packet with DF 3001 set that is larger than the PMTU, it sends an ICMP Destination 3002 Unreachable message to the source of the datagram with the Code 3003 indicating "fragmentation needed and DF set" (also known as a 3004 "Datagram Too Big" message). When a DCCP implementation receives a 3005 Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU 3006 value given in the ICMP message. If the MTU given in the message is 3007 zero, the sender chooses a value for PMTU using the algorithm 3008 described in Section 7 of [RFC 1191]. If the MTU given in the 3009 message is greater than the current PMTU, the Datagram Too Big 3010 message is ignored, as described in [RFC 1191]. (We are aware that 3011 this may cause problems for DCCP endpoints behind certain 3012 firewalls.) 3014 If the DCCP implementation has decreased the PMTU, and the sending 3015 application attempts to send a packet larger than the new MTU, the 3016 API MUST cause the send to fail returning an appropriate error to 3017 the application, and the application SHOULD then use the API to 3018 query the new value of the PMTU. When this occurs, it is possible 3019 that the kernel has some packets buffered for transmission that are 3020 smaller than the old PMTU, but larger than the new PMTU. The kernel 3021 MAY send these packets with the DF bit cleared, or it MAY discard 3022 these packets; it MUST NOT transmit these datagrams with the DF bit 3023 set. 3025 DCCP currently provides no way to increase the PMTU once it has 3026 decreased. 3028 A DCCP sender MAY optionally treat the reception of an ICMP Datagram 3029 Too Big message as an indication that the packet being reported was 3030 not lost due congestion, and so for the purposes of congestion 3031 control it MAY ignore the DCCP receiver's indication that this 3032 packet did not arrive. However, if this is done, then the DCCP 3033 sender MUST check the ECN bits of the IP header echoed in the ICMP 3034 message, and only perform this optimization if these ECN bits 3035 indicate that the packet did not experience congestion prior to 3036 reaching the router whose MTU it exceeded. 3038 12. Middlebox Considerations 3040 This section describes properties of DCCP that firewalls, network 3041 address translators, and other middleboxes should consider, 3042 including parts of the packet that middleboxes should not change. 3043 The intent is to draw attention to aspects of DCCP that may be 3044 useful, or dangerous, for middleboxes, or that differ significantly 3045 from TCP. 3047 The Service Name field in DCCP-Request packets provide information 3048 that may be useful for stateful middleboxes. With Service Name, a 3049 middlebox can tell what protocol a connection will use, without 3050 relying on port numbers. Middleboxes MAY disallow attempted 3051 connections with zero Service Names by sending a DCCP-Reset. 3052 Middleboxes SHOULD NOT modify the Service Name. 3054 The Source and Destination Port fields are in the same packet 3055 locations as the corresponding fields in TCP and UDP, which may 3056 simplify some middlebox implementations. 3058 Middleboxes MUST NOT modify DCCP packets' Sequence Number, 3059 Acknowledgement Number, and # NDP fields in order to add or remove 3060 packets from a packet stream. Any such modification would affect the 3061 endpoints' accounting of which packets have been lost, destroy the 3062 Identification mechanism, and confuse the congestion control 3063 mechanisms in use. Note that there is less need to modify DCCP's 3064 per-packet sequence numbers than TCP's per-byte sequence numbers; 3065 for example, a middlebox can change the contents of a packet without 3066 changing its sequence number. (In TCP, sequence number modification 3067 is required to support protocols like FTP that carry variable-length 3068 addresses in the data stream. If such an application were deployed 3069 over DCCP, middleboxes would simply grow or shrink the relevant 3070 packets as necessary, without changing their sequence numbers.) 3072 The exception to this rule is that middleboxes MAY reset connections 3073 in progress. Clearly this requires inserting a packet into one or 3074 both packet streams, as well as dropping all later packets on the 3075 connection. 3077 This does not explicitly prevent one sequence number modification 3078 occasionally seen with TCP, namely proxies with "connection 3079 splicing" [SHHP00]. Such proxies intercept TCP connection attempts 3080 from a client, but may later "splice" data from an external server 3081 connection into that client connection via sequence number 3082 manipulations. Packets are not added to or removed from the spliced- 3083 in stream, reducing the sequence number issues somewhat. 3084 Nevertheless, DCCP, with its extensive end-to-end feature 3085 negotiation, is inherently unfriendly to the idea of connection 3086 splicing: the proxy would have to ensure that the server chose the 3087 same feature values that the proxy had previously negotiated with 3088 the client. Furthermore, Identification options would require 3089 special handling; and there may be other issues. We suggest that 3090 DCCP splicing, if implemented, should take place at the application 3091 level. 3093 A middlebox that wants to trivially support the MD5 Identification 3094 Regime (Section 6.4.3) MUST NOT alter packets' Sequence Number, 3095 Type, CCval, Acknowledgement Number, and Reserved fields, or the 3096 Connection Nonce feature values, which are included in the MD5 hash 3097 sent with Identification and Challenge options. 3099 The contents of this section SHOULD NOT be interpreted as a 3100 wholesale endorsement of stateful middleboxes. 3102 13. Abstract API 3104 API issues for DCCP are discussed in another Internet-Draft, in 3105 progress. 3107 14. Multiplexing Issues 3109 In contrast to TCP, DCCP does not offer reliable ordered delivery. 3110 As a consequence, with DCCP there are no inherent performance 3111 penalties in layering functionality above DCCP to multiplex several 3112 sub-flows into a single DCCP connection. 3114 If it is desired to share congestion control state among multiple 3115 DCCP flows that share the same source and destination addresses, the 3116 possibilities are to add DCCP-specific mechanisms to enable this, or 3117 to use a generic multiplexing facility like the Congestion Manager 3118 [RFC 3124] residing below the transport layer. For some DCCP flows, 3119 the ability to specify the congestion control mechanism might be 3120 critical, and for these flows the Congestion Manager will only be a 3121 viable tool if it allows DCCP to specify the congestion control 3122 mechanism used by the Congestion Manager for that flow. Thus, to 3123 allow the sharing of congestion control state among multiple DCCP 3124 flows, the alternatives seem to be to add DCCP-specific 3125 functionality to the Congestion Manager, or to add a similar layer 3126 below DCCP that is specific to DCCP. We defer issues of DCCP 3127 operating over a revised version of the Congestion Manager, or over 3128 a DCCP-specific module for the sharing of congestion control state, 3129 to later work. 3131 15. DCCP and RTP 3133 The real-time transport protocol, RTP [RFC 1889], is currently used 3134 (over UDP) by many of DCCP's target applications (for instance, 3135 streaming media). This section therefore discusses the relationship 3136 between DCCP and RTP, and in particular, the question of whether any 3137 changes in RTP are necessary or desirable when it is layered over 3138 DCCP instead of UDP. The main issue here is header size: a DCCP 3139 header is at least 4 bytes larger than a UDP header. 3141 There are two potential sources of overhead in the RTP-over-DCCP 3142 combination, duplicated acknowledgement information and duplicated 3143 sequence numbers. We argue that together, these sources of overhead 3144 add just 4 bytes per packet relative to RTP-over-UDP, and that 3145 eliminating the redundancy would not reduce the overhead. However, 3146 particular CCIDs might make productive use of the space occupied by 3147 RTP's sequence number. 3149 First, consider acknowledgements. The information on packet loss 3150 that RTP communicates via RTCP SR/RR packets is communicated by DCCP 3151 via acknowledgement options. Much of the information in an RTCP 3152 receiver report could be divined from DCCP acknowledgements, 3153 depending on the CCID in use. Acknowledgement options, such as Ack 3154 Vector, can be frequent and verbose, whereas RTCP reports are sent 3155 only rarely, with a minimum interval of 5 seconds between reports 3156 [RFC 1889]. 3158 However, not all CCIDs require such verbose acknowledgements. CCID 3 3159 (TFRC) reports acknowledgements at a low rate---between 16 and 32 3160 bytes of options (depending on ECN usage), sent once per round trip 3161 time. This is not an undue burden. Furthermore, the options are 3162 necessary to implement responsive congestion control, and we cannot 3163 report less frequently, although we might design alternative 3164 acknowledgement options that take fewer bytes. DCCP gives the 3165 application the trade off between small packet overhead and the 3166 precise feedback provided by Ack Vector. 3168 While RTP receiver reports might be considered "redundant" in the 3169 presence of DCCP's more precise acknowledgements, they are sent so 3170 infrequently that it is not worth optimizing them away. Also, note 3171 that in the common case of a one-way data stream, acknowledgement 3172 packets contain no data, so acknowledgement header size (as distinct 3173 from congestion on the acknowledgement path) is not an issue. 3175 We now consider sequence number redundancy on data packets. The 3176 embedded RTP header contains a 16-bit RTP sequence number. Most data 3177 packets will use the DCCP-Data type; DCCP-DataAck and DCCP-Ack 3178 packets need not usually be sent. The DCCP-Data header is 12 bytes 3179 long without options, including a 24-bit sequence number. This is 4 3180 bytes more than a UDP header. Any options required on data packets 3181 would add further overhead, although many CCIDs (for instance, CCID 3182 3 [TFRC]) don't require options on most data packets. 3184 The DCCP sequence number cannot be inferred from the RTP sequence 3185 number since it increments on non-data packets as well as data 3186 packets. The RTP sequence number could be inferred from the DCCP 3187 sequence number, though; it might equal the DCCP sequence number 3188 minus the total number of non-data packets seen so far in the 3189 connection (as tracked by DCCP's # NDP header field). 3191 Removing RTP's sequence number would not save any header space 3192 because of alignment issues. However, particular DCCP CCIDs might 3193 make use of the 16 bits occupied by the RTP sequence number. 3194 Therefore, particular DCCP CCIDs MAY provide optional CCID-specific 3195 features that store DCCP quantities in place of the embedded RTP 3196 sequence number. A conforming DCCP would write in the calculated RTP 3197 sequence number before passing the packet to RTP. (The DCCP checksum 3198 would use the DCCP quantity, not the RTP sequence number.) 3200 Given RTP-over-DCCP's small overhead, however, implementors 3201 demanding tiny headers will probably prefer more comprehensive 3202 header compression to this ad-hoc compression technique. 3204 16. Security Considerations 3206 DCCP does not provide cryptographic security guarantees. 3207 Applications desiring hard security should use IPsec or end-to-end 3208 security of some kind. 3210 Nevertheless, DCCP is intended to protect against some classes of 3211 attackers. Attackers cannot hijack a DCCP connection (close the 3212 connection unexpectedly, or cause attacker data to be accepted by an 3213 endpoint as if it came from the sender) unless they can guess valid 3214 sequence numbers. Thus, as long as endpoints choose initial sequence 3215 numbers well, a DCCP attacker must snoop on data packets to get any 3216 reasonable probability of success. The sequence number validity 3217 (Section 5.2), Identification (Section 6.4.3), and mobility (Section 3218 10) mechanisms provide this guarantee. We also avoid leaking 3219 sequence numbers to possibly malicious endpoints. For instance, this 3220 is why invalid DCCP-Moves are ignored, rather than reset. 3222 17. IANA Considerations 3224 DCCP introduces six sets of numbers whose values should be allocated 3225 by IANA. 3227 o 32-bit Service Names (Section 5.4; not exclusive to DCCP). 3229 o 8-bit DCCP-Reset Reasons (Section 5.8). 3231 o 8-bit DCCP Option Types (Section 6). The CCID-specific options 128 3232 through 255 need not be allocated by IANA. 3234 o 8-bit DCCP Feature Numbers (Section 6.3). The CCID-specific 3235 features 128 through 255 need not be allocated by IANA. 3237 o 8-bit DCCP Congestion Control Identifiers (CCIDs) (Section 7). 3239 o 16-bit Identification Regimes, for use with DCCP Identification 3240 and Challenge options (Section 6.4). 3242 In addition, DCCP requires a Protocol Number to be added to the 3243 registry of Assigned Internet Protocol Numbers. Experimental 3244 implementors should use Protocol Number 33 for DCCP, but this number 3245 may change in future. 3247 18. Design Motivation 3249 In the section we attempt to capture some of the rationale behind 3250 specific details of DCCP design. 3252 18.1. CSlen and Partial Checksumming 3254 A great deal of discussion has taken place regarding the utility of 3255 allowing a DCCP sender to restrict the checksum so that it does not 3256 cover the complete packet. 3258 Many of the applications that we envisage using DCCP are resilient 3259 to some degree of data loss, or they would typically have chosen a 3260 reliable transport. Some of these applications may also be 3261 resilient to data corruption---some audio payloads, for example. 3262 These resilient applications might prefer to receive corrupted data 3263 than to have DCCP drop a corrupted packet. This is particularly 3264 because of congestion control: DCCP cannot tell the difference 3265 between packets dropped due to corruption and packets dropped due to 3266 congestion, and so it must reduce the transmission rate accordingly. 3267 This response may cause the connection to receive less bandwidth 3268 than it is due; corruption in some networking technologies is 3269 independent of, or at least not always correlated to, congestion. 3270 Therefore, corrupted packets do not need to cause as strong a 3271 reduction in transmission rate as the congestion response would 3272 dictate (so long as the DCCP header and options are not corrupt). 3274 Thus DCCP allows the checksum to cover all of the packet, just the 3275 DCCP header, or both the DCCP header and some number of bytes from 3276 the payload. If the application cannot tolerate any payload 3277 corruption, then the checksum SHOULD cover the whole packet. If the 3278 application would prefer to tolerate some corruption rather than 3279 have the packet dropped, then it can set the checksum to cover only 3280 part of the packet (but always the DCCP header). In addition, if 3281 the application wishes to decouple checksumming of the DCCP header 3282 from checksumming of the payload, it may do so by including the 3283 Payload Checksum option. This would allow payload corruption to 3284 cause DCCP to discard a corrupted payload, but still not mistake the 3285 corruption for network congestion. 3287 Thus, from the application point of view, partial checksums seem to 3288 be a desirable feature. However, the usefulness of partial 3289 checksums depends on partially corrupted packets being delivered to 3290 the receiver. If the link-layer CRC always discards corrupted 3291 packets, then this will not happen, and so the usefulness of partial 3292 checksums would be restricted to corruption that occurred in routers 3293 and other places not covered by link CRCs. There does not appear to 3294 be consensus on how likely it is that future network links that 3295 suffer significant corruption will not cover the entire packet with 3296 a single strong CRC. DCCP makes it possible to tailor such links to 3297 the application, but it is difficult to predict if this will be 3298 compelling for future link technologies. 3300 In addition, partial checksums do not co-exist well with IP-level 3301 authentication mechanisms such as IPsec AH, which cover the entire 3302 packet with a cryptographic hash. Thus, if cryptographic 3303 authentication mechanisms are required to co-exist with partial 3304 checksums, the authentication must be carried in the DCCP payload. 3305 A possible mode of usage would appear to be similar to that of 3306 Secure RTP. However, such "application-level" authentication does 3307 not protect the DCCP option negotiation and state machine from 3308 forged packets. An alternative would be to use IPsec ESP, and use 3309 encryption to protect the DCCP headers against attack, while using 3310 the DCCP header validity checks to authenticate that the header is 3311 from someone who possessed the correct key. However, while this is 3312 resistant to replay (due to the DCCP sequence number), it is not by 3313 itself resistant to some forms of man-in-the-middle attacks because 3314 the payload is not tightly coupled to the packet header. Thus an 3315 application-level authentication probably needs to be coupled with 3316 IPsec ESP or a similar mechanism to provide a reasonably complete 3317 security solution. The overhead of such a solution might be 3318 unacceptable for some applications that would otherwise wish to use 3319 partial checksums. 3321 On balance, the authors believe that DCCP partial checksums have the 3322 potential to enable some future uses that would otherwise be 3323 difficult. As the cost and complexity of supporting them is small, 3324 it seems worth including them at this time. It remains to be seen 3325 whether they are useful in practice. 3327 19. Thanks 3329 There is a wealth of work in this area, including the Congestion 3330 Manager. We thank the staff and interns of ICIR and, formerly, 3331 ACIRI, the members of the End-to-End Research Group, and the members 3332 of the Transport Area Working Group for their feedback on DCCP. We 3333 also thank those who provided comments and suggestions via the DCCP 3334 BOF, Working Group, and mailing lists, including Damon Lanphear, 3335 Patrick McManus, Sara Karlberg, Kevin Lai, Youngsoo Choi, Dan 3336 Duchamp, Derek Fawcus, David Timothy Fleeman, John Loughney, 3337 Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, Yufei Wang, and 3338 Michael Welzl. 3340 20. Normative References 3342 [RFC 793] J. Postel, editor. Transmission Control Protocol. RFC 793. 3344 [RFC 1191] J. C. Mogul and S. E. Deering. Path MTU Discovery. RFC 3345 1191. 3347 [RFC 2026] S. Bradner. The Internet Standards Process---Revision 3. 3348 RFC 2026. 3350 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 3351 Requirement Levels. RFC 2119. 3353 [RFC 2460] S. Deering and R. Hinden. Internet Protocol, Version 6 3354 (IPv6) Specification. RFC 2460. 3356 [RFC 3168] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition 3357 of Explicit Congestion Notification (ECN) to IP. RFC 3168. 3358 September 2001. 3360 21. Informative References 3362 [CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP Congestion 3363 Control ID 2: TCP-like Congestion Control. draft-ietf-dccp- 3364 ccid2-01.txt, work in progress, March 2003. 3366 [CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for 3367 DCCP Congestion Control ID 3: TFRC Congestion Control. draft- 3368 ietf-dccp-ccid3-01.txt, work in progress, March 2003. 3370 [ECN NONCE] David Wetherall, David Ely, and Neil Spring. Robust ECN 3371 Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-04.txt, work 3372 in progress, October 2002. 3374 [RFC 1889] Audio-Video Transport Working Group, H. Schulzrinne, S. 3375 Casner, R. Frederick, and V. Jacobson. RTP: A Transport 3376 Protocol for Real-Time Applications. RFC 1889. 3378 [RFC 1948] S. Bellovin. Defending Against Sequence Number Attacks. 3379 RFC 1948. 3381 [RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 3382 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. 3383 Paxson. Stream Control Transmission Protocol. RFC 2960. 3385 [RFC 3124] H. Balakrishnan and S. Seshan. The Congestion Manager. 3386 RFC 3124. 3388 [SB00] Alex C. Snoeren and Hari Balakrishnan. An End-to-End Approach 3389 to Host Mobility. Proc. 6th Annual ACM/IEEE International 3390 Conference on Mobile Computing and Networking (MOBICOM '00), 3391 August 2000. 3393 [SHHP00] Oliver Spatscheck, Jorgen S. Hansen, John H. Hartman, and 3394 Larry L. Peterson. Optimizing TCP Forwarder Performance. 3395 IEEE/ACM Transactions on Networking 8(2):146-157, April 2000. 3397 [SYNCOOKIES] Daniel J. Bernstein. SYN Cookies. 3398 http://cr.yp.to/syncookies.html 3400 [UDP-LITE] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson 3401 (editor), and G. Fairhurst (editor). The UDP-Lite Protocol. 3402 draft-ietf-tsvwg-udp-lite-01.txt, work in progress, December 3403 2002. 3405 22. Authors' Addresses 3407 Eddie Kohler 3408 Mark Handley 3409 Sally Floyd 3411 ICSI Center for Internet Research 3412 1947 Center Street, Suite 600 3413 Berkeley, CA 94704 USA 3415 Jitendra Padhye 3417 Microsoft Research 3418 One Microsoft Way 3419 Redmond, WA 98052 USA 3421 23. Appendix: Ack Vector Implementation Notes 3423 This appendix discusses particulars of DCCP acknowledgement 3424 handling, in the context of an abstract implementation for Ack 3425 Vector. It is informative rather than normative. 3427 The first part of our implementation runs at the HC-Receiver, and 3428 therefore acknowledges data packets. It generates Ack Vector 3429 options. The implementation has the following characteristics: 3431 o At most one byte of state per acknowledged packet. 3433 o O(1) time to update that state when a new packet arrives (normal 3434 case). 3436 o Cumulative acknowledgements. 3438 o Quick removal of old state. 3440 The basic data structure is a circular buffer containing information 3441 about acknowledged packets. Each byte in this buffer contains a 3442 state and run length; the state can be 0 (packet received), 1 3443 (packet ECN marked), or 3 (packet not yet received). The live 3444 portion of the buffer is marked off by head and tail pointers, each 3445 marked with the HC-Sender sequence number to which it corresponds. 3447 The buffer also stores a single-bit ECN Nonce Echo, which equals the 3448 one-bit sum of the ECN Nonces received on state-0 packets. The 3449 buffer grows from right to left. For example: 3451 +-------------------------------------------------------------------+ 3452 |S,L|S,L|S,L|S,L| | | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| 3453 +-------------------------------------------------------------------+ 3454 ^ ^ 3455 Tail, seqno = T Head, seqno = H ECN Nonce Echo = E 3457 <=== Head and Tail move this way <=== 3459 Each `S,L' represents a State/Run length byte. We will draw these 3460 buffers showing only their live portion; for example, here is 3461 another representation for the buffer above: 3463 +-----------------------------------------------+ 3464 H |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T ENE[E] 3465 +-----------------------------------------------+ 3467 This smaller Example Buffer contains actual data. 3469 +---------------------------+ 3470 10 |0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 ENE[1] [Example Buffer] 3471 +---------------------------+ 3473 In concrete terms, its meaning is as follows: 3475 Packet 10 was received. (The head of the buffer has sequence 3476 number 10, state 0, and run length 0.) 3478 Packets 9, 8, and 7 have not yet been received. (The three bytes 3479 preceding the head each have state 3 and run length 0.) 3481 Packets 6, 5, 4, 3, and 2 were received. 3483 Packet 1 was ECN marked. 3485 Packet 0 was received. 3487 The one-bit sum of the ECN Nonces on packets 10, 6, 5, 4, 3, 2, 3488 and 0 equals 1. 3490 23.1. New Packets 3492 When a packet arrives whose sequence number is larger than any in 3493 the buffer, the HC-Receiver simply moves the Head pointer to the 3494 left, increases the head sequence number, and stores a byte 3495 representing the packet into the buffer. For example, if HC-Sender 3496 packet 11 arrived ECN marked, the Example Buffer above would enter 3497 this new state (the change is marked with stars): 3499 +***----------------------------+ 3500 11 |1,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 ENE[1] 3501 +***----------------------------+ 3503 If the packet's state equals the state at the head of the buffer, 3504 the HC-Receiver may choose to increment its run length (up to the 3505 maximum). For example, if HC-Sender packet 11 arrived without ECN 3506 marking and with ECN Nonce 0, the Example Buffer might enter this 3507 state instead: 3509 +--*------------------------+ 3510 11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 ENE[1] 3511 +--*------------------------+ 3513 Of course, the new packet's sequence number might not equal the 3514 expected sequence number. In this case, the HC-Receiver should enter 3515 the intervening packets as State 3. If several packets are missing, 3516 the HC-Receiver may prefer to enter multiple bytes with run length 3517 0, rather than a single byte with a larger run length; this 3518 simplifies table updates when one of the missing packets arrives. 3519 For example, if HC-Sender packet 12 arrived with ECN Nonce 1, the 3520 Example Buffer would enter this state: 3522 +*******----------------------------+ * 3523 12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 ENE[0] 3524 +*******----------------------------+ * 3526 When a new packet's sequence number is less than the head sequence 3527 number, the HC-Receiver should scan the table for the byte 3528 corresponding to that sequence number. (Slightly more complex 3529 indexing structures could reduce the complexity of this scan.) 3530 Assume that the sequence number was previously lost (State 3), and 3531 that it was stored in a byte with run length 0. Then the HC-Receiver 3532 can simply change the byte's state. For example, if HC-Sender packet 3533 8 was received with ECN Nonce 0, the Example Buffer would enter this 3534 state: 3536 +--------*------------------+ 3537 10 |0,0|3,0|0,0|3,0|0,4|1,0|0,0| 0 ENE[1] 3538 +--------*------------------+ 3540 If the packet is not marked as lost, or if its sequence number is 3541 not contained in the table, the packet is probably a duplicate, and 3542 should be ignored. (The new packet's ECN marking state might differ 3543 from the state in the buffer; Section 8.5.1 describes what to do 3544 then.) If the packet's corresponding buffer byte has a non-zero run 3545 length, then the buffer might need be reshuffled to make space for 3546 one or two new bytes. 3548 Of course, the circular buffer may overflow, either when the HC- 3549 Sender is sending data at a very high rate, when the HC-Receiver's 3550 acknowledgements are not reaching the HC-Sender, or when the HC- 3551 Sender is forgetting to acknowledge those acks (so the HC-Receiver 3552 is unable to clean up old state). In this case, the HC-Receiver 3553 should either compress the buffer, transfer its state to a larger 3554 buffer, or drop all received packets, without processing them 3555 whatsoever, until its buffer shrinks again. 3557 23.2. Sending Acknowledgements 3559 Whenever the HC-Receiver needs to generate an acknowledgement, the 3560 buffer's contents can simply be copied into one or more Ack Vector 3561 options. Copied Ack Vectors might not be maximally compressed; for 3562 example, the Example Buffer above contains three adjacent 3,0 bytes 3563 that could be combined into a single 3,2 byte. The HC-Receiver 3564 might, therefore, choose to compress the buffer in place before 3565 sending the option, or to compress the buffer while copying it; 3566 either operation is simple. 3568 Every acknowledgement sent by the HC-Receiver SHOULD include the 3569 entire state of the buffer. That is, acknowledgements are 3570 cumulative. 3572 The HC-Receiver should store information about each acknowledgement 3573 it sends in another buffer. Specifically, for every acknowledgement 3574 it sends, the HC-Receiver should store: 3576 o The HC-Receiver sequence number it used for the ack packet. 3578 o The HC-Sender sequence number it acknowledged (that is, the 3579 packet's Acknowledgement Number). Since acknowledgements are 3580 cumulative, this single number completely specifies the set of HC- 3581 Sender packets acknowledged by this ack packet. 3583 23.3. Clearing State 3585 Some of the HC-Sender's packets will include acknowledgement 3586 numbers, which ack the HC-Receiver's acknowledgements. When such an 3587 ack is received, the HC-Receiver simply finds the HC-Sender sequence 3588 number corresponding to that acked HC-Receiver packet, and moves the 3589 buffer's Tail pointer up to that sequence number. (It may choose to 3590 keep some older information, in case a lost packet shows up late.) 3591 For example, say that the HC-Receiver storing the Example Buffer had 3592 sent two acknowledgements already: 3594 (1) HC-Receiver Ack 59 acknowledged HC-Sender Seq 3 with ECN Nonce 3595 Echo 1. 3597 (2) HC-Receiver Ack 60 acknowledged HC-Sender Seq 10 with ECN Nonce 3598 Echo 0. 3600 Say the HC-Receiver then received a DCCP-DataAck packet from the HC- 3601 Sender with Acknowledgement Number 59. This informs the HC-Receiver 3602 that the HC-Sender received, and processed, all the information in 3603 HC-Receiver packet 59. This packet acknowledged HC-Sender packet 3, 3604 so the HC-Sender has now received HC-Receiver's acknowledgements for 3605 packets 0, 1, 2, and 3. The Example Buffer should enter this state: 3607 +------------------*+ * * 3608 10 |0,0|3,0|3,0|3,0|0,2| 4 ENE[0] 3609 +------------------*+ * * 3611 The tail byte's run length was adjusted, since packet 3 was in the 3612 middle of that byte. The new ECN Nonce Echo field equals the 3613 exclusive-or of the old field, and the ECN Nonce Echo reported with 3614 the relevant acknowledgement. The HC-Receiver can also throw away 3615 stored information about HC-Receiver Ack 59. 3617 A careful implementation might try to ensure reasonable robustness 3618 to reordering. Suppose that the Example Buffer is as before, but 3619 that packet 9 now arrives, out of sequence. The buffer would enter 3620 this state: 3622 +----*----------------------+ 3623 10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0 ENE[1] 3624 +----*----------------------+ 3626 The danger is that the HC-Sender might acknowledge the P2's previous 3627 acknowledgement (with sequence number 60), which says that Packet 9 3628 was not received, before the HC-Receiver has a chance to send a new 3629 acknowledgement saying that Packet 9 actually was received. 3631 Therefore, when packet 9 arrived, the HC-Receiver might modify its 3632 acknowledgement record to: 3634 (1) HC-Receiver Ack 59 acknowledged HC-Sender Seq 3 with ECN Nonce 3635 Echo 1. 3637 (2) HC-Receiver Ack 60 also acknowledged HC-Sender Seq 3 with ECN 3638 Nonce Echo 1. 3640 That is, Ack 60 is now treated like a duplicate of Ack 59. This 3641 would prevent the Tail pointer from moving past packet 9 until the 3642 HC-Receiver knows that the HC-Sender has seen an Ack Vector 3643 indicating that packet's arrival. 3645 23.4. Processing Acknowledgements 3647 When the HC-Sender receives an acknowledgement, it generally cares 3648 about the number of packets that were dropped and/or ECN marked. It 3649 simply reads this off the Ack Vector. Additionally, it may check the 3650 ECN Nonce for correctness. (As described in Section 8.5.1, it may 3651 want to keep more detailed information about acknowledged packets in 3652 case packets change states between acknowledgements, or in case the 3653 application queries whether a packet arrived.) 3655 The HC-Sender must also acknowledge the HC-Receiver's 3656 acknowledgements so that the HC-Receiver can free old Ack Vector 3657 state. (Since Ack Vector acknowledgements are reliable, the HC- 3658 Receiver must maintain and resend Ack Vector information until it is 3659 sure that the HC-Sender has received that information.) A simple 3660 algorithm suffices: since Ack Vector acknowledgements are 3661 cumulative, a single acknowledgement number tells HC-Receiver how 3662 much ack information has arrived. Assuming that the HC-Receiver 3663 sends no data, the HC-Sender can simply ensure that at least once a 3664 round-trip time, it sends a DCCP-DataAck packet acknowledging the 3665 latest DCCP-Ack packet it has received. Of course, the HC-Sender 3666 only needs to acknowledge the HC-Receiver's acknowledgements if the 3667 HC-Sender is also sending data. If the HC-Sender is not sending 3668 data, then the HC-Receiver's Ack Vector state is stable, and there 3669 is no need to shrink it. The HC-Sender must watch for drops and ECN 3670 marks on received DCCP-Ack packets so that it can adjust the HC- 3671 Receiver's ack-sending rate---for example, with Ack Ratio---in 3672 response to congestion. 3674 If the other half-connection is not quiescent---that is, the HC- 3675 Receiver is sending data to the HC-Sender, possibly using another 3676 CCID---then the acknowledgements on that half-connection are 3677 sufficient for the HC-Receiver to free its state.