Hi Gerrit,
Hooray! I think we actually agree. Nevertheless, here is a full response.
On 10/28/10 4:01 AM, Gerrit Renker wrote:
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.
I like the "Send RTT Estimate" feature & always have, fwiw! And it IS the
right way for endpoints to agree to mandate RTT Estimates. My issue is simply
that all other analogous option/feature combinations in DCCP are specified like
this:
DCCP A MUST send Ack Vector options on its acknowledgements when Send
Ack Vector/A has value one, although it MAY send Ack Vector options
even when Send Ack Vector/A is zero.
This was intentional; I can explain more if you care. Your current draft says
MUST...MUST NOT, which is the core of our disagreement.
Note that I am concerned with SENDER behavior, not receiver behavior. A DCCP
sender should be able to include RTT Estimate options regardless of the Send
RTT Estimate feature value. What the receiver does with that information in
current specs, I am much more flexible.
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?
Yes; see below.
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.
FWIW I actually disagree with this. TCP is a different protocol with different
option behavior. In fact RFC793 says every TCP "must implement all options."
As a result some middleboxes/endpoints would strip or even drop packets with
unknown options. *That behavior*, to my understanding, is why RFC2018 says
endpoints shouldn't send SACK without SACK-permitted. (The survival of
SACK-permitted indicates that middleboxes/endpoints would allow SACK as well.)
There are no DCCP middleboxes; but if there were, they would likely not be so
rude, since DCCP's behavior wrt unknown options is clearly specified.
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.
If:
- the language about generating options used "MUST...MAY", instead of
"MUST...MUST NOT", and
- the paragraph above was used to define receiver behavior,
I would be happy. (Other choices of receiver behavior would also work. For
instance, "Receivers MUST use previously specified mechanisms to measure the
round-trip time when Send RTT Estimate is zero; this document does not define a
standards-track method allowing receivers to use Sender RTT Estimate options
when the Send RTT Estimate is zero." Again, I feel strongly about sender
behavior, not receiver behavior.)
OK?
Eddie
