Thanks for offering to read this, it would be much appreciated, we need
comments from the group.
I understand what you say about the "Forward Compatibility" design goal.
My view reading this again, is that it would be OK for to say the sender
MAY send RTT Estimate options on any of its packets irrespective of the
feature negotiation (I think nothing breaks when sending these).
If this were to be changed, would you expect a receiver that has not
negotiated use to use these or ignore these? It can't rely on them being
present, so it may still be true that it "SHOULD try to estimate the RTT
in some other way (not specified by this document)".
Gorry
On 19/10/2010 01:38, Eddie Kohler wrote:
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.
