Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
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
Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
Replacing this paragraph When the Send RTT Estimate Feature is disabled, the sender MUST NOT send RTT Estimate options on any of its packets, the receiver MUST ignore the RTT Estimate Option on all incoming packets, and SHOULD try to estimate the RTT in some other way (not specified by this document). with When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously specified in RFC4340/4342/5622. would be acceptable, as I said. Eddie On 11/05/2010 05:28 AM, Gerrit Renker wrote: 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
Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
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
Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
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. If a sender is permitted to add the option even if the negotiation means that it is not permitted to use the option, it generates uncommitted data which gets ignored by the receiver. This creates a lot of waste of bandwidth. Ack Vector options are a good example - they have dynamic length, so at worst there are several hundred wasted bytes per each packet when allowing the sender to go ahead and ignore the feature negotiation. I can see only disadvantages of allowing A and not-A. Apart from making the implementation complex and confusing, it also opens a door for denial of service attacks, a man in the middle could reformat most parts of the payload data simply as an Ack Vector, flip the required bits of the checksum, and turn the bitstream into random noise. 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 I still can not see a reason why there should be a state between on and off. 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. [...]) Agree in principle with this suggestion -- this is also the result of the discussions with Gorry.
Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
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
Re: [dccp] revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails
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
