S3.2.1 says:
A value of 0 indicates the absence of a valid RTT sample. The sender
MUST set the value to 0 if it does not yet have an RTT estimate.
I would also say "A packet without an RTT Estimate option is considered to
carry an RTT Estimate value of zero."
S3.3 says:
When the Send RTT Estimate Feature is enabled, the sender MUST
provide an RTT Estimate Option on all of its Data, DataAck, Sync, and
SyncAck packets. It MAY in addition provide the RTT Estimate Option
on other packet types, such as DCCP-Ack.
I am concerned about interaction of this with:
The sender is permitted to send up to MAX_INVALID_RTT=2 successive
0-valued RTT estimate options. If the receiver encounters more than
MAX_INVALID_RTT RTT Estimate options in succession, it MUST behave as
if the Send RTT Estimate Feature were off, and disregard all
subsequent RTT Estimate options.
* You meant "more than MAX_INVALID_RTT ***zero-valued*** RTT Estimate options
in succession".
* The interaction with e.g. streams of DCCP-Acks, which only MAY include RTT
Estimate options, worries me. Perhaps you want to specify "data-carrying
packets" or something similar.
* "it MUST behave as if the Send RTT Estimate Feature were off": This is
problematic, since it could be interpreted as changing the Send RTT Estimate
feature one-sidedly. Can you define this differently/more explicitly? The
MUST/SHOULD balance is also iffy, since above tracking CCval is a "SHOULD" not
a "MUST". Suggestion:
If the receiver encounters more than MAX_INVALID_RTT successive
data-carrying packets with RTT Estimate value zero, the receiver
SHOULD fall back on CCval-based RTT estimation for future packets in
the half-connection.
I think this points out the problem, is sufficient, and avoids unnecessary
constraints.
Eddie
