24 Shared Registration System (SRS) Performance

Prototypical answer:

24.1. Performance Specifications
24.1.1. Service Availability
Service Availability is defined in time, and in minutes, that the core Registry services should respond to its users. As a definition, ʺservice unavailableʺ means that one of the listed services in the Matrix becomes unavailable to all users. That is, when no user can initiate a session with or receive a response from the Registry.
Our definition of Service Availability is measured as follows:
Service Availability % = {[TM - (UOM + POM) ] ⁄ TM}*100 where:
TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes)
POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period)
UOM = Unplanned Outage Minutes.
Service Availability = 98% per month
Service Availability as it applies to the SRS refers to the ability of the SRS to respond to ICANN-Accredited Registrars that access the SRS through the EPP protocol. SRS unavailability, excluding Planned Outages and Extended Planned Outages, will be logged with the Registry Operator as Unplanned Outage Minutes. Unavailability will not include any events affecting individual ICANN-Accredited Registrars locally.
The committed Service Availability for SRS is 98% per calendar month.
24.1.2. Planned Outage
High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance (ʺPlanned Outageʺ) ensures a high level of service for the Registry.
Planned Outage Duration = 3 hours (180 minutes) per month
The Planned Outage Duration defines the maximum allowable time, in hours and minutes that the Registry Operator is allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. The Planned Outage Duration for the SRS is 3 hours (180 minutes) per month.
Planned Outage Timeframe = 00:00-03:00 UTC Sunday
The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned Outage Timeframe shall be 00:00-03:00 UTC on the third Sunday. When the day following the third Sunday is a holiday, i.e., the Sunday is included in the consecutive holidays, it shall be 00:00-03:00 UTC of the last day of the consecutive holidays.
Planned Outage Notification = 30 days
The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage Notification Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the SRS is 30 days.
24.1.3. Extended Planned Outage
In some cases such as software upgrades and platform replacements, an extended maintenance timeframe is required. Extended Planned Outages will be less frequent than regular Planned Outages but their duration will be longer.
Extended Planned Outage Duration = 12 hours (720 minutes) per month
The Extended Planned Outage Duration defines the maximum allowable time in hours and minutes that the Registry Operator is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period.
The Extended Planned Outage Duration for the SRS is 12 hours (720 minutes) per month.
Extended Planned Outage Timeframe = 00:00-12:00 UTC Sunday
The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage can occur. The Extended Planned Outage Timeframe shall be 00:00-12:00 UTC on the third Sunday. When the day following the third Sunday is a holiday, i.e., the Sunday is included in consecutive holidays, the time frame shall be 00:00-12:00 UTC of the last day of the consecutive holidays.
Extended Planned Outage Notification = 30 days
The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage Notification for the SRS is 30 days.
24.1.4. Processing Time
Processing Time is an important measurement of transaction-based services like the Registry. The first three Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that service.
Processing Time refers to the time that the Registry Operator receives a request and sends a response to that request.
Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response.
Processing Time - EPP session command = 200 milliseconds for 90%
Processing Time - EPP session command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for create EPP session.
The performance specification is 200 milliseconds for 90% of the transactions. That is, 90% of the transactions will take 200 milliseconds or less from the time the Registry Operator receives the request to the time it provides a response.
Processing Time - EPP query command = 100 milliseconds for 90%
Processing Time - EPP query command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for an availability query of a specific domain name.
The Performance Specification is 100 milliseconds for 90% of the transactions processed. That is, 90% of the transactions will take 100 milliseconds or less from the time the Registry Operator receives the request to the time it provides a response.
Processing Time - EPP transform command = 200 milliseconds for 90%
Processing Time - EPP transform command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time to add, modify, and delete transactions associated with domain names, nameservers, contacts, and registrar profile information.
The performance specification is 200 milliseconds for 90% of the transactions. That is, 90% of the transactions will take 200 milliseconds or less from the time the Registry Operator receives the request up to the time it provides a response.
24.1.5. Update Frequency
There are two important elements of the Registry that are updated frequently and are used by the general public; DNS and Whois. Registrars generate these updates through the SRS. The SRS then updates the DNS and the Whois.
Update Frequency - DNS = 60 minutes for 95%
The committed performance specification with regards to Update frequency for the DNS is 60 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the DNS during a Monthly Timeframe will be completed within 60 minutes.
Update Frequency - Whois = 60 minutes for 95%
The committed performance specification with regards to Update frequency for the Whois is 60 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the Whois during a Monthly Timeframe will be completed within 60 minutes.
24.1.6. RTT
We define the RTT for EPP by assuming that the round-trip time is 120 milliseconds for trans-Pacific communications, 100 milliseconds for trans-American communications, 120 milliseconds for trans-Atlantic communications, 120 milliseconds between EU and South Africa, and 460 milliseconds for the communications with South Africa, one of the most distant locations for us.
RTT - EPP session-command = 4,000 milliseconds for 90%
Since the Processing Time is defined as 200 milliseconds for 90%, we believe the time frame of 660 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 4,000 milliseconds for 90%.
RTT - EPP query-command = 2,000 milliseconds for 90%
Since the Processing Time is defined as 100 milliseconds for 90%, we believe the time frame of 560 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 2,000 milliseconds for 90%.
RTT - EPP transform-command = 4,000 milliseconds for 90%
Since the Processing Time is defined as 200 milliseconds for 90%, we believe the time frame of 660 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 4,000 milliseconds for 90%.
24.1.7. Performance Specification Matrix
Table_24-1_Performance Specification Matrix.pdf










24.2. SRS system description
Only the EPP will be available for the interface between registry and registrar in .sakura. The Web and other non-EPP interfaces will not be provided for domain-name registration.
ʺFigure_24-1_Outline of System Configuration.pdfʺ outlines the system configuration. For the coordination between systems, the answer for #24.2.3 (Interconnectivity with Other Registry Systems) describes the overview and the answer for #31 (Technical overview of proposed registry) describes the detail focusing on the data flow.






Figure_24-1_Outline of System Configuration.pdf

24.2.1. Network Diagram
All the servers constituting the SRS will be duplicated to avoid the system outage due to single fault.
ʺFigure_24-2_Overview of Network Configuration.pdfʺ shows the network configuration for SRS:






Figure_24-2_Overview of Network Configuration.pdf

24.2.2. Servers
All the server database applications constituting the SRS will be duplicated to avoid the system outage due to a single fault. In addition, to improve the processing performance, we will apply the load sharing scheme by operating the duplicated servers in active⁄active mode.

24.2.3. Interconnectivity with Other Registry Systems
Coordination within Registry systems
The following functions will have the direct contact point with SRS within the Registry System (please refer to ʺFigure_24-1_Outline of System Configuration.pdfʺ) :
* DNS (including DNSSEC)
* Whois, Zone File Access, Bulk Registration Data Access
* Data Escrow
As stated in #24.1.5 (Update Frequency), DNS and Whois will be synchronized through batch processing at intervals of 60 minutes.
For Zone File Access and Bulk Registration Data Access, the data will be retrieved once a day and made ready for downloading:The answer for #26 (Whois) provides the details.
For Data Escrow, the data will be retrieved once a day and transferred to Escrow Agent:The answer for #38 (Escrow) provides the details.
Coordination with Secondary site
In addition to the .sakura SRS in Primary Site, which will provide the service during normal operation, we will implement another SRS which will be operated in a hot-standby mode in the Secondary Site, to prepare for the impaired services in the Primary Site due to a large-scale disaster or other events. Any changes applied to the SRS database in the Primary Site will be reflected on the SRS in the Secondary Site through synchronization within one minute. The batch processing will be used for the synchronization from the Primary Site to the Secondary Site.
24.3. Technical resources
24.3.1. System Building and Operation Performance of .sakura Registry Operator
The .sakura Registry Operator has experiences in building and operating the registry systems, and has several staff members with abundant experiences and expertise in running a stable SRS operation.

24.3.2. Registrar System Building and Operation Performance of .sakura Registry Operator
Certified as ICANN-Accredited Registrar, the .sakura Registry Operator has experiences of building and operating the registrar system that communicates with SRSs via EPP, and has several staff members with abundant experiences and expertise in operating the EPP interface system.

24.4. Resource Planning
24.4.1. Initial Implementation
The resources required for building and setting up the networks and servers are described in the answer for (a-1) of #31.5.1 (Initial Implementation).
The resources required for the development of the software (EPP interface) are described in the answer for (b-1) of #31.5.1 (Initial Implementation). The resources required for building and setting up the SRS database are described in the answer for (c-1) of #31.5.1 (Initial Implementation).
24.4.2. Ongoing Maintenance
The resources required for the maintenance of the software (EPP interface) are described in the answer for (d-1) of #31.5.2 (Ongoing Maintenance). The resources required for the maintenance of the SRS database are described in the answer for (e-1) of #31.5.2 (Ongoing Maintenance).

Similar gTLD applications: (2)