Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
updated by
Extracted elements (25)
CCID 3 should not be used by applications that vary sending rate by changing packet size rather than packet rate, since the TCP throughput equation in TFRC is calibrated for fixed packet sizes. A new CCID would be required for variable-size-per-rate applications.
CCID 3 (TFRC) is designed for applications that prefer smooth sending rates over maximum throughput, such as streaming media with small receiver buffers. Unlike TCP-like CCID 2, TFRC avoids halving the sending rate per congestion event, at the cost of slower adaptation to available bandwidth changes.
The window counter (CCVal) is preferred over a round-trip time option for communicating sending-time information to the receiver because it conveys relative *sending* times, giving more robust performance when there is large delay variation within a window of data. A round-trip time option would only allow distinguishing relative *receive* times.
All currently defined CCID 3-specific options (Loss Event Rate, Loss Intervals, Receive Rate) MUST be ignored when they appear on DCCP-Data packets. Loss Intervals options MUST NOT be sent on packets without an Acknowledgement Number.
A loss interval's lossy part MUST be less than or equal to 1 RTT in length. 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.
Conforming CCID 3 implementations MAY track updates to the TCP throughput equation directly as standardized by IETF, but SHOULD wait for explicit updates to CCID 3 before implementing other changes to TFRC congestion control.
ECN Nonce Echo information MUST be returned by the receiver using the Loss Intervals option. Any Ack Vector options MUST include the ECN Nonce Sum. The sender MAY maintain a per-packet nonce table to probabilistically verify receiver feedback.
If the sender has not received a feedback packet when the nofeedback timer expires (set to at least four RTTs or twice the inter-packet interval, whichever is larger), the sender halves its allowed sending rate. The sending rate is never reduced below one packet per 64 seconds.
In the absence of better information, a receiver MUST conservatively assume that every lost packet was a data packet and must occur in some lossy part of a loss interval. DCCP's NDP Count option can help determine whether a particular packet contained data.
Loss Intervals options MUST contain information about at least the most recent NINTERVAL+1 = 9 loss intervals unless fewer have occurred or the sender's acknowledgements confirm prior intervals were received. The receiver MUST transmit at least one loss interval regardless.
The allowed sending rate is never reduced to less than the RFC 3390 initial sending rate as a result of an idle period. If the allowed rate was at or above the initial sending rate upon entering the idle period, it should not be reduced below that rate regardless of idle duration.
The data receiver MUST include an Elapsed Time option on every required feedback packet, and SHOULD also include the corresponding Timestamp Echo option with Elapsed Time value if recent data packets contained Timestamp options. This allows the sender to separate network RTT from receiver processing delay.
The ECN Nonce Echo in each Loss Interval MUST be reported as 0 if Lossless Length is 0, the receiver is ECN Incapable, or the lossless part contained no data packets. Non-data packet nonces MUST NOT contribute to the ECN Nonce Echo.
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 packet size, in contrast to RFC 3448 which specifies one packet per RTT. The rate is only three or four packets per RTT when that translates to at most 4380 bytes per RTT.
The sender MUST avoid wrapping CCVal on adjacent packets. The sender SHOULD use the specified algorithm: compute quarter_RTTs elapsed since last_WC_time, increment last_WC by min(quarter_RTTs, 5) mod 16, and set the packet's CCVal to last_WC.
When a sender receives Data Dropped or Slow Receiver options, it SHOULD adjust X_recv (the receive rate used in TFRC calculations) to limit the next RTT's sending rate to at most X_drop. This procedure MUST only be used for Drop Codes not related to corruption (currently Drop Codes 0, 1, and 2).
When Ack Vector or Data Dropped is used, an active sender MUST acknowledge the receiver's acknowledgements approximately once per RTT (within a factor of two or three), typically via a DCCP-DataAck packet, so the receiver can free up state.
The receiver determines whether to send feedback using the window counter: it tracks last_counter (greatest CCVal seen since last feedback). When a data packet arrives with CCVal >= last_counter + 4, a new feedback packet is sent. This replaces the TFRC feedback timer in most cases.
The Send Loss Event Rate feature (feature number 192, server-priority, initial value 0) lets endpoints negotiate whether the receiver MUST provide Loss Event Rate options on acknowledgements. When set to 1, the receiver MUST send Loss Event Rate options; it MAY send them when set to 0.
IANA registers CCID 3-specific Reset Codes (range 128-255), option types (128-255, initially populated with types 192-194), and feature numbers (128-255, initially populated with feature 192). Codes 184-190 and 248-254 in each registry are reserved for experimental/testing use; remaining unallocated values require Standards Action.
CCID 3 must protect against spoofed feedback and incorrect congestion information from receivers. When ECN is used, the ECN Nonce echo in Loss Intervals options gives a misbehaving receiver only a 50% chance per interval of successfully concealing dropped or marked packets. Without ECN, the sender can use out-of-order or absent packets to probabilistically detect receiver misbehavior, but this is less robust.
The CCVal field in the DCCP generic header is a 4-bit window counter value set by the data sender on every data packet. It is initialized to 0 and incremented by 1 every quarter RTT using circular arithmetic modulo 16. Adjacent packets' CCVal values never differ by more than 5 (mod 16).
The Loss Event Rate option (Type=192, Len=6) carries a 4-byte value indicating the inverse of the loss event rate (rounded up) in data packets per loss interval. When no losses have occurred, the value is set to 2^32 - 1 (all ones). MUST NOT be sent on DCCP-Data packets.
The Loss Intervals option (Type=193, variable length) reports up to 28 loss intervals in reverse chronological order. Each 9-byte interval encodes: Lossless Length (24 bits), ECN Nonce Echo (1 bit) + Loss Length (23 bits), and Data Length (24 bits). MUST be sent on all required acknowledgements and MUST NOT be sent on DCCP-Data packets.
The Receive Rate option (Type=194, Len=6) carries a 4-byte field indicating the rate in bytes per second at which the receiver has received data since its last acknowledgement. It MUST be sent on all required acknowledgements and MUST NOT be sent on DCCP-Data packets.