idnits 2.17.1 draft-ietf-ippm-initial-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 592 has weird spacing: '... Src the IP...' == Line 596 has weird spacing: '... Dst the IP...' == Line 613 has weird spacing: '..._lambda avera...' == Line 635 has weird spacing: '... Src launch...' == Line 638 has weird spacing: '... Dst waits ...' == (5 more instances...) -- The document date (July 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2680' is defined on line 2772, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 2795, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 2829, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 2841, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 2849, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 2854, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 2863, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 2894, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track M. Bagnulo 5 Expires: January 9, 2017 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 July 8, 2016 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-01 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * All section 4 and 5 parameters reference YANG types for alternate 21 data formats. 23 * implementation of standard naming format for parameters. 25 Still need: * revisions that follow section 4 changes in proposed 26 metrics defined in sections 6, 7, 8. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8 70 4. UDP Round-trip Latency Registry Entry . . . . . . . . . . . . 8 71 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 76 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 77 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 78 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 79 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 80 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 81 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 82 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 83 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 84 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 85 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 15 89 4.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 15 90 4.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 15 91 4.5. Administrative items . . . . . . . . . . . . . . . . . . 15 92 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 15 93 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16 94 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 95 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 97 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 98 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 99 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 101 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 104 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 105 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 106 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 107 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 108 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 109 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 110 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 111 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 112 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 113 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 114 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 116 5.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 22 117 5.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 22 118 5.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 22 119 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 120 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 121 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 23 122 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 123 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 124 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 125 6. DNS Response Latency Registry Entry . . . . . . . . . . . . . 23 126 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 23 128 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 129 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 130 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 131 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 132 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24 133 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 134 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 26 135 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 26 136 6.3.2. Packet Generation Stream . . . . . . . . . . . . . . 27 137 6.3.3. Traffic Filtering (observation) Details . . . . . . . 27 138 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 28 139 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 28 140 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 29 141 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 29 142 6.4.1. Type/Value (two diff terms used) . . . . . . . . . . 29 143 6.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 29 144 6.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 30 145 6.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 30 146 6.5. Administrative items . . . . . . . . . . . . . . . . . . 30 147 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 31 148 6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 31 149 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 31 150 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 31 151 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 31 152 7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 31 153 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 154 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 31 155 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 32 156 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 32 157 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 32 158 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 32 159 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 32 160 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 33 161 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 34 162 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 34 163 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 34 164 7.3.3. Traffic Filtering (observation) Details . . . . . . . 34 165 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 35 166 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 35 167 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 35 168 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 36 169 7.4.1. Type/Value (two diff terms used) . . . . . . . . . . 36 170 7.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 36 171 7.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 38 172 7.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 38 173 7.5. Administrative items . . . . . . . . . . . . . . . . . . 38 174 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 38 175 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 38 176 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 38 177 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 39 178 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 39 179 8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 39 180 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 39 181 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 39 182 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 39 183 8.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 40 184 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 40 185 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 40 186 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 40 187 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 41 188 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 41 189 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 41 190 8.3.2. Packet Generation Stream . . . . . . . . . . . . . . 42 191 8.3.3. Traffic Filtering (observation) Details . . . . . . . 42 192 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 42 193 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 42 194 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 43 195 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 43 196 8.4.1. Type/Value (two diff terms used) . . . . . . . . . . 44 197 8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 44 198 8.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 46 199 8.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 46 200 8.5. Administrative items . . . . . . . . . . . . . . . . . . 46 201 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 46 202 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 46 203 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 46 204 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 46 205 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 46 206 9. partly BLANK Registry Entry . . . . . . . . . . . . . . . . . 46 207 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 47 208 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 47 209 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 47 210 9.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 47 211 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 47 212 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 47 213 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 47 214 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 48 215 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 48 216 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49 217 9.3.2. Packet Generation Stream . . . . . . . . . . . . . . 49 218 9.3.3. Traffic Filtering (observation) Details . . . . . . . 49 219 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 49 220 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 49 221 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 49 222 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49 223 9.4.1. Type/Value (two diff terms used) . . . . . . . . . . 50 224 9.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 50 225 9.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 50 226 9.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 50 227 9.5. Administrative items . . . . . . . . . . . . . . . . . . 50 228 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 50 229 9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 50 230 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 50 231 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 50 232 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 50 233 10. BLANK Registry Entry . . . . . . . . . . . . . . . . . . . . 51 234 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 51 235 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 51 236 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 51 237 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 51 238 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 51 239 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 51 240 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 51 241 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 51 242 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 52 243 10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 52 244 10.3.2. Packet Generation Stream . . . . . . . . . . . . . . 52 245 10.3.3. Traffic Filtering (observation) Details . . . . . . 52 246 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 52 247 10.3.5. Run-time Parameters and Data Format . . . . . . . . 52 248 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 52 249 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 52 250 10.4.1. Type/Value (two diff terms used) . . . . . . . . . . 52 251 10.4.2. Data Format . . . . . . . . . . . . . . . . . . . . 52 252 10.4.3. Reference . . . . . . . . . . . . . . . . . . . . . 53 253 10.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 53 254 10.5. Administrative items . . . . . . . . . . . . . . . . . . 53 255 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 256 10.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . 53 257 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 258 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 53 259 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 260 11. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 53 261 11.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 53 262 11.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 54 263 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 264 11.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 54 265 11.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 54 266 11.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 54 267 11.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 54 268 11.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 54 269 11.1.8. Description . . . . . . . . . . . . . . . . . . . . 54 270 11.1.9. Reference Specification(s) . . . . . . . . . . . . . 54 271 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 54 272 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 273 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 274 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 55 275 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 276 11.3.2. Stream Type and Stream Parameters . . . . . . . . . 56 277 11.3.3. Output Type and Data Format . . . . . . . . . . . . 56 278 11.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 56 279 11.3.5. Run-time Parameters and Data Format . . . . . . . . 56 280 11.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 58 281 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 58 282 13. Security Considerations . . . . . . . . . . . . . . . . . . . 59 283 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 284 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 285 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 286 16.1. Normative References . . . . . . . . . . . . . . . . . . 59 287 16.2. Informative References . . . . . . . . . . . . . . . . . 61 288 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 290 1. Introduction 292 Note: Efforts to synchronize structure and terminology with 293 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 294 drafts are stable. 296 This memo proposes an initial set of entries for the Performance 297 Metric Registry. It uses terms and definitions from the IPPM 298 literature, primarily [RFC2330]. Proponents of Passive Performance 299 Metrics are encouraged to develop a similar document. 301 Although there are several standard templates for organizing 302 specifications of performance metrics (see [RFC2679] for an example 303 of the traditional IPPM template, based to large extent on the 304 Benchmarking Methodology Working Group's traditional template in 305 [RFC1242], and see [RFC6390] for a similar template), none of these 306 templates were intended to become the basis for the columns of an 307 IETF-wide registry of metrics. While examinating aspects of metric 308 specifications which need to be registered, it became clear that none 309 of the existing metric templates fully satisfies the particular needs 310 of a registry. 312 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 313 for a Performance Metric Registry. Section 5 of 314 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 315 requesting registration of a Metric, that is the creation of entry(s) 316 in the Performance Metric Registry: "In essence, there needs to be 317 evidence that a candidate Registered Performance Metric has 318 significant industry interest, or has seen deployment, and there is 319 agreement that the candidate Registered Performance Metric serves its 320 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 321 also requires that new entries are administered by IANA through 322 Expert Review, which will ensure that the metrics are tightly 323 defined. 325 2. Scope 327 This document defines the initial set of Performance Metrics Registry 328 entries, for which IETF approval (following development in the IP 329 Performance Metrics (IPPM) Working Group) will satisfy the 330 requirement for Expert Review. Note that all are Active Performance 331 Metrics, which are based on RFCs prepared in the IPPM working group 332 of the IETF, according to their framework [RFC2330] and its updates. 334 3. Registry Categories and Columns 336 This section provides the categories and columns of the registry, for 337 easy reference. An entry (row) therefore gives a complete 338 description of a Registered Metric. 340 Registry Categories and Columns, shown as 341 Category 342 ------------------ 343 Column | Column | 345 Summary 346 -------------------------------- 347 ID | Name | URIs | Description | 349 Metric Definition 350 ----------------------------------------- 351 Reference Definition | Fixed Parameters | 353 Method of Measurement 354 --------------------------------------------------------------- 355 Reference | Packet | Traffic | Sampling | Run-time | Role | 356 Method | Stream | Filter | dist. | Param | | 357 | Generation | 359 Output 360 ---------------------------- 361 Type | Reference | Units | 362 | Definition | | 364 Administrative information 365 ---------------------------------- 366 Status |Request | Rev | Rev.Date | 368 Comments and Remarks 369 -------------------- 371 4. UDP Round-trip Latency Registry Entry 373 This section gives an initial registry entry for the UDP Round-trip 374 Latency. 376 Note: Each Registry entry only produces a "raw" output or a 377 statistical summary. To describe both "raw" and one or more 378 statistics efficiently, the Identifier, Name, and Output Categories 379 can be split and this section can become two or more closely-related 380 metrics. See Section 7 for an example specifying multiple Registry 381 entries with many common columns. 383 4.1. Summary 385 This category includes multiple indexes to the registry entry: the 386 element ID and metric name. 388 4.1.1. ID (Identifier) 390 392 4.1.2. Name 394 396 RTDelay_Active_UDP_RFCXXXXsecY_Seconds_95%tile 398 4.1.3. URIs 400 URN: Prefix urn:ietf:params:performance:metric: 402 URL: http:/// 404 4.1.4. Description 406 This metric assesses the delay of a stream of packets exchanged 407 between two hosts (which are the two measurement points), and the 408 Output is the Round-trip delay for all successfully exchanged packets 409 expressed as the 95th percentile of their conditional delay 410 distribution. 412 4.2. Metric Definition 414 This category includes columns to prompt the entry of all necessary 415 details related to the metric definition, including the RFC reference 416 and values of input factors, called fixed parameters. 418 4.2.1. Reference Definition 420 422 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 423 Metric for IPPM", RFC 2681, September 1999. 425 [RFC2681] 427 429 Section 2.4 of [RFC2681] provides the reference definition of the 430 singleton (single value) Round-trip delay metric. Section 3.4 of 431 [RFC2681] provides the reference definition expanded to cover a 432 multi-singleton sample. Note that terms such as singleton and sample 433 are defined in Section 11 of [RFC2330]. 435 Note that although the definition of "Round-trip-Delay between Src 436 and Dst" is directionally ambiguous in the text, this metric tightens 437 the definition further to recognize that the host in the "Src" role 438 will send the first packet to "Dst", and ultimately receive the 439 corresponding return packet from "Dst" (when neither are lost). 441 Finally, note that the variable "dT" is used in [RFC2681] to refer to 442 the value of Round-trip delay in metric definitions and methods. The 443 variable "dT" has been re-used in other IPPM literature to refer to 444 different quantities, and cannot be used as a global variable name. 446 4.2.2. Fixed Parameters 448 452 Type-P as defined in Section 13 of [RFC2330]: 454 o IPv4 header values: 456 * DSCP: set to 0 458 * TTL: set to 255 460 * Protocol: Set to 17 (UDP) 462 o IPv6 header values: 464 * DSCP: set to 0 466 * Hop Count: set to 255 468 * Protocol: Set to 17 (UDP) 470 o UDP header values: 472 * Checksum: the checksum MUST be calculated 474 o UDP Payload 476 * total of 9 bytes 478 Other measurement parameters: 480 o Tmax: a loss threshold waiting time 482 * 3.0, expressed in units of seconds, as a positive value of type 483 decimal64 with fraction digits = 5 (see section 9.3 of 484 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 485 lossless conversion to/from the 32-bit NTP timestamp as per 486 section 6 of [RFC5905]. 488 4.3. Method of Measurement 490 This category includes columns for references to relevant sections of 491 the RFC(s) and any supplemental information needed to ensure an 492 unambiguous methods for implementations. 494 4.3.1. Reference Method 496 499 The methodology for this metric is defined as Type-P-Round-trip- 500 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 501 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 502 Fixed Parameters. 504 The reference method distinguishes between long-delayed packets and 505 lost packets by implementing a maximum waiting time for packet 506 arrival. Tmax is the waiting time used as the threshold to declare a 507 packet lost. Lost packets SHALL be designated as having undefined 508 delay. 510 The calculations on the delay (RTT) SHALL be performed on the 511 conditional distribution, conditioned on successful packet arrival 512 within Tmax. Also, when all packet delays are stored, the process 513 which calculates the RTT value MAY enforce the Tmax threshold on 514 stored values before calculations. See section 4.1 of [RFC3393] for 515 details on the conditional distribution to exclude undefined values 516 of delay, and Section 5 of [RFC6703] for background on this analysis 517 choice. 519 The reference method requires some way to distinguish between 520 different packets in a stream to establish correspondence between 521 sending times and receiving times for each successfully-arriving 522 packet. Sequence numbers or other send-order identification MUST be 523 retained at the Src or included with each packet to dis-ambiguate 524 packet reordering if it occurs. 526 If a standard measurement protocol is employed, then the measurement 527 process will determine the sequence numbers or timestamps applied to 528 test packets after the Fixed and Runtime parameters are passed to 529 that process. The chosen measurement protocol will dictate the 530 format of sequence numbers and time-stamps, if they are conveyed in 531 the packet payload. 533 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 534 instruction to "send a Type-P packet back to the Src as quickly as 535 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 536 [RFC6673] presents additional requirements which MUST be included in 537 the method of measurement for this metric. 539 4.3.2. Packet Stream Generation 541 This section gives the details of the packet traffic which is the 542 basis for measurement. In IPPM metrics, this is called the Stream, 543 and can easily be described by providing the list of stream 544 parameters. 546
549 Section 11.1.3 of [RFC2330] provides three methods to generate 550 Poisson sampling intervals. the reciprocal of lambda is the average 551 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 552 lambda, in seconds. 554 >>> Check with Sam, most likely it is this... 556 Method 3 SHALL be used, where given a start time (Run-time 557 Parameter), the subsequent send times are all computed prior to 558 measurement by computing the pseudo-random distribution of inter- 559 packet send times, (truncating the distribution as specified in the 560 Run-time Parameter, Trunc), and the Src sends each packet at the 561 computed times. 563 Note that Trunc is the upper limit on inter-packet times in the 564 Poisson distribution. A random value greater than Trunc is set equal 565 to Trunc instead. 567 4.3.3. Traffic Filtering (observation) Details 569 The measured results based on a filtered version of the packets 570 observed, and this section provides the filter details (when 571 present). 573
. 575 NA 577 4.3.4. Sampling Distribution 579 582 NA 584 4.3.5. Run-time Parameters and Data Format 586 Run-time Parameters are input factors that must be determined, 587 configured into the measurement system, and reported with the results 588 for the context to be complete. 590 592 Src the IP address of the host in the Src Role (format ipv4-address- 593 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 594 see Section 4 of [RFC6991]) 596 Dst the IP address of the host in the Dst Role (format ipv4-address- 597 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 598 see section 4 of [RFC6991]) 600 T0 a time, the start of a measurement interval, (format "date-and- 601 time" as specified in Section 5.6 of [RFC3339], see also Section 3 602 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 603 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 604 and Tf is to be interpreted as the Duration of the measurement 605 interval. The start time is controlled through other means. 607 Tf a time, the end of a measurement interval, (format "date-and-time" 608 as specified in Section 5.6 of [RFC3339], see also Section 3 of 609 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 610 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 611 Tf is interpreted as the Duration of the measurement interval. 613 Reciprocal_lambda average packet interval for Poisson Streams 614 expressed in units of seconds, as a positive value of type 615 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 616 with resolution of 0.0001 seconds (0.1 ms), and with lossless 617 conversion to/from the 32-bit NTP timestamp as per section 6 of 618 [RFC5905]. 620 Trunc Upper limit on Poisson distribution expressed in units of 621 seconds, as a positive value of type decimal64 with fraction 622 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 623 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 624 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 625 this limit will be clipped and set to the limit value). (if fixed, 626 Trunc = 30.0000 seconds.) 628 >>> should Poisson run-time params be fixed instead? probably yes if 629 modeling a specific version of MBA tests. 631 4.3.6. Roles 633 635 Src launches each packet and waits for return transmissions from 636 Dst. 638 Dst waits for each packet from Src and sends a return packet to Src. 640 4.4. Output 642 This category specifies all details of the Output of measurements 643 using the metric. 645 4.4.1. Type 647 649 Percentile -- for the conditional distribution of all packets with a 650 valid value of Round-trip delay (undefined delays are excluded), a 651 single value corresponding to the 95th percentile, as follows: 653 See section 4.1 of [RFC3393] for details on the conditional 654 distribution to exclude undefined values of delay, and Section 5 of 655 [RFC6703] for background on this analysis choice. 657 The percentile = 95, meaning that the reported delay, "Percentile95", 658 is the smallest value of Round-trip delay for which the Empirical 659 Distribution Function (EDF), F(Percentile95) >= 95% of the singleton 660 Round-trip delay values in the conditional distribution. See section 661 11.3 of [RFC2330] for the definition of the percentile statistic 662 using the EDF. 664 4.4.2. Data Format 666 668 For all outputs --- 670 T0 the start of a measurement interval, (format "date-and-time" as 671 specified in Section 5.6 of [RFC3339], see also Section 3 of 672 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 673 [RFC2330]. 675 Tf the start of a measurement interval, (format "date-and-time" as 676 specified in Section 5.6 of [RFC3339], see also Section 3 of 677 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 678 [RFC2330]. 680 Raw -- REMOVED IN VERSION 01 682 For Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile: 684 Percentile95 The time value of the result is expressed in units of 685 seconds, as a positive value of type decimal64 with fraction 686 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 687 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 688 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 690 4.4.3. Reference 692 694 See the Data Format column for references. 696 4.4.4. Metric Units 698 . 701 The 95th Percentile of Round-trip Delay is expressed in seconds. 703 4.5. Administrative items 705 4.5.1. Status 707 709 4.5.2. Requestor (keep?) 711 name or RFC, etc. 713 4.5.3. Revision 715 1.0 717 4.5.4. Revision Date 719 YYYY-MM-DD 721 4.6. Comments and Remarks 723 Additional (Informational) details for this entry 725 5. Packet Delay Variation Registry Entry 727 This section gives an initial registry entry for a Packet Delay 728 Variation metric. 730 Note: If each Registry entry should only produce a "raw" output or a 731 statistical summary, then the "Output" Category can be split and this 732 section can become two closely-related metrics. 734 5.1. Summary 736 This category includes multiple indexes to the registry entries, the 737 element ID and metric name. 739 741 5.1.1. ID (Identifier) 743 745 5.1.2. Name 747 749 Act_IP-UDP-One-way-pdv-95th-percentile-Poisson 751 OwPDV_Active_UDP_Poisson_RFCXXXXsecY_Seconds_95%tile 753 5.1.3. URIs 755 URI: Prefix urn:ietf:params:performance:metric: 757 URL: http:/// 759 5.1.4. Description 761 An assessment of packet delay variation with respect to the minimum 762 delay observed on the stream, and the Output is expressed as the 95th 763 percentile of the packet delay variation distribution. 765 5.2. Metric Definition 767 This category includes columns to prompt the entry of all necessary 768 details related to the metric definition, including the RFC reference 769 and values of input factors, called fixed parameters. 771 5.2.1. Reference Definition 773 775 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 776 Performance Metrics", RFC 2330, May 1998. [RFC2330] 778 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 779 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 780 [RFC3393] 782 Morton, A. and B. Claise, "Packet Delay Variation Applicability 783 Statement", RFC 5481, March 2009. [RFC5481] 785 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 786 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 787 June 2010.[RFC5905] 789 791 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 792 measured are referred to by the variable name "ddT" (applicable to 793 all forms of delay variation). However, this metric entry specifies 794 the PDV form defined in section 4.2 of [RFC5481], where the singleton 795 PDV for packet i is referred to by the variable name "PDV(i)". 797 5.2.2. Fixed Parameters 799 803 o IPv4 header values: 805 * DSCP: set to 0 807 * TTL: set to 255 809 * Protocol: Set to 17 (UDP) 811 o IPv6 header values: 813 * DSCP: set to 0 815 * Hop Count: set to 255 817 * Protocol: Set to 17 (UDP) 819 o UDP header values: 821 * Checksum: the checksum MUST be calculated 823 o UDP Payload 825 * total of 200 bytes 827 Other measurement parameters: 829 Tmax: a loss threshold waiting time with value 3.0, expressed in 830 units of seconds, as a positive value of type decimal64 with 831 fraction digits = 5 (see section 9.3 of [RFC6020]) and with 832 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 833 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 835 F a selection function unambiguously defining the packets from the 836 stream selected for the metric. See section 4.2 of [RFC5481] for 837 the PDV form. 839 5.3. Method of Measurement 841 This category includes columns for references to relevant sections of 842 the RFC(s) and any supplemental information needed to ensure an 843 unambiguous methods for implementations. 845 5.3.1. Reference Method 847 850 See section 2.6 and 3.6 of [RFC3393] for general singleton element 851 calculations. This metric entry requires implementation of the PDV 852 form defined in section 4.2 of [RFC5481]. Also see measurement 853 considerations in section 8 of [RFC5481]. 855 The reference method distinguishes between long-delayed packets and 856 lost packets by implementing a maximum waiting time for packet 857 arrival. Tmax is the waiting time used as the threshold to declare a 858 packet lost. Lost packets SHALL be designated as having undefined 859 delay. 861 The calculations on the one-way delay SHALL be performed on the 862 conditional distribution, conditioned on successful packet arrival 863 within Tmax. Also, when all packet delays are stored, the process 864 which calculates the one-way delay value MAY enforce the Tmax 865 threshold on stored values before calculations. See section 4.1 of 866 [RFC3393] for details on the conditional distribution to exclude 867 undefined values of delay, and Section 5 of [RFC6703] for background 868 on this analysis choice. 870 The reference method requires some way to distinguish between 871 different packets in a stream to establish correspondence between 872 sending times and receiving times for each successfully-arriving 873 packet. Sequence numbers or other send-order identification MUST be 874 retained at the Src or included with each packet to dis-ambiguate 875 packet reordering if it occurs. 877 If a standard measurement protocol is employed, then the measurement 878 process will determine the sequence numbers or timestamps applied to 879 test packets after the Fixed and Runtime parameters are passed to 880 that process. The chosen measurement protocol will dictate the 881 format of sequence numbers and time-stamps, if they are conveyed in 882 the packet payload. 884 5.3.2. Packet Stream Generation 886 888 Section 11.1.3 of [RFC2330] provides three methods to generate 889 Poisson sampling intervals. the reciprocal of lambda is the average 890 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 891 lambda, in seconds. 893 >>> Check with Sam, most likely it is this... 895 Method 3 SHALL be used, where given a start time (Run-time 896 Parameter), the subsequent send times are all computed prior to 897 measurement by computing the pseudo-random distribution of inter- 898 packet send times, (truncating the distribution as specified in the 899 Run-time Parameter, Trunc), and the Src sends each packet at the 900 computed times. 902 Note that Trunc is the upper limit on inter-packet times in the 903 Poisson distribution. A random value greater than Trunc is set equal 904 to Trunc instead. 906 o lambda, a rate in reciprocal seconds (for Poisson Streams). 907 lambda = 1 packet per second 909 o Upper limit on Poisson distribution (values above this limit will 910 be clipped and set to the limit value). Upper limit = 30 seconds. 912 5.3.3. Traffic Filtering (observation) Details 914 . 918 NA 920 5.3.4. Sampling Distribution 922 925 NA 927 5.3.5. Run-time Parameters and Data Format 929 931 Src the IP address of the host in the Src Role (format ipv4-address- 932 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 933 see Section 4 of [RFC6991]) 935 Dst the IP address of the host in the Dst Role (format ipv4-address- 936 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 937 see section 4 of [RFC6991]) 939 T0 a time, the start of a measurement interval, (format "date-and- 940 time" as specified in Section 5.6 of [RFC3339], see also Section 3 941 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 942 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 943 and Tf is to be interpreted as the Duration of the measurement 944 interval. The start time is controlled through other means. 946 Tf a time, the end of a measurement interval, (format "date-and-time" 947 as specified in Section 5.6 of [RFC3339], see also Section 3 of 948 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 949 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 950 Tf is interpreted as the Duration of the measurement interval. 952 Reciprocal_lambda average packet interval for Poisson Streams 953 expressed in units of seconds, as a positive value of type 954 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 955 with resolution of 0.0001 seconds (0.1 ms), and with lossless 956 conversion to/from the 32-bit NTP timestamp as per section 6 of 957 [RFC5905]. 959 Trunc Upper limit on Poisson distribution expressed in units of 960 seconds, as a positive value of type decimal64 with fraction 961 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 962 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 963 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 964 this limit will be clipped and set to the limit value). (if fixed, 965 Trunc = 30.0000 seconds.) 967 >>> should Poisson run-time params be fixed instead? probably yes if 968 modeling a specific version of MBA tests. 970 5.3.6. Roles 972 974 Src launches each packet to Dst. 976 Dst waits for each packet from Src. 978 5.4. Output 980 This category specifies all details of the Output of measurements 981 using the metric. 983 5.4.1. Type 985 986 Percentile -- for the conditional distribution of all packets with a 987 valid value of one-way delay (undefined delays are excluded), a 988 single value corresponding to the 95th percentile, as follows: 990 See section 4.1 of [RFC3393] for details on the conditional 991 distribution to exclude undefined values of delay, and Section 5 of 992 [RFC6703] for background on this analysis choice. 994 The percentile = 95, meaning that the reported delay, "Percentile95", 995 is the smallest value of one-way PDV for which the Empirical 996 Distribution Function (EDF), F(Percentile95) >= 95% of the singleton 997 one-way PDV values in the conditional distribution. See section 11.3 998 of [RFC2330] for the definition of the percentile statistic using the 999 EDF. 1001 5.4.2. Data Format 1003 1005 T0 the start of a measurement interval, (format "date-and-time" as 1006 specified in Section 5.6 of [RFC3339], see also Section 3 of 1007 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1008 [RFC2330]. 1010 Tf the start of a measurement interval, (format "date-and-time" as 1011 specified in Section 5.6 of [RFC3339], see also Section 3 of 1012 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1013 [RFC2330]. 1015 Percentile95 The time value of the result is expressed in units of 1016 seconds, as a positive value of type decimal64 with fraction 1017 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1018 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1019 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1021 5.4.3. Reference 1023 1025 See the Data Format column for references. 1027 5.4.4. Metric Units 1029 . 1032 The 95th Percentile of one-way PDV is expressed in seconds. 1034 5.5. Administrative items 1036 5.5.1. Status 1038 1040 5.5.2. Requestor (keep?) 1042 1044 5.5.3. Revision 1046 1.0 1048 5.5.4. Revision Date 1050 YYYY-MM-DD 1052 5.6. Comments and Remarks 1054 1056 Lost packets represent a challenge for delay variation metrics. See 1057 section 4.1 of [RFC3393] and the delay variation applicability 1058 statement[RFC5481] for extensive analysis and comparison of PDV and 1059 an alternate metric, IPDV. 1061 6. DNS Response Latency Registry Entry 1063 This section gives an initial registry entry for DNS Response 1064 Latency. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1065 build on that metric by specifying several of the input parameters to 1066 precisely define a metric for measuring DNS latency. 1068 6.1. Summary 1070 This category includes multiple indexes to the registry entries, the 1071 element ID and metric name. 1073 1075 6.1.1. ID (Identifier) 1077 1079 6.1.2. Name 1081 1083 RTDNS_Active_UDP_DNS_Poisson_RFCXXXXsecY_Seconds_95%tile 1085 6.1.3. URI 1087 URI: Prefix urn:ietf:params:performance:metric 1089 URL: 1091 6.1.4. Description 1093 This metric assesses the response time, the interval from the query 1094 transmission to the response. 1096 6.2. Metric Definition 1098 This category includes columns to prompt the entry of all necessary 1099 details related to the metric definition, including the RFC reference 1100 and values of input factors, called fixed parameters. 1102 6.2.1. Reference Definition 1104 1106 Mockapetris, P., "Domain names - implementation and specification", 1107 STD 13, RFC 1035, November 1987. (and updates) 1109 [RFC1035] 1111 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1112 Metric for IPPM", RFC 2681, September 1999. 1114 [RFC2681] 1116 1118 Section 2.4 of [RFC2681] provides the reference definition of the 1119 singleton (single value) Round-trip delay metric. Section 3.4 of 1120 [RFC2681] provides the reference definition expanded to cover a 1121 multi-value sample. Note that terms such as singleton and sample are 1122 defined in Section 11 of [RFC2330]. 1124 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1125 [RFC2681]. The Local Host with its User Program and Resolver take 1126 the role of "Src", and the Foreign Name Server takes the role of 1127 "Dst". 1129 Note that although the definition of "Round-trip-Delay between Src 1130 and Dst at T" is directionally ambiguous in the text, this metric 1131 tightens the definition further to recognize that the host in the 1132 "Src" role will send the first packet to "Dst", and ultimately 1133 receive the corresponding return packet from "Dst" (when neither are 1134 lost). 1136 6.2.2. Fixed Parameters 1138 1142 Type-P: 1144 o IPv4 header values: 1146 * DSCP: set to 0 1148 * TTL set to 255 1150 * Protocol: Set to 17 (UDP) 1152 o UDP header values: 1154 * Source port: 53 1156 * Destination port: 53 1158 * Checksum: the checksum must be calculated 1160 o Payload: The payload contains a DNS message as defined in RFC 1035 1161 [RFC1035] with the following values: 1163 * The DNS header section contains: 1165 + QR: set to 0 (Query) 1167 + OPCODE: set to 0 (standard query) 1169 + AA: not set 1171 + TC: not set 1173 + RD: set to one (recursion desired) 1174 + RA: not set 1176 + RCODE: not set 1178 + QDCOUNT: set to one (only one entry) 1180 + ANCOUNT: not set 1182 + NSCOUNT: not set 1184 + ARCOUNT: not set 1186 * The Question section contains: 1188 + QNAME: the FQDN provided as input for the test 1190 + QTYPE: the query type provided as input for the test 1192 + QCLASS: set to IN 1194 * The other sections do not contain any Resource Records. 1196 Observation: reply packets will contain a DNS response and may 1197 contain RRs. 1199 Timeout: Tmax = 5 seconds (to help disambiguate queries) 1201 6.3. Method of Measurement 1203 This category includes columns for references to relevant sections of 1204 the RFC(s) and any supplemental information needed to ensure an 1205 unambiguous methods for implementations. 1207 6.3.1. Reference Method 1209 1212 The methodology for this metric is defined as Type-P-Round-trip- 1213 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1214 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1215 Fixed Parameters. 1217 The method requires sequence numbers or other send-order information 1218 to be retained at the Src or included with each packet to dis- 1219 ambiguate packet reordering if it occurs. Sequence number is part of 1220 the payload described under Fixed Parameters. 1222 DNS Messages bearing Queries provide for random ID Numbers, so more 1223 than one query may be launched while a previous request is 1224 outstanding when the ID Number is used. 1226 IF a DNS response does not arrive within Tmax, the result is 1227 undefined. The Message ID SHALL be used to disambiguate the 1228 successive queries. 1230 >>> This would require support of ID generation and population in the 1231 Message. An alternative would be to use a random Source port on the 1232 Query Message, but we would choose ONE before proceding. 1234 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1235 instruction to "send a Type-P packet back to the Src as quickly as 1236 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1237 [RFC6673] presents additional requirements which shall be included in 1238 the method of measurement for this metric. 1240 6.3.2. Packet Generation Stream 1242 This section gives the details of the packet traffic which is the 1243 basis for measurement. In IPPM metrics, this is called the Stream, 1244 and can easily be dscribed by providing the list of stream 1245 parameters. 1247 1249 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1250 generate Poisson sampling intervals. the reciprocal of lambda is the 1251 average packet rate, thus the Run-time Parameter is 1/lambda. 1253 >>> Check with Sam, most likely it is this... 1255 Method 3 is used, where given a start time (Run-time Parameter), the 1256 subsequent send times are all computed prior to measurement by 1257 computing the pseudo-random distribution of inter-packet send times, 1258 (truncating the distribution as specified in the Run-time 1259 Parameters), and the Src sends each packet at the computed times. 1261 6.3.3. Traffic Filtering (observation) Details 1263 The measured results based on a filtered version of the packets 1264 observed, and this section provides the filter details (when 1265 present). 1267
. 1269 NA 1271 6.3.4. Sampling Distribution 1273 1276 NA 1278 6.3.5. Run-time Parameters and Data Format 1280 Run-time Parameters are input factors that must be determined, 1281 configured into the measurement system, and reported with the results 1282 for the context to be complete. 1284 1286 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1287 value for IPv6) 1289 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1290 value for IPv6) 1292 o T0, a time (start of measurement interval, 128-bit NTP Date 1293 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1294 start time is unspecified and Tf is to be interpreted as the 1295 Duration of the measurement interval. 1297 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1298 see section 6 of [RFC5905]), interpreted as the Duration of the 1299 measurement interval. 1301 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1302 0.1 packet per second, if fixed) 1304 o Upper limit on Poisson distribution (values above this limit will 1305 be clipped and set to the limit value). (if fixed, Upper limit = 1306 300 seconds.) 1308 o ID, the 16-bit identifier assigned by the program that generates 1309 the query, and which must vary in successive queries, see 1310 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1311 corresponding reply and can be used by the requester to match-up 1312 replies to outstanding queries. 1314 The format for 1/lambda and Upper limit of Poisson Dist. are the 1315 short format in [RFC5905] (32 bits) and is as follows: the first 16 1316 bits represent the integer number of seconds; the next 16 bits 1317 represent the fractional part of a second. 1319 >>> should Poisson run-time params be fixed instead? probably yes if 1320 modeling a specific version of MBA tests. 1322 6.3.6. Roles 1324 1326 Src - launches each packet and waits for return transmissions from 1327 Dst. 1329 Dst - waits for each packet from Src and sends a return packet to 1330 Src. 1332 6.4. Output 1334 This category specifies all details of the Output of measurements 1335 using the metric. 1337 6.4.1. Type/Value (two diff terms used) 1339 1341 For all output types: 1343 o T0, a time (start of measurement interval, 128-bit NTP Date 1344 Format, see section 6 of [RFC5905]) 1346 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1347 see section 6 of [RFC5905]) 1349 Raw -- for each packet sent, pairs of values. 1351 >>> and the status of the response, only assigning values to 1352 successful query-response pairs. 1354 Percentile -- for the conditional distribution of all packets with a 1355 valid value of Round-trip delay (undefined delays are excluded), a 1356 single value corresponding to the 95th percentile. 1358 6.4.2. Data Format 1360 1362 Raw -- for each packet sent, pairs of values as follows: 1364 o T, the time when the packet was sent from Src, 128-bit NTP Date 1365 Format, see section 6 of [RFC5905]) 1367 o dT, a value of Round-trip delay, format is *similar to* the 32-bit 1368 short NTP Time format in Section 6 of [RFC5905] and is as follows: 1369 the first 16 bits represent the *signed* integer number of 1370 seconds; the next 16 bits represent the fractional part of a 1371 second. 1373 o dT is undefined when the packet is not received at Src in waiting 1374 time Tmxax seconds (need undefined code for no-response or un- 1375 successful response) 1377 Percentile -- for the conditional distribution of all packets with a 1378 valid value of Round-trip delay (undefined delays are excluded), a 1379 single value as follows: 1381 See section 4.1 of [RFC3393] for details on the conditional 1382 distribution to exclude undefined values of delay, and Section 5 of 1383 [RFC6703] for background on this analysis choice. 1385 See section 4.3 of [RFC3393] for details on the percentile statistic 1386 (where Round-trip delay should be substituted for "ipdv"). 1388 The percentile = 95. 1390 Data format is a 32-bit signed floating point value, *similar to* the 1391 32-bit short NTP Time format in Section 6 of [RFC5905] and is as 1392 follows: the first 16 bits represent the *signed* integer number of 1393 seconds; the next 16 bits represent the fractional part of a second. 1395 6.4.3. Reference 1397 1399 See the Data Format column for references. 1401 6.4.4. Metric Units 1403 . 1406 Round-trip Delay, dT, is expressed in seconds. 1408 The 95th Percentile of Round-trip Delay is expressed in seconds. 1410 6.5. Administrative items 1411 6.5.1. Status 1413 1415 6.5.2. Requestor (keep?) 1417 name or RFC, etc. 1419 6.5.3. Revision 1421 1.0 1423 6.5.4. Revision Date 1425 YYYY-MM-DD 1427 6.6. Comments and Remarks 1429 Additional (Informational) details for this entry 1431 7. UDP Poisson One-way Delay Registry Entries 1433 This section gives an initial registry entry for the UDP Poisson One- 1434 way Delay. 1436 Note: Each Registry "Name" below specifies a single registry entry, 1437 whose output format varies according to a component of the name that 1438 specifies one form of statistical summary. 1440 IANA is asked to assign a different numeric identifiers to each Name. 1441 All column entries beside the Summary and Output categories are the 1442 same, thus this section proposes five closely-related registry 1443 entries. As a result, IANA is also asked to assign corresponding 1444 URIs and URLs. 1446 7.1. Summary 1448 This category includes multiple indexes to the registry entries, the 1449 element ID and metric name. 1451 7.1.1. ID (Identifier) 1453 1456 7.1.2. Name 1458 1460 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_ 1462 OwDelay_Active_IP_UDP_Poisson_UDP_Payload_250_RFCXXXXsecY_Seconds_ 1465 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Percentile95 1467 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Mean 1469 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Min 1471 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Max 1473 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Std_Dev 1475 7.1.3. URI and URL 1477 URI: Prefix urn:ietf:params:performance:metric... 1479 URL: http:\\www.iana.org\ ... 1481 7.1.4. Description 1483 This metric assesses the delay of a stream of packets exchanged 1484 between two hosts (or measurement points), and reports the 1485 One-way delay for all successfully exchanged packets 1486 based on their conditional delay distribution. 1488 7.2. Metric Definition 1490 This category includes columns to prompt the entry of all necessary 1491 details related to the metric definition, including the RFC reference 1492 and values of input factors, called fixed parameters. 1494 7.2.1. Reference Definition 1496 1498 Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric 1499 for IPPM", RFC 2679, September 1999. 1501 [RFC2679] 1502 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1503 6049, January 2011. 1505 [RFC6049] 1507 1509 Section 3.4 of [RFC2679] provides the reference definition of the 1510 singleton (single value) One-way delay metric. Section 4.4 of 1511 [RFC2679] provides the reference definition expanded to cover a 1512 multi-value sample. Note that terms such as singleton and sample are 1513 defined in Section 11 of [RFC2330]. 1515 Only successful packet transfers with finite delay are included in 1516 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1518 NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- 1519 ietf-ippm-2679-bis-01. 1521 7.2.2. Fixed Parameters 1523 1527 Type-P: 1529 o IPv4 header values: 1531 * DSCP: set to 0 1533 * TTL set to 255 1535 * Protocol: Set to 17 (UDP) 1537 o UDP header values: 1539 * Checksum: the checksum must be calculated 1541 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1543 * Security features in use influence the number of Padding 1544 octets. 1546 * 250 octets total, including the TWAMP format 1548 Timeout, Tmax: 3 seconds 1550 7.3. Method of Measurement 1552 This category includes columns for references to relevant sections of 1553 the RFC(s) and any supplemental information needed to ensure an 1554 unambiguous methods for implementations. 1556 7.3.1. Reference Method 1558 1561 The methodology for this metric is defined as Type-P-One-way-Delay- 1562 Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of 1563 [RFC2679] using the Type-P and Timeout defined under Fixed 1564 Parameters. 1566 The method requires sequence numbers or other send-order information 1567 to be retained at the Src or included with each packet to dis- 1568 ambiguate packet reordering if it occurs. Sequence number is part of 1569 the TWAMP payload described under Fixed Parameters. 1571 7.3.2. Packet Generation Stream 1573 This section gives the details of the packet traffic which is the 1574 basis for measurement. In IPPM metrics, this is called the Stream, 1575 and can easily be dscribed by providing the list of stream 1576 parameters. 1578 1580 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1581 generate Poisson sampling intervals. The reciprocal of lambda is the 1582 average packet rate, thus the Run-time Parameter is 1/lambda. 1584 Method 3 or equivalent SHALL used, where given a start time (Run-time 1585 Parameter), the subsequent send times are all computed prior to 1586 measurement by computing the pseudo-random distribution of inter- 1587 packet send times, (truncating the distribution as specified in the 1588 Run-time Parameters), and the Src sends each packet at the computed 1589 times. 1591 7.3.3. Traffic Filtering (observation) Details 1593 NA 1595 7.3.4. Sampling Distribution 1597 NA 1599 7.3.5. Run-time Parameters and Data Format 1601 Run-time Parameters are input factors that must be determined, 1602 configured into the measurement system, and reported with the results 1603 for the context to be complete. 1605 1607 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1608 value for IPv6) 1610 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1611 value for IPv6) 1613 o T0, a time (start of measurement interval, 128-bit NTP Date 1614 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1615 start time is unspecified and Tf is to be interpreted as the 1616 Duration of the measurement interval. 1618 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1619 see section 6 of [RFC5905]), interpreted as the Duration of the 1620 measurement interval. 1622 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1623 1 packet per second, if fixed) 1625 o Upper limit on Poisson distribution (values above this limit will 1626 be clipped and set to the limit value). (if fixed, Upper limit = 1627 30 seconds.) 1629 The format for 1/lambda and Upper limit of Poisson Dist. are the 1630 short format in [RFC5905] (32 bits) and is as follows: the first 16 1631 bits represent the integer number of seconds; the next 16 bits 1632 represent the fractional part of a second. 1634 >>> should Poisson run-time params be fixed instead? probably yes if 1635 modeling a specific version of tests. Note in the NAME, i.e. 1636 Poisson3.3 1638 7.3.6. Roles 1640 1641 Src - launches each packet and waits for return transmissions from 1642 Dst. This is the TWAMP Session-Sender. 1644 Dst - waits for each packet from Src and sends a return packet to 1645 Src. This is the TWAMP Session-Reflector. 1647 7.4. Output 1649 This category specifies all details of the Output of measurements 1650 using the metric. 1652 7.4.1. Type/Value (two diff terms used) 1654 1656 See subsection titles below for Types. 1658 7.4.2. Data Format 1660 1662 For all output types --- 1664 o T0, a time (start of measurement interval, 128-bit NTP Date 1665 Format, see section 6 of [RFC5905]) 1667 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1668 see section 6 of [RFC5905]) 1670 7.4.2.1. Percentile95 1672 The 95th percentile SHALL be calculated using the conditional 1673 distribution of all packets with a finite value of One-way delay 1674 (undefined delays are excluded), a single value as follows: 1676 See section 4.1 of [RFC3393] for details on the conditional 1677 distribution to exclude undefined values of delay, and Section 5 of 1678 [RFC6703] for background on this analysis choice. 1680 See section 4.3 of [RFC3393] for details on the percentile statistic 1681 (where Round-trip delay should be substituted for "ipdv"). 1683 The percentile = 95. 1685 Data format is a 32-bit signed value, *similar to* the 32-bit short 1686 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1687 first 16 bits represent the *signed* integer number of seconds; the 1688 next 16 bits represent the fractional part of a second. 1690 7.4.2.2. Mean 1692 The mean SHALL be calculated using the conditional distribution of 1693 all packets with a finite value of One-way delay (undefined delays 1694 are excluded), a single value as follows: 1696 See section 4.1 of [RFC3393] for details on the conditional 1697 distribution to exclude undefined values of delay, and Section 5 of 1698 [RFC6703] for background on this analysis choice. 1700 See section 4.2.2 of [RFC6049] for details on calculating this 1701 statistic, and 4.2.3 of [RFC6049]. 1703 Data format is a 32-bit signed value, *similar to* the 32-bit short 1704 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1705 first 16 bits represent the *signed* integer number of seconds; the 1706 next 16 bits represent the fractional part of a second. 1708 7.4.2.3. Min 1710 The minimum SHALL be calculated using the conditional distribution of 1711 all packets with a finite value of One-way delay (undefined delays 1712 are excluded), a single value as follows: 1714 See section 4.1 of [RFC3393] for details on the conditional 1715 distribution to exclude undefined values of delay, and Section 5 of 1716 [RFC6703] for background on this analysis choice. 1718 See section 4.3.2 of [RFC6049] for details on calculating this 1719 statistic, and 4.3.3 of [RFC6049]. 1721 Data format is a 32-bit signed value, *similar to* the 32-bit short 1722 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1723 first 16 bits represent the *signed* integer number of seconds; the 1724 next 16 bits represent the fractional part of a second. 1726 7.4.2.4. Max 1728 The maximum SHALL be calculated using the conditional distribution of 1729 all packets with a finite value of One-way delay (undefined delays 1730 are excluded), a single value as follows: 1732 See section 4.1 of [RFC3393] for details on the conditional 1733 distribution to exclude undefined values of delay, and Section 5 of 1734 [RFC6703] for background on this analysis choice. 1736 See section 4.3.2 of [RFC6049] for a closely related method for 1737 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1738 as follows: 1740 Max = (FiniteDelay [j]) 1742 such that for some index, j, where 1 <= j <= N 1743 FiniteDelay[j] >= FiniteDelay[n] for all n 1745 Data format is a 32-bit signed value, *similar to* the 32-bit short 1746 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1747 first 16 bits represent the *signed* integer number of seconds; the 1748 next 16 bits represent the fractional part of a second. 1750 7.4.2.5. Std_Dev 1752 7.4.3. Reference 1754 1756 See the Data Format column for references. 1758 7.4.4. Metric Units 1760 . 1763 The of One-way Delay is expressed in seconds. 1765 The 95th Percentile of One-way Delay is expressed in seconds. 1767 7.5. Administrative items 1769 7.5.1. Status 1771 1773 7.5.2. Requestor (keep?) 1775 name or RFC, etc. 1777 7.5.3. Revision 1779 1.0 1781 7.5.4. Revision Date 1783 YYYY-MM-DD 1785 7.6. Comments and Remarks 1787 Additional (Informational) details for this entry 1789 8. UDP Periodic One-way Delay Registry Entries 1791 This section gives an initial registry entry for the UDP Periodic 1792 One-way Delay. 1794 Note: Each Registry "Name" below specifies a single registry entry, 1795 whose output format varies according to a component of the name that 1796 specifies one form of statistical summary. 1798 IANA is asked to assign a different numeric identifiers to each Name. 1799 All other column entries are the same, thus this section is proposes 1800 five closely-related registry entries. As a result, IANA is also 1801 asked to assign corresponding URIs and URLs. 1803 8.1. Summary 1805 This category includes multiple indexes to the registry entries, the 1806 element ID and metric name. 1808 8.1.1. ID (Identifier) 1810 1813 8.1.2. Name 1815 1817 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_ 1819 OwDelay_Active_IP_UDP_Periodic_UDP_Payload_142_RFCXXXXsecY_Seconds_ 1822 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Percentile95 1824 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Mean 1826 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Min 1828 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Max 1829 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Std_Dev 1831 8.1.3. URI and URL 1833 URI: Prefix urn:ietf:params:performance:metric... 1835 URL: http:\\www.iana.org\ ... 1837 8.1.4. Description 1839 This metric assesses the delay of a stream of packets exchanged 1840 between two hosts (or measurement points), and reports the 1841 One-way delay for all successfully exchanged packets 1842 based on their conditional delay distribution. 1844 8.2. Metric Definition 1846 This category includes columns to prompt the entry of all necessary 1847 details related to the metric definition, including the RFC reference 1848 and values of input factors, called fixed parameters. 1850 8.2.1. Reference Definition 1852 1854 Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric 1855 for IPPM", RFC 2679, September 1999. 1857 [RFC2679] 1859 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1860 6049, January 2011. 1862 [RFC6049] 1864 1866 Section 3.4 of [RFC2679] provides the reference definition of the 1867 singleton (single value) One-way delay metric. Section 4.4 of 1868 [RFC2679] provides the reference definition expanded to cover a 1869 multi-value sample. Note that terms such as singleton and sample are 1870 defined in Section 11 of [RFC2330]. 1872 Only successful packet transfers with finite delay are included in 1873 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1875 NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- 1876 ietf-ippm-2679-bis-01. 1878 ANY other conditions, ... 1880 8.2.2. Fixed Parameters 1882 1886 Type-P: 1888 o IPv4 header values: 1890 * DSCP: set to 0 1892 * TTL set to 255 1894 * Protocol: Set to 17 (UDP) 1896 o UDP header values: 1898 * Checksum: the checksum must be calculated 1900 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1902 * Security features in use influence the number of Padding 1903 octets. 1905 * 142 octets total, including the TWAMP format 1907 Timeout, Tmax: 3 seconds 1909 8.3. Method of Measurement 1911 This category includes columns for references to relevant sections of 1912 the RFC(s) and any supplemental information needed to ensure an 1913 unambiguous methods for implementations. 1915 8.3.1. Reference Method 1917 1920 The methodology for this metric is defined as Type-P-One-way-Delay- 1921 Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of 1922 [RFC2679] using the Type-P and Timeout defined under Fixed 1923 Parameters. 1925 The method requires sequence numbers or other send-order information 1926 to be retained at the Src or included with each packet to dis- 1927 ambiguate packet reordering if it occurs. Sequence number is part of 1928 the TWAMP payload described under Fixed Parameters. 1930 8.3.2. Packet Generation Stream 1932 This section gives the details of the packet traffic which is the 1933 basis for measurement. In IPPM metrics, this is called the Stream, 1934 and can easily be dscribed by providing the list of stream 1935 parameters. 1937 1939 Section 3 of [RFC3432] prescribes the method for generating Periodic 1940 streams using associated parameters. 1942 o incT, the nominal duration of inter-packet interval, first bit to 1943 first bit 1945 o dT, the duration of the interval for allowed sample start times 1947 o T0, the actual start time 1949 NOTE: an initiation process with a number of control exchanges 1950 resulting in unpredictable start times (within a time interval) may 1951 be sufficient to avoid synchronization of periodic streams, and 1952 therefore a valid replacement for selecting a start time at random 1953 from a fixed interval. 1955 These stream parameters will be specified as Run-time parameters. 1957 8.3.3. Traffic Filtering (observation) Details 1959 NA 1961 8.3.4. Sampling Distribution 1963 NA 1965 8.3.5. Run-time Parameters and Data Format 1967 Run-time Parameters are input factors that must be determined, 1968 configured into the measurement system, and reported with the results 1969 for the context to be complete. 1971 1972 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1973 value for IPv6) 1975 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1976 value for IPv6) 1978 o T0, a time (start of measurement interval, 128-bit NTP Date 1979 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1980 start time is unspecified and Tf is to be interpreted as the 1981 Duration of the measurement interval. 1983 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1984 see section 6 of [RFC5905]), interpreted as the Duration of the 1985 measurement interval. 1987 o incT, the nominal duration of inter-packet interval, first bit to 1988 first bit 1990 o dT, the duration of the interval for allowed sample start times 1992 The format for incT and dT are the short format in [RFC5905] (32 1993 bits) and is as follows: the first 16 bits represent the integer 1994 number of seconds; the next 16 bits represent the fractional part of 1995 a second. 1997 >>> should Periodic run-time params be fixed instead? probably yes if 1998 modeling a specific version of tests. Note in the NAME, i.e. 1999 Poisson3.3 2001 8.3.6. Roles 2003 2005 Src - launches each packet and waits for return transmissions from 2006 Dst. This is the TWAMP Session-Sender. 2008 Dst - waits for each packet from Src and sends a return packet to 2009 Src. This is the TWAMP Session-Reflector. 2011 8.4. Output 2013 This category specifies all details of the Output of measurements 2014 using the metric. 2016 8.4.1. Type/Value (two diff terms used) 2018 2020 See subsection titles in Data Format for Types. 2022 8.4.2. Data Format 2024 2026 For all output types --- 2028 o T0, a time (start of measurement interval, 128-bit NTP Date 2029 Format, see section 6 of [RFC5905]) 2031 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 2032 see section 6 of [RFC5905]) 2034 8.4.2.1. Percentile95 2036 The 95th percentile SHALL be calculated using the conditional 2037 distribution of all packets with a finite value of One-way delay 2038 (undefined delays are excluded), a single value as follows: 2040 See section 4.1 of [RFC3393] for details on the conditional 2041 distribution to exclude undefined values of delay, and Section 5 of 2042 [RFC6703] for background on this analysis choice. 2044 See section 4.3 of [RFC3393] for details on the percentile statistic 2045 (where Round-trip delay should be substituted for "ipdv"). 2047 The percentile = 95. 2049 Data format is a 32-bit signed value, *similar to* the 32-bit short 2050 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2051 first 16 bits represent the *signed* integer number of seconds; the 2052 next 16 bits represent the fractional part of a second. 2054 8.4.2.2. Mean 2056 The mean SHALL be calculated using the conditional distribution of 2057 all packets with a finite value of One-way delay (undefined delays 2058 are excluded), a single value as follows: 2060 See section 4.1 of [RFC3393] for details on the conditional 2061 distribution to exclude undefined values of delay, and Section 5 of 2062 [RFC6703] for background on this analysis choice. 2064 See section 4.2.2 of [RFC6049] for details on calculating this 2065 statistic, and 4.2.3 of [RFC6049]. 2067 Data format is a 32-bit signed value, *similar to* the 32-bit short 2068 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2069 first 16 bits represent the *signed* integer number of seconds; the 2070 next 16 bits represent the fractional part of a second. 2072 8.4.2.3. Min 2074 The minimum SHALL be calculated using the conditional distribution of 2075 all packets with a finite value of One-way delay (undefined delays 2076 are excluded), a single value as follows: 2078 See section 4.1 of [RFC3393] for details on the conditional 2079 distribution to exclude undefined values of delay, and Section 5 of 2080 [RFC6703] for background on this analysis choice. 2082 See section 4.3.2 of [RFC6049] for details on calculating this 2083 statistic, and 4.3.3 of [RFC6049]. 2085 Data format is a 32-bit signed value, *similar to* the 32-bit short 2086 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2087 first 16 bits represent the *signed* integer number of seconds; the 2088 next 16 bits represent the fractional part of a second. 2090 8.4.2.4. Max 2092 The maximum SHALL be calculated using the conditional distribution of 2093 all packets with a finite value of One-way delay (undefined delays 2094 are excluded), a single value as follows: 2096 See section 4.1 of [RFC3393] for details on the conditional 2097 distribution to exclude undefined values of delay, and Section 5 of 2098 [RFC6703] for background on this analysis choice. 2100 See section 4.3.2 of [RFC6049] for a closely related method for 2101 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2102 as follows: 2104 Max = (FiniteDelay [j]) 2106 such that for some index, j, where 1 <= j <= N 2107 FiniteDelay[j] >= FiniteDelay[n] for all n 2109 Data format is a 32-bit signed value, *similar to* the 32-bit short 2110 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2111 first 16 bits represent the *signed* integer number of seconds; the 2112 next 16 bits represent the fractional part of a second. 2114 8.4.2.5. Std_Dev 2116 8.4.3. Reference 2118 2120 See the Data Format column for references. 2122 8.4.4. Metric Units 2124 . 2127 The of One-way Delay is expressed in seconds. 2129 8.5. Administrative items 2131 8.5.1. Status 2133 2135 8.5.2. Requestor (keep?) 2137 name or RFC, etc. 2139 8.5.3. Revision 2141 1.0 2143 8.5.4. Revision Date 2145 YYYY-MM-DD 2147 8.6. Comments and Remarks 2149 Additional (Informational) details for this entry 2151 9. partly BLANK Registry Entry 2153 This section gives an initial registry entry for .... 2155 9.1. Summary 2157 This category includes multiple indexes to the registry entries, the 2158 element ID and metric name. 2160 2162 9.1.1. ID (Identifier) 2164 2166 9.1.2. Name 2168 2170 URL: ?? 2172 9.1.3. URI 2174 URI: Prefix urn:ietf:params:performance:metric 2176 9.1.4. Description 2178 TBD. 2180 9.2. Metric Definition 2182 This category includes columns to prompt the entry of all necessary 2183 details related to the metric definition, including the RFC reference 2184 and values of input factors, called fixed parameters. 2186 9.2.1. Reference Definition 2188 2190 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2191 Metric for IPPM", RFC 2681, September 1999. 2193 2195 Section 2.4 of [RFC2681] provides the reference definition of the 2196 singleton (single value) Round-trip delay metric. Section 3.4 of 2197 [RFC2681] provides the reference definition expanded to cover a 2198 multi-value sample. Note that terms such as singleton and sample are 2199 defined in Section 11 of [RFC2330]. 2201 Note that although the definition of "Round-trip-Delay between Src 2202 and Dst at T" is directionally ambiguous in the text, this metric 2203 tightens the definition further to recognize that the host in the 2204 "Src" role will send the first packet to "Dst", and ultimately 2205 receive the corresponding return packet from "Dst" (when neither are 2206 lost). 2208 <<< Check how the Methodology also makes this clear (or not) >>> 2210 9.2.2. Fixed Parameters 2212 2216 Type-P: 2218 o IPv4 header values: 2220 * DSCP: set to 0 2222 * TTL set to 255 2224 * Protocol: Set to 17 (UDP) 2226 o UDP header values: 2228 * Checksum: the checksum must be calculated 2230 o Payload 2232 * Sequence number: 8-byte integer 2234 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 2235 as per section 6 of RFC 5905 [RFC5905] 2237 * No padding (total of 9 bytes) 2239 Timeout: 3 seconds 2241 9.3. Method of Measurement 2243 This category includes columns for references to relevant sections of 2244 the RFC(s) and any supplemental information needed to ensure an 2245 unambiguous methods for implementations. 2247 9.3.1. Reference Method 2249 2252 9.3.2. Packet Generation Stream 2254 This section gives the details of the packet traffic which is the 2255 basis for measurement. In IPPM metrics, this is called the Stream, 2256 and can easily be dscribed by providing the list of stream 2257 parameters. 2259 2261 9.3.3. Traffic Filtering (observation) Details 2263 The measured results based on a filtered version of the packets 2264 observed, and this section provides the filter details (when 2265 present). 2267
. 2269 9.3.4. Sampling Distribution 2271 2274 9.3.5. Run-time Parameters and Data Format 2276 Run-time Parameters are input factors that must be determined, 2277 configured into the measurement system, and reported with the results 2278 for the context to be complete. 2280 2282 . 2284 9.3.6. Roles 2286 2288 9.4. Output 2290 This category specifies all details of the Output of measurements 2291 using the metric. 2293 9.4.1. Type/Value (two diff terms used) 2295 2297 9.4.2. Data Format 2299 2301 o Value: 2303 o Data Format: (There may be some precedent to follow here, but 2304 otherwise use 64-bit NTP Timestamp Format, see section 6 of 2305 [RFC5905]). 2307 o Reference:
2309 9.4.3. Reference 2311 2313 9.4.4. Metric Units 2315 . 2318 9.5. Administrative items 2320 9.5.1. Status 2322 2324 9.5.2. Requestor (keep?) 2326 name or RFC, etc. 2328 9.5.3. Revision 2330 1.0 2332 9.5.4. Revision Date 2334 YYYY-MM-DD 2336 9.6. Comments and Remarks 2338 Additional (Informational) details for this entry 2340 10. BLANK Registry Entry 2342 This section gives an initial registry entry for .... 2344 10.1. Summary 2346 This category includes multiple indexes to the registry entries, the 2347 element ID and metric name. 2349 2351 10.1.1. ID (Identifier) 2353 2355 10.1.2. Name 2357 2359 URL: ?? 2361 10.1.3. URI 2363 URI: Prefix urn:ietf:params:performance:metric 2365 10.1.4. Description 2367 TBD. 2369 10.2. Metric Definition 2371 This category includes columns to prompt the entry of all necessary 2372 details related to the metric definition, including the RFC reference 2373 and values of input factors, called fixed parameters. 2375 10.2.1. Reference Definition 2377 2379 2381 10.2.2. Fixed Parameters 2383 2387 10.3. Method of Measurement 2389 This category includes columns for references to relevant sections of 2390 the RFC(s) and any supplemental information needed to ensure an 2391 unambiguous methods for implementations. 2393 10.3.1. Reference Method 2395 2398 10.3.2. Packet Generation Stream 2400 2402 10.3.3. Traffic Filtering (observation) Details 2404 . 2408 10.3.4. Sampling Distribution 2410 2413 10.3.5. Run-time Parameters and Data Format 2415 . 2417 10.3.6. Roles 2419 2421 10.4. Output 2423 This category specifies all details of the Output of measurements 2424 using the metric. 2426 10.4.1. Type/Value (two diff terms used) 2428 2430 10.4.2. Data Format 2432 2434 10.4.3. Reference 2436 2438 10.4.4. Metric Units 2440 . 2443 10.5. Administrative items 2445 10.5.1. Status 2447 2449 10.5.2. Requestor (keep?) 2451 2453 10.5.3. Revision 2455 1.0 2457 10.5.4. Revision Date 2459 YYYY-MM-DD 2461 10.6. Comments and Remarks 2463 Additional (Informational) details for this entry 2465 11. Example RTCP-XR Registry Entry 2467 This section is MAY BE DELETED or adapted before submission. 2469 This section gives an example registry entry for the end-point metric 2470 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 2471 reporting. 2473 11.1. Registry Indexes 2475 This category includes multiple indexes to the registry entries, the 2476 element ID and metric name. 2478 11.1.1. Identifier 2480 An integer having enough digits to uniquely identify each entry in 2481 the Registry. 2483 11.1.2. Name 2485 A metric naming convention is TBD. 2487 11.1.3. URI 2489 Prefix urn:ietf:params:performance:metric 2491 11.1.4. Status 2493 current 2495 11.1.5. Requestor 2497 Alcelip Mornuley 2499 11.1.6. Revision 2501 1.0 2503 11.1.7. Revision Date 2505 2014-07-04 2507 11.1.8. Description 2509 TBD. 2511 11.1.9. Reference Specification(s) 2513 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 2515 11.2. Metric Definition 2517 This category includes columns to prompt the entry of all necessary 2518 details related to the metric definition, including the RFC reference 2519 and values of input factors, called fixed parameters. Section 3.2 of 2520 [RFC7003] provides the reference information for this category. 2522 11.2.1. Reference Definition 2524 Packets Discarded in Bursts: 2526 The total number of packets discarded during discard bursts. The 2527 measured value is unsigned value. If the measured value exceeds 2528 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 2529 range measurement. If the measurement is unavailable, the value 2530 0xFFFFFF MUST be reported. 2532 11.2.2. Fixed Parameters 2534 Fixed Parameters are input factors that must be determined and 2535 embedded in the measurement system for use when needed. The values 2536 of these parameters is specified in the Registry. 2538 Threshold: 8 bits, set to value = 3 packets. 2540 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 2541 successive packets that must not be discarded prior to and following 2542 a discard packet in order for this discarded packet to be regarded as 2543 part of a gap. Note that the Threshold is set in accordance with the 2544 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 2546 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 2548 This field is used to indicate whether the burst/gap discard metrics 2549 are Sampled, Interval, or Cumulative metrics [RFC6792]: 2551 I=10: Interval Duration - the reported value applies to the most 2552 recent measurement interval duration between successive metrics 2553 reports. 2555 I=11: Cumulative Duration - the reported value applies to the 2556 accumulation period characteristic of cumulative measurements. 2558 Senders MUST NOT use the values I=00 or I=01. 2560 11.3. Method of Measurement 2562 This category includes columns for references to relevant sections of 2563 the RFC(s) and any supplemental information needed to ensure an 2564 unambiguous methods for implementations. For the Burst/Gap Discard 2565 Metric, it appears that the only guidance on methods of measurement 2566 is in Section 3.0 of [RFC7003] and its supporting references. 2567 Relevant information is repeated below, although there appears to be 2568 no section titled "Method of Measurement" in [RFC7003]. 2570 11.3.1. Reference Method 2572 Metrics in this block report on burst/gap discard in the stream 2573 arriving at the RTP system. Measurements of these metrics are made 2574 at the receiving end of the RTP stream. Instances of this metrics 2575 block use the synchronization source (SSRC) to refer to the separate 2576 auxiliary Measurement Information Block [RFC6776], which describes 2577 measurement periods in use (see [RFC6776], Section 4.2). 2579 This metrics block relies on the measurement period in the 2580 Measurement Information Block indicating the span of the report. 2581 Senders MUST send this block in the same compound RTCP packet as the 2582 Measurement Information Block. Receivers MUST verify that the 2583 measurement period is received in the same compound RTCP packet as 2584 this metrics block. If not, this metrics block MUST be discarded. 2586 11.3.2. Stream Type and Stream Parameters 2588 Since RTCP-XR Measurements are conducted on live RTP traffic, the 2589 complete description of the stream is contained in SDP messages that 2590 proceed the establishment of a compatible stream between two or more 2591 communicating hosts. See Run-time Parameters, below. 2593 11.3.3. Output Type and Data Format 2595 The output type defines the type of result that the metric produces. 2597 o Value: Packets Discarded in Bursts 2599 o Data Format: 24 bits 2601 o Reference: Section 3.2 of [RFC7003] 2603 11.3.4. Metric Units 2605 The measured results are apparently expressed in packets, although 2606 there is no section of [RFC7003] titled "Metric Units". 2608 11.3.5. Run-time Parameters and Data Format 2610 Run-Time Parameters are input factors that must be determined, 2611 configured into the measurement system, and reported with the results 2612 for the context to be complete. However, the values of these 2613 parameters is not specified in the Registry, rather these parameters 2614 are listed as an aid to the measurement system implementor or user 2615 (they must be left as variables, and supplied on execution). 2617 The Data Format of each Run-time Parameter SHALL be specified in this 2618 column, to simplify the control and implementation of measurement 2619 devices. 2621 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 2623 SDP Parameters: As defined in [RFC4566] 2625 Session description v= (protocol version number, currently only 0) 2627 o= (originator and session identifier : username, id, version number, 2628 network address) 2630 s= (session name : mandatory with at least one UTF-8-encoded 2631 character) 2633 i=* (session title or short information) u=* (URI of description) 2635 e=* (zero or more email address with optional name of contacts) 2637 p=* (zero or more phone number with optional name of contacts) 2639 c=* (connection information--not required if included in all media) 2641 b=* (zero or more bandwidth information lines) One or more Time 2642 descriptions ("t=" and "r=" lines; see below) 2644 z=* (time zone adjustments) 2646 k=* (encryption key) 2648 a=* (zero or more session attribute lines) 2650 Zero or more Media descriptions (each one starting by an "m=" line; 2651 see below) 2653 m= (media name and transport address) 2655 i=* (media title or information field) 2657 c=* (connection information -- optional if included at session level) 2659 b=* (zero or more bandwidth information lines) 2661 k=* (encryption key) 2663 a=* (zero or more media attribute lines -- overriding the Session 2664 attribute lines) 2665 An example Run-time SDP description follows: 2667 v=0 2669 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 2671 s=SDP Seminar i=A Seminar on the session description protocol 2673 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 2674 Doe) 2676 c=IN IP4 233.252.0.12/127 2678 t=2873397496 2873404696 2680 a=recvonly 2682 m=audio 49170 RTP/AVP 0 2684 m=video 51372 RTP/AVP 99 2686 a=rtpmap:99 h263-1998/90000 2688 11.4. Comments and Remarks 2690 TBD. 2692 12. Revision History 2694 This section may be removed for publication. It contains partial 2695 information on updtes. 2697 This draft replaced draft-mornuley-ippm-initial-registry. 2699 In version 02, Section 4 has been edited to reflect recent discussion 2700 on the ippm-list: * Removed the combination or "Raw" and left 95th 2701 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 2702 use bullet lists and other indenting formats. * Payload format for 2703 measurement has been removed. * Explanation of Conditional delay 2704 distribution. 2706 Version 03 addressed Phil Eardley's comments and suggestions in 2707 sections 1-4. and resolved the definition of Percentiles. 2709 Version 04 * All section 4 parameters reference YANG types for 2710 alternate data formats. * Discussion has concluded that usecase(s) 2711 for machine parse-able registry columns are not needed. 2713 Still need: * suggestion of standard naming format for parameters. 2715 Note: lambda parameter description is correct in section 4, elsewhere 2716 needs fix. 2718 13. Security Considerations 2720 These registry entries represent no known security implications for 2721 Internet Security. Each referenced Metric contains a Security 2722 Considerations section. 2724 14. IANA Considerations 2726 IANA is requested to populate The Performance Metric Registry defined 2727 in [I-D.ietf-ippm-metric-registry] with the values defined above. 2729 2731 15. Acknowledgements 2733 The authors thank Brian Trammell for suggesting the term "Run-time 2734 Parameters", which led to the distinction between run-time and fixed 2735 parameters implemented in this memo, for identifying the IPFIX metric 2736 with Flow Key as an example, and for many other productive 2737 suggestions. Thanks to Peter Koch, who provided several useful 2738 suggestions for disambiguating successive DNS Queries in the DNS 2739 Response time metric. 2741 The authors also acknowledge the constructive reviews and helpful 2742 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 2743 participants in the LMAP working group. 2745 16. References 2747 16.1. Normative References 2749 [I-D.ietf-ippm-metric-registry] 2750 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 2751 "Registry for Performance Metrics", Internet Draft (work 2752 in progress) draft-ietf-ippm-metric-registry, 2014. 2754 [RFC1035] Mockapetris, P., "Domain names - implementation and 2755 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2756 November 1987, . 2758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2759 Requirement Levels", BCP 14, RFC 2119, 2760 DOI 10.17487/RFC2119, March 1997, 2761 . 2763 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2764 "Framework for IP Performance Metrics", RFC 2330, 2765 DOI 10.17487/RFC2330, May 1998, 2766 . 2768 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2769 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 2770 September 1999, . 2772 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2773 Packet Loss Metric for IPPM", RFC 2680, 2774 DOI 10.17487/RFC2680, September 1999, 2775 . 2777 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2778 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 2779 September 1999, . 2781 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2782 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2783 . 2785 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2786 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2787 DOI 10.17487/RFC3393, November 2002, 2788 . 2790 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2791 performance measurement with periodic streams", RFC 3432, 2792 DOI 10.17487/RFC3432, November 2002, 2793 . 2795 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2796 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2797 DOI 10.17487/RFC4737, November 2006, 2798 . 2800 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2801 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2802 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2803 . 2805 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2806 "Network Time Protocol Version 4: Protocol and Algorithms 2807 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2808 . 2810 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2811 the Network Configuration Protocol (NETCONF)", RFC 6020, 2812 DOI 10.17487/RFC6020, October 2010, 2813 . 2815 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 2816 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 2817 . 2819 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 2820 DOI 10.17487/RFC6673, August 2012, 2821 . 2823 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2824 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2825 . 2827 16.2. Informative References 2829 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 2830 Distributions", March 2000. 2832 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 2833 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 2834 July 1991, . 2836 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2837 "RTP Control Protocol Extended Reports (RTCP XR)", 2838 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2839 . 2841 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2842 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2843 2005, . 2845 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2846 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2847 July 2006, . 2849 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 2850 Flow Information Export (IPFIX) Applicability", RFC 5472, 2851 DOI 10.17487/RFC5472, March 2009, 2852 . 2854 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 2855 Carle, "Information Model for Packet Sampling Exports", 2856 RFC 5477, DOI 10.17487/RFC5477, March 2009, 2857 . 2859 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 2860 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 2861 March 2009, . 2863 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 2864 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 2865 DOI 10.17487/RFC6248, April 2011, 2866 . 2868 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 2869 Performance Metric Development", BCP 170, RFC 6390, 2870 DOI 10.17487/RFC6390, October 2011, 2871 . 2873 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 2874 IP Network Performance Metrics: Different Points of View", 2875 RFC 6703, DOI 10.17487/RFC6703, August 2012, 2876 . 2878 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 2879 Reporting Using a Source Description (SDES) Item and an 2880 RTCP Extended Report (XR) Block", RFC 6776, 2881 DOI 10.17487/RFC6776, October 2012, 2882 . 2884 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 2885 of the RTP Monitoring Framework", RFC 6792, 2886 DOI 10.17487/RFC6792, November 2012, 2887 . 2889 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 2890 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 2891 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 2892 September 2013, . 2894 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 2895 Aitken, P., and A. Akhter, "A Framework for Large-Scale 2896 Measurement of Broadband Performance (LMAP)", RFC 7594, 2897 DOI 10.17487/RFC7594, September 2015, 2898 . 2900 Authors' Addresses 2902 Al Morton 2903 AT&T Labs 2904 200 Laurel Avenue South 2905 Middletown,, NJ 07748 2906 USA 2908 Phone: +1 732 420 1571 2909 Fax: +1 732 368 1192 2910 Email: acmorton@att.com 2911 URI: http://home.comcast.net/~acmacm/ 2913 Marcelo Bagnulo 2914 Universidad Carlos III de Madrid 2915 Av. Universidad 30 2916 Leganes, Madrid 28911 2917 SPAIN 2919 Phone: 34 91 6249500 2920 Email: marcelo@it.uc3m.es 2921 URI: http://www.it.uc3m.es 2923 Philip Eardley 2924 BT 2925 Adastral Park, Martlesham Heath 2926 Ipswich 2927 ENGLAND 2929 Email: philip.eardley@bt.com 2931 Kevin D'Souza 2932 AT&T Labs 2933 200 Laurel Avenue South 2934 Middletown,, NJ 07748 2935 USA 2937 Phone: +1 732 420 xxxx 2938 Email: kld@att.com