Hi Eddie,
I have conferred with Gorry. It seems there are just minor things to clarify.
The issue is that the Sender RTT Estimate option is not part of the original
specification. If it were, then it would be simpler to require the option on
each Data(Ack)/Sync(Ack) packet.
But since there are now two different algorithms with the same function, there
is an ambiguity. Without negotiating (in the sense that both endpoints commit
at the same time to use one or the other) it is not clear what to do if
suddenly Sender RTT Estimate options appear - there is no binding rule which
enforces that the options appear on all packets, or which value is preferred.
When deciding to use the option without negotiation, something similar to feature
negotiation needs to be defined, e.g. to require that Sender RTT estimate options
are only valid if they were previously present during the Request/Response exchange.
But why define additional rules if the mechanism for feature negotiation is already
provided? That is why feature negotiation has in there since the first revision.
> Here's an attempt at clarifying RFC4340.
>
> o Each DCCP extension SHOULD be controlled by some feature.
> ("Extension" refers to a behavior change on which both endpoints
> must agree.)
>
There is no contradiction. If at all possible, can we leave out the part specifying
what happens when the option is used without feature negotiation?
The case is comparable to SACK options which also require a SACK-Permitted exchange
to become valid (compare section 4, RFC 2018). While SACK options are not always
necessary, the receiver relies on the RTT option to function accurately.
When discussing this with Gorry, he pointed out the issue of middleboxes and potential
future changes. If there really are reasons to keep this future-changeable, perhaps we
could simply state something like
"This document does not define a standards-track method for using the
Sender RTT Estimate option when the Send RTT Estimate Feature is disabled."
If there is something I may have misunderstood, please can you clarify.
Gerrit
