On 1/7/2020 5:33 PM, Wessels, Duane wrote:
On Jan 6, 2020, at 6:15 PM, Michael StJohns <m...@nthpermutation.com> wrote:
As I suggested in one of my messages, giving an idea of how long it takes to
digest various sizes of zones given commodity hardware would be a good start.
Going on and talking about the ratio of that time to the typical update
frequency of the zone (e.g. zone digest 5 minutes, transfer time of 10
minutes, zone update 24 hours - ratios of 1:288 and 1:144 are probably
acceptable; zone digest of 30 minutes, transfer time of 2 hours and an update
of every 4 hours - ratios of 1:8 and 1:2 are probably stretching it)
Would text like this address your concern?
7. Performance Considerations
This section is provided to make zone publishers aware of the
performance requirements and implications of including ZONEMD RRs in
a zone.
7.1. SHA384-SIMPLE
As mentioned previously, SHA384-SIMPLE may not be appropriate for use
in zones that are either large or highly dynamic. Zone publishers
should carefully consider the use of ZONEMD in such zones, since it
might cause consumers of zone data (e.g., secondary name servers) to
expend resources on digest calculation. Furthermore, for such use
cases, it is recommended that ZONEMD only be used when digest
calculation time is significnatly less than propagation times and
update intervals.
The authors' implementation (Section 10.1) includes an option to
record and report CPU usage of its operation. The software was used
to generate digets for more than 800 TLD zones available from [CZDS].
The table below summarizes the the results for SHA384-SIMPLE, grouped
by zone size. The Rate column is the mean amount of time per RR to
calculate the digest, running on commidity hardware at the time of
this writing.
+---------------------+----------------+
| Zone Size (RRs) | Rate (msec/RR) |
+---------------------+----------------+
| 10 - 99 | 0.00683 |
| 100 - 999 | 0.00551 |
| 1000 - 9999 | 0.00505 |
| 10000 - 99999 | 0.00602 |
| 100000 - 999999 | 0.00845 |
| 1000000 - 9999999 | 0.0108 |
| 10000000 - 99999999 | 0.0148 |
+---------------------+----------------+
For example, based on the above table, it takes approximately 0.13
seconds to calculate a SHA384-SIMPLE digest for a zone with 22,000
RRs, and about 2.5 seconds for a zone with 300,000 RRs.
Hi Duane -
This is sort of what I meant. Still trying to get the authors to home
in a definition for small/static and large/dynamic. Reading the above
table, and assuming validation takes a similar time, I'd suggest that 1M
records @ ~2.3-3 hours is greater than large for your purposes. Maybe
10Min for 100K records is "large"? Assuming that churn is >> 10 minutes.
I'd add "Note that processing power tends to increase over time -
Moore's law suggest that time to process these data sets will decrease
by half every 2 years, faster if specialized hardware is used.
Implementers, publishers and consumers may extrapolate current
processing times by simple math." - to deal with the "these numbers are
stale when published so why publish them" comment . And - maybe given
publishing time - as of December 2019 instead of "at the time of writing".
Two things - Does the above include the time it takes to sort or
otherwise order the zone in canonical order or are you assuming that the
database is maintained in a sorted manner? And what is the average RR
size?
Thanks for the text. Mike
ps - what I think a number of other commenters are missing is that this
is guidance for implementers, zone publishers and zone consumers - not
just for dns geeks. For a zone publisher to use it it has to a) be cost
effective to produce, b) have some value for the zone consumer other
than "just more data", and c) has to not interfere with their current
business model. I actually thought about asking how much
energy/electricity it would take to produce or verify the ZONEMD RR -
but decided that would just be cruel. TANSTAAFL
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
