Hello Paul-san, The rationale for each measurement has been discussed in the WP, but I don't beleive that the importance or relation between each metric was discussed in the context. If we need to take such importance into consideration in finding out the threshold, shouldn't we need additional discussion on this prior to expressing the suggestion of the threshold to the spreadsheet? In addition, the importance has only suggested for the RSO metrics. The importance for RSS metrics would need another discussion as well. If these are already discussed before, I'd like to see the minutes, transcripts or whatever, as I did miss some meetings. Regards, Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd. On Wed, 11 Sep 2019 16:44:15 +0000 Paul Hoffman <paul.hoffman@icann.org> wrote:
On Sep 11, 2019, at 8:44 AM, Steve Sheng <steve.sheng@icann.org> wrote:
At the next call of the metrics WP, the metrics WP will discuss performance thresholds for individual root servers and the root server system as a whole. To prepare for those discussions, the co-chairs have requested that you fill out the following spreadsheet ahead of the meeting and provide your input.
At earlier meetings, we discussed having a set of rationale for our threshold numbers. I put together the following for my own rationale, which people might or might not like.
--Paul Hoffman
The thresholds define minimum acceptable metrics for each RSO. In order to determine the numeric thresholds, an overall view of the importance of each metric is needed. The rationale here is based on an overall idea of what is expected of an RSO by the caching recursive resolvers that uses that RSO as part of the RSS.
In summary, the importance of the RSO metrics is: correctness > publication latency >> availability > response latency
Of the four metrics, RSO correctness is by far the most important to recursive resolvers because incorrect answers can have long-lasting negative effects on the caches. It is well known that fewer than half of all resolvers use DNSSEC validation; for those resolvers, incorrect information from an RSO will poison future queries until the TTL associated with the incorrect answer expires. Incorrect information from an RSO about glue records for unsigned TLDs can cause long-term harm even to validating resolvers.
RSO publication latency is important both when NS and DS records in the root zone are changing, as well as when RRSIG records are expiring. If an RSO has consistently long publication latency, some RSOs can be affected by getting wrong answers to queries. However, historically, TLD NS change very infrequently, and DS records are usually changed in a fashion where there is a large overlap between old and new records. Emergency updates to the root zone data happen only a few times a year and, even when they do happen, the old records are cached for up to two days. Thus, there is no expectation that an RSO will update its copy of the root zone “instantaneously”, but it should update within a reasonable fraction of time of the TTLs in the root zone.
Although RSO availability and RSO response latency negatively affect recursive resolvers, they do so in a way that is easily and automatically fixed, namely by moving to a different RSO. That is, if many instances of an RSO are flaky due either to computer or routing instability, a recursive resolver will see this and switch to a different RSO for some extended period of time. Similarly, if many recursive resolvers see high latency in their responses from one RSO, they will switch to other RSOs before trying that RSO again in the future. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.