Network Working Group A. Morton Internet-Draft AT&T Labs Intended status: Standards Track M. Bagnulo Expires:January 9,May 2, 2017 UC3M P. Eardley BT K. D'Souza AT&T LabsJuly 8,October 29, 2016 Initial Performance Metric Registry Entriesdraft-ietf-ippm-initial-registry-01draft-ietf-ippm-initial-registry-02 Abstract This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * All section 4 and 5 parameters reference YANG types for alternate data formats. * implementation of standard naming format for parameters. Still need: * revisions that follow section 4 changes in proposed metrics defined in sections 6, 7, 8. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onJanuary 9,May 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .76 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Registry Categories and Columns . . . . . . . . . . . . . . .87 4. UDP Round-trip Latency Registry Entry . . . . . . . . . . . . 8 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .98 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 4.3.3. Traffic Filtering (observation) Details . . . . . . .1312 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.2.Data Format . . . . .Reference Definition . . . . . . . . . . . . . . . .1514 4.4.3.Reference . .Metric Units . . . . . . . . . . . . . . . . . . . . 15 4.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . . . 15 4.5. Administrative items . . . . . . . . . . . . . . . . . .1516 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . .1516 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 5.3. Method of Measurement . . . . . . . . . . . . . . . . . .1819 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 5.3.2. Packet Stream Generation . . . . . . . . . . . . . .1920 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . .2122 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . .2122 5.4.2.Data Format . . . . .Reference Definition . . . . . . . . . . . . . . . . 22 5.4.3.Reference . .Metric Units . . . . . . . . . . . . . . . . . . . .2223 5.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . .22. 23 5.5. Administrative items . . . . . . . . . . . . . . . . . .2324 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . .2324 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . .2324 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . .2324 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . .2324 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . .2324 6. DNS Response Latency Registry Entry . . . . . . . . . . . . .2324 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .2324 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . .2324 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . .2425 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . .2425 6.1.4. Description . . . . . . . . . . . . . . . . . . . . .2425 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . .2425 6.2.1. Reference Definition . . . . . . . . . . . . . . . .2425 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . .2526 6.3. Method of Measurement . . . . . . . . . . . . . . . . . .2627 6.3.1. Reference Method . . . . . . . . . . . . . . . . . .2627 6.3.2. Packet Generation Stream . . . . . . . . . . . . . .2728 6.3.3. Traffic Filtering (observation) Details . . . . . . .2729 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . .2829 6.3.5. Run-time Parameters and Data Format . . . . . . . . .2829 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . .2930 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . .2930 6.4.1. Type/Value (two diff terms used) . . . . . . . . . .2930 6.4.2.Data Format . . . . .Reference Definition . . . . . . . . . . . . . . . .2931 6.4.3.Reference . .Metric Units . . . . . . . . . . . . . . . . . . . .3031 6.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . .30. 32 6.5. Administrative items . . . . . . . . . . . . . . . . . .3032 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . .3132 6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . .3132 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . .3132 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . .3132 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . .3132 7. UDP Poisson One-way Delay Registry Entries . . . . . . . . .3132 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .3132 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . .3133 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . .3233 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . .3233 7.1.4. Description . . . . . . . . . . . . . . . . . . . . .3233 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . .3233 7.2.1. Reference Definition . . . . . . . . . . . . . . . .3233 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . .3334 7.3. Method of Measurement . . . . . . . . . . . . . . . . . .3435 7.3.1. Reference Method . . . . . . . . . . . . . . . . . .3435 7.3.2. Packet Generation Stream . . . . . . . . . . . . . .3435 7.3.3. Traffic Filtering (observation) Details . . . . . . .3436 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . .3536 7.3.5. Run-time Parameters and Data Format . . . . . . . . .3536 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . .3537 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . .3637 7.4.1. Type/Value (two diff terms used) . . . . . . . . . .3637 7.4.2.Data Format . . . . .Reference Definition . . . . . . . . . . . . . . . .3637 7.4.3.Reference . .Metric Units . . . . . . . . . . . . . . . . . . . .3839 7.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . .38. 39 7.5. Administrative items . . . . . . . . . . . . . . . . . .3839 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . .3839 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . .3840 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . .3840 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . .3940 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . .3940 8. UDP Periodic One-way Delay Registry Entries . . . . . . . . .3940 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .3940 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . .3940 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . .3940 8.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . .4041 8.1.4. Description . . . . . . . . . . . . . . . . . . . . .4041 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . .4041 8.2.1. Reference Definition . . . . . . . . . . . . . . . .4041 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . .4142 8.3. Method of Measurement . . . . . . . . . . . . . . . . . .4142 8.3.1. Reference Method . . . . . . . . . . . . . . . . . .4143 8.3.2. Packet Generation Stream . . . . . . . . . . . . . .4243 8.3.3. Traffic Filtering (observation) Details . . . . . . .4243 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . .4244 8.3.5. Run-time Parameters and Data Format . . . . . . . . .4244 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . .4344 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . .4345 8.4.1. Type/Value (two diff terms used) . . . . . . . . . .4445 8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . .4445 8.4.3.Reference . .Metric Units . . . . . . . . . . . . . . . . . . . .4647 8.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . . .4647 8.5. Administrative items . . . . . . . . . . . . . . . . . .4647 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . .4647 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . .4647 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . .4647 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . .4648 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . .4648 9.partlyver08 BLANK Registry Entry . . . . . . . . . . . . . . . . .4648 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .4748 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . .4748 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . .4748 9.1.3.URI .URIs . . . . . . . . . . . . . . . . . . . . . . . .4748 9.1.4. Description . . . . . . . . . . . . . . . . . . . . .4748 9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 48 9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 48 9.1.7. Version (of Registry Format) . . . . . . . . . . . . 48 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . .4749 9.2.1. Reference Definition . . . . . . . . . . . . . . . .4749 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . .4849 9.3. Method of Measurement . . . . . . . . . . . . . . . . . .4849 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49 9.3.2. PacketGenerationStream Generation . . . . . . . . . . . . . . 49 9.3.3. Traffic Filtering (observation) Details . . . . . . . 49 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 49 9.3.5. Run-time Parameters and Data Format . . . . . . . . .4950 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . .4950 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . .4950 9.4.1.Type/Value (two diff terms used)Type . . . . . . . . . . . . .50 9.4.2. Data Format. . . . . . . . . . . 50 9.4.2. Reference Definition . . . . . . . . . . .50 9.4.3. Reference. . . . . 50 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 50 9.4.4.Metric UnitsCalibration . . . . . . . . . . . . . . . . . . . . . 50 9.5. Administrative items . . . . . . . . . . . . . . . . . . 50 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 50 9.5.2. Requestor(keep?). . . . . . . . . . . . . . . . . . . . . . 50 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 50 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . .5051 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . .5051 10.BLANKExample RTCP-XR Registry Entry . . . . . . . . . . . . . . .. . . . .51 10.1.Summary .Registry Indexes . . . . . . . . . . . . . . . . . . . . 51 10.1.1. Identifier . . .51 10.1.1. ID (Identifier). . . . . . . . . . . . . . . . . . 51 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1.4.DescriptionStatus . . . . . . . . . . . . . . . . . . . .51 10.2. Metric Definition . . . . . . . . . . . . . . . .. . . 5110.2.1. Reference Definition . . . . . . . . . . . . .10.1.5. Requestor . . .51 10.2.2. Fixed Parameters. . . . . . . . . . . . . . . . . . 5110.3. Method of Measurement . . . . . . . . . . . . . .10.1.6. Revision . . .52 10.3.1. Reference Method. . . . . . . . . . . . . . . . . .52 10.3.2. Packet Generation Stream. 51 10.1.7. Revision Date . . . . . . . . . . . . .52 10.3.3. Traffic Filtering (observation) Details. . . . . . 5210.3.4. Sampling Distribution . . .10.1.8. Description . . . . . . . . . . . .52 10.3.5. Run-time Parameters and Data Format. . . . . . . . 5210.3.6. Roles . . . . . . . . . .10.1.9. Reference Specification(s) . . . . . . . . . . . . . 5210.4. Output10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 52 10.2.1. Reference Definition . . . . . .52 10.4.1. Type/Value (two diff terms used). . . . . . . . . . 5210.4.2. Data Format . .10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 5210.4.3. Reference . . . .10.3. Method of Measurement . . . . . . . . . . . . . . . . . 5310.4.4. Metric Units . .10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 5310.5. Administrative items . . . . . . . . .10.3.2. Stream Type and Stream Parameters . . . . . . . . . 5310.5.1. Status . . . . . . . . . . .10.3.3. Output Type and Data Format . . . . . . . . . . . . 5310.5.2. Requestor (keep?) . . . . . . . .10.3.4. Metric Units . . . . . . . . .53 10.5.3. Revision. . . . . . . . . . . 54 10.3.5. Run-time Parameters and Data Format . . . . . . . . 54 10.4. Comments and Remarks . . .53 10.5.4. Revision Date. . . . . . . . . . . . . . . 55 11. Revision History . . . .53 10.6. Comments and Remarks. . . . . . . . . . . . . . . . . .53 11. Example RTCP-XR Registry Entry56 12. Security Considerations . . . . . . . . . . . . . . .53 11.1. Registry Indexes. . . . 56 13. IANA Considerations . . . . . . . . . . . . . . . .53 11.1.1. Identifier. . . . . 56 14. Acknowledgements . . . . . . . . . . . . . . . .54 11.1.2. Name. . . . . . 56 15. References . . . . . . . . . . . . . . . . . .54 11.1.3. URI. . . . . . . 57 15.1. Normative References . . . . . . . . . . . . . . . . .54 11.1.4. Status. 57 15.2. Informative References . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . .54 11.1.5. Requestor. . . . . . . . . . . . . . . . . .. . . 54 11.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 54 11.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 54 11.1.8. Description . . . . . . . . . . . . . . . . . . . . 54 11.1.9. Reference Specification(s) . . . . . . . . . . . . . 54 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 54 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 55 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 11.3.2. Stream Type and Stream Parameters . . . . . . . . . 56 11.3.3. Output Type and Data Format . . . . . . . . . . . . 56 11.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 56 11.3.5. Run-time Parameters and Data Format . . . . . . . . 56 11.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 58 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 58 13. Security Considerations . . . . . . . . . . . . . . . . . . . 59 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 16.1. Normative References . . . . . . . . . . . . . . . . . . 59 16.2. Informative References . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 1. Introduction Note: Efforts to synchronize structure and terminology with [I-D.ietf-ippm-metric-registry] will likely be incomplete until both drafts are stable. This memo proposes an initial set of entries for the Performance Metric Registry. It uses terms and definitions from the IPPM literature, primarily [RFC2330]. Proponents of Passive Performance Metrics are encouraged to develop a similar document. Although there are several standard templates for organizing specifications of performance metrics (see [RFC2679] for an example of the traditional IPPM template, based to large extent on the Benchmarking Methodology Working Group's traditional template in [RFC1242], and see [RFC6390] for a similar template), none of these templates were intended to become the basis for the columns of an IETF-wide registry of metrics. While examinating aspects of metric specifications which need to be registered, it became clear that none of the existing metric templates fully satisfies the particular needs of a registry. Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format for a Performance Metric Registry. Section 5 of [I-D.ietf-ippm-metric-registry] also gives guidelines for those requesting registration of a Metric, that is the creation of entry(s) in the Performance Metric Registry: "In essence, there needs to be evidence that a candidate Registered Performance Metric has significant industry interest, or has seen deployment, and there is agreement that the candidate Registered Performance Metric serves its intended purpose." The process in [I-D.ietf-ippm-metric-registry] also requires that new entries are administered by IANA through Expert Review, which will ensure that the metrics are tightly defined. 2. Scope This document defines the initial set of Performance Metrics Registry entries, for which IETF approval (following development in the IP Performance Metrics (IPPM) Working Group) will satisfy the requirement for Expert Review. Note that all are Active Performance Metrics, which are based on RFCs prepared in the IPPM working group of the IETF, according to their framework [RFC2330] and its updates. 3. Registry Categories and Columns This section provides the categories and columns of the registry, for easy reference. An entry (row) therefore gives a complete description of a Registered Metric. Registry Categories and Columns, shown as Category ------------------ Column | Column | Summary -------------------------------- ID | Name | URIs | Description | Metric Definition ----------------------------------------- Reference Definition | Fixed Parameters | Method of Measurement --------------------------------------------------------------- Reference | Packet | Traffic | Sampling | Run-time | Role | Method | Stream | Filter | dist. | Param | | | Generation | Output ---------------------------- Type | Reference | Units | | Definition | | Administrative information ---------------------------------- Status |Request | Rev | Rev.Date | Comments and Remarks -------------------- 4. UDP Round-trip Latency Registry Entry This section gives an initial registry entry for the UDP Round-trip Latency. Note: Each Registry entry only produces a "raw" output or a statistical summary. To describe both "raw" and one or more statistics efficiently, the Identifier, Name, and Output Categories can be split and this section can become two or more closely-related metrics. See Section 7 for an example specifying multiple Registry entries with many common columns. 4.1. Summary This category includes multiple indexes to the registry entry: the element ID and metric name. 4.1.1. ID (Identifier) <insert a numeric identifier, an integer, TBD> 4.1.2. Name <insert name according to metric naming convention> RTDelay_Active_UDP_RFCXXXXsecY_Seconds_95%tile 4.1.3. URIs URN: Prefix urn:ietf:params:performance:metric:<name> URL: http://<TBD by IANA>/<name> 4.1.4. Description This metric assesses the delay of a stream of packets exchanged between two hosts (which are the two measurement points), and the Output is the Round-trip delay for all successfully exchanged packets expressed as the 95th percentile of their conditional delay distribution. 4.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. 4.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] <specific section reference and additional clarifications, if needed> 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]. Note that although the definition of "Round-trip-Delay between Src and Dst" 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 "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). Finally, note that the variable "dT" is used in [RFC2681] to refer to the value of Round-trip delay in metric definitions and methods. The variable "dT" has been re-used in other IPPM literature to refer to different quantities, and cannot be used as a global variable name. 4.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in the measurement system for use when needed> Type-P as defined in Section 13 of [RFC2330]: o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum: the checksum MUST be calculated o UDP Payload * total of 9 bytes Other measurement parameters: o Tmax: a loss threshold waiting time * 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 4.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 methods for implementations. 4.3.1. Reference Method <for metric, insert relevant section references and supplemental info> The methodology for this metric is defined as Type-P-Round-trip- Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under Fixed Parameters. 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 packet lost. Lost packets SHALL be designated as having undefined delay. 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 which calculates the RTT value MAY 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 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 packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to dis-ambiguate packet reordering if it occurs. If a standard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and time-stamps, if they are conveyed in the packet payload. Refer to Section 4.4 of [RFC6673] for expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of [RFC6673] presents additional requirements which MUST be included in the method of measurement for this metric. 4.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. <section/specification references, and description of any new generation parameters, if needed> 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 Run-time Parameter is Reciprocal_lambda = 1/ lambda, in seconds. >>> Check with Sam, most likely it is this... Method 3 SHALL be used, where given a start time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computing the pseudo-random distribution of inter- packet send times, (truncating the distribution as specified in the Run-time 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. 4.3.3. Traffic Filtering (observation) Details The measured results based on a filtered version of the packets observed, and this section provides the filter details (when present). <section reference>. NA 4.3.4. Sampling Distribution <insert time distribution details, or how this is diff from the filter> NA 4.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. <list of run-time parameters, and their data formats> 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-and- time" as specified in Section 5.6 of [RFC3339], see also 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-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored60 1. Introduction Note: Efforts to synchronize structure andTf 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 = 5 (see section 9.3 of [RFC6020])terminology withresolution[I-D.ietf-ippm-metric-registry] will likely be incomplete until both drafts are stable. This memo proposes an initial set of0.0001 seconds (0.1 ms), and with lossless conversion to/fromentries for the32-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 = 5 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms),Performance Metric Registry. It uses terms andwith lossless conversion to/fromdefinitions from the32-bit NTP timestamp as per section 6IPPM literature, primarily [RFC2330]. Proponents of[RFC5905] (values above this limit will be clipped and setPassive Performance Metrics are encouraged tothe limit value). (if fixed, Trunc = 30.0000 seconds.) >>> should Poisson run-time params be fixed instead? probably yes if modelingdevelop aspecific versionsimilar document. Although there are several standard templates for organizing specifications ofMBA tests. 4.3.6. Roles <lists the namesperformance metrics (see [RFC2679] for an example of thedifferent roles fromtraditional IPPM template, based to large extent on themeasurement method> Src launches each packetBenchmarking Methodology Working Group's traditional template in [RFC1242], andwaits for return transmissions from Dst. Dst waitssee [RFC6390] foreach packet from Src and sendsareturn packet to Src. 4.4. Output This category specifies all detailssimilar template), none of these templates were intended to become theOutput of measurements usingbasis for themetric. 4.4.1. Type <insert namecolumns of an IETF-wide registry of metrics. While examinating aspects of metric specifications which need to be registered, it became clear that none of theoutput type, raw or a selected summary statistic> Percentile -- forexisting metric templates fully satisfies theconditional distributionparticular needs ofall packets withavalid valueregistry. Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format for a Performance Metric Registry. Section 5 of [I-D.ietf-ippm-metric-registry] also gives guidelines for those requesting registration ofRound-trip delay (undefined delays are excluded),asingle value corresponding toMetric, that is the95th percentile, as follows: See section 4.1creation of[RFC3393] for details onentry(s) in theconditional distributionPerformance Metric Registry: "In essence, there needs toexclude undefined values of delay,be evidence that a candidate Registered Performance Metric has significant industry interest, or has seen deployment, andSection 5 of [RFC6703] for background on this analysis choice.there is agreement that the candidate Registered Performance Metric serves its intended purpose." Thepercentile = 95, meaningprocess in [I-D.ietf-ippm-metric-registry] also requires that new entries are administered by IANA through Expert Review, which will ensure that thereported delay, "Percentile95", ismetrics are tightly defined. 2. Scope This document defines thesmallest value of Round-trip delayinitial set of Performance Metrics Registry entries, for which IETF approval (following development in theEmpirical Distribution Function (EDF), F(Percentile95) >= 95% ofIP Performance Metrics (IPPM) Working Group) will satisfy thesingleton Round-trip delay valuesrequirement for Expert Review. Note that all are Active Performance Metrics, which are based on RFCs prepared in theconditional distribution. See section 11.3IPPM working group of the IETF, according to their framework [RFC2330]forand its updates. 3. Registry Categories and Columns This section provides thedefinitioncategories and columns of thepercentile statistic using the EDF. 4.4.2. Data Format <describe the data formatregistry, foreach type of result> For all outputs --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the start ofeasy reference. An entry (row) therefore gives ameasurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Raw -- REMOVED IN VERSION 01 For Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile: Percentile95 The time value of the result is expressed in unitscomplete description ofseconds, asapositive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns),Registered Metric. Registry Categories andwith lossless conversion to/from the 64-bit NTP timestampColumns, shown asper section 6Category ------------------ Column | Column | Summary ------------------------------------------------------------------------ Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | Metric Definition ----------------------------------------- Reference Definition | Fixed Parameters | Method ofRFC [RFC5905] 4.4.3.Measurement --------------------------------------------------------------------- Reference<pointer to section/spec where output type/format is defined> See the Data Format column for references. 4.4.4. Metric| Packet | Traffic | Sampling | Run-time | Role | Method | Stream | Filter | Distribution | Parameters | | | Generation | Output ----------------------------------------- Type | Reference | Units<insert units for the measured results, and the reference specification>. The 95th Percentile of Round-trip Delay is expressed in seconds. 4.5.| Calibration | | Definition | | | Administrativeitems 4.5.1.Information ---------------------------------- Status<current or deprecated> 4.5.2. Requestor (keep?) name or RFC, etc. 4.5.3. Revision 1.0 4.5.4. Revision Date YYYY-MM-DD 4.6.|Request | Rev | Rev.Date | Comments and RemarksAdditional (Informational) details for this entry 5. Packet Delay Variation-------------------- 4. UDP Round-trip Latency Registry Entry This section gives an initial registry entry fora Packet Delay Variation metric.the UDP Round-trip Latency. Note:If eachEach Registry entryshouldonlyproduceproduces a "raw" output or a statisticalsummary, thensummary. To describe both "raw" and one or more statistics efficiently, the"Output" CategoryIdentifier, Name, and Output Categories can be split and this section can become two or more closely-related metrics.5.1.See Section 7 for an example specifying multiple Registry entries with many common columns. 4.1. Summary This category includes multiple indexes to the registryentries,entry: the element ID and metric name.<skipping some Summary columns for now> 5.1.1.4.1.1. ID (Identifier) <insert a numeric identifier, aninteger> 5.1.2.integer, TBD> 4.1.2. Name <insert name according to metric naming convention>Act_IP-UDP-One-way-pdv-95th-percentile-Poisson OwPDV_Active_UDP_Poisson_RFCXXXXsecY_Seconds_95%tile 5.1.3.RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 4.1.3. URIsURI:URN: Prefix urn:ietf:params:performance:metric:<name> URL: http://<TBD by IANA>/<name>5.1.4.4.1.4. DescriptionAn assessment of packet delay variation with respect toThis metric assesses theminimumdelayobserved onof a stream of packets exchanged between two hosts (which are thestream,two measurement points), and the Output is the Round-trip delay for all successfully exchanged packets expressed as the 95th percentile ofthe packettheir conditional delayvariationdistribution.5.2.4.1.5. Change Controller IETF 4.1.6. Version (of Registry Format) 1.0 4.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.5.2.1.4.2.1. Reference Definition <Full bibliographic reference to an immutable doc.>Paxson, V.,Almes, G.,Mahdavi, J.,Kalidindi, S., and M.Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2330] Demichelis, C. and P. Chimento, "IP PacketZekauskas, "A Round-trip DelayVariationMetric forIP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3393] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [RFC5481] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification",IPPM", RFC5905, June 2010.[RFC5905]2681, September 1999. [RFC2681] <specific section reference and additional clarifications, if needed>See sectionsSection 2.4and 3.4of[RFC3393]. Singleton[RFC2681] provides the reference definition of the singleton (single value) Round-trip delaydifferences measured are referred to bymetric. Section 3.4 of [RFC2681] provides thevariable name "ddT" (applicablereference definition expanded toall formscover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 ofdelay variation). However,[RFC2330]. Note that although the definition of "Round-trip-Delay between Src and Dst" is directionally ambiguous in the text, this metricentry specifiestightens thePDV form defineddefinition further to recognize that the host insection 4.2 of [RFC5481], wherethesingleton PDV for"Src" role will send the first packetito "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). Finally, note that the variable "dT" isreferredused in [RFC2681] to refer tobythe value of Round-trip delay in metric definitions and methods. The variablename "PDV(i)". 5.2.2."dT" has been re-used in other IPPM literature to refer to different quantities, and cannot be used as a global variable name. 4.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in the measurement system for use when needed> Type-P as defined in Section 13 of [RFC2330]: o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum: the checksum MUST be calculated o UDP Payload * total of2009 bytes Other measurement parameters: o Tmax: a loss threshold waiting timewith value* 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].F a selection function unambiguously defining the packets from the stream selected for the metric. See section 4.2 of [RFC5481] for the PDV form. 5.3.4.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 methods for implementations.5.3.1.4.3.1. Reference Method <for metric, insert relevant section references and supplemental info>SeeThe methodology for this metric is defined as Type-P-Round-trip- Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under Fixed Parameters. 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 packet lost. Lost packets SHALL be designated as having undefined delay. 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 which calculates the RTT value MAY 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 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 packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to dis-ambiguate packet reordering if it occurs. If a standard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and3.6time-stamps, if they are conveyed in the packet payload. Refer to Section 4.4 of[RFC3393][RFC6673] forgeneral singleton element calculations. This metric entry requires implementationexpanded discussion of thePDV form definedinstruction to "send a Type-P packet back to the Src as quickly as possible" insection 4.2Section 2.6 of[RFC5481]. Also see measurement considerations in sectionRFC 2681 [RFC2681]. Section 8 of[RFC5481]. The reference[RFC6673] presents additional requirements which MUST be included in the methoddistinguishes between long-delayed packets and lost packets by implementing a maximum waiting timeof measurement for this metric. 4.3.2. Packet Stream Generation This section gives the details of the packetarrival. Tmaxtraffic which is thewaiting time used asbasis for measurement. In IPPM metrics, this is called thethresholdStream, and can easily be described by providing the list of stream parameters. <section/specification references, and description of any new generation parameters, if needed> Section 11.1.3 of [RFC2330] provides three methods todeclare agenerate Poisson sampling intervals. the reciprocal of lambda is the average packetlost. Lost packets SHALL be designated as having undefined delay. The calculations onspacing, thus theone-way delayRun-time Parameter is Reciprocal_lambda = 1/ lambda, in seconds. >>> Check with Sam, most likely it is this... Method 3 SHALL beperformed onused, where given a start time (Run-time Parameter), theconditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delayssubsequent send times arestored, the process which calculates the one-way delay value MAY enforceall computed prior to measurement by computing theTmax threshold on stored values before calculations. See section 4.1pseudo-random distribution of[RFC3393] for details oninter- packet send times, (truncating theconditionaldistributionto exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packetsas specified ina stream to establish correspondence between sending timesthe Run-time Parameter, Trunc), andreceiving times for each successfully-arriving packet. Sequence numbers or other send-order identification MUST be retained atthe Srcor included withsends each packetto dis-ambiguate packet reordering if it occurs. If a standard measurement protocolat the computed times. Note that Trunc isemployed, thenthemeasurement process will determineupper limit on inter-packet times in thesequence numbers or timestamps appliedPoisson distribution. A random value greater than Trunc is set equal totestTrunc instead. 4.3.3. Traffic Filtering (observation) Details The measured results based on a filtered version of the packetsafterobserved, and this section provides theFixedfilter details (when present). <section reference>. NA 4.3.4. Sampling Distribution <insert time distribution details, or how this is diff from the filter> NA 4.3.5. Run-time Parameters andRuntime parametersData Format Run-time Parameters arepassed toinput factors thatprocess. The chosenmust be determined, configured into the measurementprotocol will dictatesystem, and reported with theformatresults for the context to be complete. <list of run-time parameters, and their data formats> 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 ofsequence numbers and time-stamps, if they are conveyedthe host in thepacket payload. 5.3.2. Packet Stream Generation <listDst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 ofgeneration parameters and section/spec references if needed>[RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section11.1.35.6 of[RFC2330] provides three methods to generate Poisson sampling intervals. the reciprocal[RFC3339], see also Section 3 oflambda is the average packet spacing, thus the Run-time Parameter[RFC6991]). The UTC Time Zone isReciprocal_lambda = 1/ lambda, in seconds. >>> Check with Sam, most likely itrequired by Section 6.1 of [RFC2330]. When T0 isthis... Method 3 SHALL be used, where given"all-zeros", a start time(Run-time Parameter), the subsequent send times are all computed prioris unspecified and Tf is tomeasurement by computingbe interpreted as thepseudo-random distributionDuration ofinter- packet send times, (truncatingthedistributionmeasurement interval. The start time is controlled through other means. Tf a time, the end of a measurement interval, (format "date-and-time" as specified inthe Run-time Parameter, Trunc),Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored andthe Src sends each packet at the computed times. Note that TruncTf is interpreted as theupper limit on inter-packet times inDuration of the measurement interval. Reciprocal_lambda average packet interval for Poissondistribution. A random value greater than Trunc is set equal to Trunc instead. o lambda, a rate in reciprocal seconds (for Poisson Streams). lambdaStreams expressed in units of seconds, as a positive value of type decimal64 with fraction digits =1 packet5 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as persecond osection 6 of [RFC5905]. Trunc Upper limit on Poisson distribution expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) with 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).Upper limit(if fixed, Trunc =30 seconds. 5.3.3. Traffic Filtering (observation) Details <insert the measured results based on30.0000 seconds.) >>> should Poisson run-time params be fixed instead? probably yes if modeling afilteredspecific version of MBA tests. 4.3.6. Roles <lists thepackets observed, and this section providesnames of thefilter details (when present),different roles from the measurement method> Src launches each packet andsection reference>. NA 5.3.4. Sampling Distributionwaits for return transmissions from Dst. Dst waits for each packet from Src and sends a return packet to Src. 4.4. Output This category specifies all details of the Output of measurements using the metric. 4.4.1. Type <inserttime distribution details,name of the output type, raw orhow this is diff froma selected summary statistic> Percentile -- for the conditional distribution of all packets with a valid value of Round-trip delay (undefined delays are excluded), a single value corresponding to the 95th percentile, as follows: See section 4.1 of [RFC3393] for details on thefilter> NA 5.3.5. Run-time Parameters and Data Format <listconditional distribution to exclude undefined values ofrun-time parameters,delay, andtheir data formats> Src the IP addressSection 5 of [RFC6703] for background on this analysis choice. The percentile = 95, meaning that thehost inreported delay, "95Percentile", is theSrc Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zonesmallest valuefor IPv6, see Section 4of[RFC6991]) DstRound-trip delay for which theIP addressEmpirical Distribution Function (EDF), F(95Percentile) >= 95% of thehostsingleton Round-trip delay values in theDst Role (format ipv4-address- no-zone valueconditional distribution. See section 11.3 of [RFC2330] forIPv4, or ipv6-address-no-zone valuethe definition of the percentile statistic using the EDF. 4.4.2. Reference Definition <describe the reference data format forIPv6, see section 4each type of[RFC6991])result> For all outputs --- T0a time,the start of a measurement interval, (format"date-and- time""date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of[RFC2330]. When T0 is "all-zeros",[RFC2330]. Raw -- REMOVED IN VERSION 01 For Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile: 95Percentile The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 4.4.3. Metric Units <insert units for the measured results, and the reference specification>. The 95th Percentile of Round-trip Delay is expressed in seconds. 4.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of astarttimeis unspecified and Tf is tomeasurement. In-situ calibration could beinterpretedenabled with an internal loopback that includes as much of theDurationmeasurement system as possible, performs address 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 this way. When a measurementinterval. The start time is controlled through other means. Tfcontroller requests atime,calibration measurement, theend ofloopback is applied and the result is output in the same format as a normal measurementinterval, (format "date-and-time" as specified in Section 5.6with additional indication that it is a calibration result. Both internal loopback calibration and clock synchronization can be used to estimate the *available accuracy* of[RFC3339], see also Section 3the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of[RFC6991]). The UTC Time Zonethe Output result resolution which isrequired by Section 6.1the result of[RFC2330]. When T0 is "all-zeros",system noise, and thus inaccurate. 4.5. Administrative items 4.5.1. Status <current or deprecated> 4.5.2. Requestor (keep?) name or RFC, etc. 4.5.3. Revision 1.0 4.5.4. Revision Date YYYY-MM-DD 4.6. Comments and Remarks Additional (Informational) details for this entry 5. Packet Delay Variation Registry Entry This section gives an initial registry entry for aend time date is ignoredPacket Delay Variation metric. Note: If each Registry entry should only produce a "raw" output or a statistical summary, then the "Output" Category can be split andTf is interpreted asthis section can become two closely-related metrics. 5.1. Summary This category includes multiple indexes to theDurationregistry entries, the element ID and metric name. <skipping some Summary columns for now> 5.1.1. ID (Identifier) <insert numeric identifier, an integer> 5.1.2. Name <insert name according to metric naming convention> OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 5.1.3. URIs URI: Prefix urn:ietf:metric:<name> URL: http://<TBD by IANA>/<name> 5.1.4. Description An assessment ofthe measurement interval. Reciprocal_lambda averagepacketinterval for Poisson Streams expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), anddelay variation withlossless conversion to/fromrespect to the32-bit NTP timestamp as per section 6 of [RFC5905]. Trunc Upper limitminimum delay observed onPoisson distribution expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/fromthe32-bit NTP timestamp as per section 6 of [RFC5905] (values above this limit will be clippedstream, andset tothelimit value). (if fixed, Trunc = 30.0000 seconds.) >>> should Poisson run-time params be fixed instead? probably yes if modeling a specific version of MBA tests. 5.3.6. Roles <listsOutput is expressed as thenames95th percentile of thedifferent roles from the measurement method> Src launches each packet to Dst. Dst waits for eachpacketfrom Src. 5.4. Outputdelay variation distribution. 5.1.5. Change Controller <org or person > 5.1.6. Version (of Registry Format) 1.0 5.2. Metric Definition This categoryspecifiesincludes columns to prompt the entry of all necessary detailsofrelated to theOutput of measurements usingmetric definition, including themetric. 5.4.1. Type <insert nameRFC reference and values ofthe output type, raw or a selected summary statistic> Percentile --input factors, called fixed parameters. 5.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework forthe conditional distribution of all packets with a valid valueIP Performance Metrics", RFC 2330, May 1998. [RFC2330] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3393] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [RFC5481] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.[RFC5905] <specific section reference and additional clarifications, if needed> See sections 2.4 and 3.4 ofone-way[RFC3393]. Singleton delay(undefined delaysdifferences measured areexcluded), a single value correspondingreferred to by the95th percentile, as follows: See section 4.1 of [RFC3393] for details on the conditional distributionvariable name "ddT" (applicable toexclude undefined values of delay, and Section 5all forms of[RFC6703] for background ondelay variation). However, thisanalysis choice. The percentile = 95, meaning that the reported delay, "Percentile95", ismetric entry specifies thesmallest value of one-wayPDVfor which the Empirical Distribution Function (EDF), F(Percentile95) >= 95%form defined in section 4.2 of [RFC5481], where the singletonone-wayPDVvalues in the conditional distribution. See section 11.3 of [RFC2330]for packet i is referred to by thedefinition of the percentile statistic using the EDF. 5.4.2. Data Format <describevariable name "PDV(i)". 5.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in thedata formatmeasurement system foreach type of result> T0use when needed> o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum: thestartchecksum MUST be calculated o UDP Payload * total ofa200 bytes Other measurementinterval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the start ofparameters: Tmax: ameasurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Percentile95 Theloss threshold waiting time with valueof the result is3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits =95 (see section 9.3 of [RFC6020]) and with resolution of0.0000000010.0001 seconds(1.0 ns), and(0.1 ms), with lossless conversion to/from the64-bit32-bit NTP timestamp as per section 6 ofRFC [RFC5905] 5.4.3. Reference <pointer to section/spec where output type/format is defined> See[RFC5905]. F a selection function unambiguously defining theData Format columnpackets from the stream selected forreferences. 5.4.4. Metric Units <insert unitsthe metric. See section 4.2 of [RFC5481] for themeasured results, andPDV form. 5.3. Method of Measurement This category includes columns for references to relevant sections of thereference specification>. The 95th PercentileRFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 5.3.1. Reference Method <for metric, insert relevant section references and supplemental info> See section 2.6 and 3.6 ofone-way[RFC3393] for general singleton element calculations. This metric entry requires implementation of the PDVis expressedform defined inseconds. 5.5. Administrative items 5.5.1. Status <current or depricated> 5.5.2. Requestor (keep?) <namesection 4.2 of [RFC5481]. Also see measurement considerations in section 8 ofindividual or RFC, etc.> 5.5.3. Revision 1.0 5.5.4. Revision Date YYYY-MM-DD 5.6. Comments[RFC5481]. The reference method distinguishes between long-delayed packets andRemarks <Additional (Informational) details for this entry> Lostlost packetsrepresentby implementing achallengemaximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay. The calculations on the one-way delayvariation metrics.SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the one-way delay value MAY enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393]and the delay variation applicability statement[RFC5481]forextensive analysisdetails on the conditional distribution to exclude undefined values of delay, andcomparisonSection 5 ofPDV[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 andan alternate metric, IPDV. 6. DNS Response Latency Registry Entry This section gives an initial registry entryreceiving times forDNS Response Latency. RFC 2681 [RFC2681] defineseach successfully-arriving packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to dis-ambiguate packet reordering if it occurs. If aRound-trip delay metric. We build on that metric by specifying severalstandard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and time-stamps, if they are conveyed in theinputpacket payload. 5.3.2. Packet Stream Generation <list of generation parameters and section/spec references if needed> Section 11.1.3 of [RFC2330] provides three methods toprecisely definegenerate Poisson sampling intervals. the reciprocal of lambda is the average packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ lambda, in seconds. >>> Check with Sam, most likely it is this... Method 3 SHALL be used, where given ametric for measuring DNS latency. 6.1. Summary This category includes multiple indexesstart time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computing theregistry entries,pseudo-random distribution of inter- packet send times, (truncating theelement IDdistribution as specified in the Run-time Parameter, Trunc), andmetric name. <skipping some admin columns for now> 6.1.1. ID (Identifier) <insert numeric identifier, an integer> 6.1.2. Name <insert name according to metric naming convention> RTDNS_Active_UDP_DNS_Poisson_RFCXXXXsecY_Seconds_95%tile 6.1.3. URI URI: Prefix urn:ietf:params:performance:metric URL: 6.1.4. Description This metric assessestheresponse time,Src sends each packet at theinterval fromcomputed times. Note that Trunc is thequery transmission toupper limit on inter-packet times in theresponse. 6.2. Metric Definition This category includes columnsPoisson distribution. A random value greater than Trunc is set equal topromptTrunc instead. o lambda, a rate in reciprocal seconds (for Poisson Streams). lambda = 1 packet per second o Upper limit on Poisson distribution (values above this limit will be clipped and set to the limit value). Upper limit = 30 seconds. 5.3.3. Traffic Filtering (observation) Details <insert theentrymeasured results based on a filtered version ofall necessary details related to the metric definition, includingtheRFC reference and values of input factors, called fixed parameters. 6.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Mockapetris, P., "Domain names - implementationpackets observed, andspecification", STD 13, RFC 1035, November 1987. (and updates) [RFC1035] Almes, G., Kalidindi, S.,this section provides the filter details (when present), andM. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] <specificsectionreferencereference>. NA 5.3.4. Sampling Distribution <insert time distribution details, or how this is diff from the filter> NA 5.3.5. Run-time Parameters andadditional clarifications, if needed> Section 2.4Data Format <list of[RFC2681] providesrun-time parameters, and their data formats> Src thereference definitionIP address of thesingleton (single value) Round-trip delay metric.host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section3.44 of[RFC2681] provides[RFC6991]) Dst thereference definition expanded to cover a multi-value sample. Note that terms such as singleton and sample are defined in Section 11IP address of[RFC2330]. For DNS Response Latency,theentitieshost in[RFC1035] must be mapped to [RFC2681]. The Local Host with its User Program and Resolver taketheroleDst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of"Src", and the Foreign Name Server takes[RFC6991]) T0 a time, therolestart of"Dst". Note that although the definitiona measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of"Round-trip-Delay between Src[RFC2330]. When T0 is "all-zeros", a start time is unspecified andDst at T"Tf isdirectionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the "Src" role will send the first packetto"Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). 6.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that mustbedetermined and embedded ininterpreted as themeasurement system for use when needed> Type-P: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Source port: 53 * Destination port: 53 * Checksum:Duration of thechecksum must be calculated o Payload:measurement interval. Thepayload containsstart time is controlled through other means. Tf aDNS messagetime, the end of a measurement interval, (format "date-and-time" asdefinedspecified inRFC 1035 [RFC1035] with the following values: * The DNS header section contains: + QR: set to 0 (Query) + OPCODE: set to 0 (standard query) + AA: not set + TC: not set + RD: set to one (recursion desired) + RA: not set + RCODE: not set + QDCOUNT: set to one (only one entry) + ANCOUNT: not set + NSCOUNT: not set + ARCOUNT: not set *Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). TheQuestion section contains: + QNAME: the FQDN providedUTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted asinput forthetest + QTYPE:Duration of thequery type provided as inputmeasurement interval. Reciprocal_lambda average packet interval forthe test + QCLASS: set to IN * The other sections do not contain any Resource Records. Observation: reply packets will containPoisson Streams expressed in units of seconds, as aDNS response and may contain RRs. Timeout: Tmaxpositive value of type decimal64 with fraction digits = 5seconds (to help disambiguate queries) 6.3. Method(see section 9.3 ofMeasurement This category includes columns for references to relevant sections[RFC6020]) with resolution ofthe RFC(s)0.0001 seconds (0.1 ms), andany supplemental information needed to ensure an unambiguous methods for implementations. 6.3.1. Reference Method <for metric, insert relevantwith lossless conversion to/from the 32-bit NTP timestamp as per sectionreferences6 of [RFC5905]. Trunc Upper limit on Poisson distribution expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), andsupplemental info> The methodology for this metric is definedwith lossless conversion to/from the 32-bit NTP timestamp asType-P-Round-trip- Delay-Poisson-Stream inper section2.66 of [RFC5905] (values above this limit will be clipped and set to the limit value). (if fixed, Trunc = 30.0000 seconds.) >>> should Poisson run-time params be fixed instead? probably yes if modeling a specific version of MBA tests. 5.3.6. Roles <lists the names of the different roles from the measurement method> Src launches each packet to Dst. Dst waits for each packet from Src. 5.4. Output This category specifies all details ofRFC 2681 [RFC2681] and section 3.6the Output ofRFC 2681 [RFC2681]measurements using theType-P and Timeout defined under Fixed Parameters. The method requires sequence numbers or other send-order information to be retained atmetric. 5.4.1. Type <insert name of theSrcoutput type, raw orincludeda selected summary statistic> Percentile -- for the conditional distribution of all packets witheach packeta valid value of one-way delay (undefined delays are excluded), a single value corresponding todis- ambiguate packet reordering if it occurs. Sequence number is partthe 95th percentile, as follows: See section 4.1 of [RFC3393] for details on thepayload described under Fixed Parameters. DNS Messages bearing Queries provideconditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] forrandom ID Numbers, so more than one query may be launched while a previous request is outstanding whenbackground on this analysis choice. The percentile = 95, meaning that theID Numberreported delay, "95Percentile", isused. IF a DNS response does not arrive within Tmax,theresult is undefined. The Message ID SHALL be used to disambiguatesmallest value of one-way PDV for which thesuccessive queries. >>> This would require supportEmpirical Distribution Function (EDF), F(95Percentile) >= 95% ofID generation and populationthe singleton one-way PDV values in theMessage. An alternative would be to use a random Source port onconditional distribution. See section 11.3 of [RFC2330] for theQuery Message, but we would choose ONE before proceding. Refer to Section 4.4definition of[RFC6673]the percentile statistic using the EDF. 5.4.2. Reference Definition <the output type and data format forexpanded discussioneach type of result> T0 theinstruction to "sendstart of aType-P packet back to the Src as quicklymeasurement interval, (format "date-and-time" aspossible"specified in Section2.65.6 ofRFC 2681 [RFC2681].[RFC3339], see also Section83 of[RFC6673] presents additional requirements which shall be included in[RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf themethodend of a measurementfor this metric. 6.3.2. Packet Generation Stream This section gives the detailsinterval, (format "date-and-time" as specified in Section 5.6 ofthe packet traffic which is the basis for measurement. In IPPM metrics, this[RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone iscalled the Stream, and can easily be dscribedrequired byproviding the list of stream parameters. <list of generation parameters and section/spec references if needed>Section11.1.36.1 ofRFC 2681 [RFC2330] provides three methods to generate Poisson sampling intervals. the reciprocal[RFC2330]. 95Percentile The time value oflambda is the average packet rate, thustheRun-time Parameter is 1/lambda. >>> Check with Sam, most likely it is this... Method 3result isused, where givenexpressed in units of seconds, as astart time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computing the pseudo-random distributionpositive value ofinter-packet send times, (truncatingtype decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from thedistribution64-bit NTP timestamp asspecified inper section 6 of RFC [RFC5905] 5.4.3. Metric Units <insert units for theRun-time Parameters),measured results, and theSrc sends each packet at the computed times. 6.3.3. Traffic Filtering (observation) Detailsreference specification>. Themeasured results based on95th Percentile of one-way PDV is expressed in seconds. 5.4.4. Calibration Section 3.7.3 of [RFC7679] provides afiltered versionmeans to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback that includes as much of thepackets observed,measurement system as possible, performs address manipulation as needed, andthis sectionprovides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of thefilter details (when present). <section reference>. NA 6.3.4. Sampling Distribution <insert time distribution details, or howrandom and systematic error can be characterized thisis diff fromway. For one-way delay measurements, thefilter> NA 6.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors thaterror calibration mustbe determined, configured intoinclude an assessment of themeasurement system, and reportedinternal clock synchronization withthe resultsits external reference (this internal clock is supplying timestamps for measurement). In practice, thecontext to be complete. <listtime offsets ofrun-time parameters,clocks at both the source andtheir data formats> o Src,destination are needed to estimate theIP address of a host (32-bit value for IPv4, 128-bitsystematic error due to imperfect clock synchronization (the time offsets are smoothed, thus the random variation is not usually represented in the results). time_offset The time valuefor IPv6) o Dst,of theIP addressresult is expressed in units of seconds, as ahost (32-bit value for IPv4, 128-bitsigned valuefor IPv6) o T0, a time (startofmeasurement interval, 128-bit NTP Date Format, seetype decimal64 with fraction digits = 9 (see section6 of [RFC5905]). When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration9.3 ofthe measurement interval. o Tf, a time (end[RFC6020]) with resolution ofmeasurement interval, 128-bit0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTPDate Format, seetimestamp as per section 6 of[RFC5905]), interpreted as the Duration of theRFC [RFC5905] When a measurementinterval. o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 0.1 packet per second, if fixed) o Upper limit on Poisson distribution (values above this limit will be clipped and set tocontroller requests a calibration measurement, thelimit value). (if fixed, Upper limit = 300 seconds.) o ID,loopback is applied and the16-bit identifier assigned byresult is output in theprogramsame format as a normal measurement with additional indication thatgeneratesit is a calibration result. In any measurement, thequery, and which must vary in successive queries, see Section 4.1.1measurement function SHOULD report its current estimate of time offset as an indicator of[RFC1035]. This identifier is copied intothecorresponding replydegree of synchronization. Both internal loopback calibration and clock synchronization can be usedby the requester to match-up repliestooutstanding queries. The format for 1/lambda and Upper limit of Poisson Dist. areestimate theshort format in [RFC5905] (32 bits) and is as follows:*available accuracy* of thefirst 16 bits representOutput Metric Units. For example, repeated loopback delay measurements will reveal theinteger numberportion ofseconds;thenext 16 bits representOutput result resolution which is thefractional partresult of system noise, and thus inaccurate. 5.5. Administrative items 5.5.1. Status <current or depricated> 5.5.2. Requestor (keep?) <name of individual or RFC, etc.> 5.5.3. Revision 1.0 5.5.4. Revision Date YYYY-MM-DD 5.6. Comments and Remarks <Additional (Informational) details for this entry> Lost packets represent asecond. >>> should Poisson run-time params be fixed instead? probably yes if modelingchallenge for delay variation metrics. See section 4.1 of [RFC3393] and the delay variation applicability statement[RFC5481] for extensive analysis and comparison of PDV and an alternate metric, IPDV. 6. DNS Response Latency Registry Entry This section gives an initial registry entry for DNS Response Latency. RFC 2681 [RFC2681] defines aspecific versionRound-trip delay metric. We build on that metric by specifying several ofMBA tests. 6.3.6. Roles <liststhenames ofinput parameters to precisely define a metric for measuring DNS latency. 6.1. Summary This category includes multiple indexes to thedifferent roles fromregistry entries, themeasurement method> Src - launches each packetelement ID andwaits for return transmissions from Dst. Dst - waitsmetric name. <skipping some admin columns foreach packetnow> 6.1.1. ID (Identifier) <insert numeric identifier, an integer> 6.1.2. Name <insert name according to metric naming convention> RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 6.1.3. URI URI: Prefix urn:ietf:metric:<name> URL: http://<TBD by IANA>/<name> 6.1.4. Description This metric assesses the response time, the interval fromSrc and sends a return packetthe query transmission toSrc. 6.4. Outputthe response. 6.1.5. Change Controller IETF 6.1.6. Version (of Registry Format) 1.0 6.2. Metric Definition This categoryspecifies all details ofincludes columns to prompt theOutputentry ofmeasurements usingall necessary details related to themetric. 6.4.1. Type/Value (two diff terms used) <insert name ofmetric definition, including theoutput type, raw or a selected summary statistic> For all output types: o T0, a time (start of measurement interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) o Tf, a time (endRFC reference and values ofmeasurement interval, 128-bit NTP Date Format, seeinput factors, called fixed parameters. 6.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. (and updates) [RFC1035] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] <specific section6reference and additional clarifications, if needed> Section 2.4 of[RFC5905]) Raw -- for each packet sent, pairs[RFC2681] provides the reference definition ofvalues. >>> andthestatussingleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides theresponse, only assigning valuesreference definition expanded tosuccessful query-response pairs. Percentile -- for the conditional distribution of all packets withcover avalid value of Round-trip delay (undefined delaysmulti-value sample. Note that terms such as singleton and sample areexcluded), a single value corresponding todefined in Section 11 of [RFC2330]. For DNS Response Latency, the95th percentile. 6.4.2. Data Format <describeentities in [RFC1035] must be mapped to [RFC2681]. The Local Host with its User Program and Resolver take thedata format for each type of result> Raw -- for each packet sent, pairsrole ofvalues as follows: o T,"Src", and thetime whenForeign Name Server takes thepacket was sent from Src, 128-bit NTP Date Format, see section 6role of[RFC5905]) o dT, a value"Dst". Note that although the definition ofRound-trip delay, format"Round-trip-Delay between Src and Dst at T" is*similar to*directionally ambiguous in the32-bit short NTP Time formattext, this metric tightens the definition further to recognize that the host inSection 6 of [RFC5905]the "Src" role will send the first packet to "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). 6.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined andis as follows: the first 16 bits represent the *signed* integer number of seconds;embedded in thenext 16 bits representmeasurement system for use when needed> Type-P: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Source port: 53 * Destination port: 53 * Checksum: thefractional part of a second.checksum must be calculated odT is undefined whenPayload: The payload contains a DNS message as defined in RFC 1035 [RFC1035] with thepacket isfollowing values: * The DNS header section contains: + QR: set to 0 (Query) + OPCODE: set to 0 (standard query) + AA: notreceived at Src in waiting time Tmxax seconds (need undefined code for no-response or un- successful response) Percentile --set + TC: not set + RD: set to one (recursion desired) + RA: not set + RCODE: not set + QDCOUNT: set to one (only one entry) + ANCOUNT: not set + NSCOUNT: not set + ARCOUNT: not set * The Question section contains: + QNAME: the FQDN provided as input for theconditional distribution of all packets with a valid value of Round-trip delay (undefined delays are excluded), a single valuetest + QTYPE: the query type provided asfollows: See section 4.1 of [RFC3393]input fordetails ontheconditional distributiontest + QCLASS: set toexclude undefined values of delay,IN * The other sections do not contain any Resource Records. Observation: reply packets will contain a DNS response andSectionmay contain RRs. Timeout: Tmax = 5 seconds (to help disambiguate queries) 6.3. Method of[RFC6703]Measurement This category includes columns forbackground on this analysis choice. See section 4.3references to relevant sections of[RFC3393] for details onthepercentile statistic (where Round-trip delay should be substitutedRFC(s) and any supplemental information needed to ensure an unambiguous methods for"ipdv").implementations. 6.3.1. Reference Method <for metric, insert relevant section references and supplemental info> Thepercentile = 95. Data formatmethodology for this metric isa 32-bit signed floating point value, *similar to* the 32-bit short NTP Time formatdefined as Type-P-Round-trip- Delay-Poisson-Stream inSection 6section 2.6 of[RFC5905]RFC 2681 [RFC2681] andis as follows: the first 16 bits represent the *signed* integer number of seconds; the next 16 bits represent the fractional partsection 3.6 ofa second. 6.4.3. Reference <pointer to section/spec where output type/format is defined> See the Data Format column for references. 6.4.4. Metric Units <insert units forRFC 2681 [RFC2681] using themeasured results,Type-P andthe reference specification>. Round-trip Delay, dT, is expressed in seconds.Timeout defined under Fixed Parameters. The95th Percentile of Round-trip Delay is expressed in seconds. 6.5. Administrative items 6.5.1. Status <current or depricated> 6.5.2. Requestor (keep?) namemethod requires sequence numbers orRFC, etc. 6.5.3. Revision 1.0 6.5.4. Revision Date YYYY-MM-DD 6.6. Comments and Remarks Additional (Informational) details for this entry 7. UDP Poisson One-way Delay Registry Entries This section gives an initial registry entry for the UDP Poisson One- way Delay. Note: Each Registry "Name" below specifies a single registry entry, whose output format varies accordingother send-order information to be retained at the Src or included with each packet toa componentdis- ambiguate packet reordering if it occurs. Sequence number is part of thename that specifiespayload described under Fixed Parameters. DNS Messages bearing Queries provide for random ID Numbers, so more than oneform of statistical summary. IANA is asked to assignquery may be launched while adifferent numeric identifiers to each Name. All column entries beside the Summary and Output categories areprevious request is outstanding when thesame, thus this section proposes five closely-related registry entries. AsID Number is used. IF aresult, IANADNS response does not arrive within Tmax, the result isalso askedundefined. The Message ID SHALL be used toassign corresponding URIs and URLs. 7.1. Summarydisambiguate the successive queries. >>> Thiscategory includes multiple indexeswould require support of ID generation and population in the Message. An alternative would be to use a random Source port on theregistry entries,Query Message, but we would choose ONE before proceding. Refer to Section 4.4 of [RFC6673] for expanded discussion of theelement ID and metric name. 7.1.1. ID (Identifier) <insert numeric identifier, an integer, one correspondinginstruction toeach name below> 7.1.2. Name <insert name according"send a Type-P packet back tometric naming convention> Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_<statistic> OwDelay_Active_IP_UDP_Poisson_UDP_Payload_250_RFCXXXXsecY_Seconds_<st atistic> Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Percentile95 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Mean Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Min Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Max Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Std_Dev 7.1.3. URI and URL URI: Prefix urn:ietf:params:performance:metric...<name> URL: http:\\www.iana.org\ ... <name> 7.1.4. Description This metric assessesthedelaySrc as quickly as possible" in Section 2.6 ofa streamRFC 2681 [RFC2681]. Section 8 ofpackets exchanged between two hosts (or measurement points), and reports the <statistic> One-way delay[RFC6673] presents additional requirements which shall be included in the method of measurement forall successfully exchanged packets based on their conditional delay distribution. 7.2. Metric Definitionthis metric. 6.3.2. Packet Generation Stream Thiscategory includes columns to promptsection gives theentry of all necessarydetailsrelated toof themetric definition, includingpacket traffic which is theRFC referencebasis for measurement. In IPPM metrics, this is called the Stream, andvaluescan easily be dscribed by providing the list ofinput factors, called fixedstream parameters.7.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2679] Morton, A., and Stephan, E., "Spatial Composition<list ofMetrics", RFC 6049, January 2011. [RFC6049] <specific section referencegeneration parameters andadditional clarifications,section/spec references if needed> Section3.411.1.3 of[RFC2679]RFC 2681 [RFC2330] provides three methods to generate Poisson sampling intervals. thereference definitionreciprocal of lambda is thesingleton (single value) One-way delay metric. Section 4.4 of [RFC2679] providesaverage packet rate, thus thereference definition expanded to coverRun-time Parameter is 1/lambda. >>> Check with Sam, most likely it is this... Method 3 is used, where given amulti-value sample. Note that terms such as singleton and samplestart time (Run-time Parameter), the subsequent send times aredefined in Section 11all computed prior to measurement by computing the pseudo-random distribution of[RFC2330]. Only successful packet transfers with finite delay are includedinter-packet send times, (truncating the distribution as specified in thesample, as prescribed inRun-time Parameters), and the Src sends each packet at the computed times. 6.3.3. Traffic Filtering (observation) Details The measured results based on a filtered version of the packets observed, and this section4.1.2 of [RFC6049]. NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- ietf-ippm-2679-bis-01. 7.2.2. Fixedprovides the filter details (when present). <section reference>. NA 6.3.4. Sampling Distribution <insert time distribution details, or how this is diff from the filter> NA 6.3.5. Run-time Parameters<listandspecify Fixed Parameters,Data Format Run-time Parameters are input factors that must bedetermined and embedded indetermined, configured into the measurementsystemsystem, and reported with the results foruse when needed> Type-P: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum:thechecksum mustcontext to becalculated o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2complete. <list of[RFC5357] * Security features in use influencerun-time parameters, and their data formats> o Src, thenumberIP address ofPadding octets. * 250 octets total, includinga host (32-bit value for IPv4, 128-bit value for IPv6) o Dst, theTWAMP format Timeout, Tmax: 3 seconds 7.3. MethodIP address ofMeasurement This category includes columnsa host (32-bit value forreferences to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methodsIPv4, 128-bit value forimplementations. 7.3.1. Reference Method <for metric, insert relevantIPv6) o T0, a time (start of measurement interval, 128-bit NTP Date Format, see sectionreferences6 of [RFC5905]). When T0 is "all-zeros", a start time is unspecified andsupplemental info> The methodology for this metricTf isdefinedto be interpreted asType-P-One-way-Delay- Poisson-Stream in section 3.6the Duration of the measurement interval. o Tf, a time (end of[RFC2679] andmeasurement interval, 128-bit NTP Date Format, see section4.66 of[RFC2679] using[RFC5905]), interpreted as theType-P and Timeout defined under Fixed Parameters. The method requires sequence numbers or other send-order information to be retained atDuration of theSrc or included with eachmeasurement interval. o 1/lambda, average packetto dis- ambiguaterate (for Poisson Streams). (1/lambda = 0.1 packetreorderingper second, ifit occurs. Sequence number is part offixed) o Upper limit on Poisson distribution (values above this limit will be clipped and set to theTWAMP payload described under Fixed Parameters. 7.3.2. Packet Generation Stream This section giveslimit value). (if fixed, Upper limit = 300 seconds.) o ID, thedetails of16-bit identifier assigned by thepacket traffic which isprogram that generates thebasis for measurement. In IPPM metrics, thisquery, and which must vary in successive queries, see Section 4.1.1 of [RFC1035]. This identifier iscalledcopied into theStream,corresponding reply and caneasilybedscribedused byprovidingthelist of stream parameters. <list of generation parameters and section/spec references if needed> Section 11.1.3 of RFC 2681 [RFC2330] provides three methodsrequester togenerate Poisson sampling intervals.match-up replies to outstanding queries. Thereciprocalformat for 1/lambda and Upper limit oflambdaPoisson Dist. are the short format in [RFC5905] (32 bits) and is as follows: theaverage packet rate, thusfirst 16 bits represent theRun-time Parameter is 1/lambda. Method 3 or equivalent SHALL used, where giveninteger number of seconds; the next 16 bits represent the fractional part of a second. >>> should Poisson run-time params be fixed instead? probably yes if modeling astart time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computingspecific version of MBA tests. 6.3.6. Roles <lists thepseudo-random distributionnames ofinter- packet send times, (truncatingthedistribution as specified indifferent roles from theRun-time Parameters),measurement method> Src - launches each packet andthewaits for return transmissions from Dst. Dst - waits for each packet from Src and sendseacha return packetatto Src. 6.4. Output This category specifies all details of thecomputed times. 7.3.3. Traffic Filtering (observation) Details NA 7.3.4. Sampling Distribution NA 7.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured intoOutput of measurements using the metric. 6.4.1. Type/Value (two diff terms used) <insert name of the output type, raw or a selected summary statistic> For all output types: o T0, a time (start of measurementsystem,interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) o Tf, a time (end of measurement interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) Raw -- for each packet sent, pairs of values. >>> andreported withtheresults forstatus of thecontextresponse, only assigning values tobe complete. <list of run-time parameters, and their data formats> o Src,successful query-response pairs. Percentile -- for theIP addressconditional distribution of all packets with ahost (32-bit value for IPv4, 128-bitvalid valuefor IPv6) o Dst, the IP addressof Round-trip delay (undefined delays are excluded), ahost (32-bitsingle value corresponding to the 95th percentile. 6.4.2. Reference Definition <describe the data format forIPv4, 128-bit valueeach type of result> Raw -- forIPv6)each packet sent, pairs of values as follows: oT0, aT, the time(start of measurement interval,when the packet was sent from Src, 128-bit NTP Date Format, see section 6 of[RFC5905]). When T0 is "all-zeros",[RFC5905]) o dT, astart timevalue of Round-trip delay, format isunspecified*similar to* the 32-bit short NTP Time format in Section 6 of [RFC5905] andTfisto be interpretedas follows: theDurationfirst 16 bits represent the *signed* integer number of seconds; themeasurement interval. o Tf,next 16 bits represent the fractional part of a second. o dT is undefined when the packet is not received at Src in waiting time(endTmxax seconds (need undefined code for no-response or un- successful response) Percentile -- for the conditional distribution ofmeasurement interval, 128-bit NTP Date Format, see section 6all packets with a valid value of[RFC5905]), interpretedRound-trip delay (undefined delays are excluded), a single value asthe Durationfollows: See section 4.1 ofthe measurement interval. o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1 packet per second, if fixed) o Upper limit[RFC3393] for details onPoissonthe conditional distribution(values above this limit will be clipped and setto exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3 of [RFC3393] for details on thelimit value). (if fixed, Upper limit = 30 seconds.)percentile statistic (where Round-trip delay should be substituted for "ipdv"). The percentile = 95. Data formatfor 1/lambda and Upper limit of Poisson Dist. areis a 32-bit signed floating point value, *similar to* the 32-bit short NTP Time format in Section 6 of [RFC5905](32 bits)and is as follows: the first 16 bits represent the *signed* integer number of seconds; the next 16 bits represent the fractional part of a second.>>> should Poisson run-time params be fixed instead? probably yes if modeling a specific version6.4.3. Metric Units <insert units for the measured results, and the reference specification>. Round-trip Delay, dT, is expressed in seconds. The 95th Percentile oftests. NoteRound-trip Delay is expressed in seconds. 6.4.4. Calibration <pointer to > 6.5. Administrative items 6.5.1. Status <current or depricated> 6.5.2. Requestor (keep?) name or RFC, etc. 6.5.3. Revision 1.0 6.5.4. Revision Date YYYY-MM-DD 6.6. Comments and Remarks Additional (Informational) details for this entry 7. UDP Poisson One-way Delay Registry Entries This section gives an initial registry entry for theNAME, i.e. Poisson3.3 7.3.6. Roles <lists the namesUDP Poisson One- way Delay. Note: Each Registry "Name" below specifies a single registry entry, whose output format varies according to a component of the name that specifies one form of statistical summary. IANA is asked to assign a differentroles from the measurement method> Src - launchesnumeric identifiers to eachpacketName. All column entries beside the Summary andwaits for return transmissions from Dst. ThisOutput categories are the same, thus this section proposes five closely-related registry entries. As a result, IANA is also asked to assign corresponding URIs and URLs. 7.1. Summary This category includes multiple indexes to theTWAMP Session-Sender. Dst - waits for each packet from Srcregistry entries, the element ID andsends a return packetmetric name. 7.1.1. ID (Identifier) <insert numeric identifier, an integer, one corresponding toSrc.each name below> 7.1.2. Name <insert name according to metric naming convention> OWDelay_Active_IP-UDP-Poisson- Payload250B_RFCXXXXsecY_Seconds_<statistic> OWDelay_Active_IP-UDP-Poisson- Payload250B_RFCXXXXsecY_Seconds_95Percentile OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev 7.1.3. URI and URL URI: Prefix urn:ietf:params:performance:metric...<name> URL: http:\\www.iana.org\ ... <name> 7.1.4. Description Thisismetric assesses theTWAMP Session-Reflector. 7.4. Outputdelay of a stream of packets exchanged between two hosts (or measurement points), and reports the <statistic> One-way delay for all successfully exchanged packets based on their conditional delay distribution. 7.2. Metric Definition This categoryspecifiesincludes columns to prompt the entry of all necessary detailsofrelated to theOutput of measurements usingmetric definition, including themetric. 7.4.1. Type/Value (two diff terms used) <insert nameRFC reference and values ofthe output type, raw or a selected summary statistic> See subsection titles below for Types. 7.4.2. Data Format <describe the data formatinput factors, called fixed parameters. 7.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- Way Delay Metric foreach type of result> For all output types --- o T0, a time (startIP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc- editor.org/info/rfc7679>. [RFC2679] Morton, A., and Stephan, E., "Spatial Composition ofmeasurement interval, 128-bit NTP Date Format, seeMetrics", RFC 6049, January 2011. [RFC6049] <specific section6reference and additional clarifications, if needed> Section 3.4 of[RFC5905]) o Tf, a time (end[RFC2679] provides the reference definition ofmeasurement interval, 128-bit NTP Date Format, see section 6the singleton (single value) One-way delay metric. Section 4.4 of[RFC5905]) 7.4.2.1. Percentile95 The 95th percentile SHALL be calculated using[RFC2679] provides theconditional distributionreference definition expanded to cover a multi-value sample. Note that terms such as singleton and sample are defined in Section 11 ofall packets[RFC2330]. Only successful packet transfers withafinitevalue of One-waydelay(undefined delaysareexcluded), a single valueincluded in the sample, asfollows: Seeprescribed in section4.14.1.2 of[RFC3393] for details[RFC6049]. NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- ietf-ippm-2679-bis-01. 7.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in theconditional distributionmeasurement system for use when needed> Type-P: o IPv4 header values: * DSCP: set toexclude undefined values of delay, and0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum: the checksum must be calculated o UDP Payload: TWAMP Test Packet Formats, Section54.1.2 of[RFC6703] for background on this analysis choice. See section 4.3[RFC5357] * Security features in use influence the number of[RFC3393]Padding octets. * 250 octets total, including the TWAMP format Timeout, Tmax: 3 seconds 7.3. Method of Measurement This category includes columns fordetails onreferences to relevant sections of thepercentile statistic (where Round-trip delay should be substitutedRFC(s) and any supplemental information needed to ensure an unambiguous methods for"ipdv").implementations. 7.3.1. Reference Method <for metric, insert relevant section references and supplemental info> Thepercentile = 95. Data formatmethodology for this metric isa 32-bit signed value, *similar to* the 32-bit short NTP Time formatdefined as Type-P-One-way-Delay- Poisson-Stream inSection 6section 3.6 of[RFC5905][RFC2679] andis as follows: the first 16 bits represent the *signed* integer numbersection 4.6 ofseconds; the next 16 bits represent[RFC2679] using thefractional part of a second. 7.4.2.2. MeanType-P and Timeout defined under Fixed Parameters. Themean SHALLmethod requires sequence numbers or other send-order information to becalculated usingretained at theconditional distribution of all packetsSrc or included witha finite valueeach packet to dis- ambiguate packet reordering if it occurs. Sequence number is part ofOne-way delay (undefined delays are excluded), a single value as follows: Seethe TWAMP payload described under Fixed Parameters. 7.3.2. Packet Generation Stream This section4.1gives the details of[RFC3393]the packet traffic which is the basis fordetails onmeasurement. In IPPM metrics, this is called theconditional distribution to exclude undefined values of delay,Stream, andSection 5can easily be dscribed by providing the list of[RFC6703] for background on this analysis choice. See section 4.2.2stream parameters. <list of[RFC6049] for details on calculating this statistic,generation parameters and4.2.3section/spec references if needed> Section 11.1.3 of[RFC6049]. Data formatRFC 2681 [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal of lambda is the average packet rate, thus the Run-time Parameter is 1/lambda. Method 3 or equivalent SHALL used, where given a32-bit signed value, *similar to*start time (Run-time Parameter), the32-bit short NTP Time format in Section 6subsequent send times are all computed prior to measurement by computing the pseudo-random distribution of[RFC5905] and isinter- packet send times, (truncating the distribution asfollows:specified in thefirst 16 bits representRun-time Parameters), and the*signed* integer number of seconds;Src sends each packet at the computed times. 7.3.3. Traffic Filtering (observation) Details NA 7.3.4. Sampling Distribution NA 7.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with thenext 16 bits representresults for thefractional part of a second. 7.4.2.3. Min The minimum SHALLcontext to becalculated usingcomplete. <list of run-time parameters, and their data formats> o Src, theconditional distributionIP address ofall packets withafinitehost (32-bit valueof One-way delay (undefined delays are excluded), a singlefor IPv4, 128-bit valueas follows: See section 4.1 of [RFC3393]fordetails onIPv6) o Dst, theconditional distribution to exclude undefined values of delay, and Section 5IP address of[RFC6703]a host (32-bit value forbackground on this analysis choice. See section 4.3.2 of [RFC6049]IPv4, 128-bit value fordetails on calculating this statistic, and 4.3.3 of [RFC6049]. Data format isIPv6) o T0, a32-bit signed value, *similar to* the 32-bit shorttime (start of measurement interval, 128-bit NTPTime format in SectionDate Format, see section 6 of[RFC5905][RFC5905]). When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted asfollows: the first 16 bits represent the *signed* integer number of seconds; the next 16 bits representthefractional partDuration ofa second. 7.4.2.4. Max The maximum SHALL be calculated usingtheconditional distribution of all packets withmeasurement interval. o Tf, afinite valuetime (end ofOne-way delay (undefined delays are excluded), a single value as follows: Seemeasurement interval, 128-bit NTP Date Format, see section4.16 of[RFC3393] for details on[RFC5905]), interpreted as theconditional distribution to exclude undefined values of delay, and Section 5Duration of[RFC6703] for backgroundthe measurement interval. o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1 packet per second, if fixed) o Upper limit on Poisson distribution (values above thisanalysis choice. See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic,limit will be clipped and4.3.3 of [RFC6049]. The formula is as follows: Maxset to the limit value). (if fixed, Upper limit =(FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Data30 seconds.) The formatis a 32-bit signed value, *similar to*for 1/lambda and Upper limit of Poisson Dist. are the32-bitshortNTP Timeformat inSection 6 of[RFC5905] (32 bits) and is as follows: the first 16 bits represent the*signed*integer number of seconds; the next 16 bits represent the fractional part of a second.7.4.2.5. Std_Dev 7.4.3. Reference <pointer to section/spec where output type/format is defined> See the Data Format column for references. 7.4.4. Metric Units <insert units for the measured results, and the reference specification>. The <statistic>>>> should Poisson run-time params be fixed instead? probably yes if modeling a specific version ofOne-way Delay is expressedtests. Note inseconds. The 95th Percentilethe NAME, i.e. Poisson3.3 7.3.6. Roles <lists the names ofOne-way Delay is expressed in seconds. 7.5. Administrative items 7.5.1. Status <current or depricated> 7.5.2. Requestor (keep?) name or RFC, etc. 7.5.3. Revision 1.0 7.5.4. Revision Date YYYY-MM-DD 7.6. Commentsthe different roles from the measurement method> Src - launches each packet andRemarks Additional (Informational) detailswaits forthis entry 8. UDP Periodic One-way Delay Registry Entriesreturn transmissions from Dst. Thissection gives an initial registry entry foris theUDP Periodic One-way Delay. Note: Each Registry "Name" below specifies a single registry entry, whose output format varies according toTWAMP Session-Sender. Dst - waits for each packet from Src and sends acomponentreturn packet to Src. This is the TWAMP Session-Reflector. 7.4. Output This category specifies all details of the Output of measurements using the metric. 7.4.1. Type/Value (two diff terms used) <insert namethat specifies one formofstatistical summary. IANA is asked to assignthe output type, raw or adifferent numeric identifiers to each Name. All other column entries areselected summary statistic> See subsection titles below for Types. 7.4.2. Reference Definition <describe thesame, thus thisdata format for each type of result> For all output types --- o T0, a time (start of measurement interval, 128-bit NTP Date Format, see sectionis proposes five closely-related registry entries. As6 of [RFC5905]) o Tf, aresult, IANA is also asked to assign corresponding URIs and URLs. 8.1. Summary This category includes multiple indexes totime (end of measurement interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) 7.4.2.1. Percentile95 The 95th percentile SHALL be calculated using theregistry entries,conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on theelement ID and metric name. 8.1.1. ID (Identifier) <insert numeric identifier, an integer, one corresponding to each name below> 8.1.2. Name <insert name accordingconditional distribution tometric naming convention> Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_<statistic> OwDelay_Active_IP_UDP_Periodic_UDP_Payload_142_RFCXXXXsecY_Seconds_<s tatistic> Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Percentile95 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Mean Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Min Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Max Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Std_Dev 8.1.3. URIexclude undefined values of delay, andURL URI: Prefix urn:ietf:params:performance:metric...<name> URL: http:\\www.iana.org\ ... <name> 8.1.4. Description This metric assessesSection 5 of [RFC6703] for background on this analysis choice. See section 4.3 of [RFC3393] for details on the percentile statistic (where Round-trip delay should be substituted for "ipdv"). The percentile = 95. The time value of the result is expressed in units of seconds, as astreampositive value ofpackets exchanged between two hosts (or measurement points),type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), andreportswith lossless conversion to/from the<statistic> One-way delay for64-bit NTP timestamp as per section 6 of RFC [RFC5905]. 7.4.2.2. Mean The mean SHALL be calculated using the conditional distribution of allsuccessfully exchangedpacketsbased on their conditionalwith a finite value of One-way delaydistribution. 8.2. Metric Definition This category includes columns to prompt the entry(undefined delays are excluded), a single value as follows: See section 4.1 ofall necessary[RFC3393] for detailsrelated to the metric definition, includingon theRFC reference andconditional distribution to exclude undefined values ofinput factors, called fixed parameters. 8.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S.,delay, andM. Zekauskas, "A One-way Delay MetricSection 5 of [RFC6703] forIPPM", RFC 2679, September 1999. [RFC2679] Morton, A., and Stephan, E., "Spatial Compositionbackground on this analysis choice. See section 4.2.2 ofMetrics", RFC 6049, January 2011.[RFC6049]<specificfor details on calculating this statistic, and 4.2.3 of [RFC6049]. The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per sectionreference and additional clarifications, if needed> Section 3.46 of[RFC2679] providesRFC [RFC5905]. 7.4.2.3. Min The minimum SHALL be calculated using thereference definitionconditional distribution of all packets with a finite value ofthe singleton (single value)One-way delaymetric. Section 4.4(undefined delays are excluded), a single value as follows: See section 4.1 of[RFC2679] provides[RFC3393] for details on thereference definition expandedconditional distribution tocover a multi-value sample. Note that terms such as singletonexclude undefined values of delay, andsample are defined inSection115 of[RFC2330]. Only successful packet transfers with finite delay are included in the sample, as prescribed in[RFC6703] for background on this analysis choice. See section4.1.24.3.2 of[RFC6049]. NOTE: RFC2679 will be replaced by 2679-bis[RFC6049] for details onapproval, see draft- ietf-ippm-2679-bis-01. ANY other conditions, ... 8.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determinedcalculating this statistic, andembedded in4.3.3 of [RFC6049]. The time value of themeasurement system for use when needed> Type-P: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum:result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from thechecksum must be calculated o UDP Payload: TWAMP Test Packet Formats, Section 4.1.264-bit NTP timestamp as per section 6 of[RFC5357] * Security features in use influenceRFC [RFC5905]. 7.4.2.4. Max The maximum SHALL be calculated using thenumberconditional distribution ofPadding octets. * 142 octets total, including the TWAMP format Timeout, Tmax: 3 seconds 8.3. Methodall packets with a finite value ofMeasurement This category includes columnsOne-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] forreferencesdetails on the conditional distribution torelevant sectionsexclude undefined values ofthe RFC(s)delay, andany supplemental information needed to ensure an unambiguous methodsSection 5 of [RFC6703] forimplementations. 8.3.1. Reference Method <for metric, insert relevantbackground on this analysis choice. See sectionreferences and supplemental info> The methodology4.3.2 of [RFC6049] for a closely related method for calculating thismetricstatistic, and 4.3.3 of [RFC6049]. The formula isdefinedasType-P-One-way-Delay- Poisson-Streamfollows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n The time value of the result is expressed insection 3.6units of[RFC2679] andseconds, as a positive value of type decimal64 with fraction digits = 9 (see section4.69.3 of[RFC2679] using the Type-P and Timeout defined under Fixed Parameters. The method requires sequence numbers or other send-order information to be retained at the Src or included[RFC6020]) witheach packet to dis- ambiguate packet reordering if it occurs. Sequence number is partresolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from theTWAMP payload described under Fixed Parameters. 8.3.2. Packet Generation Stream This64-bit NTP timestamp as per sectiongives the details6 ofthe packet traffic which is the basisRFC [RFC5905]. 7.4.2.5. Std_Dev 7.4.3. Metric Units <insert units formeasurement. In IPPM metrics, this is calledtheStream,measured results, andcan easily be dscribed by providingthelistreference specification>. The <statistic> ofstream parameters. <listOne-way Delay is expressed in seconds. The 95th Percentile ofgeneration parametersOne-way Delay is expressed in seconds. 7.4.4. Calibration <pointer to > 7.5. Administrative items 7.5.1. Status <current or depricated> 7.5.2. Requestor (keep?) name or RFC, etc. 7.5.3. Revision 1.0 7.5.4. Revision Date YYYY-MM-DD 7.6. Comments andsection/spec references if needed> Section 3 of [RFC3432] prescribes the methodRemarks Additional (Informational) details forgeneratingthis entry 8. UDP Periodicstreams using associated parameters. o incT,One-way Delay Registry Entries This section gives an initial registry entry for thenominal duration of inter-packet interval, first bitUDP Periodic One-way Delay. Note: Each Registry "Name" below specifies a single registry entry, whose output format varies according tofirst bit o dT, the durationa component of theinterval for allowed sample start times o T0, the actual start time NOTE: an initiation process with a numbername that specifies one form ofcontrol exchanges resulting in unpredictable start times (within a time interval) may be sufficientstatistical summary. IANA is asked toavoid synchronization of periodic streams, and therefore a valid replacement for selecting a start time at random fromassign afixed interval. These stream parameters will be specified as Run-time parameters. 8.3.3. Traffic Filtering (observation) Details NA 8.3.4. Sampling Distribution NA 8.3.5. Run-time Parameters and Data Format Run-time Parametersdifferent numeric identifiers to each Name. All other column entries areinput factors that must be determined, configured intothemeasurement system,same, thus this section is proposes five closely-related registry entries. As a result, IANA is also asked to assign corresponding URIs andreported withURLs. 8.1. Summary This category includes multiple indexes to theresults forregistry entries, thecontextelement ID and metric name. 8.1.1. ID (Identifier) <insert numeric identifier, an integer, one corresponding tobe complete. <list of run-time parameters,each name below> 8.1.2. Name <insert name according to metric naming convention> OWDelay_Active_IP-UDP-Periodic- Payload142B_RFCXXXXsecY_Seconds_<statistic> OWDelay_Active_IP-UDP-Periodic- Payload142B_RFCXXXXsecY_Seconds_95Percentile OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Mean OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Min OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Max OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_StdDev 8.1.3. URI andtheir data formats> o Src, the IP address of a host (32-bit value for IPv4, 128-bit value for IPv6) o Dst,URL URI: Prefix urn:ietf:metric...<name> URL: http:\\www.iana.org\ ... <name> 8.1.4. Description This metric assesses theIP addressdelay of ahost (32-bit value for IPv4, 128-bit value for IPv6) o T0, a time (startstream of packets exchanged between two hosts (or measurementinterval, 128-bit NTP Date Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a start time is unspecifiedpoints), andTf isreports the <statistic> One-way delay for all successfully exchanged packets based on their conditional delay distribution. 8.2. Metric Definition This category includes columns tobe interpreted asprompt theDurationentry of all necessary details related to themeasurement interval. o Tf, a time (endmetric definition, including the RFC reference and values ofmeasurement interval, 128-bit NTP Date Format, see section 6input factors, called fixed parameters. 8.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2679] Morton, A., and Stephan, E., "Spatial Composition of[RFC5905]), interpreted as the DurationMetrics", RFC 6049, January 2011. [RFC6049] <specific section reference and additional clarifications, if needed> Section 3.4 of [RFC2679] provides themeasurement interval. o incT, the nominal durationreference definition ofinter-packet interval, first bit to first bit o dT,thedurationsingleton (single value) One-way delay metric. Section 4.4 of [RFC2679] provides theinterval for allowed sample start times The format for incTreference definition expanded to cover a multi-value sample. Note that terms such as singleton anddTsample arethe short formatdefined in[RFC5905] (32 bits) and is as follows: the first 16 bits represent the integer numberSection 11 ofseconds; the next 16 bits represent[RFC2330]. Only successful packet transfers with finite delay are included in thefractional partsample, as prescribed in section 4.1.2 ofa second. >>> should Periodic run-time params[RFC6049]. NOTE: RFC2679 will befixed instead? probably yes if modeling a specific version of tests. Notereplaced by 2679-bis on approval, see draft- ietf-ippm-2679-bis-01. ANY other conditions, ... 8.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in theNAME, i.e. Poisson3.3 8.3.6. Roles <lists the names of the different roles from themeasurementmethod> Src - launches each packet and waits for return transmissions from Dst. This is the TWAMP Session-Sender. Dst - waitssystem foreach packet from Src and sends a return packetuse when needed> Type-P: o IPv4 header values: * DSCP: set toSrc. This is0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum: theTWAMP Session-Reflector. 8.4. Output This category specifies all detailschecksum must be calculated o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] * Security features in use influence theOutputnumber ofmeasurements usingPadding octets. * 142 octets total, including themetric. 8.4.1. Type/Value (two diff terms used) <insert nameTWAMP format Timeout, Tmax: 3 seconds 8.3. Method ofthe output type, raw or a selected summary statistic> See subsection titles in Data FormatMeasurement This category includes columns forTypes. 8.4.2. Data Format <describereferences to relevant sections of thedata formatRFC(s) and any supplemental information needed to ensure an unambiguous methods foreach type of result> For all output types --- o T0, a time (start of measurement interval, 128-bit NTP Date Format, seeimplementations. 8.3.1. Reference Method <for metric, insert relevant section6 of [RFC5905]) o Tf, a time (endreferences and supplemental info> The methodology for this metric is defined as Type-P-One-way-Delay- Poisson-Stream in section 3.6 ofmeasurement interval, 128-bit NTP Date Format, see[RFC2679] and section64.6 of[RFC5905]) 8.4.2.1. Percentile95[RFC2679] using the Type-P and Timeout defined under Fixed Parameters. The95th percentile SHALLmethod requires sequence numbers or other send-order information to becalculated usingretained at theconditional distribution of all packetsSrc or included witha finite valueeach packet to dis- ambiguate packet reordering if it occurs. Sequence number is part ofOne-way delay (undefined delays are excluded), a single value as follows: Seethe TWAMP payload described under Fixed Parameters. 8.3.2. Packet Generation Stream This section4.1gives the details of[RFC3393]the packet traffic which is the basis fordetails onmeasurement. In IPPM metrics, this is called the Stream, and can easily be dscribed by providing theconditional distribution to exclude undefined valueslist ofdelay,stream parameters. <list of generation parameters and section/spec references if needed> Section5 of [RFC6703] for background on this analysis choice. See section 4.33 of[RFC3393] for details on[RFC3432] prescribes thepercentile statistic (where Round-trip delay should be substitutedmethod for"ipdv"). The percentile = 95. Data format is a 32-bit signed value, *similar to*generating Periodic streams using associated parameters. o incT, the32-bit short NTP Time format in Section 6nominal duration of[RFC5905] and is as follows: theinter-packet interval, first16 bits representbit to first bit o dT, the*signed* integer numberduration ofseconds; the next 16 bits representthefractional part of a second. 8.4.2.2. Mean The mean SHALL be calculated usinginterval for allowed sample start times o T0, theconditional distribution of all packetsactual start time NOTE: an initiation process with afinite valuenumber ofOne-way delay (undefined delays are excluded),control exchanges resulting in unpredictable start times (within asingle value as follows: See section 4.1 of [RFC3393] for details on the conditional distributiontime interval) may be sufficient toexclude undefined valuesavoid synchronization ofdelay,periodic streams, andSection 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049]therefore a valid replacement fordetails on calculating this statistic, and 4.2.3 of [RFC6049]. Data format isselecting a32-bit signed value, *similar to* the 32-bit short NTP Time format in Section 6 of [RFC5905]start time at random from a fixed interval. These stream parameters will be specified as Run-time parameters. 8.3.3. Traffic Filtering (observation) Details NA 8.3.4. Sampling Distribution NA 8.3.5. Run-time Parameters andis as follows: the first 16 bits representData Format Run-time Parameters are input factors that must be determined, configured into the*signed* integer number of seconds;measurement system, and reported with thenext 16 bits representresults for thefractional part of a second. 8.4.2.3. Min The minimum SHALLcontext to becalculated usingcomplete. <list of run-time parameters, and their data formats> o Src, theconditional distributionIP address ofall packets withafinitehost (32-bit valueof One-way delay (undefined delays are excluded), a singlefor IPv4, 128-bit valueas follows: See section 4.1 of [RFC3393]fordetails onIPv6) o Dst, theconditional distribution to exclude undefined values of delay, and Section 5IP address of[RFC6703]a host (32-bit value forbackground on this analysis choice. See section 4.3.2 of [RFC6049]IPv4, 128-bit value fordetails on calculating this statistic, and 4.3.3 of [RFC6049]. Data format isIPv6) o T0, a32-bit signed value, *similar to* the 32-bit shorttime (start of measurement interval, 128-bit NTPTime format in SectionDate Format, see section 6 of[RFC5905][RFC5905]). When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted asfollows: the first 16 bits represent the *signed* integer number of seconds; the next 16 bits representthefractional partDuration ofa second. 8.4.2.4. Max The maximum SHALL be calculated usingtheconditional distribution of all packets withmeasurement interval. o Tf, afinite valuetime (end ofOne-way delay (undefined delays are excluded), a single value as follows: Seemeasurement interval, 128-bit NTP Date Format, see section4.1 of [RFC3393] for details on6 of [RFC5905]), interpreted as theconditional distribution to exclude undefined valuesDuration ofdelay, and Section 5the measurement interval. o incT, the nominal duration of[RFC6703] for background on this analysis choice. See section 4.3.2inter-packet interval, first bit to first bit o dT, the duration of[RFC6049] for a closely related methodthe interval forcalculating this statistic, and 4.3.3 of [RFC6049].allowed sample start times Theformula is as follows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Dataformatis a 32-bit signed value, *similar to*for incT and dT are the32-bitshortNTP Timeformat inSection 6 of[RFC5905] (32 bits) and is as follows: the first 16 bits represent the*signed*integer number of seconds; the next 16 bits represent the fractional part of a second.8.4.2.5. Std_Dev 8.4.3. Reference <pointer to section/spec where output type/format is defined> See the Data Format column for references. 8.4.4. Metric Units <insert units for>>> should Periodic run-time params be fixed instead? probably yes if modeling a specific version of tests. Note in themeasured results, andNAME, i.e. Poisson3.3 8.3.6. Roles <lists thereference specification>. The <statistic>names ofOne-way Delay is expressed in seconds. 8.5. Administrative items 8.5.1. Status <current or depricated> 8.5.2. Requestor (keep?) name or RFC, etc. 8.5.3. Revision 1.0 8.5.4. Revision Date YYYY-MM-DD 8.6. Commentsthe different roles from the measurement method> Src - launches each packet andRemarks Additional (Informational) detailswaits forthis entry 9. partly BLANK Registry Entryreturn transmissions from Dst. Thissection gives an initial registry entryis the TWAMP Session-Sender. Dst - waits for.... 9.1. Summary This category includes multiple indexeseach packet from Src and sends a return packet to Src. This is theregistry entries,TWAMP Session-Reflector. 8.4. Output This category specifies all details of theelement ID and metric name. <skippingOutput of measurements using theadmin columns for now> 9.1.1. ID (Identifier) <insert numeric identifier, an integer> 9.1.2. Namemetric. 8.4.1. Type/Value (two diff terms used) <insert nameaccording to metric naming convention> URL: ?? 9.1.3. URI URI: Prefix urn:ietf:params:performance:metric 9.1.4. Description TBD. 9.2. Metric Definition This category includes columns to promptof theentryoutput type, raw or a selected summary statistic> See subsection titles in Data Format for Types. 8.4.2. Data Format <describe the data format for each type of result> For allnecessary details related tooutput types --- o T0, a time (start of measurement interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) o Tf, a time (end of measurement interval, 128-bit NTP Date Format, see section 6 of [RFC5905]) 8.4.2.1. 95Percentile The 95th percentile SHALL be calculated using themetric definition, includingconditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on theRFC reference andconditional distribution to exclude undefined values ofinput factors, called fixed parameters. 9.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. <specific section referencedelay, andadditional clarifications, if needed>Section2.45 of[RFC2681] provides the reference definition[RFC6703] for background on this analysis choice. See section 4.3 of [RFC3393] for details on thesingleton (single value)percentile statistic (where Round-trip delaymetric. Section 3.4 of [RFC2681] provides the reference definition expanded to covershould be substituted for "ipdv"). The percentile = 95. Data format is amulti-value sample. Note that terms such as singleton and sample are defined32-bit signed value, *similar to* the 32-bit short NTP Time format in Section11 of [RFC2330]. Note that although the definition6 of"Round-trip-Delay between Src[RFC5905] andDst at T"isdirectionally ambiguous inas follows: thetext, this metric tightensfirst 16 bits represent thedefinition further to recognize that*signed* integer number of seconds; thehost innext 16 bits represent the"Src" role will sendfractional part of a second. The time value of thefirst packet to "Dst",result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), andultimately receive the corresponding return packet from "Dst" (when neither are lost). <<< Check howwith lossless conversion to/from theMethodology also makes this clear (or not) >>> 9.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must64-bit NTP timestamp as per section 6 of RFC [RFC5905]. 8.4.2.2. Mean The mean SHALL bedetermined and embedded incalculated using themeasurement system for use when needed> Type-P: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: Set to 17 (UDP) o UDP header values: * Checksum:conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on thechecksum must be calculated o Payload * Sequence number: 8-byte integer * Timestamp: 8 byte integer. Expressedconditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049] for details on calculating this statistic, and 4.2.3 of [RFC6049]. The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with 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 [RFC5905] * No padding (total[RFC5905]. 8.4.2.3. Min The minimum SHALL be calculated using the conditional distribution of9 bytes) Timeout: 3 seconds 9.3. Methodall packets with a finite value ofMeasurement This category includes columnsOne-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] forreferencesdetails on the conditional distribution torelevant sectionsexclude undefined values ofthe RFC(s)delay, andany supplemental information needed to ensure an unambiguous methodsSection 5 of [RFC6703] forimplementations. 9.3.1. Reference Method <for metric, insert relevant section references and supplemental info> 9.3.2. Packet Generation Stream Thisbackground on this analysis choice. See sectiongives the details4.3.2 ofthe packet traffic which is the basis[RFC6049] formeasurement. In IPPM metrics,details on calculating thisis calledstatistic, and 4.3.3 of [RFC6049]. The time value of theStream,result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), andcan easilywith lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]. 8.4.2.4. Max The maximum SHALL bedscribed by providingcalculated using thelistconditional distribution ofstream parameters. <listall packets with a finite value ofgeneration parameters and section/spec references if needed> 9.3.3. Traffic Filtering (observation) Details The measured results based onOne-way delay (undefined delays are excluded), afiltered versionsingle value as follows: See section 4.1 of [RFC3393] for details on thepackets observed,conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See sectionprovides the filter details (when present). <section reference>. 9.3.4. Sampling Distribution <insert time distribution details, or how4.3.2 of [RFC6049] for a closely related method for calculating thisis diff from the filter> 9.3.5. Run-time Parametersstatistic, andData Format Run-time Parameters are input factors4.3.3 of [RFC6049]. The formula is as follows: Max = (FiniteDelay [j]) such thatmust be determined, configured into the measurement system, and reported with the resultsforthe context to be complete. <listsome index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n The time value ofrun-time parameters> <reference(s)>. 9.3.6. Roles <liststhenamesresult is expressed in units ofthe different roles from the measurement method> 9.4. Output This category specifies all detailsseconds, as a positive value ofthe Outputtype decimal64 with fraction digits = 9 (see section 9.3 ofmeasurements using the metric. 9.4.1. Type/Value (two diff terms used) <insert name[RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from theoutput type, raw or a selected summary statistic> 9.4.2. Data Format <describe the data format for each type of result> o Value: o Data Format: (There may be some precedent to follow here, but otherwise use64-bit NTPTimestamp Format, seetimestamp as per section 6 of[RFC5905]). o Reference: <section reference> 9.4.3. Reference <pointer to section/spec where output type/format is defined> 9.4.4.RFC [RFC5905]. 8.4.2.5. Std_Dev 8.4.3. Metric Units <insert units for the measured results, and the reference specification>.9.5.The <statistic> of One-way Delay is expressed in seconds. 8.4.4. Calibration <pointer to > 8.5. Administrative items9.5.1.8.5.1. Status <current or depricated>9.5.2.8.5.2. Requestor (keep?) name or RFC, etc.9.5.3.8.5.3. Revision 1.09.5.4.8.5.4. Revision Date YYYY-MM-DD9.6.8.6. Comments and Remarks Additional (Informational) details for this entry10.9. ver08 BLANK Registry Entry This section gives an initial registry entry for ....10.1.9.1. Summary This category includes multiple indexes to the registry entries, the element ID and metric name.<skipping the Summary columns for now> 10.1.1.9.1.1. ID (Identifier) <insert numeric identifier, an integer>10.1.2.9.1.2. Name <insert name according to metric naming convention>URL: ?? 10.1.3. URI9.1.3. URIs URI: Prefix urn:ietf:params:performance:metric10.1.4.URL: 9.1.4. Description TBD.10.2.9.1.5. Reference <reference to the RFC of spec where the registry entry is defined> 9.1.6. Change Controller <org or person > 9.1.7. Version (of Registry Format) <currently 1.0> 9.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.10.2.1.9.2.1. Reference Definition <Full bibliographic reference to an immutable doc.> <specific section reference and additional clarifications, if needed>10.2.2.9.2.2. Fixed Parameters <list and specify Fixed Parameters, input factors that must be determined and embedded in the measurement system for use when needed>10.3.9.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 methods for implementations.10.3.1.9.3.1. Reference Method <for metric, insert relevant section references and supplemental info>10.3.2.9.3.2. PacketGenerationStream Generation <list of generation parameters and section/spec references if needed>10.3.3.9.3.3. Traffic Filtering (observation) Details <insert the measured results based on a filtered version of the packets observed, and this section provides the filter details (when present), and section reference>.10.3.4.9.3.4. Sampling Distribution <insert time distribution details, or how this is diff from the filter>10.3.5.9.3.5. Run-time Parameters and Data Format <list of run-time parameters, and any reference(s)>.10.3.6.9.3.6. Roles <lists the names of the different roles from the measurement method>10.4.9.4. Output This category specifies all details of the Output of measurements using the metric.10.4.1. Type/Value (two diff terms used)9.4.1. Type <insert name of the output type, raw or a selected summary statistic>10.4.2. Data Format <describe the data format for each type of result> 10.4.3.9.4.2. Reference Definition <pointer to section/spec where output type/format is defined>10.4.4.9.4.3. Metric Units <insert units for the measured results, and the reference specification>.10.5.9.4.4. Calibration <describe the error calibration, a way to indicate that the results were collected in a calbration mode of operation, and a way to report internal status metrics related to calibration, such as time offset> 9.5. Administrative items10.5.1.9.5.1. Status <current or depricated>10.5.2.9.5.2. Requestor(keep?)<name of individual orRFC,Internet Draft, etc.>10.5.3.9.5.3. Revision 1.010.5.4.9.5.4. Revision Date YYYY-MM-DD10.6.9.6. Comments and Remarks Additional (Informational) details for this entry11.10. Example RTCP-XR Registry Entry This section is MAY BE DELETED or adapted before submission. This section gives an example registry entry for the end-point metric described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric reporting.11.1.10.1. Registry Indexes This category includes multiple indexes to the registry entries, the element ID and metric name.11.1.1.10.1.1. Identifier An integer having enough digits to uniquely identify each entry in the Registry.11.1.2.10.1.2. Name A metric naming convention is TBD.11.1.3.10.1.3. URI Prefix urn:ietf:params:performance:metric11.1.4.10.1.4. Status current11.1.5.10.1.5. Requestor Alcelip Mornuley11.1.6.10.1.6. Revision 1.011.1.7.10.1.7. Revision Date 2014-07-0411.1.8.10.1.8. Description TBD.11.1.9.10.1.9. Reference Specification(s) [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003]11.2.10.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. Section 3.2 of [RFC7003] provides the reference information for this category.11.2.1.10.2.1. Reference Definition Packets Discarded in Bursts: The total number of packets discarded during discard bursts. The measured value is unsigned value. If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- range measurement. If the measurement is unavailable, the value 0xFFFFFF MUST be reported.11.2.2.10.2.2. Fixed Parameters Fixed Parameters are input factors that must be determined and embedded in the measurement system for use when needed. The values of these parameters is specified in the Registry. Threshold: 8 bits, set to value = 3 packets. The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of successive packets that must not be discarded prior to and following a discard packet in order for this discarded packet to be regarded as part of a gap. Note that the Threshold is set in accordance with the Gmin calculation defined in Section 4.7.2 of [RFC3611]. Interval Metric flag: 2 bits, set to value 11=Cumulative Duration This field is used to indicate whether the burst/gap discard metrics are Sampled, Interval, or Cumulative metrics [RFC6792]: I=10: Interval Duration - the reported value applies to the most recent measurement interval duration between successive metrics reports. I=11: Cumulative Duration - the reported value applies to the accumulation period characteristic of cumulative measurements. Senders MUST NOT use the values I=00 or I=01.11.3.10.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 methods for implementations. For the Burst/Gap Discard Metric, it appears that the only guidance on methods of measurement is in Section 3.0 of [RFC7003] and its supporting references. Relevant information is repeated below, although there appears to be no section titled "Method of Measurement" in [RFC7003].11.3.1.10.3.1. Reference Method Metrics in this block report on burst/gap discard in the stream arriving at the RTP system. Measurements of these metrics are made at the receiving end of the RTP stream. Instances of this metrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Information Block [RFC6776], which describes measurement periods in use (see [RFC6776], Section 4.2). This metrics block relies on the measurement period in the Measurement Information Block indicating the span of the report. Senders MUST send this block in the same compound RTCP packet as the Measurement Information Block. Receivers MUST verify that the measurement period is received in the same compound RTCP packet as this metrics block. If not, this metrics block MUST be discarded.11.3.2.10.3.2. Stream Type and Stream Parameters Since RTCP-XR Measurements are conducted on live RTP traffic, the complete description of the stream is contained in SDP messages that proceed the establishment of a compatible stream between two or more communicating hosts. See Run-time Parameters, below.11.3.3.10.3.3. Output Type and Data Format The output type defines the type of result that the metric produces. o Value: Packets Discarded in Bursts o Data Format: 24 bits o Reference: Section 3.2 of [RFC7003]11.3.4.10.3.4. Metric Units The measured results are apparently expressed in packets, although there is no section of [RFC7003] titled "Metric Units".11.3.5.10.3.5. Run-time Parameters and Data Format Run-Time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. However, the values of these parameters is not specified in the Registry, rather these parameters are listed as an aid to the measurement system implementor or user (they must be left as variables, and supplied on execution). The Data Format of each Run-time Parameter SHALL be specified in this column, to simplify the control and implementation of measurement devices. SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. SDP Parameters: As defined in [RFC4566] Session description v= (protocol version number, currently only 0) o= (originator and session identifier : username, id, version number, network address) s= (session name : mandatory with at least one UTF-8-encoded character) i=* (session title or short information) u=* (URI of description) e=* (zero or more email address with optional name of contacts) p=* (zero or more phone number with optional name of contacts) c=* (connection information--not required if included in all media) b=* (zero or more bandwidth information lines) One or more Time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more Media descriptions (each one starting by an "m=" line; see below) m= (media name and transport address) i=* (media title or information field) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines -- overriding the Session attribute lines) An example Run-time SDP description follows: v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/9000011.4.10.4. Comments and Remarks TBD.12.11. Revision History This section may be removed for publication. It contains partial information on updtes. This draft replaced draft-mornuley-ippm-initial-registry. In version 02, Section 4 has been edited to reflect recent discussion on the ippm-list: * Removed the combination or "Raw" and left 95th percentile. * Hanging Indent on Run-time parameters (Fixed parameters use bullet lists and other indenting formats. * Payload format for measurement has been removed. * Explanation of Conditional delay distribution. Version 03 addressed Phil Eardley's comments and suggestions in sections 1-4. and resolved the definition of Percentiles. Version 04 * All section 4 parameters reference YANG types for alternate data formats. * Discussion has concluded that usecase(s) for machine parse-able registry columns are not needed. Still need: * suggestion of standard naming format for parameters. Note: lambda parameter description is correct in section 4, elsewhere needs fix.13.12. Security Considerations These registry entries represent no known security implications for Internet Security. Each referenced Metric contains a Security Considerations section.14.13. IANA Considerations IANA is requested to populate The Performance Metric Registry defined in [I-D.ietf-ippm-metric-registry] with the values defined above. <more is needed here>15.14. Acknowledgements The authors thank Brian Trammell for suggesting the term "Run-time Parameters", which led to the distinction between run-time and fixed parameters implemented in this memo, for identifying the IPFIX metric with Flow Key as an example, and for many other productive suggestions. Thanks to Peter Koch, who provided several useful suggestions for disambiguating successive DNS Queries in the DNS Response time metric. The authors also acknowledge the constructive reviews and helpful suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and participants in the LMAP working group.16.15. References16.1.15.1. Normative References [I-D.ietf-ippm-metric-registry] Bagnulo, M., Claise, B., Eardley, P., and A. Morton, "Registry for Performance Metrics", Internet Draft (work in progress) draft-ietf-ippm-metric-registry, 2014. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, DOI 10.17487/RFC2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <http://www.rfc-editor.org/info/rfc2681>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <http://www.rfc-editor.org/info/rfc3393>. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, <http://www.rfc-editor.org/info/rfc3432>. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <http://www.rfc-editor.org/info/rfc4737>. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <http://www.rfc-editor.org/info/rfc6049>. [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, <http://www.rfc-editor.org/info/rfc6673>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <http://www.rfc-editor.org/info/rfc6991>.16.2.[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-editor.org/info/rfc7679>. [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/rfc7680>. 15.2. Informative References [Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", March 2000. [RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, <http://www.rfc-editor.org/info/rfc4148>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, DOI 10.17487/RFC5472, March 2009, <http://www.rfc-editor.org/info/rfc5472>. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, <http://www.rfc-editor.org/info/rfc5477>. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>. [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, DOI 10.17487/RFC6248, April 2011, <http://www.rfc-editor.org/info/rfc6248>. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>. [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>. [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block", RFC 6776, DOI 10.17487/RFC6776, October 2012, <http://www.rfc-editor.org/info/rfc6776>. [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, <http://www.rfc-editor.org/info/rfc6792>. [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, September 2013, <http://www.rfc-editor.org/info/rfc7003>. [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <http://www.rfc-editor.org/info/rfc7594>. Authors' Addresses Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Philip Eardley BT Adastral Park, Martlesham Heath Ipswich ENGLAND Email: philip.eardley@bt.com Kevin D'Souza AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 xxxx Email: kld@att.com