|
A. rcPing Facility
The Registry Component Ping (rcPing) facility is used to determine two levels of service level agreement (SLA) compliance by the registry. The first level of compliance involves determining the availability of specific components/functions within the registry system. The second level of compliance involves determining if the components/functions are responding within a pre-determined time period.
The rcPing request is generated by a monitor (rcPing Monitor) component within the server complex. The interface/request handler which is responsible for receiving commands for the monitored components/functions should record the time of the request arriving, ping the monitored component/function, record the stop time, determine the difference in milliseconds and respond with the integer value in milliseconds of the difference.
The rcPing Monitor will time out if no response is received from the interface within a pre-determined interval. The rcPing request is specific to the component being monitored. Monitoring requests are sent independent of one another.
The following table lists the components to be monitored by the rcPing facility.
Components to be Monitored by rcPing Facility
| Component |
Function |
Interface |
rcPing Command |
Response Time |
| eppServer |
AddDomain |
eppServer |
RcPingepp(add) |
800 |
| eppServer |
renewDomain |
eppServer |
RcPingepp(renew) |
800 |
| eppServer |
deleteDomain |
eppServer |
RcPingepp(delete) |
800 |
| eppServer |
transferDomain |
eppServer |
RcPingepp(transfer) |
1600 |
| eppServer |
checkDomain |
eppServer |
RcPingepp(check) |
350 |
| Radmin |
updateRegistrar |
radmin |
RcPingAdmin(update) |
800 |
| billingServer |
checkBalance |
eppServer |
RcPingepp(checkBalance) |
800 |
| billingServer |
updateBalance |
eppServer |
RcPingepp(updateBalance) |
800 |
| Whois |
whois |
whois |
RcPingWhois(whois) |
800 |
| Dns |
transfer |
eppServer |
RcPingepp(dnsTransfer) |
800 |
Each component being monitored can be configured with the following:
- The time-out threshold. A typical value for timeout is three (3) seconds.
- The expected response time for each ping command, as listed above.
- The interval at which the ping commands will be sent. A typical value for the sampling interval is five (5) minutes.
- The number of consecutive failures (i.e. exceeded response times and ping time outs) that determine a non-compliance with the SLA for a single component. A typical value is three (3) consecutive failures.
The rcPing monitor will store all response time data in a database that will be archived on a daily basis.
B. Nameserver Availability and Performance Measurements
1. Availability of each .ORG nameserver shall be measured by the rcPing utility
A nameserver that does not respond to three consecutive ping requests (pings at five-minute intervals with three-second timeouts) will be considered as Not Responding.
2. Cross-Network Nameserver Performance Requirements
Nameserver Round-trip time and packet loss from the Internet are important elements of the quality of service provided by the registry operator. These characteristics, however, are affected by Internet performance and therefore cannot be closely controlled by registry operator. Accordingly, these requirements are not matters subject to Service Level Exceptions and credits under the Service Level Agreement in Appendix M. The committed Performance Specification for cross-network nameserver performance is a measured Round-trip time of under 300ms and measured packet loss of under 10%. Cross-network nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner:
2.1. The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .ORG nameservers and observing the responses from the .ORG nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and Europe).
2.2. Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .ORG second-level domains, pre-selected to ensure that the names exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received will be noted.
2.3. To meet the packet loss and Round-trip-time requirements for a particular CNNP Test, all three of the following must be true:
2.3.1. The Round-trip time and packet loss from each measurement location to at least one .ORG nameserver must not exceed the required values.
2.3.2. The Round-trip time to each of 75% of the .ORG nameservers from at least one of the measurement locations must not exceed the required value.
2.3.3. The packet loss to each of the .ORG nameservers from at least one of the measurement locations must not exceed the required value.
2.4. Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.
2.5. To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of the day, as well as on different days of the week). The registry operator will be deemed to have failed to meet the cross-network nameserver performance requirement only if the .ORG nameservers persistently fail (see item 1.1.3 above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.
2.6. In the event of persistent failure of the CNNP Tests, ICANN will give registry operator written notice of the failures (with backup data) and registry operator will have sixty days to cure the failure.
2.7. If, following that opportunity to cure, the .ORG nameservers continue to persistently fail CNNP Tests and registry operator fails to resolve the problem within thirty days after written notice of the continuing failures.
2.8. Sixty days before the commencement of testing under this provision, ICANN will provide registry operator with the opportunity to evaluate the testing tools and procedures to be used by ICANN. In the event that registry operator does not approve of such tools and procedures, ICANN will work directly with registry operator to make necessary modifications.
Back to top
|
