@@ Page 5 @@ The TCP-like Congestion Control CCID sends data using a close variant of TCP's congestion control mechanisms, incorporating - selective acknowledgements (SACK) [RFC 2018] [RFC 3517]. CCID 2 is + selective acknowledgements (SACK) [RFC 2018, RFC 3517]. CCID 2 is suitable for senders who can adapt to the abrupt changes in congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control, and particularly useful for @@ Page 5 @@ 2. Conventions and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC 2119. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. A DCCP half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other @@ Page 5 @@ receivers send DCCP-Ack packets. Both of these categories are meant to include DCCP-DataAck packets. + The phrases "ECN-marked" and "marked" refer to packets marked ECN + Congestion Experienced unless otherwise noted. 3. Usage @@ Page 6 @@ The congestion control mechanisms described here closely follow mechanisms standardized by the IETF for use in SACK-based TCP, and - we rely partially on existing TCP documentation, such as [RFC 793], - [RFC 2581], [RFC 3465], and [RFC 3517]. TCP congestion control - continues to evolve, but CCID 2 implementations SHOULD wait for - explicit updates to CCID 2 rather than track TCP's evolution - directly. The differences between CCID 2 and straight TCP include: - CCID 2 applies congestion control to acknowledgements, a mechanism - not currently standardized for use in TCP. DCCP is a datagram - protocol, so several parameters whose units are specified in bytes - in TCP, such as the congestion window cwnd, have units of packets in - DCCP. Unreliability also leads to differences from TCP: DCCP never + we rely partially on existing TCP documentation, such as RFC 793, + RFC 2581, RFC 3465, and RFC 3517. TCP congestion control continues + to evolve, but CCID 2 implementations SHOULD wait for explicit + updates to CCID 2 rather than track TCP's evolution directly. The + differences between CCID 2 and straight TCP include: CCID 2 applies + congestion control to acknowledgements, a mechanism not currently + standardized for use in TCP. DCCP is a datagram protocol, so + several parameters whose units are specified in bytes in TCP, such + as the congestion window cwnd, have units of packets in DCCP. + Unreliability also leads to differences from TCP: DCCP never retransmits a packet, so congestion control mechanisms that distinguish retransmissions from new packets have been redesigned for the DCCP context. @@ Page 7 @@ Notification (ECN) capable (the ECN Incapable feature is zero -- the default), each DCCP-Data packet is sent as ECN-Capable with either the ECT(0) or the ECT(1) codepoint set, as described in - [RFC 3540]. + RFC 3540. 2. The receiver sends a DCCP-Ack packet acknowledging the data packets for every Ack Ratio data packets transmitted by the @@ Page 9 @@ packets, such as DCCP-Acks, even though the Ack Vector will contain information about them. - Congestion events, namely one or more packets lost or marked from a - window of data, cause CCID 2 to reduce its congestion window. For - each congestion event, either indicated explicitly as an Ack Vector - State 1 (ECN-marked) acknowledgement or inferred via "duplicate - acknowledgements", cwnd is halved, then ssthresh is set to the new - cwnd. Cwnd is never reduced below one packet. After a timeout, the - slow-start threshold is set to cwnd/2, then cwnd is set to one - packet. When halved, cwnd and ssthresh have their values rounded - down, except that cwnd is never less than one and ssthresh is never - less than two. + Congestion events cause CCID 2 to reduce its congestion window. A + congestion event contains at least one lost or marked packet. As in + TCP, two losses or marks are considered to be part of a single + congestion event when the second packet was sent before the loss or + + + + + + mark of the first packet was detected. As an approximation, a + sender can consider two losses or marks to be part of a single + congestion event when the packets were sent within one RTT estimate + of one another, using an RTT estimate current at the time the + packets were sent. For each congestion event, either indicated + explicitly as an Ack Vector State 1 (ECN-marked) acknowledgement or + inferred via "duplicate acknowledgements", cwnd is halved, then + ssthresh is set to the new cwnd. Cwnd is never reduced below one + packet. After a timeout, the slow-start threshold is set to cwnd/2, + then cwnd is set to one packet. When halved, cwnd and ssthresh have + their values rounded down, except that cwnd is never less than one + and ssthresh is never less than two. When cwnd < ssthresh, meaning that the sender is in slow-start, the congestion window is increased by one packet for every two newly @@ Page 12 @@ options that declare exactly which packets arrived, and whether those packets were ECN-marked. Acknowledgement data in the Ack Vector options SHOULD generally cover the receiver's entire - Acknowledgement Window (Section 11.4.2 of [DCCP]). + Acknowledgement Window; see [DCCP] (Section 11.4.2). CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at which DCCP-Ack packets are generated, thus controlling reverse-path @@ Page 12 @@ just tries to avoid congestion collapse, and to be somewhat better than TCP in the presence of a high packet loss or mark rate on the reverse path. The default Ack Ratio is two, and CCID 2 with this - Ack Ratio behaves like TCP with delayed acks. Section 11.3 of - [DCCP] describes the Ack Ratio in more detail, including its - relationship to acknowledgement pacing and DCCP-DataAck packets. - Section 6.1.1 below describes the sender's detection of lost or - marked acknowledgements, and Section 6.1.2 gives the sender's rules - for changing the Ack Ratio. + Ack Ratio behaves like TCP with delayed acks. [DCCP] (Section 11.3) + describes the Ack Ratio in more detail, including its relationship + to acknowledgement pacing and DCCP-DataAck packets. Section 6.1.1 + below describes the sender's detection of lost or marked + acknowledgements, and Section 6.1.2 gives the sender's rules for + changing the Ack Ratio. 6.1. Congestion Control on Acknowledgements @@ Page 13 @@ consecutive congestion windows of data with no lost or marked DCCP- Ack packets, Ack Ratio is decreased by 1. (See Appendix A for the derivation.) Changes in Ack Ratio are signalled through feature - negotiation; see Section 11.3 of [DCCP]. + negotiation; see [DCCP] (Section 11.3). For a constant congestion window, this gives an Ack sending rate that is roughly TCP-friendly. Of course, cwnd usually varies over @@ Page 14 @@ 6.2.1. Determining Quiescence - This section refers to quiescence in the DCCP sense (see Section - 11.1 of [DCCP]): How does a CCID 2 receiver determine that the - corresponding sender is not sending any data? + This section describes how a CCID 2 receiver determines that the + corresponding sender is not sending any data, and therefore has gone + quiescent. See [DCCP] (Section 11.1) for general information on + quiescence. Let T equal the greater of 0.2 seconds and two round-trip times. (The receiver may know the round-trip time in its role as the sender @@ Page 14 @@ for the other half-connection. If it does not, it should use a - default RTT of 0.2 seconds, as described in Section 3.4 of [DCCP].) + default RTT of 0.2 seconds, as described in [DCCP] (Section 3.4).) Once the sender acknowledges the receiver's Ack Vectors, and the sender has not sent additional data for at least T seconds, the receiver can infer that the sender is quiescent. More precisely, @@ Page 15 @@ CCID 2 supports Explicit Congestion Notification (ECN) [RFC 3168]. The sender will use the ECN Nonce for data packets, and the receiver - will echo those nonces in its Ack Vectors, as specified in Section - 12.2 of [DCCP]. Information about marked packets is also returned + will echo those nonces in its Ack Vectors, as specified in [DCCP] + (Section 12.2). Information about marked packets is also returned in the Ack Vector. Because the information in the Ack Vector is reliably transferred, DCCP does not need the TCP flags of ECN-Echo and Congestion Window Reduced. @@ Page 15 @@ For unmarked data packets, the receiver computes the ECN Nonce Echo - as in [RFC 3540], and returns it as part of its Ack Vector options. + as in RFC 3540, and returns it as part of its Ack Vector options. The sender SHOULD check these ECN Nonce Echoes against the expected values, thus protecting against the accidental or malicious concealment of marked packets. @@ Page 15 @@ 9. Security Considerations Security considerations for DCCP have been discussed in [DCCP], and - security considerations for TCP have been discussed in [RFC 2581]. - [RFC 2581] discusses ways that an attacker could impair the + security considerations for TCP have been discussed in RFC 2581. + + RFC 2581 discusses ways that an attacker could impair the performance of a TCP connection by dropping packets, or by forging extra duplicate acknowledgements or acknowledgements for new data. We are not aware of any new security considerations created by this @@ Page 15 @@ managed by IANA. This assignment is also mentioned in [DCCP]. CCID 2 also introduces three sets of numbers whose values should be - allocated by IANA. We refer to allocation policies, such as - Standards Action, outlined in [RFC 2434], and most registries - reserve some values for experimental and testing use [RFC 3692]. + allocated by IANA, namely CCID 2-specific Reset Codes, option types, + and feature numbers. These ranges will prevent any future + CCID 2-specific allocations from polluting DCCP's corresponding + + + + + + global namespaces; see [DCCP] (Section 10.3). However, this + document makes no particular allocations from any range, except for + experimental and testing use [RFC 3692]. We refer to the Standards + Action policy outlined in RFC 2434. 10.1. Reset Codes @@ Page 16 @@ defining the Reset Code. Reset Codes 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining Reset Codes -- 128-183, 191-247, and 255 -- are currently - reserved, and should be allocated with the IETF Consensus policy, - which requires RFC publication (not necessarily standards-track). + reserved, and should be allocated with the Standards Action policy, + which requires IESG review and approval and standards-track IETF RFC + publication. 10.2. Option Types @@ Page 16 @@ option type. Option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191-247, and 255 -- are currently reserved, and - should be allocated with the IETF Consensus policy, which requires - RFC publication (not necessarily standards-track). + should be allocated with the Standards Action policy, which requires + IESG review and approval and standards-track IETF RFC publication. 10.3. Feature Numbers @@ Page 16 @@ defining the feature number. Feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 128-183, 191-247, and 255 -- are - currently reserved, and should be allocated with the IETF Consensus - policy, which requires RFC publication (not necessarily standards- - track). + currently reserved, and should be allocated with the Standards + Action policy, which requires IESG review and approval and + standards-track IETF RFC publication. 11. Thanks