On 12/20/2017 1:15 PM, Wes Hardaker wrote:
Michael StJohns <[email protected]> writes:
1) Drift happens per query.
Agreed. I'll go double check that I didn't imply that, or better: make
sure I state that in the document.
Take it out of any formula. It has little impact outside of the
addHoldDown interval and in there all it does is shift the end point.
It's OK to mention it as part of the general slop, but in reality it
turns out to have only very minor impacts.
2) Any drift that happens related to the multiple queries in the
addHoldDown interval can safely be ignored with respect to its impact
on the overall wait time for the publisher. (e.g. all the drift is
going to do is change the phase of the last query in the interval with
respect to the end of the addHoldDown time)
Most likely, but I could see bad code calculating total waited time by
adding time between queries together, rather than doing a wall clock
subtraction from new - start_hold_down like they should.
Anyway, I agree only the last one should be shifted in the correct case.
That's not what I said. What I said was that the cumulative effect of
drift within the add hold down interval is to shift the phase of the
last query before the end of the period. The intermediate queries also
shift phase, but are subsumed in analysis by the cumulative shift within
the interval.
3) The only other drift that may be of interest is the drift at the
beginning and end of the queryInterval where the end of the interval
is the beginning of the addHoldDown interval. Given that a typical
drift is something like 1-60 seconds it can safely be ignored related
to all the other stuff.
I think I agree with that too. Only a small percentage of clients will
end up needing the extra queryInterval.
No. Drift per query is ~<= 10 seconds or so. queryInterval ~>=
hours. Drift for these two queries can safely be ignored in the
evaluation.
(And yes, I realize that Wes has set driftSafetyMargin to
activeRefresh meaning that calculated results are identical to what I
want, but there's no analysis that supports the use of a
driftSafetyMargin and this just seems to be sleight of hand to replace
activeRefreshOffset with a term that has a value
activeRefresh... *pounds head against wall*)
Hmm... I'll try to clean up the wording some more to make the analysis
more clear. But in the end, yes: when real world conditions occur
you're right and the extra activeRefresh is needed. Again, you're right
there is *another* new issue with 5011 that had to be spelled out, and
I'm glad you caught yet another needed length extension during last
call.
I'm glad you got here, but if you were showing your work, you would not
be getting a good grade..... sorry.
The activeRefresh before the addHoldDown interval is from the worst-case
assumption that at least one out of N resolvers will have made a query
just before the lastSigExpire date.
The activeRefresh after the addHoldDown interval is from the worst-case
assumption that at least one out of N resolvers will have made a query
just before ITS addHoldDown expired and will have to wait an entire
activeRefresh interval
These assumptions are made without reference to any assumptions about
drift or retransmissions.
But no, it wasn't slight of hand and have no idea why you think I'd be
trying to trick you.
I'm sorry if you thought my words implied I thought you were trying to
trick me. However, given that you had no real reason for setting
driftOffset to activeRefresh it really did look like "and then a miracle
occurs" type of logic.
Again, Mike, I can't state this more clearly: I
admit you were right and found a more important timing constraint than
activeRefreshOffset. That being said, I left (and want to leave)
activeRefreshOffset in the document so that others performing similar
analysis of the whole 5011 process understand all the ramifications of
both the theoretical and practical applications of the 5011 algorithm
and usage. Thus, we actually agree. You just want to limit what goes
into it.
Wes - I just want to not have "fake math" in this document.
timingSafetyMargin depends on driftSafetyMargin.
driftSafetyMargin seems to have been pulled out of thin air and has no
support which means that timingSafetyMargin also makes no sense.
Neither of these terms are of any use in either the equations or analysis.
Delete them and refactor any text that references them.
Again:
addWaitClockTime = lastSigExpirationTime + activeRefresh +
addHoldDownTime + activeRefresh + safetyMargin (which now seems to be
labeled retrySafetyMargin).
Which is exactly what's in ... *crap* ... I missed a term in an
equation.
But 6.2.1.1 *will* state:
addWaitTime = addHoldDownTime
+ sigExpirationTimeRemaining
+ MAX(1 hour,
MIN(sigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days)
)
+ 2 * activeRefresh
+ retrySafetyMargin
So your desired equation is there.
(the current published document doesn't have the 2*, even though the
previous non-expanded version should have lead to it).
I'll do a final check of equations again today, as well as look to make
sure I didn't state drift can only happen for one query (though I'm sure
I didn't say that).
*sigh* As currently written you get the second activeRefresh from the
random setting of driftSafetyOffset (see 6.1.7) via timingSafetyMargin
(6.1.8). That's wrong. Since 6.2.1 uses timingSafetyMargin - its
also wrong. Since the rest of the equations derive from 6.2.1 they are
suspect.
Delete these (6.1.7) (6.1.8) section and fix any references to these
terms in the base equation. From there fix the rest of the math.
Later, Mike
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
