|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi,Will look over the new draft, but I have a response to your comments. It would be good to hash it out.
On 10/18/2010 04:19 AM, Gerrit Renker wrote:
* S3.3 "When the Send RTT Estimate FEATURE [sic, note added word] is disabled, the sender MUST NOT send RTT Estimate options...." Why not? DCCP receivers will correctly ignore RTT Estimate options they do not understand. And it would seem useful to take advantage of RTT Estimates whether or not they were required.The document follows RFC 4340, 15. We much prefer to give one unambiguous specification that agrees with the existing standards.
This choice isn't justified by RFC4340's "Forward Compatibility", and seems a mistake.
Extensions SHOULD default to off, and Send RTT Estimate does default to off. But the Send RTT Estimate feature controls the MANDATORY inclusion of RTT Estimates. This is important to control via a feature since mandatory RTT Estimates change behavior -- as we discussed, the receiver may penalize senders that neglect to include mandatory RTT Estimates.
The "0" state for Send RTT Estimate thus means "Mandatory RTT Estimates not available".
As for non-mandatory RTT Estimates: A nice quality of the RTT Estimate option is that the endpoint sending the option *has the same behavior as a "legacy" sender* (one that doesn't understand explicit RTT Estimates), except for the option itself. If a middlebox stripped out every RTT Estimate option, leaving the packets otherwise valid, the result should be identical to what a legacy receiver would expect.
But already legacy receivers MUST ignore the option, per RFC4340 Forward Compatibility!
In summary, MUST NOT is not justified here. I could see reasons to include an RTT Estimate on an initial packet, before feature negotiation can complete, if a relatively up-to-date RTT estimate was available. Such uses shouldn't be specified now. They also needn't be ruled out. Since MUST NOT doesn't simplify implementation, I don't see any reason for the strict language.
Any comments? Eddie
The document should also perhaps define what happens if a sender agrees to Send RTT Estimate and then doesn't actually do so (or sends 0 for too long).That is a good point, section 3.3 has been revised with regard to that (please see changelog).A first thought: - If Send RTT Estimate is 1, the sender MUST provide RTT Estimate options on the described packets. - If Send RTT Estimate is 1, the receiver MUST use the provided RTT Estimates in place of the CCVal window counter values. (Note: The current doc says MUST NOT estimate the RTT using CCVal. Of course, an implementation MIGHT estimate the RTT that way; it's just not supposed to USE that estimate.)Revised that section: the CCVal value now serves as a fallback mechanism.- If Send RTT Estimate is 0, the sender MAY provide RTT Estimate options. - If Send RTT Estimate is 0, the receiver MAY use provided RTT Estimate options to augment RTTs estimated another way, but MUST use CCVal window counter values or other RTT estimation techniques when valid RTT Estimates are not available.Not done due to decision above.- Invalid RTT Estimates: A packet without an RTT Estimate option is considered to have an RTT Estimate of 0. - Invalid RTT Estimates: [TOTAL GUESSWORK -- DO WE ACTUALLY NEED TO SPECIFY?] If at least 64 consecutive packets are received with zero RTT Estimates, the receiver MUST treat the RTT Estimate as 64000000. ????????????????The general idea is very good and as a consequence section 3.3 has been reworked in order to specify what happens in this case. Tracking 64 consecutive packets is a lot of state. Decided to use a maximum of 2 successive 0-valued RTT Estimate options since this allows to track the state e.g. in a single-bit boolean flag.