[RFCs/IDs] [Plain Text] [From draft-ietf-dccp-ccid3]
PROPOSED STANDARD
Network Working Group S. Floyd
Request for Comments: 4342 ICIR
Category: Standards Track E. Kohler
UCLA
J. Padhye
Microsoft Research
March 2006
Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
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
3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion
Control Protocol (DCCP). CCID 3 should be used by senders that want
a TCP-friendly sending rate, possibly with Explicit Congestion
Notification (ECN), while minimizing abrupt rate changes.
Table of Contents
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Usage ...........................................................3
3.1. Relationship with TFRC .....................................4
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 ...........7
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Sizes ...............................................9
6. Acknowledgements ................................................9
6.1. Loss Interval Definition ..................................10
6.1.1. Loss Interval Lengths ..............................12
6.2. Congestion Control on Acknowledgements ....................13
Floyd, et al. Standards Track [Page 1]
RFC 4342 DCCP CCID3 TFRC March 2006
6.3. Acknowledgements of Acknowledgements ......................13
6.4. Determining Quiescence ....................................14
7. Explicit Congestion Notification ...............................14
8. Options and Features ...........................................14
8.1. Window Counter Value ......................................15
8.2. Elapsed Time Options ......................................17
8.3. Receive Rate Option .......................................17
8.4. Send Loss Event Rate Feature ..............................18
8.5. Loss Event Rate Option ....................................18
8.6. Loss Intervals Option .....................................18
8.6.1. Option Details .....................................19
8.6.2. Example ............................................20
9. Verifying Congestion Control Compliance with ECN ...............22
9.1. Verifying the ECN Nonce Echo ..............................22
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................23
10. Implementation Issues .........................................23
10.1. Timestamp Usage ..........................................23
10.2. Determining Loss Events at the Receiver ..................24
10.3. Sending Feedback Packets .................................25
11. Security Considerations .......................................27
12. IANA Considerations ...........................................28
12.1. Reset Codes ..............................................28
12.2. Option Types .............................................28
12.3. Feature Numbers ..........................................28
13. Thanks ........................................................29
A. Appendix: Possible Future Changes to CCID 3 ....................30
Normative References ..............................................31
Informative References ............................................31
List of Tables
Table 1: DCCP CCID 3 Options ......................................14
Table 2: DCCP CCID 3 Feature Numbers ..............................15
1. Introduction
This document contains the profile for Congestion Control Identifier
3, TCP-Friendly Rate Control (TFRC), 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.
TFRC is a receiver-based congestion control mechanism that provides a
TCP-friendly sending rate while minimizing the abrupt rate changes
characteristic of TCP or of TCP-like congestion control [RFC3448].
The sender's allowed sending rate is set in response to the loss
Floyd, et al. Standards Track [Page 2]
RFC 4342 DCCP CCID3 TFRC March 2006
event rate, which is typically reported by the receiver to the
sender. See Section 3 for more on application requirements.
2. Conventions
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].
All multi-byte numerical quantities in CCID 3, such as arguments to
options, are transmitted in network byte order (most significant byte
first).
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.
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.
This document uses a number of variables from [RFC3448], including
the following:
o X_recv: The receive rate in bytes per second. See [RFC3448],
Section 3.2.2.
o s: The packet size in bytes. See [RFC3448], Section 3.1.
o p: The loss event rate. See [RFC3448], Section 3.1.
3. Usage
CCID 3's TFRC congestion control is appropriate for flows that would
prefer to minimize abrupt changes in the sending rate, including
streaming media applications with small or moderate receiver
buffering before playback. TCP-like congestion control, such as that
of DCCP's CCID 2 [RFC4341], halves the sending rate in response to
each congestion event and thus cannot provide a relatively smooth
sending rate.
Floyd, et al. Standards Track [Page 3]
RFC 4342 DCCP CCID3 TFRC March 2006
As explained in [RFC3448], Section 1, the penalty of having smoother
throughput than TCP while competing fairly for bandwidth with TCP is
that the TFRC mechanism in CCID 3 responds slower to changes in
available bandwidth than do TCP or TCP-like mechanisms. Thus, CCID 3
should only be used for applications with a requirement for smooth
throughput. For applications that simply need to transfer as much
data as possible in as short a time as possible, we recommend using
TCP-like congestion control, such as CCID 2.
CCID 3 should also not be used by applications that change their
sending rate by varying the packet size, rather than by varying the
rate at which packets are sent. A new CCID will be required for
these applications.
3.1. Relationship with TFRC
The congestion control mechanisms described here follow the TFRC
mechanism standardized by the IETF [RFC3448]. Conforming CCID 3
implementations MAY track updates to the TCP throughput equation
directly, as updates are standardized in the IETF, rather than wait
for revisions of this document. However, conforming implementations
SHOULD wait for explicit updates to CCID 3 before implementing other
changes to TFRC congestion control.
3.2. Half-Connection Example
This example shows the typical progress of a half-connection using
CCID 3's TFRC Congestion Control, not including connection initiation
and termination. The example is informative, not normative.
1. The sender transmits DCCP-Data packets. Its sending rate is
governed by the allowed transmit rate as specified in [RFC3448],
Section 3.2. Each DCCP-Data packet has a sequence number and the
DCCP header's CCVal field contains the window counter value, which
is used by the receiver in determining when multiple losses belong
in a single loss event.
In the typical case of an ECN-capable half-connection, each DCCP-
Data and DCCP-DataAck packet is sent as ECN Capable, with either
the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce
with TFRC is described in Section 9.
2. The receiver sends DCCP-Ack packets acknowledging the data packets
at least once per round-trip time, unless the sender is sending at
a rate of less than one packet per round-trip time, as indicated
by the TFRC specification ([RFC3448], Section 6). Each DCCP-Ack
packet uses a sequence number, identifies the most recent packet
Floyd, et al. Standards Track [Page 4]
RFC 4342 DCCP CCID3 TFRC March 2006
received from the sender, and includes feedback about the recent
loss intervals experienced by the receiver.
3. The sender continues sending DCCP-Data packets as controlled by
the allowed transmit rate. Upon receiving DCCP-Ack packets, the
sender updates its allowed transmit rate as specified in
[RFC3448], Section 4.3. This update is based on a loss event rate
calculated by the sender using the receiver's loss intervals
feedback. If it prefers, the sender can also use a loss event
rate calculated and reported by the receiver.
4. The sender estimates round-trip times and calculates a nofeedback
time, as specified in [RFC3448], Section 4.4. If no feedback is
received from the receiver in that time (at least four round-trip
times), the sender halves its sending rate.
4. Connection Establishment
The client initiates the connection by using mechanisms described in
the DCCP specification [RFC4340]. During or after CCID 3
negotiation, the client and/or server may want to negotiate the
values of the Send Ack Vector and Send Loss Event Rate features.
5. Congestion Control on Data Packets
CCID 3 uses the congestion control mechanisms of TFRC [RFC3448]. The
following discussion summarizes information from [RFC3448], which
should be considered normative except where specifically indicated
otherwise.
Loss Event Rate
The basic operation of CCID 3 centers around the calculation of a
loss event rate: the number of loss events as a fraction of the
number of packets transmitted, weighted over the last several loss
intervals. This loss event rate, a round-trip time estimate, and the
average packet size are plugged into the TCP throughput equation, as
specified in [RFC3448], Section 3.1. The result is a fair transmit
rate close to what a modern TCP would achieve in the same conditions.
CCID 3 senders are limited to this fair rate.
The loss event rate itself is calculated in CCID 3 using recent loss
interval lengths reported by the receiver. Loss intervals are
precisely defined in Section 6.1. In summary, a loss interval is up
to 1 RTT of possibly lost or ECN-marked data packets, followed by an
arbitrary number of non-dropped, non-marked data packets. Thus, long
loss intervals represent low congestion rates. The CCID 3 Loss
Floyd, et al. Standards Track [Page 5]
RFC 4342 DCCP CCID3 TFRC March 2006
Intervals option is used to report loss interval lengths; see Section
8.6.
Other Congestion Control Mechanisms
The sender starts in a slow-start phase, roughly doubling its allowed
sending rate each round-trip time. The slow-start phase is ended by
the receiver's report of a data packet drop or mark, after which the
sender uses the loss event rate to calculate its allowed sending
rate.
[RFC3448], Section 4, specifies an initial sending rate of one packet
per round-trip time (RTT) as follows: The sender initializes the
allowed sending rate to one packet per second. As soon as a feedback
packet is received from the receiver, the sender has a measurement of
the round-trip time and then sets the initial allowed sending rate to
one packet per RTT. However, while the initial TCP window used to be
one segment, [RFC2581] allows an initial TCP window of two segments,
and [RFC3390] allows an initial TCP window of three or four segments
(up to 4380 bytes). [RFC3390] gives an upper bound on the initial
window of min(4*MSS, max(2*MSS, 4380 bytes)).
Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate
is allowed to be at least two packets per RTT, and at most four
packets per RTT, depending on the packet size. The initial rate is
only allowed to be three or four packets per RTT when, in terms of
segment size, that translates to at most 4380 bytes per RTT.
The sender's measurement of the round-trip time uses the Elapsed Time
and/or Timestamp Echo option contained in feedback packets, as
described in Section 8.2. The Elapsed Time option is required, while
the Timestamp Echo option is not. The sender maintains an average
round-trip time heavily weighted on the most recent measurements.
Each DCCP-Data packet contains a sequence number. Each DCCP-Data
packet also contains a window counter value, as described in Section
8.1. The window counter is generally incremented by one every
quarter round-trip time. The receiver uses it as a coarse-grained
timestamp to determine when a packet loss should be considered part
of an existing loss interval and when it must begin a new loss
interval.
Because TFRC is rate-based instead of window-based, and because
feedback packets can be dropped in the network, the sender needs some
mechanism for reducing its sending rate in the absence of positive
feedback from the receiver. As described in Section 6, the receiver
sends feedback packets roughly once per round-trip time. As
specified in [RFC3448], Section 4.3, the sender sets a nofeedback
Floyd, et al. Standards Track [Page 6]
RFC 4342 DCCP CCID3 TFRC March 2006
timer to at least four round-trip times, or to twice the interval
between data packets, whichever is larger. If the sender hasn't
received a feedback packet from the receiver when the nofeedback
timer expires, then the sender halves its allowed sending rate. The
allowed sending rate is never reduced below one packet per 64
seconds. Note that not all acknowledgements are considered feedback
packets, since feedback packets must contain valid Loss Intervals,
Elapsed Time, and Receive Rate options.
If the sender never receives a feedback packet from the receiver, and
as a consequence never gets to set the allowed sending rate to one
packet per RTT, then the sending rate is left at its initial rate of
one packet per second, with the nofeedback timer expiring after two
seconds. The allowed sending rate is halved each time the nofeedback
timer expires. Thus, if no feedback is received from the receiver,
the allowed sending rate is never above one packet per second and is
quickly reduced below one packet per second.
The feedback packets from the receiver contain a Receive Rate option
specifying the rate at which data packets arrived at the receiver
since the last feedback packet. The allowed sending rate can be at
most twice the rate received at the receiver in the last round-trip
time. This may be less than the nominal fair rate if, for example,
the application is sending less than its fair share.
5.1. Response to Idle and Application-Limited Periods
One consequence of the nofeedback timer is that the sender reduces
the allowed sending rate when the sender has been idle for a
significant period of time. In [RFC3448], Section 4.4, the allowed
sending rate is never reduced to fewer than two packets per round-
trip time as the result of an idle period. CCID 3 revises this to
take into account the larger initial windows allowed by [RFC3390]:
the allowed sending rate is never reduced to less than the [RFC3390]
initial sending rate as the result of an idle period. If the allowed
sending rate is less than the initial sending rate upon entry to the
idle period, then it will still be less than the initial sending rate
when the idle period is exited. However, if the allowed sending rate
is greater than or equal to the initial sending rate upon entry to
the idle period, then it should not be reduced below the initial
sending rate no matter how long the idle period lasts.
The sender's allowed sending rate is limited to at most twice the
receive rate reported by the receiver. Thus, after an application-
limited period, the sender can at most double its sending rate from
one round-trip time to the next, until it reaches the allowed sending
rate determined by the loss event rate.
Floyd, et al. Standards Track [Page 7]
RFC 4342 DCCP CCID3 TFRC March 2006
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. Its 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 3 senders respond to these options as described in
[RFC4340], with the following further clarifications.
o Drop Code 2 ("receive buffer drop"). The allowed sending rate is
reduced by one packet per RTT for each packet newly acknowledged
as Drop Code 2, except that it is never reduced below one packet
per RTT as a result of Drop Code 2.
o Adjusting the receive rate X_recv. A CCID 3 sender SHOULD also
respond to non-network-congestion events, such as those implied by
Data Dropped and Slow Receiver options, by adjusting X_recv, the
receive rate reported by the receiver in Receive Rate options (see
Section 8.3). The CCID 3 sender's allowed sending rate is limited
to at most twice the receive rate reported by the receiver via the
"min(..., 2*X_recv)" clause in TFRC's throughput calculations
([RFC3448], Section 4.3). When the sender receives one or more
Data Dropped and Slow Receiver options, the sender adjusts X_recv
as follows:
1. X_inrecv is equal to the Receive Rate in bytes per second
reported by the receiver in the most recent acknowledgement.
2. X_drop is set to the sending rate upper bound implied by Data
Dropped and Slow Receiver options. If the sender receives a
Slow Receiver option, which requests that the sender not
increase its sending rate for roughly a round-trip time
[RFC4340], then X_drop should be set to X_inrecv. Similarly,
if the sender receives a Data Dropped option indicating, for
example, that three packets were dropped with Drop Code 2, then
the upper bound on the sending rate will be decreased by at
most three packets per RTT, by the sender setting X_drop to
max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
Again, s is the packet size in bytes.
3. X_recv is then set to min(X_inrecv, X_drop/2).
As a result, the next round-trip time's sending rate will be
limited to at most 2*(X_drop/2) = X_drop. The effects of the Slow
Receiver and Data Dropped options on X_recv will mostly vanish by
Floyd, et al. Standards Track [Page 8]
RFC 4342 DCCP CCID3 TFRC March 2006
the round-trip time after that, which is appropriate for this
non-network-congestion feedback. This procedure MUST only be used
for those Drop Codes not related to corruption (see [RFC4340]).
Currently, this is limited to Drop Codes 0, 1, and 2.
5.3. Packet Sizes
CCID 3 is intended for applications that use a fixed packet size, and
that vary their sending rate in packets per second in response to
congestion. CCID 3 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. However,
some attention might be required for applications using CCID 3 that
vary their packet size not in response to congestion, but in response
to other application-level requirements.
The packet size s is used in the TCP throughput equation. A CCID 3
implementation MAY calculate s as the segment size averaged over
multiple round trip times -- for example, over the most recent four
loss intervals, for loss intervals as defined in Section 6.1.
Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
to derive s. In this case, s is set to the Maximum Segment Size
(MSS), the maximum size in bytes for the data segment, not including
the default DCCP and IP packet headers. Each packet transmitted then
counts as one MSS, regardless of the actual segment size, and the TCP
throughput equation can be interpreted as specifying the sending rate
in packets per second.
CCID 3 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
The receiver sends a feedback packet to the sender roughly once per
round-trip time, if the sender is sending packets that frequently.
This rate is determined by the TFRC protocol as specified in
[RFC3448], Section 6.
Each feedback packet contains an Acknowledgement Number, which equals
the greatest valid sequence number received so far on this
connection. ("Greatest" is, of course, measured in circular sequence
space.) Each feedback packet also includes at least the following
options:
Floyd, et al. Standards Track [Page 9]
RFC 4342 DCCP CCID3 TFRC March 2006
1. An Elapsed Time and/or Timestamp Echo option specifying the amount
of time elapsed since the arrival at the receiver of the packet
whose sequence number appears in the Acknowledgement Number field.
These options are described in [RFC4340], Section 13.
2. A Receive Rate option, defined in Section 8.3, specifying the rate
at which data was received since the last DCCP-Ack was sent.
3. A Loss Intervals option, defined in Section 8.6, specifying the
most recent loss intervals experienced by the receiver. (The
definition of a loss interval is provided below.) From Loss
Intervals, the sender can easily calculate the loss event rate p
using the procedure described in [RFC3448], Section 5.4.
Acknowledgements not containing at least these three options are not
considered feedback packets.
The receiver MAY also include other options concerning the loss event
rate, including Loss Event Rate, which gives the loss event rate
calculated by the receiver (Section 8.5), and DCCP's generic Ack
Vector option, which reports the specific sequence numbers of any
lost or marked packets ([RFC4340], Section 11.4). Ack Vector is not
required by CCID 3's congestion control mechanisms: the Loss
Intervals option provides all the information needed to manage the
transmit rate and probabilistically verify receiver feedback.
However, Ack Vector may be useful for applications that need to
determine exactly which packets were lost. The receiver MAY also
include other acknowledgement-related options, such as DCCP's Data
Dropped option ([RFC4340], Section 11.7).
If the HC-Receiver is also sending data packets to the HC-Sender,
then it MAY piggyback acknowledgement information on those data
packets more frequently than TFRC's specified acknowledgement rate
allows.
6.1. Loss Interval Definition
As described in [RFC3448], Section 5.2, a loss interval begins with a
lost or ECN-marked data packet; continues with at most one round-trip
time's worth of packets that may or may not be lost or marked; and
completes with an arbitrarily long series of non-dropped, non-marked
data packets. For example, here is a single loss interval, assuming
that sequence numbers increase as you move right:
Floyd, et al. Standards Track [Page 10]
RFC 4342 DCCP CCID3 TFRC March 2006
Lossy Part
<= 1 RTT __________ Lossless Part __________
/ \/ \
*----*--*--*-------------------------------------
^ ^ ^ ^
losses or marks
Note that a loss interval's lossless part might be empty, as in the
first interval below:
Lossy Part Lossy Part
<= 1 RTT <= 1 RTT _____ Lossless Part _____
/ \/ \/ \
*----*--*--***--------*-*---------------------------
^ ^ ^ ^^^ ^ ^
\_ Int. 1 _/\_____________ Interval 2 _____________/
As in [RFC3448], Section 5.2, the length of the lossy part MUST be
less than or equal to 1 RTT. CCID 3 uses window counter values, not
receive times, to determine whether multiple packets occurred in the
same RTT and thus belong to the same loss event; see Section 10.2. A
loss interval whose lossy part lasts for more than 1 RTT, or whose
lossless part contains a dropped or marked data packet, is invalid.
A missing data packet doesn't begin a new loss interval until NDUPACK
packets have been seen after the "hole", where NDUPACK = 3. Thus, up
to NDUPACK of the most recent sequence numbers (including the
sequence numbers of any holes) might temporarily not be part of any
loss interval while the implementation waits to see whether a hole
will be filled. See [RFC3448], Section 5.1, and [RFC2581], Section
3.2, for further discussion of NDUPACK.
As specified by [RFC3448], Section 5, all loss intervals except the
first begin with a lost or marked data packet, and all loss intervals
are as long as possible, subject to the validity constraints above.
Lost and ECN-marked non-data packets may occur freely in the lossless
part of a loss interval. (Non-data packets consist of those packet
types that cannot carry application data; namely, DCCP-Ack, DCCP-
Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.) In
the absence of better information, a receiver MUST conservatively
assume that every lost packet was a data packet and thus must occur
in some lossy part. DCCP's NDP Count option can help the receiver
determine whether a particular packet contained data; see [RFC4340],
Section 7.7.
Floyd, et al. Standards Track [Page 11]
RFC 4342 DCCP CCID3 TFRC March 2006
6.1.1. Loss Interval Lengths
[RFC3448] defines the TFRC congestion control mechanism in terms of a
one-way transfer of data, with data packets going from the sender to
the receiver and feedback packets going from the receiver back to the
sender. However, CCID 3 applies in a context of two half-
connections, with DCCP-Data and DCCP-DataAck packets from one half-
connection sharing sequence number space with DCCP-Ack packets from
the other half-connection. For the purposes of CCID 3 congestion
control, loss interval lengths should include data packets and should
exclude the acknowledgement packets from the reverse half-connection.
However, it is also useful to report the total number of packets in
each loss interval (for example, to facilitate ECN Nonce
verification).
CCID 3's Loss Intervals option thus reports three lengths for each
loss interval, the lengths of the lossy and lossless parts defined
above and a separate data length. First, the lossy and lossless
lengths are measured in sequence numbers. Together, they sum to the
interval's sequence length, which is the total number of packets the
sender transmitted during the interval. This is easily calculated in
DCCP as the greatest packet sequence number in the interval minus the
greatest packet sequence number in the preceding interval (or, if
there is no preceding interval, then the predecessor to the half-
connection's initial sequence number). The interval's data length,
however, is the number used in TFRC's loss event rate calculation, as
defined in [RFC3448], Section 5, and is calculated as follows.
For all loss intervals except the first, the data length equals the
sequence length minus the number of non-data packets the sender
transmitted during the loss interval, except that the minimum data
length is one packet. In the absence of better information, an
endpoint MUST conservatively assume that the loss interval contained
only data packets, in which case the data length equals the sequence
length. To achieve greater precision, the sender can calculate the
exact number of non-data packets in an interval by remembering which
sent packets contained data; the receiver can account for received
non-data packets by not including them in the data length, and for
packets that were not received, it may be able to discriminate
between lost data packets and lost non-data packets using DCCP's NDP
Count option.
The first loss interval's data length is undefined until the first
loss event. [RFC3448], Section 6.3.1 specifies how the first loss
interval's data length is calculated once the first loss event has
occurred; this calculation uses X_recv, the most recent receive rate,
as input. Until this first loss event, the loss event rate is zero,
Floyd, et al. Standards Track [Page 12]
RFC 4342 DCCP CCID3 TFRC March 2006
as is the data length reported for the interval in the Loss Intervals
option.
The first loss interval's data length might be less than, equal to,
or even greater than its sequence length. Any other loss interval's
data length must be less than or equal to its sequence length.
A sender MAY use the loss event rate or loss interval data lengths as
reported by the receiver, or it MAY recalculate loss event rate
and/or loss interval data lengths based on receiver feedback and
additional information. For example, assume the network drops a
DCCP-Ack packet with sequence number 50. The receiver might then
report a loss interval beginning at sequence number 50. If the
sender determined that this loss interval actually contained no lost
or ECN-marked data packets, then it might coalesce the loss interval
with the previous loss interval, resulting in a larger allowed
transmit rate.
6.2. Congestion Control on Acknowledgements
The rate and timing for generating acknowledgements is determined by
the TFRC algorithm ([RFC3448], Section 6). The sending rate for
acknowledgements is relatively low -- roughly once per round-trip
time -- so there is no need for explicit congestion control on
acknowledgements.
6.3. Acknowledgements of Acknowledgements
TFRC acknowledgements don't generally need to be reliable, so the
sender generally need not acknowledge the receiver's
acknowledgements. When Ack Vector or Data Dropped is used, however,
the sender, DCCP A, MUST occasionally acknowledge the receiver's
acknowledgements so that the receiver can free up Ack Vector or Data
Dropped state. When both half-connections are active, the necessary
acknowledgements will be contained in A's acknowledgements to B's
data. If the B-to-A half-connection goes quiescent, however, DCCP A
must send an acknowledgement proactively.
Thus, when Ack Vector or Data Dropped is used, an active sender MUST
acknowledge the receiver's acknowledgements approximately once per
round-trip time, within a factor of two or three, probably by sending
a DCCP-DataAck packet. No acknowledgement options are necessary,
just the Acknowledgement Number in the DCCP-DataAck header.
The sender MAY choose to acknowledge the receiver's acknowledgements
even if they do not contain Ack Vectors or Data Dropped options. For
instance, regular acknowledgements can shrink the size of the Loss
Intervals option. Unlike Ack Vector and Data Dropped, however, the
Floyd, et al. Standards Track [Page 13]
RFC 4342 DCCP CCID3 TFRC March 2006
Loss Intervals option is bounded in size (and receiver state), so
acks-of-acks are not required.
6.4. Determining Quiescence
This section describes how a CCID 3 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. (A
CCID 3 receiver has a rough measure of the round-trip time so that it
can pace its acknowledgements.) The receiver detects that the sender
has gone quiescent after T seconds have passed without receiving any
additional data from the sender.
7. Explicit Congestion Notification
CCID 3 supports Explicit Congestion Notification (ECN) [RFC3168]. In
the typical case of an ECN-capable half-connection (where the
receiver's ECN Incapable feature is set to zero), the sender will use
the ECN Nonce for its data packets, as specified in [RFC4340],
Section 12.2. Information about the ECN Nonce MUST be returned by
the receiver using the Loss Intervals option, and any Ack Vector
options MUST include the ECN Nonce Sum. The sender MAY maintain a
table with the ECN nonce sum for each packet and use this information
to probabilistically verify the ECN nonce sums returned in Loss
Intervals or Ack Vector options. Section 9 describes this further.
8. Options and Features
CCID 3 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo,
and Elapsed Time options, and its Send Ack Vector and ECN Incapable
features. In addition, the following CCID-specific options are
defined for use with CCID 3.
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-191 Reserved
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195-255 Reserved
Table 1: DCCP CCID 3 Options
Floyd, et al. Standards Track [Page 14]
RFC 4342 DCCP CCID3 TFRC March 2006
The "DCCP-Data?" column indicates that all currently defined CCID 3-
specific options MUST be ignored when they occur on DCCP-Data
packets.
The following CCID-specific feature is also defined.
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-191 Reserved
192 Send Loss Event Rate SP 0 N 8.4
193-255 Reserved
Table 2: DCCP CCID 3 Feature Numbers
The column meanings are described in [RFC4340], Table 4. "Rec'n
Rule" defines the feature's reconciliation rule, where "SP" means
server-priority. "Req'd" specifies whether every CCID 3
implementation MUST understand a feature; Send Loss Event Rate is
optional, in that it behaves like an extension ([RFC4340], Section
15).
8.1. Window Counter Value
The data sender stores a 4-bit window counter value in the DCCP
generic header's CCVal field on every data packet it sends. This
value is set to 0 at the beginning of the transmission and generally
increased by 1 every quarter of a round-trip time, as described in
[RFC3448], Section 3.2.1. Window counters use circular arithmetic
modulo 16 for all operations, including comparisons; see [RFC4340],
Section 3.1, for more information on circular arithmetic. For
reference, the DCCP generic header is as follows. (The diagram is
repeated from [RFC4340], Section 5.1, which also shows the generic
header with a 24-bit Sequence Number field.)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |1| Reserved | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Floyd, et al. Standards Track [Page 15]
RFC 4342 DCCP CCID3 TFRC March 2006
The CCVal field has enough space to express 4 round-trip times at
quarter-RTT granularity. The sender MUST avoid wrapping CCVal on
adjacent packets, as might happen, for example, if two data-carrying
packets were sent 4 round-trip times apart with no packets
intervening. Therefore, the sender SHOULD use the following
algorithm for setting CCVal. The algorithm uses three variables:
"last_WC" holds the last window counter value sent, "last_WC_time" is
the time at which the first packet with window counter value
"last_WC" was sent, and "RTT" is the current round-trip time
estimate. last_WC is initialized to zero, and last_WC_time to the
time of the first packet sent. Before sending a new packet, proceed
like this:
Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)).
If quarter_RTTs > 0, then:
Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16.
Set last_WC_time := current_time.
Set the packet header's CCVal field to last_WC.
When this algorithm is used, adjacent data-carrying packets' CCVal
counters never differ by more than five, modulo 16.
The window counter value may also change as feedback packets arrive.
In particular, after receiving an acknowledgement for a packet sent
with window counter WC, the sender SHOULD increase its window
counter, if necessary, so that subsequent packets have window counter
value at lea