Hi Eddie,
I am sorry if my previous email has offended you, that was certainly not
my intention.
I think that neither I nor you are right here -- it is not as easy as
saying, "basta, we leave it like that, end of story".
Your suggestion of treating this issue separately is a good point. Since
whether allowing options to appear without negotiating a corresponding feature
seems to be more of a case-by-case issue:
* in an earlier email you mentioned an RFC where apparently sending options
before completing feature negotiation is helpful;
* there are other cases where both allowing and disallowing gets in the way,
as in the Sender RTT Estimate case: it is like having two oscillators but
a CPU can be clocked only by one;
* this may also shed light on which options are truly "optional", i.e. not
essential to the operation of DCCP.
I don't mind to do the extra work of coming up with a list, but that can only
be a starting point.
With regards to the draft, the 'MAY' has become an unnecessary stumbling
block. Is it an agreeable compromise to completely leave this sentence out,
i.e. no more MUST NOT, but at the same time no guidance when using the option
in an unspecified way?
That is the state of the discussions with Gorry, but apparently I did not
formulate this very well in the emails.
And perhaps I misunderstood your minimal necessary specification:
"The minimal necessary specification would be
When the Send RTT Estimate Feature is disabled, the receiver MUST
estimate the RTT as previously specified in RFC4340/4342/5622."
If we can leave out the MUST NOT part, then "less is more". Would that
be ok?
Gerrit
Quoting Eddie Kohler:
> Gerrit:
>
> As I have explained now several times, all analogous features in DCCP are
> defined with MUST/MAY language. You continue to use language like
> "bypassing feature negotiation" that is simply not a correct description
> of the spec. Feature negotiation is not being bypassed, as I hope you
> understand; the features just don't mean what you want them to mean, and
> never did.
>
> Though I haven't double-checked, I believe that NO existing DCCP spec
> (except DCCP-Thin, which has expired) tells a sender that it MUST NOT
> send an extension option when a feature is off.
> The sender RTT estimate option is not worth making the DCCP specs
> internally inconsistent.
>
> I will not support this draft unless a change is made to MUST/MAY behavior.
>
> If you want to change DCCP's supposedly "ugly" MUST/MAY behavior, you
> should do so for all corresponding options in a separate draft, rather
> than add to that ugliness by introducing a new form of behavior. Perhaps
> other people on the list would support you. I wouldn't.
>
> I owe you other comments on the rest of the draft but this is my last
> word on this.
>
> Eddie
>
>
> On 11/02/2010 05:25 AM, Gerrit Renker wrote:
>>>>> 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.
>>>> Please do - I asked for that in the previous email.
>>>>
>>>> I can not see the point of doing the above.
>>>> It says "you MUST do A, but you MAY also not do A".
>>>
>>> No, it doesn't. The plain language of the feature description says
>>> - If the feature is one, the sender MUST send the option.
>>> - If the feature is zero, the sender MAY send the option.
>>> This is not a contradiction.
>>>
>> I did not say it is a contradiction and what you say above in a way paraphrases
>> what I said above, hence also no contradiction.
>>
>>
>>>> If a sender is permitted to add the option even if the negotiation means that
>>>> it is not permitted to use the option,
>>>
>>> The idea of "not permitting" an option is not in the spec; you've
>>> invented it. An endpoint is always permitted to send Ack Vector options.
>>> "Send Ack Vector", when on, REQUIRES that an endpoint send Ack Vector
>>> options. When off, the feature has no effect; the endpoint is still
>>> permitted to send Ack Vector options, *as it always was*.
>>>
>> Perhaps I invented it because I got confused by the specification. If a receiver
>> may send something without negotiation, then to me this says that the negotiation
>> is not really required.
>>
>> Seriously Eddie I don't mean to nitpick here, but this behaviour of requiring
>> feature negotiation on the one side and allowing to bypass it on the other hand
>> is one of the most ugly parts in the entire specification, and sorry I remain
>> reluctant to do the same here.
>>
>> First, it is the opposite of the Robustness Principle [RFC 4340, 3.6]: it means
>> being liberal in what the sender is "do"-ing. Throughout the email discussion we
>> have so far established that we both agree (and as I understand Gorry, he, too)
>> on the receiver ("accepts") side of the robustness deal.
>>
>> The second issue is that this extra rule of allowing a sender to bypass feature
>> negotiation seems to make sense only in theoretical thinking. In practice,
>> within an implementation, the endpoints have to negotiate about their feature
>> sets anyhow; adding a few more bytes to make clear whether to use/not-use Ack
>> Vectors, Send Loss Event Rate, Sender RTT Estimate almost does not increase the
>> complexity at all.
>>
>> There is at least one feature negotiation during the lifetime of a connection,
>> when exchanging Request/Response, so it can be assumed that any implementation
>> will be able to perform at least one clear feature negotiation.
>>
>> Third, I don't like to see all the good work you and Sally put in to make feature
>> negotiation clear and unambiguous to be diluted by this anti-robustness rule.
>>
>>
>>> Among the reasons that we preferred MUST...MAY for features like this:
>>>
>>> - It allows an endpoint to generate an option unconditionally, which
>>> might be preferred for simplicity of implementation. Sender RTT
>>> Estimate, CCID-3 Loss Event Rate are good examples.
>>>
>> Sorry, but exactly the opposite is the case. The Linux implementation makes sure
>> that Loss Event Rate feature and ECN capabilities are negotiated, hence there are
>> no in-between states. This does not increase complexity, all it boils down to is
>> adding a few table entries.
>>
>> But since the implementation always sticks to yes/no, it ignores the 'MAY' with
>> regard to sending options outside of any feature negotiation.
>>
>> Which is why I don't like to add the same to the present specification. It is
>> adding something that ends up having to be ignored just to make the
>> implementation work at all.
>>
>>> - When an extension-feature is off (zero), we don't constrain endpoints'
>>> behavior. That is key to forward compatibility; an endpoint by
>>> definition cannot be constrained by an extension that does not yet exist.
>>>
>> But as far as I can read this, this also means the receiver end, where we three
>> already agree. The receiver just ignores the option, which is clear and unambiguous.
>>
>>>> I can see only disadvantages of allowing A and not-A. Apart from making the
>>>> implementation complex and confusing,
>>>
>>> Doubt it. Among other reasons, for senders, the behavior you prefer
>>> ("MUST...MUST NOT") is a strict subset of the behavior we allow
>>> ("MUST...MAY").
>>>
>> Please can you state the other reasons then?
>>
>> The sender is more conservative on the outgoing side than on the incoming side
>> because of the robustness principle.
>>
>
--
