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.
