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.
> 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.
> 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.
> (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.
But no, it wasn't slight of hand and have no idea why you think I'd be
trying to trick you. 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.
> 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).
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
