[Gnso-newgtld-wg-wt4] Root Zone Scaling Myths

Mon Jun 19 20:53:46 UTC 2017

Thanks Rubens.  Who are these consultants who compiled the final report on Root Zone Stability in relation to scaling (i.e. growth in TLDs)?
NLnet Labs, SIDN LABS, and TNO?  Were they hired by the Board or by PTI?

What is the degree of participation by PTI in oversight of the stability of the root?  Is there an ongoing operational responsibility that rests with PTI to monitor this as TLDs are added?

What is the impact of the statement in the report that “boundless” new gTLDs could affect root stability?  Should this affect the WG’s discussions regarding a period of open applications (first-come first served) AFTER a period of window(s) to deal with pent –up demand?

Thank you,
Anne

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

AAikman at lrrc.com<mailto:AAikman at lrrc.com>

_____________________________

[cid:image004.png at 01D2E903.781791F0]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 700

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

From: gnso-newgtld-wg-wt4-bounces at icann.org [mailto:gnso-newgtld-wg-wt4-bounces at icann.org] On Behalf Of Rubens Kuhl
Sent: Saturday, June 17, 2017 7:41 PM
To: gnso-newgtld-wg-wt4 at icann.org
Subject: [Gnso-newgtld-wg-wt4] Root Zone Scaling Myths

While most current root zone scaling information is available in the CDAR report (https://www.icann.org/en/system/files/files/cdar-root-stability-final-08mar17-en.pdf), I did some research regarding root zone scaling, and found that the most comprehensive source to understand is this ICANN report of 2012:
http://newgtlds.icann.org/en/about/historical-documentation/root-scaling-27jun12-en.pdf

Besides all its interesting content, they compiled a list of previous root zone scaling studies that I reproduce here, changing only the link style and updating the links to their current publishing points:

"Appendix A — Previous Studies and Analyses

A number of studies and analyses have been compiled on the topic of scaling of the DNS Root Zone in the last three years:
            • Root Zone Augmentation and Impact Analysis(https://www.icann.org/en/system/files/files/root-zone-augementation-analysis-17sep09-en.pdf) — This study, also known as the “L-Root Study,” examined the impacts of multifaceted growth of the size of the Root Zone on the performance of “l.root-servers.net,” the root server that is managed by ICANN. This analysis considered the implications of IPv6 addresses, DNSSEC, as well as new TLDs in a laboratory simulation. The work was conducted by the independent DNS Operations and Research Center (DNS-OARC). This study was published in September 2009, and its conclusions include that root zone servers’ requirements for memory grow linearly with the number of top-level domains, that the then-deployed software was capable of handling at least 100,000 top-level domains before there was potential degradation in response times. Other software in use had higher thresholds (i.e. over a million TLDs) before the size of the root zone became a factor.
            • Report on the Impact on the DNS Root System of Increasing the Size and Volatility of the Root Zone(https://www.icann.org/en/system/files/files/root-scaling-study-report-31aug09-en.pdf) — This report was developed by a specially convened “Root Server Scaling Team” (RSST), comprised of experts from the RSSAC, SSAC as well as experts from outside the ICANN community.
            • Summary of the Impact of Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf) — An analysis of issues relating to the impact of Root Zone Scaling was prepared by ICANN and published the document in October 2010. This document considers the findings of the DNS-OARC and RSST reports, and the various root scaling events to date. It identifies the impacts from IPv6 deployment, TLD growth, DNSSEC deployment and other factors, and concludes the maximum growth to the Root Zone caused by the New gTLD Program is unlikely to cause any disruption.
            • Report of the Security and Stability Advisory Committee on Root Scaling(https://www.icann.org/en/system/files/files/sac-046-en.pdf) — ICANN’s Security and Stability Advisory Committee reviewed the original research questions relating to Root Zone Scaling, and provided recommendations relating to processes to handle the increase in the number of top-level domains.
            • Explanatory memorandum on Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/root-zone-scaling-15apr11-en.pdf) — As part of a number of briefing papers associated with the New gTLD Program following dialogue between the ICANN Board and the Governmental Advisory Committee, ICANN published a memorandum concerning Root Scaling in April 2011.
            • Board response to the GAC on Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/root-scaling-30may11-en.pdf) — ICANN published an additional response to the issues raised on dialogue between the ICANN Board and the Governmental Advisory Committee, by providing further detail on how ICANN undertakes to address the ICANN community’s and the GAC’s concerns regarding root scaling. This response was published in May 2011."

Besides those documents, the other interesting documents on this are:
Anticipated delegation rate model: http://www.icann.org/en/topics/new-gtlds/anticipated-delegation-rate-model-25feb10-en.pdf
2010 RSSAC e-mail to Board regarding scaling: https://www.icann.org/en/system/files/files/murai-to-board-25nov10-en.pdf
SAC 042 (https://www.icann.org/en/system/files/files/sac-042-en.pdf) (later superseded by SAC 046)

In short, the anticipated delegation rate model estimated the maximum *evaluation* throughput to be near a 1000 per year, and other ACs responded that it wouldn't be a problem to be delegated. They have not said that the system had a 1000/year limit, a myth that started only when the number of applications (near 2000) exceeded the high estimate of applications (a thousand), that discussion went stray and landed at that being a limit.

Since those studies, processing power, memory sizes, DNS software design and available bandwidth all greatly increased, so even figures that were determined at that point (like the 100,000 TLDs root zone size) are outdated, although still limited by latency of the global Internet (which is mainly determined by the speed of light in optical fiber). The root zone now features DNSSEC and IPv6 to most TLDs, so something that was an unknown at that time is now a baseline, the root zone management system has been completely rewritten, and root server monitoring instrumentation greatly improved (see RSSAC 002, https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf)

But, we didn't get an RSSAC response to our CC2 question on the CDAR report, nor they mentioned this in their comments to the CDAR report which were mostly clarifying questions. I believe we could ask them to clarify that and clear the fog in this topic.

Rubens

________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170619/0e6382f6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 112 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170619/0e6382f6/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 6488 bytes
Desc: image004.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170619/0e6382f6/image004-0001.png>