|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.