Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)
updates
Extracted elements (19)
Receiver-based RTT sampling using the cyclic 4-bit CCVal window counter in CCID-3/CCID-4 is inherently unreliable: it requires adjacent packets with CCVal differences between 2 and 4, fails during loss events, and is distorted by NIC interrupt coalescing that delivers packets in bursts. The sender is better equipped to measure RTT using timestamps and elapsed time, producing higher-accuracy and more frequent samples.
The update follows a recommendation in RFC 5348, Section 3.2.1 to measure RTT at the sender rather than the receiver. Sender-based RTT estimates enable more accurate X_recv measurement, better loss event disambiguation, accurate quiescence period computation, and can also help middleboxes verify conforming congestion control.
DCCP B can require DCCP A to send RTT Estimate options by sending 'Mandatory Change R(Send RTT Estimate, 1)'; DCCP A will reset the connection if it does not understand this feature. This enables end-to-end negotiation of the sender RTT extension.
A sender MUST set the RTT Estimate Option value to 0 if it does not yet have an RTT estimate. RTT estimates of less than 1 microsecond MUST be reported as 1 microsecond.
The receiver SHOULD track the long-term RTT estimate using a moving average (such as the one in RFC 5348, Section 4.3), referred to as 'receiver_RTT'.
The sender MUST continue to implement and update the CCVal window counter as specified in RFC 4342, Section 8.1, even when the Send RTT Estimate Feature is enabled.
The sender SHOULD round up RTT samples to the next microsecond when capable of sub-microsecond granularity, to avoid under-estimating the RTT.
The sender SHOULD select the smallest format (fewest leading zero bytes) suitable to carry the RTT estimate.
To avoid under-estimating the RTT during extended no-number RTT option periods, the receiver MUST back off receiver_RTT: if no-number options persist for longer than receiver_RTT seconds, set receiver_RTT = MIN(2 * receiver_RTT, t_mbi), where t_mbi = 64 seconds.
Until the first numeric RTT option (value 1..0xFFFFFE) arrives, the receiver MUST use 0.5 seconds for receiver_RTT, matching the initial 2-second TFRC nofeedback timer timeout.
When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously specified in RFC 4340, RFC 4342, and RFC 5622.
When the Send RTT Estimate Feature is enabled, the receiver MUST use the RTT Estimate Option value in all places requiring an RTT. If the receiver encounters an invalid RTT Estimate Option, it MUST reset the connection with Reset Code 5 ('Option Error'), setting Data 1..3 to the first 3 bytes of the offending option.
The RTT Estimate Option (type 128) carries the sender's current RTT estimate to the receiver. It has a variable length of 3, 4, or 5 bytes, with 1, 2, or 3 value bytes encoding the RTT in microseconds. The option may be placed in any DCCP packet and is flagged as usable in DCCP Data packets.
The Send RTT Estimate Feature (feature number 128) is a server-priority, 1-byte Boolean feature that governs whether the sender must provide RTT Estimate options on its data packets. It is off by default (initial value 0) and is OPTIONAL for DCCP implementations.
This document allocates feature number 128 in both the dccp-ccid3-parameters and dccp-ccid4-parameters IANA registries for the Send RTT Estimate Feature (HC-sender located), within the CCID-specific feature range 128..191.
This document allocates option number 128 in both the dccp-ccid3-parameters and dccp-ccid4-parameters IANA registries for the RTT Estimate Option, within the CCID-specific option range 128..191.
An on-path attacker able to guess valid sequence numbers could alter the RTT Estimate Option to manipulate the perceived RTT, causing TFRC to compute inflated or deflated X_recv values and thus obtain higher or lower sending rates than network conditions warrant. The threat model requires the attacker to be on the same path as the DCCP sender and receiver.
Receiver RTT state transitions: initial state uses 0.5s receiver_RTT until first numeric option; on receiving numeric options, updates via moving average; on extended no-number options (duration > receiver_RTT), backs off via doubling capped at t_mbi=64s; MAY close connection when receiver_RTT reaches MAX_RTT.
The RTT Estimate Option encodes the RTT value in 1–3 bytes (option type 128, length 3–5). The value is in units of 1 microsecond, allowing values up to 16.7 seconds (0xFFFFFE). The reserved value 0xFFFFFF signals a delay spike larger than 16.7 seconds; 0x000000 indicates no valid RTT sample.