The version of draft-ietf-dccp-ccid2-10.txt used to generate this diff is slightly different from the published version, in that we altered its margins and whitespace formatting in order to obtain a closer correspondence with the published RFC.







Network Working Group S. Floyd	Internet Engineering Task Force Sally Floyd
Request for Comments: 4341 ICIR	INTERNET-DRAFT ICIR
Category: Standards Track E. Kohler	draft-ietf-dccp-ccid2-10.txt Eddie Kohler
UCLA	Expires: 3 October 2006 UCLA
March 2006	3 April 2006
	Profile for DCCP Congestion Control ID 2:
	TCP-like Congestion Control
Profile for Datagram Congestion Control Protocol (DCCP)	Status of this Memo
Congestion Control ID 2: TCP-like Congestion Control	This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each
Status of This Memo	author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of
This document specifies an Internet standards track protocol for the	which he or she become aware will be disclosed, in accordance with
Internet community, and requests discussion and suggestions for	RFC 3668.
improvements. Please refer to the current edition of the "Internet	Internet-Drafts are working documents of the Internet Engineering
Official Protocol Standards" (STD 1) for the standardization state	Task Force (IETF), its areas, and its working groups. Note that
and status of this protocol. Distribution of this memo is unlimited.	other groups may also distribute working documents as Internet-
	Drafts.
Copyright Notice	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on 3 October 2006.

Copyright (C) The Internet Society (2006).	Copyright (C) The Internet Society (2005). All Rights Reserved.

Abstract

This document contains the profile for Congestion Control Identifier
2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion	2, TCP-like Congestion Control, in the Datagram Congestion Control
Control Protocol (DCCP). CCID 2 should be used by senders who would	Protocol (DCCP). CCID 2 should be used by senders who would like to
like to take advantage of the available bandwidth in an environment	take advantage of the available bandwidth in an environment with
with rapidly changing conditions, and who are able to adapt to the	rapidly changing conditions, and who are able to adapt to the abrupt
abrupt changes in the congestion window typical of TCP's Additive	changes in the congestion window typical of TCP's Additive Increase
Increase Multiplicative Decrease (AIMD) congestion control.	Multiplicative Decrease (AIMD) congestion control.
	TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Table of Contents	Changes from draft-ietf-dccp-ccid2-07.txt:
	* Restrict the use of byte-counting to be at most as aggressive
	as the current TCP (without byte-counting).
	Changes from draft-ietf-dccp-ccid2-06.txt:
	* Moved three citations to Informational.
	* Added that "The sender SHOULD not attempt Ack Ratio
	renegotiations more than once per round-trip time."
	* Specified that ssthresh is never less than two, instead of one.
	* Added references to RFC 2988 and RFC 2018.
	* Specify that the congestion window is only increased for packets
	that aren't ECN-marked.
	Changes from draft-ietf-dccp-ccid2-05.txt:
	* Changes to the discussion about how the sender infers that DCCP-Ack
	packets are lost. The sender does not know for sure whether a
	missing sequence number is for a dropped ACK packet or a dropped data
	packet. Our changes include a new appendix on "The Costs of
	Inferring Lost Ack Packets".
	* Minor editing for clarity, including some reordering of sections.
	* Added a section on response to idle and application-limited
	periods.
	* Clarifications on changing the Ack Ratio, based on feedback from
	Nils-Erik Mattsson.
	Changes from draft-ietf-dccp-ccid2-04.txt:
	* Minor editing, as follows:
	- Added a note that CCID2 implementations MAY check for apps that
	are
	gaming with regard to the packet size.
	- Deleted a statement that the maximum packet size is 1500 bytes.
	- Added that the receiver MAY know the round-trip time from its
	role as
	- Added a note that the initial cwnd is up to four packets.
	* Added Intellectual Property Notice.
	Changes from draft-ietf-dccp-ccid2-03.txt:
	* Disallow direct tracking of TCP standards.
	Changes from draft-ietf-dccp-ccid2-02.txt:
	* Added to the section on application requirements.
	* Changed the default Ack Ratio to be two, as recommended for TCP.
	* Added a paragraph about packet sizes.
	Changes from draft-ietf-dccp-ccid2-01.txt:
	* Added "Security Considerations" and "IANA Considerations" sections.
	* Refer explicitly to SACK-based TCP, and flesh out Section 3
	("Congestion Control on Data Packets").
	* When cwnd < ssthresh, increase cwnd by one per newly acknowledged
	packet up to some limit, in line with TCP Appropriate Byte Counting.
	* Refined definition of quiescence.
	Changes from draft-ietf-dccp-ccid2-00.txt:
	* Said that the Acknowledgement Number reports the largest sequence
	number, not the most recent packet, for consistency with draft-ietf-
	dccp-spec.
	* Added notes about ECN nonces for acknowledgements, and about
	dealing with piggybacked acknowledgements.

1. Introduction ....................................................2	1. Introduction ....................................................6
2. Conventions and Notation ........................................2	2. Conventions and Notation ........................................6
3. Usage ...........................................................3	3. Usage ...........................................................6
3.1. Relationship with TCP ......................................3	3.1. Relationship with TCP ......................................7
3.2. Half-Connection Example ....................................4	3.2. Example Half-Connection ....................................8
4. Connection Establishment ........................................5	4. Connection Establishment ........................................9
5. Congestion Control on Data Packets ..............................5	5. Congestion Control on Data Packets ..............................9
5.1. Response to Idle and Application-Limited Periods ...........8	5.1. Response to Idle and Application-limited Periods ..........11
5.2. Response to Data Dropped and Slow Receiver .................8	5.2. Response to Data Dropped and Slow Receiver ................12
5.3. Packet Size ................................................8	5.3. Packet Size ...............................................12
6. Acknowledgements ................................................9	6. Acknowledgements ...............................................13
6.1. Congestion Control on Acknowledgements .....................9	6.1. Congestion Control on Acknowledgements ....................13
6.1.1. Detecting Lost and Marked Acknowledgements .........10	6.1.1. Detecting Lost and Marked Acknowledgements .........13
	6.1.2. Changing Ack Ratio .................................14
	6.2. Acknowledgements of Acknowledgements ......................15
	6.2.1. Determining Quiescence .............................15
	7. Explicit Congestion Notification ...............................16
Floyd & Kohler Standards Track [Page 1]	8. Options and Features ...........................................16

RFC 4341 DCCP CCID2 March 2006	9. Security Considerations ........................................16
	10. IANA Considerations ...........................................16
	10.1. Reset Codes ..............................................17
6.1.2. Changing Ack Ratio .................................10	10.2. Option Types .............................................17
6.2. Acknowledgements of Acknowledgements ......................11	10.3. Feature Numbers ..........................................17
6.2.1. Determining Quiescence .............................12	11. Thanks ........................................................17
7. Explicit Congestion Notification ...............................12	A. Appendix: Derivation of Ack Ratio Decrease .....................18
8. Options and Features ...........................................12	B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio .........18
9. Security Considerations ........................................13	Normative References ..............................................20
10. IANA Considerations ...........................................13	Informative References ............................................21
10.1. Reset Codes ..............................................13	Authors' Addresses ................................................21
10.2. Option Types .............................................13	Full Copyright Statement ..........................................22
10.3. Feature Numbers ..........................................14	Intellectual Property .............................................22
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	2, TCP-like Congestion Control, in the Datagram Congestion Control
Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control	Protocol (DCCP) [DCCP]. DCCP uses Congestion Control Identifiers, or
Identifiers, or CCIDs, to specify the congestion control mechanism in	CCIDs, to specify the congestion control mechanism in use on a half-
use on a half-connection.	connection.

The TCP-like Congestion Control CCID sends data using a close variant
of TCP's congestion control mechanisms, incorporating a variant of	of TCP's congestion control mechanisms, incorporating selective
selective acknowledgements (SACK) [RFC2018, RFC3517]. CCID 2 is	acknowledgements (SACK) [RFC 2018, RFC 3517]. CCID 2 is suitable for
suitable for senders who can adapt to the abrupt changes in	senders who can adapt to the abrupt changes in congestion window
congestion window typical of TCP's Additive Increase Multiplicative	typical of TCP's Additive Increase Multiplicative Decrease (AIMD)
Decrease (AIMD) congestion control, and particularly useful for	congestion control, and particularly useful for senders who would
senders who would like to take advantage of the available bandwidth	like to take advantage of the available bandwidth in an environment
in an environment with rapidly changing conditions. See Section 3	with rapidly changing conditions. See Section 3 for more on
for more on application requirements.	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].	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
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.	this document. See [DCCP] 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.	long term, consistent with the use of end-to-end congestion control,
CCID 2 flows must also tolerate the large sending rate variations	and that can 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	CCID 3, TCP-Friendly Rate Control (TFRC) Congestion Control [CCID 3
appropriate for flows that would prefer to minimize abrupt changes in	PROFILE], which is appropriate for flows that would prefer to
the sending rate. For example, CCID 2 is recommended over CCID 3 for	minimize abrupt changes in the sending rate. For example, CCID 2 is
streaming media applications that buffer a considerable amount of	recommended over CCID 3 for streaming media applications that buffer
data at the application receiver before playback time, insulating the	a considerable amount of data at the application receiver before
application somewhat from abrupt changes in the sending rate. Such	playback time, insulating the application somewhat from abrupt
applications could easily choose DCCP's CCID 2 over TCP itself,	changes in the sending rate. Such applications could easily choose
possibly adding some form of selective reliability at the application	DCCP's CCID 2 over TCP itself, possibly adding some form of selective
layer. CCID 2 is also recommended over CCID 3 for applications where	reliability at the application layer. CCID 2 is also recommended
halving the sending rate in response to congestion is not likely to	over CCID 3 for applications where halving the sending rate in
interfere with application-level performance.	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	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,	congestion control over that 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],	rely partially on existing TCP documentation, such as RFC 793, RFC
[RFC2581], [RFC3465], and [RFC3517]. TCP congestion control	2581, RFC 3465, and RFC 3517. TCP congestion control continues to
continues to evolve, but CCID 2 implementations SHOULD wait for	evolve, but CCID 2 implementations SHOULD wait for explicit updates
explicit updates to CCID 2 rather than track TCP's evolution	to CCID 2 rather than track TCP's evolution directly. Differences
directly.	between CCID 2 and straight TCP congestion control include the
	following:


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	3.2. Example Half-Connection

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	Notification (ECN) capable (the ECN Incapable feature is zero --
default), each DCCP-Data packet is sent as ECN Capable with either	the default), each DCCP-Data packet is sent as ECN-Capable with
the ECT(0) or the ECT(1) codepoint set, as described in [RFC3540].	either the ECT(0) or the ECT(1) codepoint set, as described in RFC
	3540.
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.	number, rather than 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	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.	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	sender sends a DCCP-DataAck packet that includes an
window.	Acknowledgement Number in the header.

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	is used to determine when a new DCCP-Data packet can be
sender has been limited by the congestion window and no feedback	transmitted when the sender has been limited by the congestion
has been received from the receiver.	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-	Vector, 1)" from the receiver, except possibly for data included on
Request packets.	the initial DCCP-Request packet.

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	based TCP [RFC 3517], 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	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	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	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	timeout value [RFC 2988]. (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	of the averagers would have to be adjusted, so that the average
average round-trip time is effectively derived from measurements	round-trip time is effectively derived from measurements over
	multiple round-trip times.) Because DCCP does not retransmit


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	TCP, two losses or marks are considered to be part of a single
event when the second packet was sent before the loss or mark of the	congestion event when the second packet was sent before the loss or
first packet was detected. As an approximation, a sender can	mark of the first packet was detected. As an approximation, a sender
consider two losses or marks to be part of a single congestion event	can consider two losses or marks to be part of a single congestion
when the packets were sent within one RTT estimate of one another,	event when the packets were sent within one RTT estimate of one
using an RTT estimate current at the time the packets were sent. For	another, using an RTT estimate current at the time the packets were
each congestion event, either indicated explicitly as an Ack Vector	sent. For each congestion event, either indicated explicitly as an
State 1 (ECN-marked) acknowledgement or inferred via "duplicate	Ack Vector State 1 (ECN-marked) acknowledgement or inferred via
acknowledgements", cwnd is halved, then ssthresh is set to the new	"duplicate acknowledgements", cwnd is halved, then ssthresh is set to
cwnd. Cwnd is never reduced below one packet. After a timeout, the	the new cwnd. Cwnd is never reduced below one packet. After a
slow-start threshold is set to cwnd/2, then cwnd is set to one	timeout, the slow-start threshold is set to cwnd/2, then cwnd is set
packet. When halved, cwnd and ssthresh have their values rounded	to one packet. When halved, cwnd and ssthresh have their values
down, except that cwnd is never less than one and ssthresh is never	rounded down, except that cwnd is never less than one and ssthresh is
less than two.	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	a modified form of Appropriate Byte Counting [RFC 3465] that is
consistent with TCP's current standard (which does not include byte	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	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	connections, following the rules from RFC 3390; 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	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	For idle periods, RFC 2581 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	period exceeding the timeout interval. RFC 2861, 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	large during a long uncongested period when the sender is
limited, sending at a low rate. [RFC2861] essentially suggests that	application-limited, sending at a low rate. RFC 2861 essentially
TCP's congestion window not be increased during application-limited	suggests that TCP's congestion window not be increased during
periods when the congestion window is not being fully utilized.	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	As described in [DCCP], the Data Dropped option lets an endpoint
dropped at the end host before delivery to the application -- for	declare that a packet was dropped at the end host before delivery to
instance, because of corruption or receive buffer overflow. DCCP's	the application -- for instance, because of corruption or receive
Slow Receiver option lets a receiver declare that it is having	buffer overflow. CCID 2 senders respond to these options as
trouble keeping up with the sender's packets, although nothing has	described in [DCCP], with the following further clarifications.
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	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	packet size, and that vary their sending rate in packets per second
response to congestion. CCID 2 is not appropriate for applications	in response to congestion. CCID 2 is not appropriate for
that require a fixed interval of time between packets and vary their	applications that require a fixed interval of time between packets,
packet size instead of their packet rate in response to congestion.	and vary their packet size instead of their packet rate in response
	to congestion. 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
Floyd & Kohler Standards Track [Page 8]	applications using CCID 2 that vary their packet size not in response

RFC 4341 DCCP CCID2 March 2006	to congestion, but in response to other application-level
	requirements.

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].)	clear 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	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	Window; see [DCCP] (Section 11.4.2).
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-	which DCCP-Ack packets are generated, thus controlling reverse-path
path congestion. This differs from TCP, which presently has no	congestion. This differs from TCP, which presently has no congestion
congestion control for pure acknowledgement traffic. CCID 2's	control for pure acknowledgement traffic. CCID 2's reverse-path
reverse-path congestion control does not try to be TCP friendly; it	congestion control does not try to be TCP-friendly; it just tries to
just tries to avoid congestion collapse, and to be somewhat better	avoid congestion collapse, and to be somewhat better than TCP in the
than TCP is in the presence of a high packet loss or mark rate on the	presence of a high packet loss or mark rate on the reverse path. The
reverse path. The default Ack Ratio is two, and CCID 2 with this Ack	default Ack Ratio is two, and CCID 2 with this Ack Ratio behaves like
Ratio behaves like TCP with delayed acks. [RFC4340], Section 11.3,	TCP with delayed acks. [DCCP] (Section 11.3) describes the Ack Ratio
describes the Ack Ratio in more detail, including its relationship to	in more detail, including its relationship to acknowledgement pacing
acknowledgement pacing and DCCP-DataAck packets. This document's	and DCCP-DataAck packets. Section 6.1.1 below describes the sender's
Section 6.1.1 describes how a CCID 2 sender detects lost or marked	detection of lost or marked acknowledgements, and Section 6.1.2 gives
acknowledgements, and Section 6.1.2 describes how it changes the Ack	the sender's rules for changing the Ack Ratio.
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	roughly TCP-friendly by monitoring the acknowledgement stream for
lost and marked DCCP-Ack packets and modifying R accordingly. 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	sender infers receiver packet loss in the same way as 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	SHOULD NOT reduce its DCCP-Ack acknowledgement rate due to losses or
acknowledgement rate due to losses or marks on its data packets.	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.	negotiation; see [DCCP] (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;	is roughly TCP-friendly. Of course, cwnd usually varies over time;
the dynamics will be rather complex, but roughly TCP friendly. We	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	however, that if congestion is sufficiently heavy that all of the ack
packets are dropped, and then the sender falls back on an	packets are dropped, then the sender falls back on an exponentially-
exponentially backed-off timeout, as in TCP. Thus, if congestion is	backed-off timeout, as in TCP. Thus, if congestion is sufficiently
sufficiently heavy on the reverse path, then the sender reduces its	heavy on the reverse path, then the sender reduces its sending rate
sending rate on the forward path, which reduces the rate on the	on the forward path, which reduces the rate on the reverse path as
reverse path as well.	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.	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,	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	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	corresponding sender is not sending any data, and therefore has gone
quiescent. See [RFC4340], Section 11.1, for general information on	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
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.)	default RTT of 0.2 seconds, as described in [DCCP] (Section 3.4).)
Once the sender acknowledges the receiver's Ack Vectors and the	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	the sender has acknowledged receiver Ack Vectors covering all data
data packets received at the receiver.	packets received at the receiver.

7. Explicit Congestion Notification

CCID 2 supports Explicit Congestion Notification (ECN) [RFC3168].	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