Michael StJohns <m...@nthpermutation.com> writes: > Below is a java program I wrote to model this stuff. In the table, > SF2 represents the number of clients that blew past twice the safety > factor (for aR+aHD+aR), SF1 represents the number of clients that blew > past the single safety factor. OF is the number of clients using the > activeRefreshOffset calculation that finished after the calculated > interval (e.g. aR+aHD+aRO). OF+s is the number of clients that > finished after the activeRefreshOffset + safetyFactor (in the first > table these are the same because of perfect responses). In the > second table, compare SF1 to OF+s - SF1 < OF+s suggesting that > activeRefresh is a better choice that activeRefreshQuery for the third > term of the equation. You can try a lot of different combinations, > but I haven't found any case where OF+s performs better that SF1. > > The difference between lastStart and lAddHoldBegin represents the > retransmits after the first query. The differences between > lAddHoldEnd and lFinalQuery represent retransmits after the last > normal query before the end of the add hold down time until a valid > answer was received after the addHoldDown time expired. > > Feel free to twiddle with this.
Work bogged me down to able to write anything back so far. Thanks for the java code; I'll respond with the java*script* code I've been hacking up at the same time: https://www.isi.edu/~hardaker/projects/5011/ I didn't add the re-transmit time issue that your code takes into account, but I did add a query drift that nicely shows one of your concerns. In particular, with various values of query drift (including -1) you can reproduce the real world situation that you're worried about, which is (as I've mentioned) an important one to call out. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop