RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw All section numbers below refer to RFC 8912 6.1. Summary This category includes multiple indexes to the Registry Entries: the element ID and Metric Name. 6.1.1. ID (Identifier) 4 6.1.2. Name RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw 6.1.3. URI URL: https://www.iana.org/assignments/performance-metrics/RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw 6.1.4. Description This is a metric for DNS Response performance from a network user's perspective, for a specific named resource. The metric can be measured repeatedly using different resource names. RTDNS: This metric assesses the response time, the interval from the query transmission to the response. 6.1.5. Change Controller IETF 6.1.6. Version (of Registry Format) 1.0 6.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters". 6.2.1. Reference Definition Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035> (and updates). [RFC1035] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681] Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as "singleton" and "sample" are defined in Section 11 of [RFC2330]. For DNS Response Latency, the entities in [RFC1035] must be mapped to [RFC2681]. The Local Host with its User Program and Resolver take the Role of "Src", and the Foreign Name Server takes the Role of "Dst". Note that although the definition of round-trip delay between the Source (Src) and the Destination (Dst) at T as provided in Section 2.4 of [RFC2681] is directionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the Src Role will send the first packet to the host in the Dst Role and will ultimately receive the corresponding return packet from the Dst (when neither is lost). 6.2.2. Fixed Parameters Type-P as defined in Section 13 of [RFC2330]: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP) IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None UDP header values: Source port: 53 Destination port: 53 Checksum: The checksum MUST be calculated and the non-zero checksum included in the header Payload: The payload contains a DNS message as defined in [RFC1035] with the following values: The DNS header section contains: Identification (see the Runtime column) QR: Set to 0 (Query) OPCODE: Set to 0 (standard query) AA: Not set TC: Not set RD: Set to 1 (recursion desired) RA: Not set RCODE: Not set QDCOUNT: Set to 1 (only one entry) ANCOUNT: Not set NSCOUNT: Not set ARCOUNT: Not set The Question section contains: QNAME: The Fully Qualified Domain Name (FQDN) provided as input for the test; see the Runtime column QTYPE: The query type provided as input for the test; see the Runtime column QCLASS: Set to 1 for IN The other sections do not contain any Resource Records (RRs). Other measurement Parameters: Tmax: A loss threshold waiting time (and to help disambiguate queries). The value is 5.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905]. Observation: Reply packets will contain a DNS Response and may contain RRs. 6.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations. 6.3.1. Reference Methods The methodology for this metric (equivalent to Type-P-Round-trip-Delay-Poisson-Stream) is defined as in Section 2.6 of [RFC2681] (for singletons) and Section 3.6 of [RFC2681] (for samples) using the Type-P and Timeout defined in the Fixed Parameters column. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a response packet lost. Lost packets SHALL be designated as having undefined delay and counted for the RLDNS metric. The calculations on the delay (RTT) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process that calculates the RTT value MUST enforce the Tmax threshold on stored values before calculations. See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully arriving reply. DNS messages bearing queries provide for random ID Numbers in the Identification header field, so more than one query may be launched while a previous request is outstanding when the ID Number is used. Therefore, the ID Number MUST be retained at the Src and included with each response packet to disambiguate packet reordering if it occurs. If a DNS Response does not arrive within Tmax, the response time RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to disambiguate the successive queries that are otherwise identical. Since the ID Number field is only 16 bits in length, it places a limit on the number of simultaneous outstanding DNS queries during a stress test from a single Src address. Refer to Section 4.4 of [RFC6673] for an expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of [RFC2681]. However, the DNS server is expected to perform all required functions to prepare and send a response, so the response time will include processing time and network delay. Section 8 of [RFC6673] presents additional requirements that SHALL be included in the Method of Measurement for this metric. In addition to operations described in [RFC2681], the Src MUST parse the DNS headers of the reply and prepare the query response information for subsequent reporting as a measured result, along with the round-trip delay. 6.3.2. Packet Stream Generation This section provides details regarding packet traffic, which is used as the basis for measurement. In IPPM Metrics, this is called the "stream"; this stream can easily be described by providing the list of stream Parameters. Section 11.1.3 of [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal of lambda is the average packet spacing; thus, the Runtime Parameter is Reciprocal_lambda = 1/lambda, in seconds. Method 3 SHALL be used. Where given a start time (Runtime Parameter), the subsequent send times are all computed prior to measurement by computing the pseudorandom distribution of inter-packet send times (truncating the distribution as specified in the Parameter Trunc), and the Src sends each packet at the computed times. Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater than Trunc is set equal to Trunc instead. 6.3.3. Traffic Filtering (Observation) Details N/A 6.3.4. Sampling Distribution N/A 6.3.5. Runtime Parameters and Data Format Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src: The IP address of the host in the Src Role (format ipv4‑address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]). Dst: The IP address of the host in the Dst Role (format ipv4‑address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]). T0: A time, the start of a measurement interval (format "date‑time" as specified in Section 5.6 of [RFC3339]; see also "date‑and‑time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through other means. Tf: A time, the end of a measurement interval (format "date‑time" as specified in Section 5.6 of [RFC3339]; see also "date‑and‑time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time and date is ignored and Tf is interpreted as the duration of the measurement interval. Reciprocal_lambda: Average packet interval for Poisson streams, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905]. Trunc: Upper limit on Poisson distribution, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905] (values above this limit will be clipped and set to the limit value). ID: The 16-bit Identifier assigned by the program that generates the query. The ID value must vary in successive queries (a list of IDs is needed); see Section 4.1.1 of [RFC1035]. This Identifier is copied into the corresponding reply and can be used by the requester (Src) to match replies with any outstanding queries. QNAME: The domain name of the query, formatted as specified in Section 4 of [RFC6991]. QTYPE: The query type, which will correspond to the IP address family of the query (decimal 1 for IPv4 or 28 for IPv6), formatted as a uint16, as per Section 9.2 of [RFC6020]. 6.3.6. Roles Src: Launches each packet and waits for return transmissions from the Dst. Dst: Waits for each packet from the Src and sends a return packet to the Src. 6.4. Output This category specifies all details of the output of measurements using the metric. 6.4.1. Type Raw: For each DNS query packet sent, sets of values as defined in the next column, including the status of the response, only assigning delay values to successful query-response pairs. 6.4.2. Reference Definition For all outputs: T: The time the DNS query was sent during the measurement interval (format "date‑time" as specified in Section 5.6 of [RFC3339]; see also "date‑and‑time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. dT: The time value of the round-trip delay to receive the DNS Response, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. This value is undefined when the response packet is not received at the Src within a waiting time of Tmax seconds. RCODE: The value of the RCODE field in the DNS Response header, expressed as a uint64 as specified in Section 9.2 of [RFC6020]. Non-zero values convey errors in the response, and such replies must be analyzed separately from successful requests. 6.4.3. Metric Units RTDNS: Round-trip delay, dT, is expressed in seconds. 6.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. Calibration in-situ could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address and payload manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized in this way. When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement, with an additional indication that it is a calibration result. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the output result resolution that is the result of system noise and is thus inaccurate. 6.5. Administrative Items 6.5.1. Status Current 6.5.2. Requester RFC 8912 6.5.3. Revision 1.0 6.5.4. Revision Date 2021-11-17 6.6. Comments and Remarks None