Lengths MUST be ignored.
Loss Interval structures follow Skip Length. Each Loss Interval
consists of a Lossless Length, a Loss Length, an ECN Nonce Echo (E),
and a Data Length.
Lossless Length, a 24-bit number, specifies the number of packets in
the loss interval’s lossless part. Note again that this part may
contain lost or marked non-data packets.
Loss Length, a 23-bit number, specifies the number of packets in the
loss interval’s lossy part. The sum of the Lossless Length and the
Loss Length equals the loss interval’s sequence length. Receivers
SHOULD report the minimum valid Loss Length for each loss interval,
making the first and last sequence numbers in each lossy part
correspond to lost or marked data packets.
The ECN Nonce Echo, stored in the high-order bit of the 3-byte field
containing Loss Length, equals the one-bit sum (exclusive-or, or
parity) of data packet nonces received over the loss interval’s
lossless part (which is Lossless Length packets long). If Lossless
Length is 0, the receiver is ECN Incapable, or the Lossless Length
contained no data packets, then the ECN Nonce Echo MUST be reported
as 0. Note that any ECN nonces on received non-data packets MUST NOT
contribute to the ECN Nonce Echo.
Finally, Data Length, a 24-bit number, specifies the loss interval’s
data length, as defined in Section 6.1.1.
8.6.2. Example
Consider the following sequence of packets, where "-" represents a
safely delivered packet and "*" represents a lost or marked packet.
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Assuming that packet 43 was lost, not marked, this sequence might be
divided into loss intervals as follows:
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
A Loss Intervals option sent on a packet with Acknowledgement Number
44 to acknowledge this set of loss intervals might contain the bytes
193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8,
0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. This option is interpreted as
follows.
193 The Loss Intervals option number.
39 The length of the option, including option type and length bytes.
This option contains information about (39 - 3)/9 = 4 loss
intervals.
2 The Skip Length is 2 packets. Thus, the most recent loss
interval, L3, ends immediately before sequence number 44 - 2 + 1
= 43.
0,0,10, 128,0,1, 0,0,10
These bytes define L3. L3 consists of a 10-packet lossless part
(0,0,10), preceded by a 1-packet lossy part. Continuing to
subtract, the lossless part begins with sequence number 43 - 10 =
33, and the lossy part begins with sequence number 33 - 1 = 32.
The ECN Nonce Echo for the lossless part (namely, packets 33
through 42, inclusive) equals 1. The interval’s data length is
10, so the receiver believes that the interval contained exactly
one non-data packet.
0,0,8, 0,0,5, 0,0,10
This defines L2, whose lossless part begins with sequence number
32 - 8 = 24; whose lossy part begins with sequence number 24 - 5
= 19; whose ECN Nonce Echo (for packets [24,31]) equals 0; and
whose data length is 10.
0,0,8, 0,0,1, 0,0,8
L1’s lossless part begins with sequence number 11, its lossy part
begins with sequence number 10, its ECN Nonce Echo (for packets
[11,18]) equals 0, and its data length is 8.
0,0,10, 128,0,0, 0,0,15
L0’s lossless part begins with sequence number 0, it has no lossy
part, its ECN Nonce Echo (for packets [0,9]) equals 1, and its
data length is 15. (This must be the first loss interval in the
connection; otherwise, a data length greater than the sequence
length would be invalid.)
9. Verifying Congestion Control Compliance with ECN
The sender can use Loss Intervals options’ ECN Nonce Echoes (and
possibly any Ack Vectors’ ECN Nonce Echoes) to probabilistically
verify that the receiver is correctly reporting all dropped or marked
packets. Even if ECN is not used (the receiver’s ECN Incapable
feature is set to one), the sender could still check on the receiver
by occasionally not sending a packet, or sending a packet out-of-
order, to catch the receiver in an error in Loss Intervals or Ack
Vector information. This is not as robust or non-intrusive as the
verification provided by the ECN Nonce, however.
9.1. Verifying the ECN Nonce Echo
To verify the ECN Nonce Echo included with a Loss Intervals option,
the sender maintains a table with the ECN nonce sum for each data
packet. As defined in [RFC3540], the nonce sum for sequence number S
is the one-bit sum (exclusive-or, or parity) of data packet nonces
over the sequence number range [I,S], where I is the initial sequence
number. Let NonceSum(S) represent this nonce sum for sequence number
S, and define NonceSum(I - 1) as 0. Note that NonceSum does not
account for the nonces of non-data packets such as DCCP-Ack. Then
the Nonce Echo for an interval of packets with sequence numbers X to
Y, inclusive, should equal the following one-bit sum:
NonceSum(X - 1) + NonceSum(Y)
Since an ECN Nonce Echo is returned for the lossless part of each
Loss Interval, a misbehaving receiver -- meaning a receiver that
reports a lost or marked data packet as "received non-marked", to
avoid rate reductions -- has only a 50% chance of guessing the
correct Nonce Echo for each loss interval.
To verify the ECN Nonce Echo included with an Ack Vector option, the
sender maintains a table with the ECN nonce value sent for each
packet. The Ack Vector option explicitly says which packets were
received non-marked; the sender just adds up the nonces for those
packets using a one-bit sum and compares the result to the Nonce Echo
encoded in the Ack Vector’s option type. Again, a misbehaving
receiver has only a 50% chance of guessing an Ack Vector’s correct
Nonce Echo. Alternatively, an Ack Vector’s ECN Nonce Echo may also
be calculated from a table of ECN nonce sums, rather than from ECN
nonces. If the Ack Vector contains many long runs of non-marked,
non-dropped packets, the nonce sum-based calculation will probably be
faster than a straightforward nonce-based calculation.
Note that Ack Vector’s ECN Nonce Echo is measured over both data
packets and non-data packets, while the Loss Intervals option reports
ECN Nonce Echoes for data packets only. Thus, different nonce sum
tables are required to verify the two options.
9.2. Verifying the Reported Loss Intervals and Loss Event Rate
Besides probabilistically verifying the ECN Nonce Echoes reported by
the receiver, the sender may also verify the loss intervals and any
loss event rate reported by the receiver, if it so desires.
Specifically, the Loss Intervals option explicitly reports the size
of each loss interval as seen by the receiver; the sender can verify
that the receiver is not falsely combining two loss events into one
reported Loss Interval by using saved window counter information.
The sender can also compare any Loss Event Rate option to the loss
event rate it calculates using the Loss Intervals option.
Note that in some cases the loss event rate calculated by the sender
could differ from an explicit Loss Event Rate option sent by the
receiver. In particular, when a number of successive packets are
dropped, the receiver does not know the sending times for these
packets and interprets these losses as a single loss event. In
contrast, if the sender has saved the sending times or window counter
information for these packets, then the sender can determine if these
losses constitute a single loss event or several successive loss
events. Thus, with its knowledge of the sending times of dropped
packets, the sender is able to make a more accurate calculation of
the loss event rate. These kinds of differences SHOULD NOT be
misinterpreted as attempted receiver misbehavior.
10. Implementation Issues
10.1. Timestamp Usage
CCID 3 data packets need not carry Timestamp options. The sender can
store the times at which recent packets were sent; the
Acknowledgement Number and Elapsed Time option contained on each
required acknowledgement then provide sufficient information to
compute the round trip time. Alternatively, the sender MAY include
Timestamp options on some of its data packets. The receiver will
respond with Timestamp Echo options including Elapsed Times, allowing
the sender to calculate round-trip times without storing sent
packets’ timestamps at all.
10.2. Determining Loss Events at the Receiver
The window counter is used by the receiver to determine whether
multiple lost packets belong to the same loss event. The sender
increases the window counter by one every quarter round-trip time.
This section describes in detail the procedure for using the window
counter to determine when two lost packets belong to the same loss
event.
[RFC3448], Section 3.2.1 specifies that each data packet contains a
timestamp and gives as an alternative implementation a "timestamp"
that is incremented every quarter of an RTT, as is the window counter
in CCID 3. However, [RFC3448], Section 5.2 on "Translation from Loss
History to Loss Events" is written in terms of timestamps, not in
terms of window counters. In this section, we give a procedure for
the translation from loss history to loss events that is explicitly
in terms of window counters.
To determine whether two lost packets with sequence numbers X and Y
belong to different loss events, the receiver proceeds as follows.
Assume Y > X in circular sequence space.
o Let X_prev be the greatest valid sequence number received with
X_prev < X.
o Let Y_prev be the greatest valid sequence number received with
Y_prev < Y.
o Given a sequence number N, let C(N) be the window counter value
associated with that packet.
o Packets X and Y belong to different loss events if there exists a
packet with sequence number S so that X_prev < S <= Y_prev, and
the distance from C(X_prev) to C(S) is greater than 4. (The
distance is the number D so that C(X_prev) + D = C(S) (mod
WCTRMAX), where WCTRMAX is the maximum value for the window
counter -- in our case, 16.)
That is, the receiver only considers losses X and Y as separate
loss events if there exists some packet S received between X and
Y, with the distance from C(X_prev) to C(S) greater than 4. This
complex calculation is necessary in order to handle the case where
window counter space wrapped completely between X and Y. When
that space does not wrap, the receiver can simply check whether
the distance from C(X_prev) to C(Y_prev) is greater than 4; if so,
then X and Y belong to separate loss events.
Window counters can help the receiver disambiguate multiple losses
after a sudden decrease in the actual round-trip time. When the
sender receives an acknowledgement acknowledging a data packet with
window counter i, the sender increases its window counter, if
necessary, so that subsequent data packets are sent with window
counter values of at least i+4. This can help minimize errors where
the receiver incorrectly interprets multiple loss events as a single
loss event.
We note that if all of the packets between X and Y are lost in the
network, then X_prev and Y_prev are equal, and the series of
consecutive losses is treated by the receiver as a single loss event.
However, the sender will receive no DCCP-Ack packets during a period
of consecutive losses, and the sender will reduce its sending rate
accordingly.
As an alternative to the window counter, the sender could have sent
its estimate of the round-trip time to the receiver directly in a
round-trip time option; the receiver would use the sender’s round-
trip time estimate to infer when multiple lost or marked packets
belong in the same loss event. In some respects, a round-trip time
option would give a more precise encoding of the sender’s round-trip
time estimate than does the window counter. However, the window
counter conveys information about the relative *sending* times for
packets, while the receiver could only use the round-trip time option
to distinguish between the relative *receive* times (in the absence
of timestamps). That is, the window counter will give more robust
performance when there is a large variation in delay for packets sent
within a window of data. Slightly more speculatively, a round-trip
time option might possibly be used more easily by middleboxes
attempting to verify that a flow used conforming end-to-end
congestion control.
10.3. Sending Feedback Packets
[RFC3448], Sections 6.1 and 6.2 specify that the TFRC receiver must
send a feedback packet when a newly calculated loss event rate p is
greater than its previous value. CCID 3 follows this rule.
In addition, [RFC3448], Section 6.2, specifies that the receiver use
a feedback timer to decide when to send additional feedback packets.
If the feedback timer expires and data packets have been received
since the previous feedback was sent, then the receiver sends a
feedback packet. When the feedback timer expires, the receiver
resets the timer to expire after R_m seconds, where R_m is the most
recent estimate of the round-trip time received from the sender.
CCID 3 receivers, however, generally use window counter values
instead of a feedback timer to determine when to send additional
feedback packets. This section describes how.
Whenever the receiver sends a feedback message, the receiver sets a
local variable last_counter to the greatest received value of the
window counter since the last feedback message was sent, if any data
packets have been received since the last feedback message was sent.
If the receiver receives a data packet with a window counter value
greater than or equal to last_counter + 4, then the receiver sends a
new feedback packet. ("Greater" and "greatest" are measured in
circular window counter space.)
This procedure ensures that when the sender is sending at a rate less
than one packet per round-trip time, the receiver sends a feedback
packet after each data packet. Similarly, this procedure ensures
that when the sender is sending several packets per round-trip time,
the receiver will send a feedback packet each time that a data packet
arrives with a window counter at least four greater than the window
counter when the last feedback packet was sent. Thus, the feedback
timer is not necessary when the window counter is used.
However, the feedback timer still could be useful in some rare cases
to prevent the sender from unnecessarily halving its sending rate.
In particular, one could construct scenarios where the use of the
feedback timer at the receiver would prevent the unnecessary
expiration of the nofeedback timer at the sender. Consider the case
below, in which a feedback packet is sent when a data packet arrives
with a window counter of K.
Window
Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ...
| | | | | | | | | |
Data | | | | | | | | | |
Packets | | | | | | | | | |
Received: - - --- - ... - - -- - -- -- -
| | | | | |
| | | | | |
Events: 1: 2: 3: 4: 5: 6:
"A" "B" Timer "B"
sent sent received
1: Feedback message A is sent.
2: A feedback message would have been sent if feedback
timers had been used.
3: Feedback message B is sent.
4: Sender’s nofeedback timer expires.
5: Feedback message B is received at the sender.
6: Sender’s nofeedback timer would have expired if feedback
timers had been used, and the feedback message at 2 had
been sent.
The receiver receives data after the feedback packet has been sent
but has received no data packets with a window counter between K+4
and K+14. A data packet with a window counter of K+4 or larger would
have triggered sending a new feedback packet, but no feedback packet
is sent until time 3.
The TFRC protocol specifies that after a feedback packet is received,
the sender sets a nofeedback timer to at least four times the round-
trip time estimate. If the sender doesn’t receive any feedback
packets before the nofeedback timer expires, then the sender halves
its sending rate. In the figure, the sender receives feedback
message A (time 1) and then sets the nofeedback timer to expire
roughly four round-trip times later (time 4). The sender starts
sending again just before the nofeedback timer expires but doesn’t
receive the resulting feedback message until after its expiration,
resulting in an unnecessary halving of the sending rate. If the
connection had used feedback timers, the receiver would have sent a
feedback message when the feedback timer expired at time 2, and the
halving of the sending rate would have been avoided.
For implementors who wish to implement a feedback timer for the data
receiver, we suggest estimating the round-trip time from the most
recent data packet, as described in Section 8.1. We note that this
procedure does not work when the inter-packet sending times are
greater than the RTT.
11. Security Considerations
Security considerations for DCCP have been discussed in [RFC4340],
and security considerations for TFRC have been discussed in
[RFC3448], Section 9. The security considerations for TFRC include
the need to protect against spoofed feedback and the need to protect
the congestion control mechanisms against incorrect information from
the receiver.
In this document, we have extensively discussed the mechanisms the
sender can use to verify the information sent by the receiver. When
ECN is used, the receiver returns ECN Nonce information to the
sender. When ECN is not used, then, as Section 9 shows, the sender
could still use various techniques that might catch the receiver in
an error in reporting congestion, but this is not as robust or non-
intrusive as the verification provided by the ECN Nonce.
12. IANA Considerations
This specification defines the value 3 in the DCCP CCID namespace
managed by IANA. This assignment is also mentioned in [RFC4340].
CCID 3 also introduces three sets of numbers whose values should be
allocated by IANA; namely, CCID 3-specific Reset Codes, option types,
and feature numbers. These ranges will prevent any future CCID 3-
specific allocations from polluting DCCP’s corresponding global
namespaces; see [RFC4340], Section 10.3. However, we note that this
document makes no particular allocations from the Reset Code range,
except for experimental and testing use [RFC3692]. We refer to the
Standards Action policy outlined in [RFC2434].
12.1. Reset Codes
Each entry in the DCCP CCID 3 Reset Code registry contains a CCID 3-
specific Reset Code, which is a number in the range 128-255; a short
description of the Reset Code; and a reference to the RFC defining
the Reset Code. Reset Codes 184-190 and 248-254 are permanently
reserved for experimental and testing use. The remaining Reset Codes
-- 128-183, 191-247, and 255 -- are currently reserved and should be
allocated with the Standards Action policy, which requires IESG
review and approval and standards-track IETF RFC publication.
12.2. Option Types
Each entry in the DCCP CCID 3 option type registry contains a CCID
3-specific option type, which is a number in the range 128-255; the
name of the option, such as "Loss Intervals"; and a reference to the
RFC defining the option type. The registry is initially populated
using the values in Table 1, in Section 8. This document allocates
option types 192-194, and option types 184-190 and 248-254 are
permanently reserved for experimental and testing use. The remaining
option types -- 128-183, 191, 195-247, and 255 -- are currently
reserved and should be allocated with the Standards Action policy,
which requires IESG review and approval and standards-track IETF RFC
publication.
12.3. Feature Numbers
Each entry in the DCCP CCID 3 feature number registry contains a CCID
3-specific feature number, which is a number in the range 128-255;
the name of the feature, such as "Send Loss Event Rate"; and a
reference to the RFC defining the feature number. The registry is
initially populated using the values in Table 2, in Section 8. This
document allocates feature number 192, and feature numbers 184-190
and 248-254 are permanently reserved for experimental and testing
use. The remaining feature numbers -- 128-183, 191, 193-247, and 255
-- are currently reserved and should be allocated with the Standards
Action policy, which requires IESG review and approval and
standards-track IETF RFC publication.
13. Thanks
We thank Mark Handley for his help in defining CCID 3. We also thank
Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall,
Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, and
members of the DCCP Working Group for feedback on versions of this
document.
A. Appendix: Possible Future Changes to CCID 3
There are a number of cases where the behavior of TFRC as specified
in [RFC3448] does not match the desires of possible users of DCCP.
These include the following:
1. The initial sending rate of at most four packets per RTT, as
specified in [RFC3390].
2. The receiver’s sending of an acknowledgement for every data packet
received, when the receiver receives at a rate less than one
packet per round-trip time.
3. The sender’s limitation of at most doubling the sending rate from
one round-trip time to the next (or, more specifically, of
limiting the sending rate to at most twice the reported receive
rate over the previous round-trip time).
4. The limitation of halving the allowed sending rate after an idle