Internet Engineering Task Force Sally Floyd
INTERNET-DRAFT ICIR
draft-ietf-dccp-ccid2-08.txt Eddie Kohler	draft-ietf-dccp-ccid2-07.txt Eddie Kohler
Expires: 14 May 2005 UCLA	Expires: 25 April 2005 UCLA
14 November 2004	25 October 2004


Profile for DCCP Congestion Control ID 2:
TCP-like Congestion Control


Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
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
which he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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 14 May 2005.	This Internet-Draft will expire on 25 April 2005.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.







Floyd/Kohler [Page 1]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


Abstract

This document contains the profile for Congestion Control Identifier
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.










































Floyd/Kohler [Page 2]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:

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.




Floyd/Kohler [Page 3]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


* 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.
















Floyd/Kohler [Page 4]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Notation. . . . . . . . . . . . . . . . . . . 6
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Relationship with TCP. . . . . . . . . . . . . . . . . . 7
3.2. Example Half-Connection. . . . . . . . . . . . . . . . . 7
4. Connection Establishment. . . . . . . . . . . . . . . . . . . 9
5. Congestion Control on Data Packets. . . . . . . . . . . . . . 9
5.1. Response to Idle and Application-limited
Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Response to Data Dropped and Slow Receiver . . . . . . . 12
5.3. Packet Size. . . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Congestion Control on Acknowledgements . . . . . . . . . 13
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. . . . . . . . . . . . . . . 15
8. Options and Features. . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 16
10.1. Reset Codes . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Option Types. . . . . . . . . . . . . . . . . . . . . . 17
10.3. Feature Numbers . . . . . . . . . . . . . . . . . . . . 17
11. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A. Appendix: Derivation of Ack Ratio Decrease. . . . . . . . . . 17
B. Appendix: Cost of Loss Inference Mistakes to Ack
Ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 21















Floyd/Kohler [Page 5]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


1. Introduction

This document contains the profile for Congestion Control Identifier
2, TCP-like Congestion Control, in the Datagram Congestion Control
Protocol (DCCP) [DCCP]. 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
selective acknowledgements (SACK) [RFC 2018] [RFC 3517]. CCID 2 is	selective acknowledgements (SACK) [RFC 2018] [RFC 3517] ". " CCID 2
suitable for senders who can adapt to the abrupt changes in	is suitable for senders who can adapt to the abrupt changes in
congestion window typical of TCP's Additive Increase Multiplicative	congestion window typical of AIMD (Additive Increase Multiplicative
Decrease (AIMD) congestion control, and particularly useful for	Decrease) congestion control in TCP, 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 RFC 2119.	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
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 [DCCP] for more discussion.

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.

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,
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	CCID 2 is recommended for applications that simply need to transfer
in as short a time as possible should use CCID 2. This contrasts	as much data as possible in as short a time as possible. This
with CCID 3, TCP-Friendly Rate Control (TFRC) Congestion Control	contrasts with CCID 3, TCP-Friendly Rate Control (TFRC) Congestion
	Control [CCID 3 PROFILE], 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
Floyd/Kohler Section 3. [Page 6]	that buffer a considerable amount of data at the application

INTERNET-DRAFT Expires: 14 May 2005 November 2004	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
[CCID 3 PROFILE], which is appropriate for flows that would prefer	form of selective reliability at the application layer. CCID 2 is
to minimize abrupt changes in the sending rate. For example, CCID 2	also recommended over CCID 3 for applications where the halving of
is recommended over CCID 3 for streaming media applications that	the sending rate in response to congestion is not likely to
buffer a considerable amount of data at the application receiver	interfere with application-level performance.
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	of TCP congestion control as the dominant transport protocol in the
applications might prefer the more well-known dynamics of TCP-like	Internet, some applications might prefer the more well-known
congestion control over that of newer congestion control mechanisms,	dynamics of TCP-like congestion control over that of newer
which haven't yet met the test of widespread Internet deployment.	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 [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.

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	TCP-like Congestion Control specified by CCID 2, not including
initiation and termination. The example is informative, not	connection initiation and termination. The example is informative,
normative.	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



Floyd/Kohler Section 3.2. [Page 7]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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
[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, rather than a TCP-like cumulative
acknowledgement.

The receiver returns the sum of received ECN Nonces via Ack	If the half-connection is ECN capable, the receiver returns the
Vector options, allowing the sender to probabilistically verify	sum of received ECN Nonces via Ack Vector options, allowing the
that the receiver is not misbehaving. DCCP-Ack packets from the	sender to probabilistically verify that the receiver is not
receiver are also sent as ECN-Capable, since the sender will	misbehaving. DCCP-Ack packets from the receiver are also sent
control the acknowledgement rate in a roughly TCP-friendly way	as ECN-Capable, since the sender will control the
using the Ack Ratio feature. There is little need for the	acknowledgement rate in a roughly TCP-friendly way using the Ack
receiver to verify the nonces of its DCCP-Ack packets, since the	Ratio feature. There is little need for the receiver to verify
sender cannot get significant benefit from misreporting the ack	the nonces of its DCCP-Ack packets, since the sender cannot get
mark rate.	significant benefit from misreporting the ack mark rate.

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 a DCCP-DataAck packet



Floyd/Kohler Section 3.2. [Page 8]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


that includes an 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 is used to determine 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 possibly for data included	Ack Vector, 1)" from the receiver, except for possible data included
on 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 [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.

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.)	DataAck, and occasionally DCCP-Request, DCCP-Response, and DCCP-
	Move.)
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.




Floyd/Kohler Section 5. [Page 9]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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 [RFC 2988]. (If more than one	deviation, and timeout value [RFC 2988]. (If more than one
measurement per round-trip time was used for these calculations,	round-trip time measurement per round-trip time was used for
then the weights of the averagers would have to be adjusted, so	these calculations, then the weights of the averagers would have
that the average round-trip time is effectively derived from	to be adjusted, so that the average round-trip time is
measurements over multiple round-trip times.) Because DCCP does	effectively derived from measurements over multiple round-trip
not retransmit data, DCCP does not require TCP's recommended	times.) Because DCCP does not retransmit data, DCCP does not
minimum timeout of one second. The exponential backoff of the	require TCP's recommended minimum timeout of one second. The
timer is exactly as in TCP. When a transmit timeout occurs, the	exponential backoff of the timer is exactly as in TCP. When a
sender sets pipe to zero. The adjustments to cwnd and ssthresh	transmit timeout occurs, the sender sets pipe to zero. The
are described below.	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.
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, 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



Floyd/Kohler Section 5. [Page 10]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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	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	congestion window is increased by one packet for every newly
acknowledged data packets with Ack Vector State 0 (not ECN-marked),	acknowledged data packet with Ack Vector State 0 (not ECN-marked),
up to a maximum of Ack Ratio/2 packets per acknowledgement. This is	up to a maximum of Ack Ratio packets per acknowledgement. This
a modified form of Appropriate Byte Counting [RFC 3465] that is	differs from TCP's historical behavior, which (in DCCP terms) would
consistent with TCP's current standard (which does not include byte-	increase cwnd by one per DCCP-Ack received, not by one per packet
counting), but allows CCID 2 to increase as aggressively as TCP when	newly acknowledged by some DCCP-Ack; but it is in line with TCP's
CCID-2's Ack Ratio is greater than the default value of two. When	behavior with Appropriate Byte Counting [RFC 3465]. 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 RFC 3390; the ssthresh	for new connections, following the rules from RFC 3390 [RFC 3390];
parameter is initialized to an arbitrarily high value.	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.

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, 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. RFC 2861, currently	a period exceeding the timeout interval. [RFC 2861], currently
Experimental, suggests a slightly more moderate mechanism where the	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. RFC 2861 essentially
suggests that TCP's congestion window not be increased during
application-limited periods, when the congestion window is not being
fully utilized.




Floyd/Kohler Section 5.1. [Page 11]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


5.2. Response to Data Dropped and Slow Receiver

As described in [DCCP], the Data Dropped option lets an endpoint
declare that a packet was dropped at the end host before delivery to
the application -- for instance, because of corruption or receive
buffer overflow. CCID 2 senders respond to these options as	buffer overflow. CCID 2 senders respond to packets acknowledged as
described in [DCCP], with the following further clarifications.	Data Dropped as described in [DCCP], 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 that 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. 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 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 (Section 11.4.2 of [DCCP]).

CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at
which DCCP-Ack packets are generated, thus controlling reverse-path



Floyd/Kohler Section 6. [Page 12]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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 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.

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	DCCP-Ack packets per round-trip time. The sender modifies R so as
rate roughly TCP-friendly by monitoring the acknowledgement stream	to keep the acknowledgement rate roughly TCP-friendly, by monitoring
for lost and marked DCCP-Ack packets, and modifying R accordingly.	the acknowledgement stream for lost and marked DCCP-Ack packets.
For every RTT containing a DCCP-Ack congestion event (that is, a
lost or 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 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.



Floyd/Kohler Section 6.1.1. [Page 13]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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 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 Section 11.3 of [DCCP].

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	sender SHOULD not attempt Ack Ratio renegotiations more than once
once per round-trip time. Additionally, it MAY bound Ack Ratio	per round-trip time. Additionally, it MAY bound Ack Ratio below by
below by two, or it MAY set Ack Ratio to one for half-connections	two, or it MAY set Ack Ratio to one for half-connections with
with persistent congestion windows of 1 or 2 packets.	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 that all of the
ack packets are dropped, 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.



Floyd/Kohler Section 6.1.2. [Page 14]

INTERNET-DRAFT Expires: 14 May 2005 November 2004


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.

6.2.1. Determining Quiescence

This section refers to quiescence in the DCCP sense (see Section	This section refers to quiescence in the DCCP sense (see section 8.1
11.1 of [DCCP]): How does a CCID 2 receiver determine that the	of [DCCP]): How does a CCID 2 receiver determine that the
corresponding sender is not sending any data?

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	for the other half-connection; or if it does not, it should use an
default RTT of 0.2 seconds, as described in Section 3.4 of [DCCP].)	estimated RTT of 0.1 seconds.) Once the sender acknowledges the
Once the sender acknowledges the receiver's Ack Vectors, and the	receiver's Ack Vectors, and the sender has not sent additional data
sender has not sent additional data for at least T seconds, the	for at least T seconds, the receiver can infer that the sender is
receiver can infer that the sender is quiescent. More precisely,	quiescent. More precisely, the receiver infers that the sender has
the receiver infers that the sender has gone quiescent when at least	gone quiescent when at least T seconds have passed without receiving
T seconds have passed without receiving any data from the sender,	any data from the sender, and the sender has acknowledged receiver
and the sender has acknowledged receiver Ack Vectors covering all	Ack Vectors covering all data packets received at the receiver.
data packets received at the receiver.

7. Explicit Congestion Notification

CCID 2 supports Explicit Congestion Notification (ECN) [RFC 3168].	Explicit Congestion Notif