From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4341.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc4341.txt (limited to 'doc/rfc/rfc4341.txt') diff --git a/doc/rfc/rfc4341.txt b/doc/rfc/rfc4341.txt new file mode 100644 index 0000000..e37b7f9 --- /dev/null +++ b/doc/rfc/rfc4341.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group S. Floyd +Request for Comments: 4341 ICIR +Category: Standards Track E. Kohler + UCLA + March 2006 + + + Profile for Datagram Congestion Control Protocol (DCCP) + Congestion Control ID 2: TCP-like Congestion Control + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document contains the profile for Congestion Control Identifier + 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion + Control Protocol (DCCP). CCID 2 should be used by senders who would + like to take advantage of the available bandwidth in an environment + with rapidly changing conditions, and who are able to adapt to the + abrupt changes in the congestion window typical of TCP's Additive + Increase Multiplicative Decrease (AIMD) congestion control. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions and Notation ........................................2 + 3. Usage ...........................................................3 + 3.1. Relationship with TCP ......................................3 + 3.2. Half-Connection Example ....................................4 + 4. Connection Establishment ........................................5 + 5. Congestion Control on Data Packets ..............................5 + 5.1. Response to Idle and Application-Limited Periods ...........8 + 5.2. Response to Data Dropped and Slow Receiver .................8 + 5.3. Packet Size ................................................8 + 6. Acknowledgements ................................................9 + 6.1. Congestion Control on Acknowledgements .....................9 + 6.1.1. Detecting Lost and Marked Acknowledgements .........10 + + + + +Floyd & Kohler Standards Track [Page 1] + +RFC 4341 DCCP CCID2 March 2006 + + + 6.1.2. Changing Ack Ratio .................................10 + 6.2. Acknowledgements of Acknowledgements ......................11 + 6.2.1. Determining Quiescence .............................12 + 7. Explicit Congestion Notification ...............................12 + 8. Options and Features ...........................................12 + 9. Security Considerations ........................................13 + 10. IANA Considerations ...........................................13 + 10.1. Reset Codes ..............................................13 + 10.2. Option Types .............................................13 + 10.3. Feature Numbers ..........................................14 + 11. Thanks ........................................................14 + A. Appendix: Derivation of Ack Ratio Decrease ....................15 + B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio ........15 + Normative References ..............................................17 + Informative References ............................................18 + +1. Introduction + + This document contains the profile for Congestion Control Identifier + 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion + Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control + Identifiers, or CCIDs, to specify the congestion control mechanism in + use on a half-connection. + + The TCP-like Congestion Control CCID sends data using a close variant + of TCP's congestion control mechanisms, incorporating a variant of + selective acknowledgements (SACK) [RFC2018, RFC3517]. 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 + senders who would like to take advantage of the available bandwidth + in an environment with rapidly changing conditions. See Section 3 + for more on application requirements. + +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 [RFC2119]. + + A DCCP half-connection consists of the application data sent by one + endpoint and the corresponding acknowledgements sent by the other + endpoint. The terms "HC-Sender" and "HC-Receiver" denote the + endpoints sending application data and acknowledgements, + respectively. Since CCIDs apply at the level of half-connections, we + abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in + this document. See [RFC4340] for more discussion. + + + + +Floyd & Kohler Standards Track [Page 2] + +RFC 4341 DCCP CCID2 March 2006 + + + For simplicity, we say that senders send DCCP-Data packets and + 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 + + CCID 2, TCP-like Congestion Control, is appropriate for DCCP flows + that would like to receive as much bandwidth as possible over the + long term, consistent with the use of end-to-end congestion control. + CCID 2 flows must also tolerate the large sending rate variations + characteristic of AIMD congestion control, including halving of the + congestion window in response to a congestion event. + + Applications that simply need to transfer as much data as possible in + as short a time as possible should use CCID 2. This contrasts with + CCID 3, TCP-Friendly Rate Control (TFRC) [RFC4342], which is + appropriate for flows that would prefer to minimize abrupt changes in + the sending rate. For example, CCID 2 is recommended over CCID 3 for + streaming media applications that buffer a considerable amount of + data at the application receiver before playback time, insulating the + application somewhat from abrupt changes in the sending rate. Such + applications could easily choose DCCP's CCID 2 over TCP itself, + possibly adding some form of selective reliability at the application + layer. CCID 2 is also recommended over CCID 3 for applications where + halving the sending rate in response to congestion is not likely to + interfere with application-level performance. + + An additional advantage of CCID 2 is that its TCP-like congestion + control mechanisms are reasonably well understood, with traffic + dynamics quite similar to those of TCP. While the network research + community is still learning about the dynamics of TCP after 15 years + of its being the dominant transport protocol in the Internet, some + applications might prefer the more well-known dynamics of TCP-like + congestion control over those of newer congestion control mechanisms, + which haven't yet met the test of widespread Internet deployment. + +3.1. Relationship with TCP + + 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 [RFC793], + [RFC2581], [RFC3465], and [RFC3517]. 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. + + + +Floyd & Kohler Standards Track [Page 3] + +RFC 4341 DCCP CCID2 March 2006 + + + Differences between CCID 2 and straight TCP congestion control + include the following: + + o CCID 2 applies congestion control to acknowledgements, a mechanism + not currently standardized for use in TCP. + + o 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. + + o As an unreliable protocol, DCCP never retransmits a packet, so + congestion control mechanisms that distinguish retransmissions + from new packets have been redesigned for the DCCP context. + +3.2. Half-Connection Example + + This example shows the typical progress of a half-connection using + CCID 2's TCP-like Congestion Control, not including connection + initiation and termination. The example is informative, not + normative. + + 1. The sender sends DCCP-Data packets, where the number of packets + sent is governed by a congestion window, cwnd, as in TCP. Each + DCCP-Data packet uses a sequence number. The sender also sends an + Ack Ratio feature option specifying the number of data packets to + be covered by an Ack packet from the receiver; Ack Ratio defaults + to two. The DCCP header's CCVal field is set to zero. + + Assuming that the half-connection is Explicit Congestion + 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 [RFC3540]. + + 2. The receiver sends a DCCP-Ack packet acknowledging the data + packets for every Ack Ratio data packets transmitted by the + sender. Each DCCP-Ack packet uses a sequence number and contains + an Ack Vector. The sequence number acknowledged in a DCCP-Ack + packet is that of the received packet with the highest sequence + number; it is not a TCP-like cumulative acknowledgement. + + The receiver returns the sum of received ECN Nonces via Ack Vector + options, allowing the sender to probabilistically verify that the + receiver is not misbehaving. DCCP-Ack packets from the receiver + are also sent as ECN Capable, since the sender will control the + acknowledgement rate in a roughly TCP-friendly way using the Ack + Ratio feature. There is little need for the receiver to verify + the nonces of its DCCP-Ack packets, since the sender cannot get + significant benefit from misreporting the ack mark rate. + + + +Floyd & Kohler Standards Track [Page 4] + +RFC 4341 DCCP CCID2 March 2006 + + + 3. The sender continues sending DCCP-Data packets as controlled by + the congestion window. Upon receiving DCCP-Ack packets, the + sender examines their Ack Vectors to learn about marked or dropped + data packets and adjusts its congestion window accordingly. + Because this is unreliable transfer, the sender does not + retransmit dropped packets. + + 4. Because DCCP-Ack packets use sequence numbers, the sender has some + information about lost or marked DCCP-Ack packets. The sender + responds to lost or marked DCCP-Ack packets by modifying the Ack + Ratio sent to the receiver. + + 5. The sender acknowledges the receiver's acknowledgements at least + once per congestion window. If both half-connections are active, + the sender's acknowledgement of the receiver's acknowledgements is + included in the sender's acknowledgement of the receiver's data + packets. If the reverse-path half-connection is quiescent, the + sender sends at least one DCCP-DataAck packet per congestion + window. + + 6. The sender estimates round-trip times, either through keeping + track of acknowledgement round-trip times as TCP does or through + explicit Timestamp options, and calculates a TimeOut (TO) value + much as the RTO (Retransmit Timeout) is calculated in TCP. The TO + determines when a new DCCP-Data packet can be transmitted when the + sender has been limited by the congestion window and no feedback + has been received from the receiver. + +4. Connection Establishment + + Use of the Ack Vector is MANDATORY on CCID 2 half-connections, so the + sender MUST send a "Change R(Send Ack Vector, 1)" option to the + receiver as part of connection establishment. The sender SHOULD NOT + send data until it has received the corresponding "Confirm L(Send Ack + Vector, 1)" from the receiver, except that it MAY send data on DCCP- + Request packets. + +5. Congestion Control on Data Packets + + CCID 2's congestion control mechanisms are based on those for SACK- + based TCP [RFC3517], since the Ack Vector provides all the + information that might be transmitted in SACK options. + + A CCID 2 data sender maintains three integer parameters measured in + packets. + + + + + + +Floyd & Kohler Standards Track [Page 5] + +RFC 4341 DCCP CCID2 March 2006 + + + 1. The congestion window "cwnd", which equals the maximum number of + data packets allowed in the network at any time. ("Data packet" + means any DCCP packet that contains user data: DCCP-Data, DCCP- + DataAck, and occasionally DCCP-Request and DCCP-Response.) + + 2. The slow-start threshold "ssthresh", which controls adjustments to + cwnd. + + 3. The pipe value "pipe", which is the sender's estimate of the + number of data packets outstanding in the network. + + These parameters are manipulated, and their initial values + determined, according to SACK-based TCP's behavior, except that they + are measured in packets, not bytes. The rest of this section + provides more specific guidance. + + The sender MAY send a data packet when pipe < cwnd but MUST NOT send + a data packet when pipe >= cwnd. Every data packet sent increases + pipe by 1. + + The sender reduces pipe as it infers that data packets have left the + network, either by being received or by being dropped. In + particular: + + 1. Acked data packets. The sender reduces pipe by 1 for each data + packet newly acknowledged as received (Ack Vector State 0 or State + 1) by some DCCP-Ack. + + 2. Dropped data packets. The sender reduces pipe by 1 for each data + packet it can infer as lost due to the DCCP equivalent of TCP's + "duplicate acknowledgements". This depends on the NUMDUPACK + parameter, the number of duplicate acknowledgements needed to + infer a loss. The NUMDUPACK parameter is set to three, as is + currently the case in TCP. A packet P is inferred to be lost, + rather than delayed, when at least NUMDUPACK packets transmitted + after P have been acknowledged as received (Ack Vector State 0 or + 1) by the receiver. Note that the acknowledged packets following + the hole may be DCCP-Acks or other non-data packets. + + 3. Transmit timeouts. Finally, the sender needs transmit timeouts, + handled like TCP's retransmission timeouts, in case an entire + window of packets is lost. The sender estimates the round-trip + time at most once per window of data and uses the TCP algorithms + for maintaining the average round-trip time, mean deviation, and + timeout value [RFC2988]. (If more than one measurement per + round-trip time was used for these calculations, then the weights + of the averagers would have to be adjusted to ensure that the + average round-trip time is effectively derived from measurements + + + +Floyd & Kohler Standards Track [Page 6] + +RFC 4341 DCCP CCID2 March 2006 + + + over multiple round-trip times.) Because DCCP does not retransmit + data, DCCP does not require TCP's recommended minimum timeout of + one second. The exponential backoff of the timer is exactly as in + TCP. When a transmit timeout occurs, the sender sets pipe to + zero. The adjustments to cwnd and ssthresh are described below. + + The sender MUST NOT decrement pipe more than once per data packet. + True duplicate acknowledgements, for example, MUST NOT affect pipe. + The sender also MUST NOT decrement pipe again upon receiving + acknowledgement of a packet previously inferred as lost. + Furthermore, the sender MUST NOT decrement pipe for non-data packets, + such as DCCP-Acks, even though the Ack Vector will contain + information about them. + + 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 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 + acknowledged data packets with Ack Vector State 0 (not ECN-marked), + up to a maximum of Ack Ratio/2 packets per acknowledgement. This is + a modified form of Appropriate Byte Counting [RFC3465] that is + consistent with TCP's current standard (which does not include byte + counting), but allows CCID 2 to increase as aggressively as TCP when + CCID 2's Ack Ratio is greater than the default value of two. When + cwnd >= ssthresh, the congestion window is increased by one packet + for every window of data acknowledged without lost or marked packets. + The cwnd parameter is initialized to at most four packets for new + connections, following the rules from [RFC3390]; the ssthresh + parameter is initialized to an arbitrarily high value. + + Senders MAY use a form of rate-based pacing when sending multiple + data packets liberated by a single ack packet, rather than sending + all liberated data packets in a single burst. + + + +Floyd & Kohler Standards Track [Page 7] + +RFC 4341 DCCP CCID2 March 2006 + + +5.1. Response to Idle and Application-Limited Periods + + CCID 2 is designed to follow TCP's congestion control mechanisms to + the extent possible, but TCP does not have complete standardization + for its congestion control response to idle periods (when no data + packets are sent) or to application-limited periods (when the sending + rate is less than that allowed by cwnd). This section is a brief + guide to the standards for TCP in this area. + + For idle periods, [RFC2581] recommends that the TCP sender SHOULD + slow-start after an idle period, where an idle period is defined as a + period exceeding the timeout interval. [RFC2861], currently + Experimental, suggests a slightly more moderate mechanism where the + congestion window is halved for every round-trip time that the sender + has remained idle. + + There are currently no standards governing TCP's use of the + congestion window during an application-limited period. In + particular, it is possible for TCP's congestion window to grow quite + large during a long uncongested period when the sender is application + limited, sending at a low rate. [RFC2861] essentially suggests that + TCP's congestion window not be increased during application-limited + periods when the congestion window is not being fully utilized. + +5.2. Response to Data Dropped and Slow Receiver + + DCCP's Data Dropped option lets a receiver declare that a packet was + dropped at the end host before delivery to the application -- for + instance, because of corruption or receive buffer overflow. DCCP's + Slow Receiver option lets a receiver declare that it is having + trouble keeping up with the sender's packets, although nothing has + yet been dropped. CCID 2 senders respond to these options as + described in [RFC4340], with the following further clarifications. + + o Drop Code 2 ("receive buffer drop"). The congestion window "cwnd" + is reduced by one for each packet newly acknowledged as Drop Code + 2, except that it is never reduced below one. + + o Exiting slow start. The sender MUST exit slow start whenever it + receives a relevant Data Dropped or Slow Receiver option. + +5.3. Packet Size + + CCID 2 is optimized for applications that generally use a fixed + packet size and vary their sending rate in packets per second in + response to congestion. CCID 2 is not appropriate for applications + that require a fixed interval of time between packets and vary their + packet size instead of their packet rate in response to congestion. + + + +Floyd & Kohler Standards Track [Page 8] + +RFC 4341 DCCP CCID2 March 2006 + + + CCID 2 maintains a congestion window in packets and does not increase + the congestion window in response to a decrease in the packet size. + However, some attention might be required for applications using CCID + 2 that vary their packet size not in response to congestion, but in + response to other application-level requirements. + + CCID 2 implementations MAY check for applications that appear to be + manipulating the packet size inappropriately. For example, an + application might send small packets for a while, building up a fast + rate, then switch to large packets to take advantage of the fast + rate. (Preliminary simulations indicate that applications may not be + able to increase their overall transfer rates this way, so it is not + clear that this manipulation will occur in practice [V03].) + +6. Acknowledgements + + CCID 2 acknowledgements are generally paced by the sender's data + packets. Each required acknowledgement MUST contain Ack Vector + 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; see [RFC4340], Section 11.4.2. Any Data Dropped options + SHOULD likewise cover the receiver's entire Acknowledgement Window. + + CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at + which receivers generate DCCP-Ack packets, thus controlling reverse- + path congestion. This differs from TCP, which presently has no + congestion control for pure acknowledgement traffic. CCID 2's + reverse-path congestion control does not try to be TCP friendly; it + just tries to avoid congestion collapse, and to be somewhat better + than TCP is 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. [RFC4340], Section 11.3, + describes the Ack Ratio in more detail, including its relationship to + acknowledgement pacing and DCCP-DataAck packets. This document's + Section 6.1.1 describes how a CCID 2 sender detects lost or marked + acknowledgements, and Section 6.1.2 describes how it changes the Ack + Ratio. + +6.1. Congestion Control on Acknowledgements + + When Ack Ratio is R, the receiver sends one DCCP-Ack packet per R + data packets, more or less. Since the sender sends cwnd data packets + per round-trip time, the acknowledgement rate equals cwnd/R DCCP-Acks + per round-trip time. The sender keeps the acknowledgement rate + roughly TCP friendly by monitoring the acknowledgement stream for + lost and marked DCCP-Ack packets and modifying R accordingly. For + every RTT containing a DCCP-Ack congestion event (that is, a lost or + + + +Floyd & Kohler Standards Track [Page 9] + +RFC 4341 DCCP CCID2 March 2006 + + + marked DCCP-Ack), the sender halves the acknowledgement rate by + doubling Ack Ratio; for every RTT containing no DCCP-Ack congestion + event, it additively increases the acknowledgement rate through + gradual decreases in Ack Ratio. + +6.1.1. Detecting Lost and Marked Acknowledgements + + All packets from the receiver contain sequence numbers, so the sender + can detect both losses and marks on the receiver's packets. The + sender infers receiver packet loss in the same way that it infers + losses of its data packets: a packet from the receiver is considered + lost after at least NUMDUPACK packets with greater sequence numbers + have been received. + + DCCP-Ack packets are generally small, so they might impose less load + on congested network links than DCCP-Data and DCCP-DataAck packets. + For this reason, Ack Ratio depends on losses and marks on the + receiver's non-data packets, not on aggregate losses and marks on all + of the receiver's packets. The non-data packet category consists of + those packet types that cannot carry application data: DCCP-Ack, + DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck. + The sender can easily distinguish non-data marks from other marks. + This is harder for losses, though, since the sender can't always know + whether a lost packet carried data. Unless it has better + information, the sender SHOULD assume, for the purpose of Ack Ratio + calculation, that every lost packet was a non-data packet. Better + information is available via DCCP's NDP Count option, if necessary. + (Appendix B discusses the costs of mistaking data packet loss for + non-data packet loss.) + + A receiver that implements its own acknowledgement congestion control + independent of Ack Ratio SHOULD NOT reduce its DCCP-Ack + acknowledgement rate due to losses or marks on its data packets. + +6.1.2. Changing Ack Ratio + + Ack Ratio always meets three constraints: (1) Ack Ratio is an + integer. (2) Ack Ratio does not exceed cwnd/2, rounded up, except + that Ack Ratio 2 is always acceptable. (3) Ack Ratio is two or more + for a congestion window of four or more packets. + + The sender changes Ack Ratio within those constraints as follows. + For each congestion window of data with lost or marked DCCP-Ack + packets, Ack Ratio is doubled; and for each cwnd/(R^2 - R) + 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 [RFC4340], Section 11.3. + + + +Floyd & Kohler Standards Track [Page 10] + +RFC 4341 DCCP CCID2 March 2006 + + + For a constant congestion window, this gives an Ack sending rate that + is roughly TCP friendly. Of course, cwnd usually varies over time; + the dynamics will be rather complex, but roughly TCP friendly. We + recommend that the sender use the most recent value of cwnd when + determining whether to decrease Ack Ratio by 1. + + The sender need not keep Ack Ratio completely up to date. For + instance, it MAY rate-limit Ack Ratio renegotiations to once every + four or five round-trip times, or to once every second or two. The + sender SHOULD NOT attempt to renegotiate the Ack Ratio more than once + per round-trip time. Additionally, it MAY enforce a minimum Ack + Ratio of two, or it MAY set Ack Ratio to one for half-connections + with persistent congestion windows of 1 or 2 packets. + + Putting it all together, the receiver always sends at least one + acknowledgement per window of data when cwnd = 1, and at least two + acknowledgements per window of data otherwise. Thus, the receiver + could be sending two ack packets per window of data even in the face + of very heavy congestion on the reverse path. We would note, + however, that if congestion is sufficiently heavy, all the ack + packets are dropped, and then the sender falls back on an + exponentially backed-off timeout, as in TCP. Thus, if congestion is + sufficiently heavy on the reverse path, then the sender reduces its + sending rate on the forward path, which reduces the rate on the + reverse path as well. + +6.2. Acknowledgements of Acknowledgements + + An active sender DCCP A MUST occasionally acknowledge its peer DCCP + B's acknowledgements so that DCCP B can free up Ack Vector state. + When both half-connections are active, A's acknowledgements of B's + acknowledgements are automatically contained in A's acknowledgements + of B's data. If the B-to-A half-connection is quiescent, however, + DCCP A must occasionally send acknowledgements proactively, such as + by sending a DCCP-DataAck packet that includes an Acknowledgement + Number in the header. + + An active sender SHOULD acknowledge the receiver's acknowledgements + at least once per congestion window. Of course, the sender's + application might fall silent. This is no problem; when neither side + is sending data, a sender can wait arbitrarily long before sending an + ack. + + + + + + + + + +Floyd & Kohler Standards Track [Page 11] + +RFC 4341 DCCP CCID2 March 2006 + + +6.2.1. Determining Quiescence + + This section describes how a CCID 2 receiver determines that the + corresponding sender is not sending any data and therefore has gone + quiescent. See [RFC4340], 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 + for the other half-connection. If it does not, it should use a + default RTT of 0.2 seconds, as described in [RFC4340], 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, the + receiver infers that the sender has gone quiescent when at least T + seconds have passed without receiving any data from the sender, and + when the sender has acknowledged receiver Ack Vectors covering all + data packets received at the receiver. + +7. Explicit Congestion Notification + + CCID 2 supports Explicit Congestion Notification (ECN) [RFC3168]. + The sender will use the ECN Nonce for data packets, and the receiver + will echo those nonces in its Ack Vectors, as specified in [RFC4340], + 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. + + For unmarked data packets, the receiver computes the ECN Nonce Echo + as in [RFC3540] 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. + + Because CCID 2 acknowledgements are congestion controlled, ECN may + also be used for its acknowledgements. In this case we do not make + use of the ECN Nonce, because it would not be easy to provide + protection against the concealment of marked ack packets by the + sender, and because the sender does not have much motivation for + lying about the mark rate on acknowledgements. + +8. Options and Features + + DCCP's Ack Vector option, and its ECN Capable, Ack Ratio, and Send + Ack Vector features, are relevant for CCID 2. + + + + + +Floyd & Kohler Standards Track [Page 12] + +RFC 4341 DCCP CCID2 March 2006 + + +9. Security Considerations + + Security considerations for DCCP have been discussed in [RFC4340], + and security considerations for TCP have been discussed in [RFC2581]. + + [RFC2581] discusses ways in which 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 + document in its use of TCP-like congestion control. + +10. IANA Considerations + + This specification defines the value 2 in the DCCP CCID namespace + managed by IANA. This assignment is also mentioned in [RFC4340]. + CCID 2 also introduces three sets of numbers whose values should be + 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 [RFC4340], Section 10.3. However, this document + makes no particular allocations from any range, except for + experimental and testing use [RFC3692]. We refer to the Standards + Action policy outlined in [RFC2434]. + +10.1. Reset Codes + + Each entry in the DCCP CCID 2 Reset Code registry contains a CCID + 2-specific Reset Code, which is a number in the range 128-255; a + short description of the Reset Code; and a reference to the RFC + 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 Standards Action policy, which + requires IESG review and approval and standards-track IETF RFC + publication. + +10.2. Option Types + + Each entry in the DCCP CCID 2 option type registry contains a CCID + 2-specific option type, which is a number in the range 128-255; the + name of the option; and a reference to the RFC defining the 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 Standards Action policy, which requires IESG review and + approval and standards-track IETF RFC publication. + + + + + +Floyd & Kohler Standards Track [Page 13] + +RFC 4341 DCCP CCID2 March 2006 + + +10.3. Feature Numbers + + Each entry in the DCCP CCID 2 feature number registry contains a CCID + 2-specific feature number, which is a number in the range 128-255; + the name of the feature; and a reference to the RFC 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 Standards Action policy, which requires + IESG review and approval and standards-track IETF RFC publication. + +11. Thanks + + We thank Mark Handley and Jitendra Padhye for their help in defining + CCID 2. We also thank Mark Allman, Aaron Falk, Nils-Erik Mattsson, + Greg Minshall, Arun Venkataramani, Magnus Westerlund, and members of + the DCCP Working Group for feedback on this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd & Kohler Standards Track [Page 14] + +RFC 4341 DCCP CCID2 March 2006 + + +A. Appendix: Derivation of Ack Ratio Decrease + + This section justifies the algorithm for increasing and decreasing + the Ack Ratio given in Section 6.1.2. + + The congestion avoidance phase of TCP halves the cwnd for every + window with congestion. Similarly, CCID 2 doubles Ack Ratio for + every window with congestion on the return path, roughly halving the + DCCP-Ack sending rate. + + The congestion avoidance phase of TCP increases cwnd by one MSS for + every congestion-free window. When this congestion avoidance + behavior is applied to acknowledgement traffic, this would correspond + to increasing the number of DCCP-Ack packets per window by one after + every congestion-free window of DCCP-Ack packets. We cannot achieve + this exactly using Ack Ratio, since it is an integer. Instead, we + must decrease Ack Ratio by one after K windows have been sent without + a congestion event on the reverse path, where K is chosen so that the + long-term number of DCCP-Ack packets per congestion window is roughly + TCP friendly, following AIMD congestion control. + + In CCID 2, rough TCP-friendliness for the ack traffic can be + accomplished by setting K to cwnd/(R^2 - R), where R is the current + Ack Ratio. + + This result was calculated as follows: + + R = Ack Ratio = # data packets / ack packets, and + W = Congestion Window = # data packets / window, so + W/R = # ack packets / window. + + Requirement: Increase W/R by 1 per congestion-free window. Since + we can only reduce R by increments of one, we find K so that, + after K congestion-free windows, W/R + K would equal W/(R-1). + + (W/R) + K = W/(R-1), so + K = W/(R-1) - W/R = W/(R^2 - R). + +B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio + + As discussed in Section 6.1.1, the sender often cannot determine + whether lost packets carried data. This hinders its ability to + separate non-data loss events from other loss events. In the absence + of better information, the sender assumes, for the purpose of Ack + Ratio calculation, that all lost packets were non-data packets. This + may overestimate the non-data loss event rate, which can lead to a + too-high Ack Ratio, and thus to a too-slow acknowledgement rate. All + acknowledgement information will still get through -- DCCP + + + +Floyd & Kohler Standards Track [Page 15] + +RFC 4341 DCCP CCID2 March 2006 + + + acknowledgements are reliable -- but acknowledgement information will + arrive in a burstier fashion. Absent some form of rate-based pacing, + this could lead to increased burstiness for the sender's data + traffic. + + There are several cases when the problem of an overly-high Ack Ratio, + and the resulting increased burstiness of the data traffic, will not + arise. In particular, call the receiver DCCP B and the sender DCCP + A: + + o The problem won't arise unless DCCP B is sending a significant + amount of data itself. When the B-to-A half-connection is + quiescent or low rate, most packets sent by DCCP B will, in fact, + be pure acknowledgements, and DCCP A's estimate of the DCCP-Ack + loss rate will be reasonably accurate. + + o The problem won't arise if DCCP B habitually piggybacks + acknowledgement information on its data packets. The piggybacked + acknowledgements are not limited by Ack Ratio, so they can arrive + frequently enough to prevent burstiness. + + o The problem won't arise if DCCP A's sending rate is low, since + burstiness isn't a problem at low rates. + + o The problem won't arise if DCCP B's sending rate is high relative + to DCCP A's sending rate, since the B-to-A loss rate must be low + to support DCCP B's sending rate. This bounds the Ack Ratio to + reasonable values even when DCCP A labels every loss as a DCCP- + Ack loss. + + o The problem won't arise if DCCP B sends NDP Count options when + appropriate (the Send NDP Count/B feature is true). Then the + sender can use the receiver's NDP Count options to detect, in most + cases, whether lost packets were data packets or DCCP-Acks. + + o Finally, the problem won't arise if DCCP A rate-paces its data + packets. + + This leaves the case when DCCP B is sending roughly the same amount + of data packets and non-data packets, without NDP Count options, and + with all acknowledgement information in DCCP-Ack packets. We now + quantify the potential cost, in terms of a too-large Ack Ratio, due + to the sender's misclassifying data packet losses as DCCP-Ack losses. + For simplicity, we assume an environment of large-scale statistical + multiplexing where the packet drop rate is independent of the sending + rate of any individual connection. + + + + + +Floyd & Kohler Standards Track [Page 16] + +RFC 4341 DCCP CCID2 March 2006 + + + Assume that when DCCP A correctly counts non-data losses, Ack Ratio + is set so that B-to-A data and acknowledgement traffic both have a + sending rate of D packets per second. Then when DCCP A incorrectly + counts data losses as non-data losses, the sending rate for the + B-to-A data traffic is still D pps, but the reduced sending rate for + the B-to-A acknowledgement traffic is f*D pps, with f < 1. Let the + packet loss rate be p. The sender incorrectly estimates the non-data + loss rate as (pD+pfD)/fD, or, equivalently, as p(1 + 1/f). Because + the congestion control mechanism for acknowledgement traffic is + roughly TCP friendly, and therefore the non-data sending rate and the + data sending rate both grow as 1/sqrt(x) for x the packet drop rate, + we have + + fD/D = sqrt(p)/sqrt(p(1 + 1/f)), + + so + + f^2 = 1/(1 + 1/f). + + Solving, we get f = 0.62. If the sender incorrectly counts lost data + packets as non-data in this scenario, the acknowledgement rate is + decreased by a factor of 0.62. This would result in a moderate + increase in burstiness for the A-to-B data traffic, which could be + mitigated by sending NDP Count options or piggybacked + acknowledgements, or by rate-pacing out the data. + +Normative References + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, + "TCP Selective Acknowledgement Options", RFC 2018, + October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP + Congestion Control", RFC 2581, April 1999. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's + Retransmission Timer", RFC 2988, November 2000. + + + + +Floyd & Kohler Standards Track [Page 17] + +RFC 4341 DCCP CCID2 March 2006 + + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The + Addition of Explicit Congestion Notification (ECN) to + IP", RFC 3168, September 2001. + + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing + TCP's Initial Window", RFC 3390, October 2002. + + [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A + Conservative Selective Acknowledgment (SACK)-based + Loss Recovery Algorithm for TCP", RFC 3517, April + 2003. + + [RFC3692] Narten, T., "Assigning Experimental and Testing + Numbers Considered Useful", BCP 82, RFC 3692, January + 2004. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, March + 2006. + +Informative References + + [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion + Window Validation", RFC 2861, June 2000. + + [RFC3465] Allman, M., "TCP Congestion Control with Appropriate + Byte Counting (ABC)", RFC 3465, February 2003. + + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust + Explicit Congestion Notification (ECN) Signaling with + Nonces", RFC 3540, June 2003. + + [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for + Datagram Congestion Control Protocol (DCCP) Congestion + Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC + 4342, March 2006. + + [V03] Arun Venkataramani, August 2003. Citation for + acknowledgement purposes only. + + + + + + + + + + + + +Floyd & Kohler Standards Track [Page 18] + +RFC 4341 DCCP CCID2 March 2006 + + +Authors' Addresses + + Sally Floyd + ICSI Center for Internet Research + 1947 Center Street, Suite 600 + Berkeley, CA 94704 + USA + + EMail: floyd@icir.org + + + Eddie Kohler + 4531C Boelter Hall + UCLA Computer Science Department + Los Angeles, CA 90095 + USA + + EMail: kohler@cs.ucla.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd & Kohler Standards Track [Page 19] + +RFC 4341 DCCP CCID2 March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Floyd & Kohler Standards Track [Page 20] + -- cgit v1.2.3