idnits 2.17.1 draft-ietf-ippm-initial-registry-00.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 594 has weird spacing: '... Src the IP...' == Line 598 has weird spacing: '... Dst the IP...' == Line 615 has weird spacing: '..._lambda avera...' == Line 637 has weird spacing: '... Src launch...' == Line 640 has weird spacing: '... Dst waits ...' -- The document date (March 12, 2016) is 2966 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 2701, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 2724, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 2758, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 2770, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 2778, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 2783, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 2792, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 2823, 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 (~~), 14 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: September 13, 2016 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 March 12, 2016 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-00 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. 20 WG 00 is the same as Individual 04, which was updated 3 times since 21 IETF-94. 23 Version 04 * All section 4 parameters reference YANG types for 24 alternate data formats. * Discussion has concluded that usecase(s) 25 for machine parse-able registry columns are not needed. 27 Still need: * suggestion of standard naming format for parameters. * 28 revisions that follow section 4 changes in other proposed metrics. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 13, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8 73 4. UDP Round-trip Latency Registry Entry . . . . . . . . . . . . 8 74 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 76 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 79 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 80 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 81 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 82 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 83 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 84 4.3.2. Packet Generation Stream . . . . . . . . . . . . . . 12 85 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 86 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 87 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 88 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 15 92 4.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 15 93 4.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 15 94 4.5. Administrative items . . . . . . . . . . . . . . . . . . 15 95 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 15 96 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16 97 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 98 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 99 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 100 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 101 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 103 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 104 5.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 106 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 107 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 108 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 17 109 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 110 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 18 111 5.3.2. Packet Generation Stream . . . . . . . . . . . . . . 18 112 5.3.3. Traffic Filtering (observation) Details . . . . . . . 18 113 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 19 114 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 19 115 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 19 116 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 5.4.1. Type/Value (two diff terms used) . . . . . . . . . . 19 118 5.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 20 119 5.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 21 120 5.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 21 121 5.5. Administrative items . . . . . . . . . . . . . . . . . . 21 122 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 21 123 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 21 124 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 21 125 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 21 126 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 22 127 6. DNS Response Latency Registry Entry . . . . . . . . . . . . . 22 128 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 129 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 22 130 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 22 131 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 22 132 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 22 133 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 22 134 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 23 135 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 23 136 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 25 137 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 25 138 6.3.2. Packet Generation Stream . . . . . . . . . . . . . . 26 139 6.3.3. Traffic Filtering (observation) Details . . . . . . . 26 140 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 26 141 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 26 142 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 27 143 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 27 144 6.4.1. Type/Value (two diff terms used) . . . . . . . . . . 28 145 6.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 28 146 6.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 29 147 6.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 29 148 6.5. Administrative items . . . . . . . . . . . . . . . . . . 29 149 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 29 150 6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 29 151 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 29 152 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 29 153 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 29 154 7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 30 155 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30 156 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 30 157 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 30 158 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 30 159 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 31 160 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 31 161 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 31 162 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 31 163 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 32 164 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 32 165 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 32 166 7.3.3. Traffic Filtering (observation) Details . . . . . . . 33 167 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 33 168 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 33 169 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 34 170 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34 171 7.4.1. Type/Value (two diff terms used) . . . . . . . . . . 34 172 7.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 34 173 7.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 36 174 7.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 36 175 7.5. Administrative items . . . . . . . . . . . . . . . . . . 37 176 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 37 177 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 37 178 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 37 179 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 37 180 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 37 181 8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 37 182 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 37 183 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 37 184 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 38 185 8.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 38 186 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 38 187 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 38 188 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 38 189 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 39 190 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 40 191 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 40 192 8.3.2. Packet Generation Stream . . . . . . . . . . . . . . 40 193 8.3.3. Traffic Filtering (observation) Details . . . . . . . 41 194 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 41 195 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 41 196 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 42 197 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 42 198 8.4.1. Type/Value (two diff terms used) . . . . . . . . . . 42 199 8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 42 200 8.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 44 201 8.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 44 202 8.5. Administrative items . . . . . . . . . . . . . . . . . . 44 203 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 44 204 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 44 205 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 44 206 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 45 207 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 45 208 9. partly BLANK Registry Entry . . . . . . . . . . . . . . . . . 45 209 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 45 210 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 45 211 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 45 212 9.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 45 213 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 45 214 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 45 215 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 45 216 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 46 217 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 47 218 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 47 219 9.3.2. Packet Generation Stream . . . . . . . . . . . . . . 47 220 9.3.3. Traffic Filtering (observation) Details . . . . . . . 47 221 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 47 222 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 47 223 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 224 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 48 225 9.4.1. Type/Value (two diff terms used) . . . . . . . . . . 48 226 9.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 48 227 9.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 48 228 9.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 48 229 9.5. Administrative items . . . . . . . . . . . . . . . . . . 48 230 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 48 231 9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 48 232 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 49 233 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 49 234 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 49 235 10. BLANK Registry Entry . . . . . . . . . . . . . . . . . . . . 49 236 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 49 237 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 49 238 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 49 239 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 49 240 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 49 241 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 49 242 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 50 243 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 50 244 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 50 245 10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 50 246 10.3.2. Packet Generation Stream . . . . . . . . . . . . . . 50 247 10.3.3. Traffic Filtering (observation) Details . . . . . . 50 248 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 50 249 10.3.5. Run-time Parameters and Data Format . . . . . . . . 50 250 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 50 251 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 51 252 10.4.1. Type/Value (two diff terms used) . . . . . . . . . . 51 253 10.4.2. Data Format . . . . . . . . . . . . . . . . . . . . 51 254 10.4.3. Reference . . . . . . . . . . . . . . . . . . . . . 51 255 10.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 51 256 10.5. Administrative items . . . . . . . . . . . . . . . . . . 51 257 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 51 258 10.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . 51 259 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 51 260 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 51 261 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 51 262 11. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 52 263 11.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 52 264 11.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 52 265 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 52 266 11.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 52 267 11.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 52 268 11.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 52 269 11.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 52 270 11.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 52 271 11.1.8. Description . . . . . . . . . . . . . . . . . . . . 52 272 11.1.9. Reference Specification(s) . . . . . . . . . . . . . 53 273 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 53 274 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 53 275 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 53 276 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 54 277 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 54 278 11.3.2. Stream Type and Stream Parameters . . . . . . . . . 54 279 11.3.3. Output Type and Data Format . . . . . . . . . . . . 54 280 11.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 54 281 11.3.5. Run-time Parameters and Data Format . . . . . . . . 55 282 11.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 56 283 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 56 284 13. Security Considerations . . . . . . . . . . . . . . . . . . . 57 285 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 286 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 287 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 288 16.1. Normative References . . . . . . . . . . . . . . . . . . 58 289 16.2. Informative References . . . . . . . . . . . . . . . . . 59 290 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 292 1. Introduction 294 Note: Efforts to synchronize structure and terminology with 295 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 296 drafts are stable. 298 This memo proposes an initial set of entries for the Performance 299 Metric Registry. It uses terms and definitions from the IPPM 300 literature, primarily [RFC2330]. Proponents of Passive Performance 301 Metrics are encouraged to develop a similar document. 303 Although there are several standard templates for organizing 304 specifications of performance metrics (see [RFC2679] for an example 305 of the traditional IPPM template, based to large extent on the 306 Benchmarking Methodology Working Group's traditional template in 307 [RFC1242], and see [RFC6390] for a similar template), none of these 308 templates were intended to become the basis for the columns of an 309 IETF-wide registry of metrics. While examinating aspects of metric 310 specifications which need to be registered, it became clear that none 311 of the existing metric templates fully satisfies the particular needs 312 of a registry. 314 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 315 for a Performance Metric Registry. Section 5 of 316 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 317 requesting registration of a Metric, that is the creation of entry(s) 318 in the Performance Metric Registry: "In essence, there needs to be 319 evidence that a candidate Registered Performance Metric has 320 significant industry interest, or has seen deployment, and there is 321 agreement that the candidate Registered Performance Metric serves its 322 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 323 also requires that new entries are administered by IANA through 324 Expert Review, which will ensure that the metrics are tightly 325 defined. 327 2. Scope 329 This document defines the initial set of Performance Metrics Registry 330 entries, for which IETF approval (following development in the IP 331 Performance Metrics (IPPM) Working Group) will satisfy the 332 requirement for Expert Review. Note that all are Active Performance 333 Metrics, which are based on RFCs prepared in the IPPM working group 334 of the IETF, according to their framework [RFC2330] and its updates. 336 3. Registry Categories and Columns 338 This section provides the categories and columns of the registry, for 339 easy reference. An entry (row) therefore gives a complete 340 description of a Registered Metric. 342 Registry Categories and Columns, shown as 343 Category 344 ------------------ 345 Column | Column | 347 Summary 348 -------------------------------- 349 ID | Name | URIs | Description | 351 Metric Definition 352 ----------------------------------------- 353 Reference Definition | Fixed Parameters | 355 Method of Measurement 356 --------------------------------------------------------------- 357 Reference | Packet | Traffic | Sampling | Run-time | Role | 358 Method | Generation | Filter | dist. | Param | | 359 | Stream | 361 Output 362 ---------------------------- 363 Type | Reference | Units | 364 | Definition | | 366 Administrative information 367 ---------------------------------- 368 Status |Request | Rev | Rev.Date | 370 Comments and Remarks 371 -------------------- 373 4. UDP Round-trip Latency Registry Entry 375 This section gives an initial registry entry for the UDP Round-trip 376 Latency. 378 Note: Each Registry entry only produces a "raw" output or a 379 statistical summary. To describe both "raw" and one or more 380 statistics efficiently, the Identifier, Name, and Output Categories 381 can be split and this section can become two or more closely-related 382 metrics. See Section 7 for an example specifying multiple Registry 383 entries with many common columns. 385 4.1. Summary 387 This category includes multiple indexes to the registry entry: the 388 element ID and metric name. 390 4.1.1. ID (Identifier) 392 394 4.1.2. Name 396 398 Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile 400 4.1.3. URIs 402 URN: Prefix urn:ietf:params:performance:metric... 404 URL: http:/// 406 4.1.4. Description 408 This metric assesses the delay of a stream of packets exchanged 409 between two hosts (which are the two measurement points), and the 410 Output is the Round-trip delay for all successfully exchanged packets 411 expressed as the 95th percentile of their conditional delay 412 distribution. 414 4.2. Metric Definition 416 This category includes columns to prompt the entry of all necessary 417 details related to the metric definition, including the RFC reference 418 and values of input factors, called fixed parameters. 420 4.2.1. Reference Definition 422 424 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 425 Metric for IPPM", RFC 2681, September 1999. 427 [RFC2681] 429 431 Section 2.4 of [RFC2681] provides the reference definition of the 432 singleton (single value) Round-trip delay metric. Section 3.4 of 433 [RFC2681] provides the reference definition expanded to cover a 434 multi-value sample. Note that terms such as singleton and sample are 435 defined in Section 11 of [RFC2330]. 437 Note that although the definition of "Round-trip-Delay between Src 438 and Dst" is directionally ambiguous in the text, this metric tightens 439 the definition further to recognize that the host in the "Src" role 440 will send the first packet to "Dst", and ultimately receive the 441 corresponding return packet from "Dst" (when neither are lost). 443 Finally, note that the variable "dT" is used in [RFC2681] to refer to 444 the value of Round-trip delay in metric definitions and methods. The 445 variable "dT" has been re-used in other IPPM literature to refer to 446 different quantities, and cannot be used as a global variable name. 448 4.2.2. Fixed Parameters 450 454 Type-P: 456 o IPv4 header values: 458 * DSCP: set to 0 460 * TTL: set to 255 462 * Protocol: Set to 17 (UDP) 464 o IPv6 header values: 466 * DSCP: set to 0 468 * Hop Count: set to 255 470 * Protocol: Set to 17 (UDP) 472 o UDP header values: 474 * Checksum: the checksum MUST be calculated 476 o UDP Payload 478 * total of 9 bytes 480 Other measurement parameters: 482 o Tmax: a loss threshold waiting time 484 * 3.0, expressed in units of seconds, as a positive value of type 485 decimal64 with fraction digits = 5 (see section 9.3 of 486 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 487 lossless conversion to/from the 32-bit NTP timestamp as per 488 section 6 of [RFC5905]. 490 4.3. Method of Measurement 492 This category includes columns for references to relevant sections of 493 the RFC(s) and any supplemental information needed to ensure an 494 unambiguous methods for implementations. 496 4.3.1. Reference Method 498 501 The methodology for this metric is defined as Type-P-Round-trip- 502 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 503 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 504 Fixed Parameters. 506 The reference method distinguishes between long-delayed packets and 507 lost packets by implementing a maximum waiting time for packet 508 arrival. Tmax is the waiting time used as the threshold to declare a 509 packet lost. Lost packets SHALL be designated as having undefined 510 delay. 512 The calculations on the delay (RTT) SHALL be performed on the 513 conditional distribution, conditioned on successful packet arrival 514 within Tmax. Also, when all packet delays are stored, the process 515 which calculates the RTT value MAY enforce the Tmax threshold on 516 stored values before calculations. See section 4.1 of [RFC3393] for 517 details on the conditional distribution to exclude undefined values 518 of delay, and Section 5 of [RFC6703] for background on this analysis 519 choice. 521 The reference method requires some way to distinguish between 522 different packets in a stream to establish correspondence between 523 sending times and receiving times for each successfully-arriving 524 packet. Sequence numbers or other send-order identification MUST be 525 retained at the Src or included with each packet to dis-ambiguate 526 packet reordering if it occurs. 528 If a standard measurement protocol is employed, then the measurement 529 process will determine the sequence numbers or timestamps applied to 530 test packets after the Fixed and Runtime parameters are passed to 531 that process. The chosen measurement protocol will dictate the 532 format of sequence numbers and time-stamps, if they are conveyed in 533 the packet payload. 535 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 536 instruction to "send a Type-P packet back to the Src as quickly as 537 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 538 [RFC6673] presents additional requirements which MUST be included in 539 the method of measurement for this metric. 541 4.3.2. Packet Generation Stream 543 This section gives the details of the packet traffic which is the 544 basis for measurement. In IPPM metrics, this is called the Stream, 545 and can easily be described by providing the list of stream 546 parameters. 548
551 Section 11.1.3 of [RFC2330] provides three methods to generate 552 Poisson sampling intervals. the reciprocal of lambda is the average 553 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 554 lambda, in seconds. 556 >>> Check with Sam, most likely it is this... 558 Method 3 SHALL be used, where given a start time (Run-time 559 Parameter), the subsequent send times are all computed prior to 560 measurement by computing the pseudo-random distribution of inter- 561 packet send times, (truncating the distribution as specified in the 562 Run-time Parameter, Trunc), and the Src sends each packet at the 563 computed times. 565 Note that Trunc is the upper limit on inter-packet times in the 566 Poisson distribution. A random value greater than Trunc is set equal 567 to Trunc instead. 569 4.3.3. Traffic Filtering (observation) Details 571 The measured results based on a filtered version of the packets 572 observed, and this section provides the filter details (when 573 present). 575
. 577 NA 579 4.3.4. Sampling Distribution 581 584 NA 586 4.3.5. Run-time Parameters and Data Format 588 Run-time Parameters are input factors that must be determined, 589 configured into the measurement system, and reported with the results 590 for the context to be complete. 592 594 Src the IP address of the host in the Src Role (format ipv4-address- 595 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 596 see Section 4 of [RFC6991]) 598 Dst the IP address of the host in the Dst Role (format ipv4-address- 599 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 600 see section 4 of [RFC6991]) 602 T0 a time, the start of a measurement interval, (format "date-and- 603 time" as specified in Section 5.6 of [RFC3339], see also Section 3 604 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 605 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 606 and Tf is to be interpreted as the Duration of the measurement 607 interval. The start time is controlled through other means. 609 Tf a time, the end of a measurement interval, (format "date-and-time" 610 as specified in Section 5.6 of [RFC3339], see also Section 3 of 611 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 612 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 613 Tf is interpreted as the Duration of the measurement interval. 615 Reciprocal_lambda average packet interval for Poisson Streams 616 expressed in units of seconds, as a positive value of type 617 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 618 with resolution of 0.0001 seconds (0.1 ms), and with lossless 619 conversion to/from the 32-bit NTP timestamp as per section 6 of 620 [RFC5905]. 622 Trunc Upper limit on Poisson distribution expressed in units of 623 seconds, as a positive value of type decimal64 with fraction 624 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 625 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 626 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 627 this limit will be clipped and set to the limit value). (if fixed, 628 Trunc = 30.0000 seconds.) 630 >>> should Poisson run-time params be fixed instead? probably yes if 631 modeling a specific version of MBA tests. 633 4.3.6. Roles 635 637 Src launches each packet and waits for return transmissions from 638 Dst. 640 Dst waits for each packet from Src and sends a return packet to Src. 642 4.4. Output 644 This category specifies all details of the Output of measurements 645 using the metric. 647 4.4.1. Type 649 651 Percentile -- for the conditional distribution of all packets with a 652 valid value of Round-trip delay (undefined delays are excluded), a 653 single value corresponding to the 95th percentile, as follows: 655 See section 4.1 of [RFC3393] for details on the conditional 656 distribution to exclude undefined values of delay, and Section 5 of 657 [RFC6703] for background on this analysis choice. 659 The percentile = 95, meaning that the reported delay, "Percentile95", 660 is the smallest value of Round-trip delay for which the Empirical 661 Distribution Function (EDF), F(Percentile95) >= 95% of the singleton 662 Round-trip delay values in the conditional distribution. See section 663 11.3 of [RFC2330] for the definition of the percentile statistic 664 using the EDF. 666 4.4.2. Data Format 668 670 For all outputs --- 672 T0 the start of a measurement interval, (format "date-and-time" as 673 specified in Section 5.6 of [RFC3339], see also Section 3 of 674 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 675 [RFC2330]. 677 Tf the start of a measurement interval, (format "date-and-time" as 678 specified in Section 5.6 of [RFC3339], see also Section 3 of 679 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 680 [RFC2330]. 682 Raw -- REMOVED IN VERSION 01 684 For Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile: 686 Percentile95 The time value of the result is expressed in units of 687 seconds, as a positive value of type decimal64 with fraction 688 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 689 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 690 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 692 4.4.3. Reference 694 696 See the Data Format column for references. 698 4.4.4. Metric Units 700 . 703 The 95th Percentile of Round-trip Delay is expressed in seconds. 705 4.5. Administrative items 707 4.5.1. Status 709 711 4.5.2. Requestor (keep?) 713 name or RFC, etc. 715 4.5.3. Revision 717 1.0 719 4.5.4. Revision Date 721 YYYY-MM-DD 723 4.6. Comments and Remarks 725 Additional (Informational) details for this entry 727 5. Packet Delay Variation Registry Entry 729 This section gives an initial registry entry for a Packet Delay 730 Variation metric. 732 Note: If each Registry entry should only produce a "raw" output or a 733 statistical summary, then the "Output" Category can be split and this 734 section can become two closely-related metrics. 736 5.1. Summary 738 This category includes multiple indexes to the registry entries, the 739 element ID and metric name. 741 743 5.1.1. ID (Identifier) 745 747 5.1.2. Name 749 751 Act_IP-UDP-One-way-pdv-95th-percentile-Poisson 753 URL: ?? 755 5.1.3. URI 757 URI: Prefix urn:ietf:params:performance:metric 759 5.1.4. Description 761 An assessment of packet delay variation with respect to the minimum 762 delay observed on the stream. 764 5.2. Metric Definition 766 This category includes columns to prompt the entry of all necessary 767 details related to the metric definition, including the RFC reference 768 and values of input factors, called fixed parameters. 770 5.2.1. Reference Definition 772 774 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 775 Performance Metrics", RFC 2330, May 1998. [RFC2330] 777 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 778 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 779 [RFC3393] 781 Morton, A. and B. Claise, "Packet Delay Variation Applicability 782 Statement", RFC 5481, March 2009. [RFC5481] 784 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 785 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 786 June 2010.[RFC5905] 788 790 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 791 measured are referred to by the variable name "ddT". 793 5.2.2. Fixed Parameters 795 799 o F, a selection function defining unambiguously the packets from 800 the stream selected for the metric. See section 4.2 of [RFC5481] 801 for the PDV form. 803 o L, a packet length in bits. L = 200 bits. 805 o Tmax, a maximum waiting time for packets to arrive at Dst, set 806 sufficiently long to disambiguate packets with long delays from 807 packets that are discarded (lost). Tmax = 3 seconds. 809 o Type-P, as defined in [RFC2330], which includes any field that may 810 affect a packet's treatment as it traverses the network. The 811 packets are IP/UDP, with DSCP = 0 (BE). 813 5.3. Method of Measurement 815 This category includes columns for references to relevant sections of 816 the RFC(s) and any supplemental information needed to ensure an 817 unambiguous methods for implementations. 819 5.3.1. Reference Method 821 824 See section 2.6 and 3.6 of [RFC3393] for singleton elements. 826 5.3.2. Packet Generation Stream 828 830 Poisson distributed as described in [RFC2330], with the following 831 Parameters. 833 o lambda, a rate in reciprocal seconds (for Poisson Streams). 834 lambda = 1 packet per second 836 o Upper limit on Poisson distribution (values above this limit will 837 be clipped and set to the limit value). Upper limit = 30 seconds. 839 5.3.3. Traffic Filtering (observation) Details 841 . 845 NA 847 5.3.4. Sampling Distribution 849 852 NA 854 5.3.5. Run-time Parameters and Data Format 856 . 858 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 859 value for IPv6) 861 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 862 value for IPv6) 864 o T, a time (start of measurement interval, 128-bit NTP Date Format, 865 see section 6 of [RFC5905]). When T0 is "all-zeros", a start time 866 is unspecified and Tf is to be interpreted as the Duration of the 867 measurement interval. 869 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 870 see section 6 of [RFC5905]), interpreted as the Duration of the 871 measurement interval. 873 5.3.6. Roles 875 877 Src - the host that sends the stream of packets. 879 Dst - the host that receives the stream of packets. 881 5.4. Output 883 This category specifies all details of the Output of measurements 884 using the metric. 886 5.4.1. Type/Value (two diff terms used) 888 890 Raw -- for each packet sent, pairs of values. 892 Percentile -- for the conditional distribution of all packets with a 893 valid value of one-way delay (undefined delays are excluded), a 894 single value corresponding to the 95th percentile of the singletons, 895 ddT. 897 5.4.2. Data Format 899 901 For all Output types 903 o T, a time (start of measurement interval, 128-bit NTP Date Format, 904 see section 6 of [RFC5905]) 906 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 907 see section 6 of [RFC5905]) 909 Raw - 911 o T1, the wire time of the first packet in a pair, measured at 912 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 913 section 6 of [RFC5905]). 915 o T2, the wire time of the second packet in a pair, measured at 916 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 917 section 6 of [RFC5905]). 919 o I(i),I(i+1), i >=0, pairs of times which mark the beginning and 920 ending of the intervals in which the packet stream from which the 921 measurement is taken occurs. Here, I(0) = T0 and assuming that n 922 is the largest index, I(n) = Tf (pairs of 64-bit NTP Timestamp 923 Format, see section 6 of [RFC5905]). 925 o When the one-way delay of a packet in the calculation pair for ddT 926 is undefined, then ddT is undefined for that pair. 928 Percentile -- for the conditional distribution of all packets with a 929 valid value of one-way delay (undefined delays are excluded), a 930 single value as follows: 932 See section 4.1 of [RFC3393] for details on the conditional 933 distribution to exclude undefined values of delay, and Section 5 of 934 [RFC6703] for background on this analysis choice. 936 See section 4.3 of [RFC3393] for details on the percentile statistic 937 (where pdv should be substituted for "ipdv"). 939 The percentile = 95. 941 Data format is a 32-bit signed floating point value, *similar to* the 942 32-bit short NTP Time format in Section 6 of [RFC5905] and is as 943 follows: the first 16 bits represent the *signed* integer number of 944 seconds; the next 16 bits represent the fractional part of a second. 946 5.4.3. Reference 948 950 see Data Format column. 952 5.4.4. Metric Units 954 . 957 See section 3.3 of [RFC3393] for singleton elements, ddT. The units 958 are seconds, and the same units are used for 95th percentile. 960 [RFC2330] recommends that when a time is given, it will be expressed 961 in UTC. 963 The timestamp format (for T, Tf, etc.) is the same as in [RFC5905] 964 (64 bits) and is as follows: the first 32 bits represent the unsigned 965 integer number of seconds elapsed since 0h on 1 January 1900; the 966 next 32 bits represent the fractional part of a second that has 967 elapsed since then. 969 5.5. Administrative items 971 5.5.1. Status 973 975 5.5.2. Requestor (keep?) 977 979 5.5.3. Revision 981 1.0 983 5.5.4. Revision Date 985 YYYY-MM-DD 987 5.6. Comments and Remarks 989 991 Lost packets represent a challenge for delay variation metrics. See 992 section 4.1 of [RFC3393] and the delay variation applicability 993 statement[RFC5481] for extensive analysis and comparison of PDV and 994 an alternate metric, IPDV. 996 6. DNS Response Latency Registry Entry 998 This section gives an initial registry entry for DNS Response 999 Latency. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1000 build on that metric by specifying several of the input parameters to 1001 precisely define a metric for measuring DNS latency. 1003 6.1. Summary 1005 This category includes multiple indexes to the registry entries, the 1006 element ID and metric name. 1008 1010 6.1.1. ID (Identifier) 1012 1014 6.1.2. Name 1016 1018 URL: ?? 1020 6.1.3. URI 1022 URI: Prefix urn:ietf:params:performance:metric 1024 6.1.4. Description 1026 This metric assesses the response time, the interval from the query 1027 transmission to the response. 1029 6.2. Metric Definition 1031 This category includes columns to prompt the entry of all necessary 1032 details related to the metric definition, including the RFC reference 1033 and values of input factors, called fixed parameters. 1035 6.2.1. Reference Definition 1037 1039 Mockapetris, P., "Domain names - implementation and specification", 1040 STD 13, RFC 1035, November 1987. (and updates) 1042 [RFC1035] 1044 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1045 Metric for IPPM", RFC 2681, September 1999. 1047 [RFC2681] 1049 1051 Section 2.4 of [RFC2681] provides the reference definition of the 1052 singleton (single value) Round-trip delay metric. Section 3.4 of 1053 [RFC2681] provides the reference definition expanded to cover a 1054 multi-value sample. Note that terms such as singleton and sample are 1055 defined in Section 11 of [RFC2330]. 1057 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1058 [RFC2681]. The Local Host with its User Program and Resolver take 1059 the role of "Src", and the Foreign Name Server takes the role of 1060 "Dst". 1062 Note that although the definition of "Round-trip-Delay between Src 1063 and Dst at T" is directionally ambiguous in the text, this metric 1064 tightens the definition further to recognize that the host in the 1065 "Src" role will send the first packet to "Dst", and ultimately 1066 receive the corresponding return packet from "Dst" (when neither are 1067 lost). 1069 6.2.2. Fixed Parameters 1071 1075 Type-P: 1077 o IPv4 header values: 1079 * DSCP: set to 0 1081 * TTL set to 255 1082 * Protocol: Set to 17 (UDP) 1084 o UDP header values: 1086 * Source port: 53 1088 * Destination port: 53 1090 * Checksum: the checksum must be calculated 1092 o Payload: The payload contains a DNS message as defined in RFC 1035 1093 [RFC1035] with the following values: 1095 * The DNS header section contains: 1097 + QR: set to 0 (Query) 1099 + OPCODE: set to 0 (standard query) 1101 + AA: not set 1103 + TC: not set 1105 + RD: set to one (recursion desired) 1107 + RA: not set 1109 + RCODE: not set 1111 + QDCOUNT: set to one (only one entry) 1113 + ANCOUNT: not set 1115 + NSCOUNT: not set 1117 + ARCOUNT: not set 1119 * The Question section contains: 1121 + QNAME: the FQDN provided as input for the test 1123 + QTYPE: the query type provided as input for the test 1125 + QCLASS: set to IN 1127 * The other sections do not contain any Resource Records. 1129 Observation: reply packets will contain a DNS response and may 1130 contain RRs. 1132 Timeout: Tmax = 5 seconds (to help disambiguate queries) 1134 6.3. Method of Measurement 1136 This category includes columns for references to relevant sections of 1137 the RFC(s) and any supplemental information needed to ensure an 1138 unambiguous methods for implementations. 1140 6.3.1. Reference Method 1142 1145 The methodology for this metric is defined as Type-P-Round-trip- 1146 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1147 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1148 Fixed Parameters. 1150 The method requires sequence numbers or other send-order information 1151 to be retained at the Src or included with each packet to dis- 1152 ambiguate packet reordering if it occurs. Sequence number is part of 1153 the payload described under Fixed Parameters. 1155 DNS Messages bearing Queries provide for random ID Numbers, so more 1156 than one query may be launched while a previous request is 1157 outstanding when the ID Number is used. 1159 IF a DNS response does not arrive within Tmax, the result is 1160 undefined. The Message ID SHALL be used to disambiguate the 1161 successive queries. 1163 >>> This would require support of ID generation and population in the 1164 Message. An alternative would be to use a random Source port on the 1165 Query Message, but we would choose ONE before proceding. 1167 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1168 instruction to "send a Type-P packet back to the Src as quickly as 1169 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1170 [RFC6673] presents additional requirements which shall be included in 1171 the method of measurement for this metric. 1173 6.3.2. Packet Generation Stream 1175 This section gives the details of the packet traffic which is the 1176 basis for measurement. In IPPM metrics, this is called the Stream, 1177 and can easily be dscribed by providing the list of stream 1178 parameters. 1180 1182 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1183 generate Poisson sampling intervals. the reciprocal of lambda is the 1184 average packet rate, thus the Run-time Parameter is 1/lambda. 1186 >>> Check with Sam, most likely it is this... 1188 Method 3 is used, where given a start time (Run-time Parameter), the 1189 subsequent send times are all computed prior to measurement by 1190 computing the pseudo-random distribution of inter-packet send times, 1191 (truncating the distribution as specified in the Run-time 1192 Parameters), and the Src sends each packet at the computed times. 1194 6.3.3. Traffic Filtering (observation) Details 1196 The measured results based on a filtered version of the packets 1197 observed, and this section provides the filter details (when 1198 present). 1200
. 1202 NA 1204 6.3.4. Sampling Distribution 1206 1209 NA 1211 6.3.5. Run-time Parameters and Data Format 1213 Run-time Parameters are input factors that must be determined, 1214 configured into the measurement system, and reported with the results 1215 for the context to be complete. 1217 1219 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1220 value for IPv6) 1222 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1223 value for IPv6) 1225 o T0, a time (start of measurement interval, 128-bit NTP Date 1226 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1227 start time is unspecified and Tf is to be interpreted as the 1228 Duration of the measurement interval. 1230 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1231 see section 6 of [RFC5905]), interpreted as the Duration of the 1232 measurement interval. 1234 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1235 0.1 packet per second, if fixed) 1237 o Upper limit on Poisson distribution (values above this limit will 1238 be clipped and set to the limit value). (if fixed, Upper limit = 1239 300 seconds.) 1241 o ID, the 16-bit identifier assigned by the program that generates 1242 the query, and which must vary in successive queries, see 1243 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1244 corresponding reply and can be used by the requester to match-up 1245 replies to outstanding queries. 1247 The format for 1/lambda and Upper limit of Poisson Dist. are the 1248 short format in [RFC5905] (32 bits) and is as follows: the first 16 1249 bits represent the integer number of seconds; the next 16 bits 1250 represent the fractional part of a second. 1252 >>> should Poisson run-time params be fixed instead? probably yes if 1253 modeling a specific version of MBA tests. 1255 6.3.6. Roles 1257 1259 Src - launches each packet and waits for return transmissions from 1260 Dst. 1262 Dst - waits for each packet from Src and sends a return packet to 1263 Src. 1265 6.4. Output 1267 This category specifies all details of the Output of measurements 1268 using the metric. 1270 6.4.1. Type/Value (two diff terms used) 1272 1274 For all output types: 1276 o T0, a time (start of measurement interval, 128-bit NTP Date 1277 Format, see section 6 of [RFC5905]) 1279 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1280 see section 6 of [RFC5905]) 1282 Raw -- for each packet sent, pairs of values. 1284 >>> and the status of the response, only assigning values to 1285 successful query-response pairs. 1287 Percentile -- for the conditional distribution of all packets with a 1288 valid value of Round-trip delay (undefined delays are excluded), a 1289 single value corresponding to the 95th percentile. 1291 6.4.2. Data Format 1293 1295 Raw -- for each packet sent, pairs of values as follows: 1297 o T, the time when the packet was sent from Src, 128-bit NTP Date 1298 Format, see section 6 of [RFC5905]) 1300 o dT, a value of Round-trip delay, format is *similar to* the 32-bit 1301 short NTP Time format in Section 6 of [RFC5905] and is as follows: 1302 the first 16 bits represent the *signed* integer number of 1303 seconds; the next 16 bits represent the fractional part of a 1304 second. 1306 o dT is undefined when the packet is not received at Src in waiting 1307 time Tmxax seconds (need undefined code for no-response or un- 1308 successful response) 1310 Percentile -- for the conditional distribution of all packets with a 1311 valid value of Round-trip delay (undefined delays are excluded), a 1312 single value as follows: 1314 See section 4.1 of [RFC3393] for details on the conditional 1315 distribution to exclude undefined values of delay, and Section 5 of 1316 [RFC6703] for background on this analysis choice. 1318 See section 4.3 of [RFC3393] for details on the percentile statistic 1319 (where Round-trip delay should be substituted for "ipdv"). 1321 The percentile = 95. 1323 Data format is a 32-bit signed floating point value, *similar to* the 1324 32-bit short NTP Time format in Section 6 of [RFC5905] and is as 1325 follows: the first 16 bits represent the *signed* integer number of 1326 seconds; the next 16 bits represent the fractional part of a second. 1328 6.4.3. Reference 1330 1332 See the Data Format column for references. 1334 6.4.4. Metric Units 1336 . 1339 Round-trip Delay, dT, is expressed in seconds. 1341 The 95th Percentile of Round-trip Delay is expressed in seconds. 1343 6.5. Administrative items 1345 6.5.1. Status 1347 1349 6.5.2. Requestor (keep?) 1351 name or RFC, etc. 1353 6.5.3. Revision 1355 1.0 1357 6.5.4. Revision Date 1359 YYYY-MM-DD 1361 6.6. Comments and Remarks 1363 Additional (Informational) details for this entry 1365 7. UDP Poisson One-way Delay Registry Entries 1367 This section gives an initial registry entry for the UDP Poisson One- 1368 way Delay. 1370 Note: Each Registry "Name" below specifies a single registry entry, 1371 whose output format varies according to a component of the name that 1372 specifies one form of statistical summary. 1374 IANA is asked to assign a different numeric identifiers to each Name. 1375 All column entries beside the Summary and Output categories are the 1376 same, thus this section proposes five closely-related registry 1377 entries. As a result, IANA is also asked to assign corresponding 1378 URIs and URLs. 1380 7.1. Summary 1382 This category includes multiple indexes to the registry entries, the 1383 element ID and metric name. 1385 7.1.1. ID (Identifier) 1387 1390 7.1.2. Name 1392 1394 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_ 1396 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Percentile95 1398 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Mean 1400 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Min 1402 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Max 1404 Act_IP_UDP_Poisson_UDP-Payload-250_One-way_Delay_Std_Dev 1406 7.1.3. URI and URL 1408 URI: Prefix urn:ietf:params:performance:metric... 1410 URL: http:\\www.iana.org\ ... 1412 7.1.4. Description 1414 This metric assesses the delay of a stream of packets exchanged 1415 between two hosts (or measurement points), and reports the 1416 One-way delay for all successfully exchanged packets 1417 based on their conditional delay distribution. 1419 7.2. Metric Definition 1421 This category includes columns to prompt the entry of all necessary 1422 details related to the metric definition, including the RFC reference 1423 and values of input factors, called fixed parameters. 1425 7.2.1. Reference Definition 1427 1429 Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric 1430 for IPPM", RFC 2679, September 1999. 1432 [RFC2679] 1434 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1435 6049, January 2011. 1437 [RFC6049] 1439 1441 Section 3.4 of [RFC2679] provides the reference definition of the 1442 singleton (single value) One-way delay metric. Section 4.4 of 1443 [RFC2679] provides the reference definition expanded to cover a 1444 multi-value sample. Note that terms such as singleton and sample are 1445 defined in Section 11 of [RFC2330]. 1447 Only successful packet transfers with finite delay are included in 1448 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1450 NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- 1451 ietf-ippm-2679-bis-01. 1453 7.2.2. Fixed Parameters 1455 1459 Type-P: 1461 o IPv4 header values: 1463 * DSCP: set to 0 1465 * TTL set to 255 1467 * Protocol: Set to 17 (UDP) 1469 o UDP header values: 1471 * Checksum: the checksum must be calculated 1473 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1475 * Security features in use influence the number of Padding 1476 octets. 1478 * 250 octets total, including the TWAMP format 1480 Timeout, Tmax: 3 seconds 1482 7.3. Method of Measurement 1484 This category includes columns for references to relevant sections of 1485 the RFC(s) and any supplemental information needed to ensure an 1486 unambiguous methods for implementations. 1488 7.3.1. Reference Method 1490 1493 The methodology for this metric is defined as Type-P-One-way-Delay- 1494 Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of 1495 [RFC2679] using the Type-P and Timeout defined under Fixed 1496 Parameters. 1498 The method requires sequence numbers or other send-order information 1499 to be retained at the Src or included with each packet to dis- 1500 ambiguate packet reordering if it occurs. Sequence number is part of 1501 the TWAMP payload described under Fixed Parameters. 1503 7.3.2. Packet Generation Stream 1505 This section gives the details of the packet traffic which is the 1506 basis for measurement. In IPPM metrics, this is called the Stream, 1507 and can easily be dscribed by providing the list of stream 1508 parameters. 1510 1512 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1513 generate Poisson sampling intervals. The reciprocal of lambda is the 1514 average packet rate, thus the Run-time Parameter is 1/lambda. 1516 Method 3 or equivalent SHALL used, where given a start time (Run-time 1517 Parameter), the subsequent send times are all computed prior to 1518 measurement by computing the pseudo-random distribution of inter- 1519 packet send times, (truncating the distribution as specified in the 1520 Run-time Parameters), and the Src sends each packet at the computed 1521 times. 1523 7.3.3. Traffic Filtering (observation) Details 1525 NA 1527 7.3.4. Sampling Distribution 1529 NA 1531 7.3.5. Run-time Parameters and Data Format 1533 Run-time Parameters are input factors that must be determined, 1534 configured into the measurement system, and reported with the results 1535 for the context to be complete. 1537 1539 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1540 value for IPv6) 1542 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1543 value for IPv6) 1545 o T0, a time (start of measurement interval, 128-bit NTP Date 1546 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1547 start time is unspecified and Tf is to be interpreted as the 1548 Duration of the measurement interval. 1550 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1551 see section 6 of [RFC5905]), interpreted as the Duration of the 1552 measurement interval. 1554 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1555 1 packet per second, if fixed) 1557 o Upper limit on Poisson distribution (values above this limit will 1558 be clipped and set to the limit value). (if fixed, Upper limit = 1559 30 seconds.) 1561 The format for 1/lambda and Upper limit of Poisson Dist. are the 1562 short format in [RFC5905] (32 bits) and is as follows: the first 16 1563 bits represent the integer number of seconds; the next 16 bits 1564 represent the fractional part of a second. 1566 >>> should Poisson run-time params be fixed instead? probably yes if 1567 modeling a specific version of tests. Note in the NAME, i.e. 1568 Poisson3.3 1570 7.3.6. Roles 1572 1574 Src - launches each packet and waits for return transmissions from 1575 Dst. This is the TWAMP Session-Sender. 1577 Dst - waits for each packet from Src and sends a return packet to 1578 Src. This is the TWAMP Session-Reflector. 1580 7.4. Output 1582 This category specifies all details of the Output of measurements 1583 using the metric. 1585 7.4.1. Type/Value (two diff terms used) 1587 1589 See subsection titles below for Types. 1591 7.4.2. Data Format 1593 1595 For all output types --- 1597 o T0, a time (start of measurement interval, 128-bit NTP Date 1598 Format, see section 6 of [RFC5905]) 1600 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1601 see section 6 of [RFC5905]) 1603 7.4.2.1. Percentile95 1605 The 95th percentile SHALL be calculated using the conditional 1606 distribution of all packets with a finite value of One-way delay 1607 (undefined delays are excluded), a single value as follows: 1609 See section 4.1 of [RFC3393] for details on the conditional 1610 distribution to exclude undefined values of delay, and Section 5 of 1611 [RFC6703] for background on this analysis choice. 1613 See section 4.3 of [RFC3393] for details on the percentile statistic 1614 (where Round-trip delay should be substituted for "ipdv"). 1616 The percentile = 95. 1618 Data format is a 32-bit signed value, *similar to* the 32-bit short 1619 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1620 first 16 bits represent the *signed* integer number of seconds; the 1621 next 16 bits represent the fractional part of a second. 1623 7.4.2.2. Mean 1625 The mean SHALL be calculated using the conditional distribution of 1626 all packets with a finite value of One-way delay (undefined delays 1627 are excluded), a single value as follows: 1629 See section 4.1 of [RFC3393] for details on the conditional 1630 distribution to exclude undefined values of delay, and Section 5 of 1631 [RFC6703] for background on this analysis choice. 1633 See section 4.2.2 of [RFC6049] for details on calculating this 1634 statistic, and 4.2.3 of [RFC6049]. 1636 Data format is a 32-bit signed value, *similar to* the 32-bit short 1637 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1638 first 16 bits represent the *signed* integer number of seconds; the 1639 next 16 bits represent the fractional part of a second. 1641 7.4.2.3. Min 1643 The minimum SHALL be calculated using the conditional distribution of 1644 all packets with a finite value of One-way delay (undefined delays 1645 are excluded), a single value as follows: 1647 See section 4.1 of [RFC3393] for details on the conditional 1648 distribution to exclude undefined values of delay, and Section 5 of 1649 [RFC6703] for background on this analysis choice. 1651 See section 4.3.2 of [RFC6049] for details on calculating this 1652 statistic, and 4.3.3 of [RFC6049]. 1654 Data format is a 32-bit signed value, *similar to* the 32-bit short 1655 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1656 first 16 bits represent the *signed* integer number of seconds; the 1657 next 16 bits represent the fractional part of a second. 1659 7.4.2.4. Max 1661 The maximum SHALL be calculated using the conditional distribution of 1662 all packets with a finite value of One-way delay (undefined delays 1663 are excluded), a single value as follows: 1665 See section 4.1 of [RFC3393] for details on the conditional 1666 distribution to exclude undefined values of delay, and Section 5 of 1667 [RFC6703] for background on this analysis choice. 1669 See section 4.3.2 of [RFC6049] for a closely related method for 1670 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1671 as follows: 1673 Max = (FiniteDelay [j]) 1675 such that for some index, j, where 1 <= j <= N 1676 FiniteDelay[j] >= FiniteDelay[n] for all n 1678 Data format is a 32-bit signed value, *similar to* the 32-bit short 1679 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1680 first 16 bits represent the *signed* integer number of seconds; the 1681 next 16 bits represent the fractional part of a second. 1683 7.4.2.5. Std_Dev 1685 7.4.3. Reference 1687 1689 See the Data Format column for references. 1691 7.4.4. Metric Units 1693 . 1696 The of One-way Delay is expressed in seconds. 1698 The 95th Percentile of One-way Delay is expressed in seconds. 1700 7.5. Administrative items 1702 7.5.1. Status 1704 1706 7.5.2. Requestor (keep?) 1708 name or RFC, etc. 1710 7.5.3. Revision 1712 1.0 1714 7.5.4. Revision Date 1716 YYYY-MM-DD 1718 7.6. Comments and Remarks 1720 Additional (Informational) details for this entry 1722 8. UDP Periodic One-way Delay Registry Entries 1724 This section gives an initial registry entry for the UDP Periodic 1725 One-way Delay. 1727 Note: Each Registry "Name" below specifies a single registry entry, 1728 whose output format varies according to a component of the name that 1729 specifies one form of statistical summary. 1731 IANA is asked to assign a different numeric identifiers to each Name. 1732 All other column entries are the same, thus this section is proposes 1733 five closely-related registry entries. As a result, IANA is also 1734 asked to assign corresponding URIs and URLs. 1736 8.1. Summary 1738 This category includes multiple indexes to the registry entries, the 1739 element ID and metric name. 1741 8.1.1. ID (Identifier) 1743 1746 8.1.2. Name 1748 1750 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_ 1752 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Percentile95 1754 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Mean 1756 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Min 1758 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Max 1760 Act_IP_UDP_Periodic-var_UDP-Payload-142_One-way_Delay_Std_Dev 1762 8.1.3. URI and URL 1764 URI: Prefix urn:ietf:params:performance:metric... 1766 URL: http:\\www.iana.org\ ... 1768 8.1.4. Description 1770 This metric assesses the delay of a stream of packets exchanged 1771 between two hosts (or measurement points), and reports the 1772 One-way delay for all successfully exchanged packets 1773 based on their conditional delay distribution. 1775 8.2. Metric Definition 1777 This category includes columns to prompt the entry of all necessary 1778 details related to the metric definition, including the RFC reference 1779 and values of input factors, called fixed parameters. 1781 8.2.1. Reference Definition 1783 1785 Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric 1786 for IPPM", RFC 2679, September 1999. 1788 [RFC2679] 1790 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1791 6049, January 2011. 1793 [RFC6049] 1794 1796 Section 3.4 of [RFC2679] provides the reference definition of the 1797 singleton (single value) One-way delay metric. Section 4.4 of 1798 [RFC2679] provides the reference definition expanded to cover a 1799 multi-value sample. Note that terms such as singleton and sample are 1800 defined in Section 11 of [RFC2330]. 1802 Only successful packet transfers with finite delay are included in 1803 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1805 NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft- 1806 ietf-ippm-2679-bis-01. 1808 ANY other conditions, ... 1810 8.2.2. Fixed Parameters 1812 1816 Type-P: 1818 o IPv4 header values: 1820 * DSCP: set to 0 1822 * TTL set to 255 1824 * Protocol: Set to 17 (UDP) 1826 o UDP header values: 1828 * Checksum: the checksum must be calculated 1830 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1832 * Security features in use influence the number of Padding 1833 octets. 1835 * 142 octets total, including the TWAMP format 1837 Timeout, Tmax: 3 seconds 1839 8.3. Method of Measurement 1841 This category includes columns for references to relevant sections of 1842 the RFC(s) and any supplemental information needed to ensure an 1843 unambiguous methods for implementations. 1845 8.3.1. Reference Method 1847 1850 The methodology for this metric is defined as Type-P-One-way-Delay- 1851 Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of 1852 [RFC2679] using the Type-P and Timeout defined under Fixed 1853 Parameters. 1855 The method requires sequence numbers or other send-order information 1856 to be retained at the Src or included with each packet to dis- 1857 ambiguate packet reordering if it occurs. Sequence number is part of 1858 the TWAMP payload described under Fixed Parameters. 1860 8.3.2. Packet Generation Stream 1862 This section gives the details of the packet traffic which is the 1863 basis for measurement. In IPPM metrics, this is called the Stream, 1864 and can easily be dscribed by providing the list of stream 1865 parameters. 1867 1869 Section 3 of [RFC3432] prescribes the method for generating Periodic 1870 streams using associated parameters. 1872 o incT, the nominal duration of inter-packet interval, first bit to 1873 first bit 1875 o dT, the duration of the interval for allowed sample start times 1877 o T0, the actual start time 1879 NOTE: an initiation process with a number of control exchanges 1880 resulting in unpredictable start times (within a time interval) may 1881 be sufficient to avoid synchronization of periodic streams, and 1882 therefore a valid replacement for selecting a start time at random 1883 from a fixed interval. 1885 These stream parameters will be specified as Run-time parameters. 1887 8.3.3. Traffic Filtering (observation) Details 1889 NA 1891 8.3.4. Sampling Distribution 1893 NA 1895 8.3.5. Run-time Parameters and Data Format 1897 Run-time Parameters are input factors that must be determined, 1898 configured into the measurement system, and reported with the results 1899 for the context to be complete. 1901 1903 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1904 value for IPv6) 1906 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1907 value for IPv6) 1909 o T0, a time (start of measurement interval, 128-bit NTP Date 1910 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1911 start time is unspecified and Tf is to be interpreted as the 1912 Duration of the measurement interval. 1914 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1915 see section 6 of [RFC5905]), interpreted as the Duration of the 1916 measurement interval. 1918 o incT, the nominal duration of inter-packet interval, first bit to 1919 first bit 1921 o dT, the duration of the interval for allowed sample start times 1923 The format for incT and dT are the short format in [RFC5905] (32 1924 bits) and is as follows: the first 16 bits represent the integer 1925 number of seconds; the next 16 bits represent the fractional part of 1926 a second. 1928 >>> should Periodic run-time params be fixed instead? probably yes if 1929 modeling a specific version of tests. Note in the NAME, i.e. 1930 Poisson3.3 1932 8.3.6. Roles 1934 1936 Src - launches each packet and waits for return transmissions from 1937 Dst. This is the TWAMP Session-Sender. 1939 Dst - waits for each packet from Src and sends a return packet to 1940 Src. This is the TWAMP Session-Reflector. 1942 8.4. Output 1944 This category specifies all details of the Output of measurements 1945 using the metric. 1947 8.4.1. Type/Value (two diff terms used) 1949 1951 See subsection titles in Data Format for Types. 1953 8.4.2. Data Format 1955 1957 For all output types --- 1959 o T0, a time (start of measurement interval, 128-bit NTP Date 1960 Format, see section 6 of [RFC5905]) 1962 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1963 see section 6 of [RFC5905]) 1965 8.4.2.1. Percentile95 1967 The 95th percentile SHALL be calculated using the conditional 1968 distribution of all packets with a finite value of One-way delay 1969 (undefined delays are excluded), a single value as follows: 1971 See section 4.1 of [RFC3393] for details on the conditional 1972 distribution to exclude undefined values of delay, and Section 5 of 1973 [RFC6703] for background on this analysis choice. 1975 See section 4.3 of [RFC3393] for details on the percentile statistic 1976 (where Round-trip delay should be substituted for "ipdv"). 1978 The percentile = 95. 1980 Data format is a 32-bit signed value, *similar to* the 32-bit short 1981 NTP Time format in Section 6 of [RFC5905] and is as follows: the 1982 first 16 bits represent the *signed* integer number of seconds; the 1983 next 16 bits represent the fractional part of a second. 1985 8.4.2.2. Mean 1987 The mean SHALL be calculated using the conditional distribution of 1988 all packets with a finite value of One-way delay (undefined delays 1989 are excluded), a single value as follows: 1991 See section 4.1 of [RFC3393] for details on the conditional 1992 distribution to exclude undefined values of delay, and Section 5 of 1993 [RFC6703] for background on this analysis choice. 1995 See section 4.2.2 of [RFC6049] for details on calculating this 1996 statistic, and 4.2.3 of [RFC6049]. 1998 Data format is a 32-bit signed value, *similar to* the 32-bit short 1999 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2000 first 16 bits represent the *signed* integer number of seconds; the 2001 next 16 bits represent the fractional part of a second. 2003 8.4.2.3. Min 2005 The minimum SHALL be calculated using the conditional distribution of 2006 all packets with a finite value of One-way delay (undefined delays 2007 are excluded), a single value as follows: 2009 See section 4.1 of [RFC3393] for details on the conditional 2010 distribution to exclude undefined values of delay, and Section 5 of 2011 [RFC6703] for background on this analysis choice. 2013 See section 4.3.2 of [RFC6049] for details on calculating this 2014 statistic, and 4.3.3 of [RFC6049]. 2016 Data format is a 32-bit signed value, *similar to* the 32-bit short 2017 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2018 first 16 bits represent the *signed* integer number of seconds; the 2019 next 16 bits represent the fractional part of a second. 2021 8.4.2.4. Max 2023 The maximum SHALL be calculated using the conditional distribution of 2024 all packets with a finite value of One-way delay (undefined delays 2025 are excluded), a single value as follows: 2027 See section 4.1 of [RFC3393] for details on the conditional 2028 distribution to exclude undefined values of delay, and Section 5 of 2029 [RFC6703] for background on this analysis choice. 2031 See section 4.3.2 of [RFC6049] for a closely related method for 2032 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2033 as follows: 2035 Max = (FiniteDelay [j]) 2037 such that for some index, j, where 1 <= j <= N 2038 FiniteDelay[j] >= FiniteDelay[n] for all n 2040 Data format is a 32-bit signed value, *similar to* the 32-bit short 2041 NTP Time format in Section 6 of [RFC5905] and is as follows: the 2042 first 16 bits represent the *signed* integer number of seconds; the 2043 next 16 bits represent the fractional part of a second. 2045 8.4.2.5. Std_Dev 2047 8.4.3. Reference 2049 2051 See the Data Format column for references. 2053 8.4.4. Metric Units 2055 . 2058 The of One-way Delay is expressed in seconds. 2060 8.5. Administrative items 2062 8.5.1. Status 2064 2066 8.5.2. Requestor (keep?) 2068 name or RFC, etc. 2070 8.5.3. Revision 2072 1.0 2074 8.5.4. Revision Date 2076 YYYY-MM-DD 2078 8.6. Comments and Remarks 2080 Additional (Informational) details for this entry 2082 9. partly BLANK Registry Entry 2084 This section gives an initial registry entry for .... 2086 9.1. Summary 2088 This category includes multiple indexes to the registry entries, the 2089 element ID and metric name. 2091 2093 9.1.1. ID (Identifier) 2095 2097 9.1.2. Name 2099 2101 URL: ?? 2103 9.1.3. URI 2105 URI: Prefix urn:ietf:params:performance:metric 2107 9.1.4. Description 2109 TBD. 2111 9.2. Metric Definition 2113 This category includes columns to prompt the entry of all necessary 2114 details related to the metric definition, including the RFC reference 2115 and values of input factors, called fixed parameters. 2117 9.2.1. Reference Definition 2119 2120 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2121 Metric for IPPM", RFC 2681, September 1999. 2123 2125 Section 2.4 of [RFC2681] provides the reference definition of the 2126 singleton (single value) Round-trip delay metric. Section 3.4 of 2127 [RFC2681] provides the reference definition expanded to cover a 2128 multi-value sample. Note that terms such as singleton and sample are 2129 defined in Section 11 of [RFC2330]. 2131 Note that although the definition of "Round-trip-Delay between Src 2132 and Dst at T" is directionally ambiguous in the text, this metric 2133 tightens the definition further to recognize that the host in the 2134 "Src" role will send the first packet to "Dst", and ultimately 2135 receive the corresponding return packet from "Dst" (when neither are 2136 lost). 2138 <<< Check how the Methodology also makes this clear (or not) >>> 2140 9.2.2. Fixed Parameters 2142 2146 Type-P: 2148 o IPv4 header values: 2150 * DSCP: set to 0 2152 * TTL set to 255 2154 * Protocol: Set to 17 (UDP) 2156 o UDP header values: 2158 * Checksum: the checksum must be calculated 2160 o Payload 2162 * Sequence number: 8-byte integer 2164 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 2165 as per section 6 of RFC 5905 [RFC5905] 2167 * No padding (total of 9 bytes) 2169 Timeout: 3 seconds 2171 9.3. Method of Measurement 2173 This category includes columns for references to relevant sections of 2174 the RFC(s) and any supplemental information needed to ensure an 2175 unambiguous methods for implementations. 2177 9.3.1. Reference Method 2179 2182 9.3.2. Packet Generation Stream 2184 This section gives the details of the packet traffic which is the 2185 basis for measurement. In IPPM metrics, this is called the Stream, 2186 and can easily be dscribed by providing the list of stream 2187 parameters. 2189 2191 9.3.3. Traffic Filtering (observation) Details 2193 The measured results based on a filtered version of the packets 2194 observed, and this section provides the filter details (when 2195 present). 2197
. 2199 9.3.4. Sampling Distribution 2201 2204 9.3.5. Run-time Parameters and Data Format 2206 Run-time Parameters are input factors that must be determined, 2207 configured into the measurement system, and reported with the results 2208 for the context to be complete. 2210 2212 . 2214 9.3.6. Roles 2216 2218 9.4. Output 2220 This category specifies all details of the Output of measurements 2221 using the metric. 2223 9.4.1. Type/Value (two diff terms used) 2225 2227 9.4.2. Data Format 2229 2231 o Value: 2233 o Data Format: (There may be some precedent to follow here, but 2234 otherwise use 64-bit NTP Timestamp Format, see section 6 of 2235 [RFC5905]). 2237 o Reference:
2239 9.4.3. Reference 2241 2243 9.4.4. Metric Units 2245 . 2248 9.5. Administrative items 2250 9.5.1. Status 2252 2254 9.5.2. Requestor (keep?) 2256 name or RFC, etc. 2258 9.5.3. Revision 2260 1.0 2262 9.5.4. Revision Date 2264 YYYY-MM-DD 2266 9.6. Comments and Remarks 2268 Additional (Informational) details for this entry 2270 10. BLANK Registry Entry 2272 This section gives an initial registry entry for .... 2274 10.1. Summary 2276 This category includes multiple indexes to the registry entries, the 2277 element ID and metric name. 2279 2281 10.1.1. ID (Identifier) 2283 2285 10.1.2. Name 2287 2289 URL: ?? 2291 10.1.3. URI 2293 URI: Prefix urn:ietf:params:performance:metric 2295 10.1.4. Description 2297 TBD. 2299 10.2. Metric Definition 2301 This category includes columns to prompt the entry of all necessary 2302 details related to the metric definition, including the RFC reference 2303 and values of input factors, called fixed parameters. 2305 10.2.1. Reference Definition 2307 2309 2311 10.2.2. Fixed Parameters 2313 2317 10.3. Method of Measurement 2319 This category includes columns for references to relevant sections of 2320 the RFC(s) and any supplemental information needed to ensure an 2321 unambiguous methods for implementations. 2323 10.3.1. Reference Method 2325 2328 10.3.2. Packet Generation Stream 2330 2332 10.3.3. Traffic Filtering (observation) Details 2334 . 2338 10.3.4. Sampling Distribution 2340 2343 10.3.5. Run-time Parameters and Data Format 2345 . 2347 10.3.6. Roles 2349 2351 10.4. Output 2353 This category specifies all details of the Output of measurements 2354 using the metric. 2356 10.4.1. Type/Value (two diff terms used) 2358 2360 10.4.2. Data Format 2362 2364 10.4.3. Reference 2366 2368 10.4.4. Metric Units 2370 . 2373 10.5. Administrative items 2375 10.5.1. Status 2377 2379 10.5.2. Requestor (keep?) 2381 2383 10.5.3. Revision 2385 1.0 2387 10.5.4. Revision Date 2389 YYYY-MM-DD 2391 10.6. Comments and Remarks 2393 Additional (Informational) details for this entry 2395 11. Example RTCP-XR Registry Entry 2397 This section is MAY BE DELETED or adapted before submission. 2399 This section gives an example registry entry for the end-point metric 2400 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 2401 reporting. 2403 11.1. Registry Indexes 2405 This category includes multiple indexes to the registry entries, the 2406 element ID and metric name. 2408 11.1.1. Identifier 2410 An integer having enough digits to uniquely identify each entry in 2411 the Registry. 2413 11.1.2. Name 2415 A metric naming convention is TBD. 2417 11.1.3. URI 2419 Prefix urn:ietf:params:performance:metric 2421 11.1.4. Status 2423 current 2425 11.1.5. Requestor 2427 Alcelip Mornuley 2429 11.1.6. Revision 2431 1.0 2433 11.1.7. Revision Date 2435 2014-07-04 2437 11.1.8. Description 2439 TBD. 2441 11.1.9. Reference Specification(s) 2443 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 2445 11.2. Metric Definition 2447 This category includes columns to prompt the entry of all necessary 2448 details related to the metric definition, including the RFC reference 2449 and values of input factors, called fixed parameters. Section 3.2 of 2450 [RFC7003] provides the reference information for this category. 2452 11.2.1. Reference Definition 2454 Packets Discarded in Bursts: 2456 The total number of packets discarded during discard bursts. The 2457 measured value is unsigned value. If the measured value exceeds 2458 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 2459 range measurement. If the measurement is unavailable, the value 2460 0xFFFFFF MUST be reported. 2462 11.2.2. Fixed Parameters 2464 Fixed Parameters are input factors that must be determined and 2465 embedded in the measurement system for use when needed. The values 2466 of these parameters is specified in the Registry. 2468 Threshold: 8 bits, set to value = 3 packets. 2470 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 2471 successive packets that must not be discarded prior to and following 2472 a discard packet in order for this discarded packet to be regarded as 2473 part of a gap. Note that the Threshold is set in accordance with the 2474 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 2476 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 2478 This field is used to indicate whether the burst/gap discard metrics 2479 are Sampled, Interval, or Cumulative metrics [RFC6792]: 2481 I=10: Interval Duration - the reported value applies to the most 2482 recent measurement interval duration between successive metrics 2483 reports. 2485 I=11: Cumulative Duration - the reported value applies to the 2486 accumulation period characteristic of cumulative measurements. 2488 Senders MUST NOT use the values I=00 or I=01. 2490 11.3. Method of Measurement 2492 This category includes columns for references to relevant sections of 2493 the RFC(s) and any supplemental information needed to ensure an 2494 unambiguous methods for implementations. For the Burst/Gap Discard 2495 Metric, it appears that the only guidance on methods of measurement 2496 is in Section 3.0 of [RFC7003] and its supporting references. 2497 Relevant information is repeated below, although there appears to be 2498 no section titled "Method of Measurement" in [RFC7003]. 2500 11.3.1. Reference Method 2502 Metrics in this block report on burst/gap discard in the stream 2503 arriving at the RTP system. Measurements of these metrics are made 2504 at the receiving end of the RTP stream. Instances of this metrics 2505 block use the synchronization source (SSRC) to refer to the separate 2506 auxiliary Measurement Information Block [RFC6776], which describes 2507 measurement periods in use (see [RFC6776], Section 4.2). 2509 This metrics block relies on the measurement period in the 2510 Measurement Information Block indicating the span of the report. 2511 Senders MUST send this block in the same compound RTCP packet as the 2512 Measurement Information Block. Receivers MUST verify that the 2513 measurement period is received in the same compound RTCP packet as 2514 this metrics block. If not, this metrics block MUST be discarded. 2516 11.3.2. Stream Type and Stream Parameters 2518 Since RTCP-XR Measurements are conducted on live RTP traffic, the 2519 complete description of the stream is contained in SDP messages that 2520 proceed the establishment of a compatible stream between two or more 2521 communicating hosts. See Run-time Parameters, below. 2523 11.3.3. Output Type and Data Format 2525 The output type defines the type of result that the metric produces. 2527 o Value: Packets Discarded in Bursts 2529 o Data Format: 24 bits 2531 o Reference: Section 3.2 of [RFC7003] 2533 11.3.4. Metric Units 2535 The measured results are apparently expressed in packets, although 2536 there is no section of [RFC7003] titled "Metric Units". 2538 11.3.5. Run-time Parameters and Data Format 2540 Run-Time Parameters are input factors that must be determined, 2541 configured into the measurement system, and reported with the results 2542 for the context to be complete. However, the values of these 2543 parameters is not specified in the Registry, rather these parameters 2544 are listed as an aid to the measurement system implementor or user 2545 (they must be left as variables, and supplied on execution). 2547 The Data Format of each Run-time Parameter SHALL be specified in this 2548 column, to simplify the control and implementation of measurement 2549 devices. 2551 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 2553 SDP Parameters: As defined in [RFC4566] 2555 Session description v= (protocol version number, currently only 0) 2557 o= (originator and session identifier : username, id, version number, 2558 network address) 2560 s= (session name : mandatory with at least one UTF-8-encoded 2561 character) 2563 i=* (session title or short information) u=* (URI of description) 2565 e=* (zero or more email address with optional name of contacts) 2567 p=* (zero or more phone number with optional name of contacts) 2569 c=* (connection information--not required if included in all media) 2571 b=* (zero or more bandwidth information lines) One or more Time 2572 descriptions ("t=" and "r=" lines; see below) 2574 z=* (time zone adjustments) 2576 k=* (encryption key) 2578 a=* (zero or more session attribute lines) 2580 Zero or more Media descriptions (each one starting by an "m=" line; 2581 see below) 2583 m= (media name and transport address) 2585 i=* (media title or information field) 2586 c=* (connection information -- optional if included at session level) 2588 b=* (zero or more bandwidth information lines) 2590 k=* (encryption key) 2592 a=* (zero or more media attribute lines -- overriding the Session 2593 attribute lines) 2595 An example Run-time SDP description follows: 2597 v=0 2599 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 2601 s=SDP Seminar i=A Seminar on the session description protocol 2603 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 2604 Doe) 2606 c=IN IP4 233.252.0.12/127 2608 t=2873397496 2873404696 2610 a=recvonly 2612 m=audio 49170 RTP/AVP 0 2614 m=video 51372 RTP/AVP 99 2616 a=rtpmap:99 h263-1998/90000 2618 11.4. Comments and Remarks 2620 TBD. 2622 12. Revision History 2624 This section may be removed for publication. It contains partial 2625 information on updtes. 2627 This draft replaced draft-mornuley-ippm-initial-registry. 2629 In version 02, Section 4 has been edited to reflect recent discussion 2630 on the ippm-list: * Removed the combination or "Raw" and left 95th 2631 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 2632 use bullet lists and other indenting formats. * Payload format for 2633 measurement has been removed. * Explanation of Conditional delay 2634 distribution. 2636 Version 03 addressed Phil Eardley's comments and suggestions in 2637 sections 1-4. and resolved the definition of Percentiles. 2639 Version 04 * All section 4 parameters reference YANG types for 2640 alternate data formats. * Discussion has concluded that usecase(s) 2641 for machine parse-able registry columns are not needed. 2643 Still need: * suggestion of standard naming format for parameters. 2645 Note: lambda parameter description is correct in section 4, elsewhere 2646 needs fix. 2648 13. Security Considerations 2650 These registry entries represent no known security implications for 2651 Internet Security. Each referenced Metric contains a Security 2652 Considerations section. 2654 14. IANA Considerations 2656 IANA is requested to populate The Performance Metric Registry defined 2657 in [I-D.ietf-ippm-metric-registry] with the values defined above. 2659 2661 15. Acknowledgements 2663 The authors thank Brian Trammell for suggesting the term "Run-time 2664 Parameters", which led to the distinction between run-time and fixed 2665 parameters implemented in this memo, for identifying the IPFIX metric 2666 with Flow Key as an example, and for many other productive 2667 suggestions. Thanks to Peter Koch, who provided several useful 2668 suggestions for disambiguating successive DNS Queries in the DNS 2669 Response time metric. 2671 The authors also acknowledge the constructive reviews and helpful 2672 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 2673 participants in the LMAP working group. 2675 16. References 2676 16.1. Normative References 2678 [I-D.ietf-ippm-metric-registry] 2679 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 2680 "Registry for Performance Metrics", Internet Draft (work 2681 in progress) draft-ietf-ippm-metric-registry, 2014. 2683 [RFC1035] Mockapetris, P., "Domain names - implementation and 2684 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2685 November 1987, . 2687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2688 Requirement Levels", BCP 14, RFC 2119, 2689 DOI 10.17487/RFC2119, March 1997, 2690 . 2692 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2693 "Framework for IP Performance Metrics", RFC 2330, 2694 DOI 10.17487/RFC2330, May 1998, 2695 . 2697 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2698 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 2699 September 1999, . 2701 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2702 Packet Loss Metric for IPPM", RFC 2680, 2703 DOI 10.17487/RFC2680, September 1999, 2704 . 2706 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2707 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 2708 September 1999, . 2710 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2711 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2712 . 2714 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2715 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2716 DOI 10.17487/RFC3393, November 2002, 2717 . 2719 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2720 performance measurement with periodic streams", RFC 3432, 2721 DOI 10.17487/RFC3432, November 2002, 2722 . 2724 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2725 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2726 DOI 10.17487/RFC4737, November 2006, 2727 . 2729 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2730 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2731 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2732 . 2734 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2735 "Network Time Protocol Version 4: Protocol and Algorithms 2736 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2737 . 2739 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2740 the Network Configuration Protocol (NETCONF)", RFC 6020, 2741 DOI 10.17487/RFC6020, October 2010, 2742 . 2744 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 2745 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 2746 . 2748 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 2749 DOI 10.17487/RFC6673, August 2012, 2750 . 2752 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2753 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2754 . 2756 16.2. Informative References 2758 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 2759 Distributions", March 2000. 2761 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 2762 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 2763 July 1991, . 2765 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 2766 "RTP Control Protocol Extended Reports (RTCP XR)", 2767 RFC 3611, DOI 10.17487/RFC3611, November 2003, 2768 . 2770 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2771 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2772 2005, . 2774 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2775 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2776 July 2006, . 2778 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 2779 Flow Information Export (IPFIX) Applicability", RFC 5472, 2780 DOI 10.17487/RFC5472, March 2009, 2781 . 2783 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 2784 Carle, "Information Model for Packet Sampling Exports", 2785 RFC 5477, DOI 10.17487/RFC5477, March 2009, 2786 . 2788 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 2789 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 2790 March 2009, . 2792 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 2793 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 2794 DOI 10.17487/RFC6248, April 2011, 2795 . 2797 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 2798 Performance Metric Development", BCP 170, RFC 6390, 2799 DOI 10.17487/RFC6390, October 2011, 2800 . 2802 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 2803 IP Network Performance Metrics: Different Points of View", 2804 RFC 6703, DOI 10.17487/RFC6703, August 2012, 2805 . 2807 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 2808 Reporting Using a Source Description (SDES) Item and an 2809 RTCP Extended Report (XR) Block", RFC 6776, 2810 DOI 10.17487/RFC6776, October 2012, 2811 . 2813 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 2814 of the RTP Monitoring Framework", RFC 6792, 2815 DOI 10.17487/RFC6792, November 2012, 2816 . 2818 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 2819 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 2820 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 2821 September 2013, . 2823 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 2824 Aitken, P., and A. Akhter, "A Framework for Large-Scale 2825 Measurement of Broadband Performance (LMAP)", RFC 7594, 2826 DOI 10.17487/RFC7594, September 2015, 2827 . 2829 Authors' Addresses 2831 Al Morton 2832 AT&T Labs 2833 200 Laurel Avenue South 2834 Middletown,, NJ 07748 2835 USA 2837 Phone: +1 732 420 1571 2838 Fax: +1 732 368 1192 2839 Email: acmorton@att.com 2840 URI: http://home.comcast.net/~acmacm/ 2842 Marcelo Bagnulo 2843 Universidad Carlos III de Madrid 2844 Av. Universidad 30 2845 Leganes, Madrid 28911 2846 SPAIN 2848 Phone: 34 91 6249500 2849 Email: marcelo@it.uc3m.es 2850 URI: http://www.it.uc3m.es 2852 Philip Eardley 2853 BT 2854 Adastral Park, Martlesham Heath 2855 Ipswich 2856 ENGLAND 2858 Email: philip.eardley@bt.com 2859 Kevin D'Souza 2860 AT&T Labs 2861 200 Laurel Avenue South 2862 Middletown,, NJ 07748 2863 USA 2865 Phone: +1 732 420 xxxx 2866 Email: kld@att.com