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.
