Potential RSSAC caucus work item: Interpreting RSS Metrics
I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC. "Interpreting RSS Metrics" There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading. 1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ? What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)? -Ken
+1 I am in favor of the proposed work item. I recall suggesting a highly similar work item in a previous RSSAC annual survey, titled “Operationalizing RSSAC metrics,” where I outlined the motivations and specific goals in high-level terms. Dessalegn On Wed, Nov 12, 2025 at 3:48 PM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC.
"Interpreting RSS Metrics"
There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading.
1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ?
What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)?
-Ken _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
+2 This aligns with the survey response I shared during our previous session. I would also like to propose including a standard definition of key terms, such as RSS Physical Server Density—potentially from a continental or specific geographical perspective—and an RSS Resilience Factor or Calculation. For example, the "RSS Resilience Calculation" could refer to a set of analytical techniques and metrics used to assess the overall capacity of the entire Root Server System (RSS) to withstand failures, attacks (such as Denial of Service), and operational disruptions. Resilience might be characterized by factors like global diversity and redundancy. This is just a preliminary idea and can certainly be refined further. On Wed, Nov 12, 2025 at 4:27 PM Dessalegn Yehuala via rssac-caucus < rssac-caucus@icann.org> wrote:
+1 I am in favor of the proposed work item. I recall suggesting a highly similar work item in a previous RSSAC annual survey, titled “Operationalizing RSSAC metrics,” where I outlined the motivations and specific goals in high-level terms.
Dessalegn
On Wed, Nov 12, 2025 at 3:48 PM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC.
"Interpreting RSS Metrics"
There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading.
1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ?
What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)?
-Ken _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
-- Kunle Olorundare (MNSE, PRINCE2) +2348036551591
Hi Ken, I think the key question you pose is: How can the DNS community use these metrics to their advantage? Can you please provide greater detail on the audience, are they technical, operational...if not, my fear is that what they don't understand will hurt us...negative perception towards the RSS, and potentially "the sky is falling" syndrome. People will always assume the worst, so we need to tread this one carefully -- understanding the audience and how this information may be potentially used and possibly misconstrued will be key. Just a thought. Thanks, Erum On Wed, Nov 12, 2025 at 9:48 AM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC.
"Interpreting RSS Metrics"
There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading.
1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ?
What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)?
-Ken _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
Dear Ken, Thank you for initiating this thoughtful discussion. The proposed topic, “Interpreting RSS Metrics,” is indeed valuable and timely. I fully agree that there is often misinterpretation in how RSS performance metrics are viewed, particularly when emphasis is placed on latency rather than more critical indicators such as availability and correctness. I believe a focused work party on this subject could bring great clarity to the DNS community, helping stakeholders better understand and apply RSS metrics in meaningful ways. I would be pleased to contribute to further discussions and to the development of a potential Statement of Work. Regards Rolla Hassan ________________________________ From: Erum Welling via rssac-caucus <rssac-caucus@icann.org> Sent: Thursday, November 13, 2025 4:24 AM To: Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) <kenneth.d.renard.ctr@army.mil> Cc: rssac-caucus@icann.org <rssac-caucus@icann.org> Subject: [RSSAC Caucus] Re: Potential RSSAC caucus work item: Interpreting RSS Metrics Hi Ken, I think the key question you pose is: How can the DNS community use these metrics to their advantage? Can you please provide greater detail on the audience, are they technical, operational...if not, my fear is that what they don't understand will hurt us...negative perception towards the RSS, and potentially "the sky is falling" syndrome. People will always assume the worst, so we need to tread this one carefully -- understanding the audience and how this information may be potentially used and possibly misconstrued will be key. Just a thought. Thanks, Erum On Wed, Nov 12, 2025 at 9:48 AM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org<mailto:rssac-caucus@icann.org>> wrote: I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC. "Interpreting RSS Metrics" There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading. 1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ? What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)? -Ken _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> To unsubscribe send an email to rssac-caucus-leave@icann.org<mailto:rssac-caucus-leave@icann.org> _______________________________________________ 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.
Hello, Thank you for initiating this very important discussion. I strongly support the proposed work item on “Interpreting RSS Metrics.” I fully agree that our efforts must focus on more critical metrics like availability and correctness, rather than the often-misleading emphasis on latency. I also think the point Erum raised is key—understanding the target audience (technical, operational, etc.) and the potential for misinterpretation will be vital to making sure this work brings clarity and doesn't inadvertently create negative perception of the RSS. I would be pleased to contribute to the further discussions and the development of the Statement of Work. Regards, Mohibul On Thu, Nov 13, 2025 at 4:30 AM Dr. Rolla Hassan via rssac-caucus < rssac-caucus@icann.org> wrote:
Dear Ken, Thank you for initiating this thoughtful discussion. The proposed topic, *“Interpreting RSS Metrics,”* is indeed valuable and timely. I fully agree that there is often misinterpretation in how RSS performance metrics are viewed, particularly when emphasis is placed on latency rather than more critical indicators such as availability and correctness. I believe a focused work party on this subject could bring great clarity to the DNS community, helping stakeholders better understand and apply RSS metrics in meaningful ways. I would be pleased to contribute to further discussions and to the development of a potential Statement of Work. Regards Rolla Hassan ------------------------------ *From:* Erum Welling via rssac-caucus <rssac-caucus@icann.org> *Sent:* Thursday, November 13, 2025 4:24 AM *To:* Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) < kenneth.d.renard.ctr@army.mil> *Cc:* rssac-caucus@icann.org <rssac-caucus@icann.org> *Subject:* [RSSAC Caucus] Re: Potential RSSAC caucus work item: Interpreting RSS Metrics
Hi Ken,
I think the key question you pose is: How can the DNS community use these metrics to their advantage? Can you please provide greater detail on the audience, are they technical, operational...if not, my fear is that what they don't understand will hurt us...negative perception towards the RSS, and potentially "the sky is falling" syndrome. People will always assume the worst, so we need to tread this one carefully -- understanding the audience and how this information may be potentially used and possibly misconstrued will be key. Just a thought.
Thanks, Erum
On Wed, Nov 12, 2025 at 9:48 AM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings. If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC.
"Interpreting RSS Metrics"
There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance. Interpretation of these measurements can sometimes be misleading.
1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS). Availability and correctness seem to be more important with respect to the RSS. 2. Another focus is on the number and geographic distribution of the root server instances. While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts. 3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for. 4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ?
What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)? The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion). How can we refine the topics listed above? What other topics/measurements would be good to include? How can the DNS community use these metrics to their advantage? How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)?
-Ken _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ 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.
participants (6)
-
Dessalegn Yehuala -
Dr. Rolla Hassan -
Erum Welling -
James Olorundare -
Mohibul Mahmud -
Renard, Kenneth D CTR USARMY DEVCOM ARL (USA)