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:
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.
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,
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
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
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 least (WC + 4) mod 16.
The CCVal counters are used by the receiver to determine whether
multiple losses belong to a single loss event, to determine the
interval to use for calculating the receive rate, and to determine
when to send feedback packets. None of these procedures require the
receiver to maintain an explicit estimate of the round-trip time.
However, implementors who wish to keep such an RTT estimate may do so
using CCVal. Let T(I) be the arrival time of the earliest valid
received packet with CCVal = I. (Of course, when the window counter
value wraps around to the same value mod 16, we must recalculate
T(I).) Let D = 2, 3, or 4 and say that T(K) and T(K+D) both exist
(packets were received with window counters K and K+D). Then the
value (T(K+D) - T(K)) * 4/D MAY serve as an estimate of the round-
trip time. Values of D = 4 SHOULD be preferred for RTT estimation.
Concretely, say that the following packets arrived:
Time: T1 T2 T3 T4 T5 T6 T7 T8 T9
------*---*---*-*----*------------*---*----*--*---->
CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4
Then T7 - T3, the difference between the receive times of the first
packet received with window counter K+4 and the first packet received
with window counter K, is a reasonable round-trip time estimate.
Because of the necessary constraint that measurements only come from
packet pairs whose CCVals differ by at most 4, this procedure does
not work when the inter-packet sending times are significantly
greater than the RTT, resulting in packet pairs whose CCVals differ
by 5. Explicit RTT measurement techniques, such as Timestamp and
Timestamp Echo, should be used in that case.
8.2. Elapsed Time Options
The data receiver MUST include an elapsed time value on every
required acknowledgement. This helps the sender distinguish between
network round-trip time, which it must include in its rate equations,
and delay at the receiver due to TFRC’s infrequent acknowledgement
rate, which it need not include. The receiver MUST at least include
an Elapsed Time option on every feedback packet, but if at least one
recent data packet (i.e., a packet received after the previous DCCP-
Ack was sent) included a Timestamp option, then the receiver SHOULD
include the corresponding Timestamp Echo option, with Elapsed Time
value, as well. All of these option types are defined in the main
DCCP specification [RFC4340].
8.3. Receive Rate Option
+--------+--------+--------+--------+--------+--------+
|11000010|00000110| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=6
This option MUST be sent by the data receiver on all required
acknowledgements. Its four data bytes indicate the rate at which the
receiver has received data since it last sent an acknowledgement, in
bytes per second. To calculate this receive rate, the receiver sets
t to the larger of the estimated round-trip time and the time since
the last Receive Rate option was sent. (Received data packets’
window counters can be used to produce a suitable RTT estimate, as
described in Section 8.1.) The receive rate then equals the number
of data bytes received in the most recent t seconds, divided by t.
Receive Rate options MUST NOT be sent on DCCP-Data packets, and any
Receive Rate options on received DCCP-Data packets MUST be ignored.
8.4. Send Loss Event Rate Feature
The Send Loss Event Rate feature lets CCID 3 endpoints negotiate
whether the receiver MUST provide Loss Event Rate options on its
acknowledgements. DCCP A sends a "Change R(Send Loss Event Rate, 1)"
option to ask DCCP B to send Loss Event Rate options as part of its
acknowledgement traffic.
Send Loss Event Rate has feature number 192 and is server-priority.
It takes one-byte Boolean values. DCCP B MUST send Loss Event Rate
options on its acknowledgements when Send Loss Event Rate/B is one,
although it MAY send Loss Event Rate options even when Send Loss
Event Rate/B is zero. Values of two or more are reserved. A CCID 3
half-connection starts with Send Loss Event Rate equal to zero.
8.5. Loss Event Rate Option
+--------+--------+--------+--------+--------+--------+
|11000000|00000110| Loss Event Rate |
+--------+--------+--------+--------+--------+--------+
Type=192 Len=6
The option value indicates the inverse of the loss event rate,
rounded UP, as calculated by the receiver. Its units are data
packets per loss interval. Thus, if the Loss Event Rate option value
is 100, then the loss event rate is 0.01 loss events per data packet
(and the average loss interval contains 100 data packets). When each
loss event has exactly one data packet loss, the loss event rate is
the same as the data packet drop rate.
See [RFC3448], Section 5, for a normative calculation of loss event
rate. Before any losses have occurred, when the loss event rate is
zero, the Loss Event Rate option value is set to
"11111111111111111111111111111111" in binary (or, equivalently, to
2^32 - 1). The loss event rate calculation uses loss interval data
lengths, as defined in Section 6.1.1.
Loss Event Rate options MUST NOT be sent on DCCP-Data packets, and
any Loss Event Rate options on received DCCP-Data packets MUST be
ignored.
8.6. Loss Intervals Option
+--------+--------+--------+--------...--------+--------+---
|11000001| Length | Skip | Loss Interval | More Loss
| | | Length | | Intervals...
+--------+--------+--------+--------...--------+--------+---
Type=193 9 bytes
Each 9-byte Loss Interval contains three fields, as follows:
____________________ Loss Interval _____________________
/ \
+--------...-------+--------...--------+--------...--------+
| Lossless Length |E| Loss Length | Data Length |
+--------...-------+--------...--------+--------...--------+
3 bytes 3 bytes 3 bytes
The receiver reports its observed loss intervals using a Loss
Intervals option. Section 6.1 defines loss intervals. This option
MUST be sent by the data receiver on all required acknowledgements.
The option reports up to 28 loss intervals seen by the receiver,
although TFRC currently uses at most the latest 9 of these. This
lets the sender calculate a loss event rate and probabilistically
verify the receiver’s ECN Nonce Echo.
The Loss Intervals option serves several purposes.
o The sender can use the Loss Intervals option to calculate the loss
event rate.
o Loss Intervals information is easily checked for consistency
against previous Loss Intervals options, and against any Loss
Event Rate calculated by the receiver.
o The sender can probabilistically verify the ECN Nonce Echo for
each Loss Interval, reducing the likelihood of misbehavior.
Loss Intervals options MUST NOT be sent on DCCP-Data packets, and any
Loss Intervals options on received DCCP-Data packets MUST be ignored.
8.6.1. Option Details
The Loss Intervals option contains information about one to 28
consecutive loss intervals, always including the most recent loss
interval. Intervals are listed in reverse chronological order.
Should more than 28 loss intervals need to be reported, then multiple
Loss Intervals options can be sent; the second option begins where
the first left off, and so forth. The options MUST contain
information about at least the most recent NINTERVAL + 1 = 9 loss
intervals unless (1) there have not yet been NINTERVAL + 1 loss
intervals, or (2) the receiver knows, because of the sender’s
acknowledgements, that some previously transmitted loss interval
information has been received. In this second case, the receiver
need not send loss intervals that the sender already knows about,
except that it MUST transmit at least one loss interval regardless.
The NINTERVAL parameter is equal to "n" as defined in [RFC3448],
Section 5.4.
Loss interval sequence numbers are delta encoded starting from the
Acknowledgement Number. Therefore, Loss Intervals options MUST NOT
be sent on packets without an Acknowledgement Number, and any Loss
Intervals options received on such packets MUST be ignored.
The first byte of option data is Skip Length, which indicates the
number of packets up to and including the Acknowledgement Number that
are not part of any Loss Interval. As discussed above, Skip Length
must be less than or equal to NDUPACK = 3. In a packet containing
multiple Loss Intervals options, the Skip Lengths of the second and
subsequent options MUST equal zero; such options with nonzero Skip