idnits 2.17.1 draft-ietf-ippm-multimetrics-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2306. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 83 has weird spacing: '...segment using...' == Line 968 has weird spacing: '...segment using...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2008) is 5782 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) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet-Draft France Telecom 4 Intended status: Standards Track L. Liang 5 Expires: December 28, 2008 University of Surrey 6 A. Morton 7 AT&T Labs 8 June 26, 2008 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 28, 2008. 38 Abstract 40 The IETF IP Performance Metrics (IPPM) working group has standardized 41 metrics for measuring end-to-end performance between two points. 42 This memo defines two new categories of metrics that extend the 43 coverage to multiple measurement points. It defines spatial metrics 44 for measuring the performance of segments of a source to destination 45 path, and metrics for measuring the performance between a source and 46 many destinations in multiparty communications (e.g., a multicast 47 tree). 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 7 62 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 7 63 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 64 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 65 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 69 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 70 3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 71 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 72 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 73 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 74 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 14 75 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16 76 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 17 77 5.1. A Definition of a sample of One-way Delay of a segment 78 of the path . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.2. A Definition of a sample of Packet Loss of a segment 80 of the path . . . . . . . . . . . . . . . . . . . . . . . 19 81 5.3. A Definition of a sample of ipdv of a segment using 82 the previous packet selection function . . . . . . . . . . 20 83 5.4. A Definition of a sample of ipdv of a segment using 84 the minimum delay selection function . . . . . . . . . . . 22 85 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 86 6.1. A Definition for One-to-group One-way Delay . . . . . . . 23 87 6.2. A Definition for One-to-group One-way Packet Loss . . . . 24 88 6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 25 89 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26 90 7.1. Discussion on the Impact of packet loss on statistics . . 28 91 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 29 92 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 30 93 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 32 94 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 34 95 8. Measurement Methods: Scalability and Reporting . . . . . . . . 35 96 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36 97 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37 98 8.3. Effect of Time and Space Aggregation Order on Stats . . . 37 99 9. Manageability Considerations . . . . . . . . . . . . . . . . . 38 100 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39 101 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40 102 9.3. Metric identification . . . . . . . . . . . . . . . . . . 40 103 9.4. Information model . . . . . . . . . . . . . . . . . . . . 41 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 105 10.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 43 106 10.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 43 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 48 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 49 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 113 Intellectual Property and Copyright Statements . . . . . . . . . . 50 115 1. Introduction 117 The IETF IP Performance Metrics (IPPM) working group has standardized 118 metrics for measuring end-to-end performance between two points. 119 This memo defines two new categories of metrics that extend the 120 coverage to multiple measurement points. It defines spatial metrics 121 for measuring the performance of segments of a source to destination 122 path, and metrics for measuring the performance between a source and 123 many destinations in multiparty communications (e.g., a multicast 124 tree). 126 The purpose of the memo is to define metrics to fulfill the new 127 requirements of measurement involving multiple measurement points. 128 Spatial metrics are defined to measure the performance of each 129 segments along a path while the one-to-group metrics are aiming to 130 provide a ruler to measure the performance of a group of users. 131 These metrics are derived from one-way end-to-end metrics defined by 132 IETF and follow the criteria described in the IPPM framework 133 [RFC2330]. 135 New terms are introduced to extend the terminology of the IPPM 136 framework to spatial metrics and one-to-group metrics. Then a 137 section motivates the need of defining each category of metrics. 138 After, each category is defined in a separate section. Then the memo 139 discusses the impact of the measurement methods on the scalability 140 and proposes an information model for reporting the measurements. 141 Finally the document discusses security aspects related to 142 measurement and registers the metrics in the IANA IP Performance 143 Metrics Registry [RFC4148]. 145 Note that all these metrics are based on observations of packets 146 dedicated to testing, a process which is called Active measurement. 147 Purely passive spatial measurement (for example, a spatial metric 148 based on the observation of user traffic) is beyond the scope of this 149 memo. 151 Following is a summary of the metrics defined. 153 This memo firstly defines metrics for spatial measurement based on 154 the decomposition of standard end-to-end metrics defined by IETF in 155 [[RFC2679], [RFC2680], [RFC3393], [RFC3432]. Seven metrics are 156 defined including their names, parameters, units and measurement 157 methodologies. Each definion includes a specific section discussing 158 measurements constraints and issues, and proposing guidance to 159 increase results accucacy. These spatial metrics are: 160 o A 'Vector', called Type-P-Spatial-One-way-Delay-Vector, will be 161 introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679] 162 into a spatial sequence of one-way delay metrics. 164 o A 'Vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 165 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 166 [RFC2680] in a spatial sequence of packet loss metrics. 167 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector', 168 called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to 169 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of 170 ipdv metrics. 171 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 172 called Type-P-Segment-One-way-Delay-Stream, will be introduced to 173 collect one-way delay metrics over time between two points of 174 interest of the path; 175 o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', 176 called Type-P-Segment-Packet-Loss-Stream, will be introduced to 177 collect packet loss metrics over time between two points of 178 interest of the path; 179 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 180 called Type-P-Segment-ipdv-prev-Stream, will be introduced to 181 compute ipdv metrics over time between two points of interest of 182 the path using the previous packet selection function; 183 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 184 called Type-P-Segment-ipdv-min-Stream, will be introduced to 185 compute ipdv metrics over time between two points of interest of 186 the path using the shortest delay selection function; 188 Then the memo defines one-to-group metrics and one-to-group 189 statistics. 191 Three one-to-group metrics are defined to measure the one-way 192 performance between a source and a group of receivers. Definitions 193 derive from one-way metrics definitions of RFCs in [RFC2679], 194 [RFC2680], [RFC3393], [RFC3432]: 195 o A 'Vector', called Type-P-One-to-Group-One-way-Delay-Vector, will 196 be introduced to collect the set of Type-P-one-way-delay 197 singletons between one sender and N receivers; 198 o A 'Vector', called Type-P-One-to-Group-One-way-Packet-Loss-Vector, 199 will be introduced to collect the set of Type-P-One-way-Packet- 200 Loss singletons between one sender and N receivers; 201 o A 'Vector', called Type-P-One-to-Group-One-way-ipdv-Vector, will 202 be introduced to collect the set of Type-P-One-way-ipdv singletons 203 between one sender and N receivers. 205 Then, based on the One-to-group vector metrics listed above, 206 statistics are defined to capture single receiver performance, group 207 performance and relative performance situation inside a multiparty 208 communication for each packet sent during the test interval between 209 one sender and N receivers: 211 o Using the Type-P-One-to-Group-One-way-Delay-Vector, a metric 212 called Type-P-One-to-Group-Receiver-n-Mean-Delay will be 213 introduced to present the mean of delays between one sender and a 214 receiver 'n'. Then, based on this definition, 3 metrics will be 215 defined to characterize the mean delay over the entire group 216 during this interval: 217 * a metric called Type-P-One-to-Group-Mean-Delay, will be 218 introduced to present the mean of delays; 219 * a metric called Type-P-One-to-Group-Range-Mean-Delay will be 220 introduced to present the range of mean delays; 221 * a metric called Type-P-One-to-Group-Max-Mean-Delay will be 222 introduced to present the maximum of mean delays; 223 o Using the Type-P-one-to-group-One-way-Packet-Loss-Vector, a metric 224 called Type-P-One-to-Group-Receiver-n-Loss-Ratio will be 225 introduced to capture packet loss ratio between one sender and a 226 receiver 'n'. Then based on this definition, 2 metrics will be 227 defined to characterize packet loss over the entire group during 228 this interval: 229 * a metric called Type-P-One-to-Group-Loss-Ratio will be 230 introduced to capture packet loss ratio overall over the entire 231 group or all receivers; 232 * a metric called Type-P-One-to-Group-Range-Loss-Ratio will be 233 introduced to present comparative packet loss ratio for each 234 packet during the test interval between one sender and N 235 Receivers. 236 o Using Type-P-one-to-group-One-way-ipdv-Vector, a metric called 237 Type-P-One-to-Group-Range-Delay-Variation will be introduced to 238 present the range of delay variation between one sender and a 239 group of receivers. 241 2. Terminology 243 2.1. Path Digest Hosts 245 The list of the hosts on a path from the source to the destination. 247 2.2. Multiparty metric 249 A metric is said to be multiparty if the topology involves more than 250 one measurement collection point. All multiparty metrics define a 251 set of hosts called "points of interest", where one host is the 252 source and other hosts are the measurement collection points. For 253 example, if the set of points of interest is < ha, hb, hc, ..., hn >, 254 where ha is the source and < hb, hc, ..., hn > are the destinations, 255 then measurements may be conducted between < ha, hb>, < ha, hc>, ..., 256 . 258 For the purposes of this memo (reflecting the scope of a single 259 source), the only multiparty metrics are one-to-group metrics. 261 2.3. Spatial metric 263 A metric is said to be spatial if one of the hosts (measurement 264 collection points) involved is neither the source nor a destination 265 of the measured packet. 267 2.4. One-to-group metric 269 A metric is said to be one-to-group if the measured packet is sent by 270 one source and (potentially) received by several destinations. Thus, 271 the topology of the communication group can be viewed as a centre- 272 distributed or server-client topology with the source as the centre/ 273 server in the topology. 275 2.5. Points of interest 277 Points of interest are the hosts* (as per RFC2330 definition, that 278 includes routing nodes) that are measurement collection points, a 279 sub-set of the set of hosts involved in the delivery of the packets 280 (in addition to the source itself). Note that the points of interest 281 are a possibly arbitrary sub-set of all the hosts involved in the 282 path. 284 Points of interest of one-to-group metrics are the intended 285 destination hosts for packets from the source (in addition to the 286 source itself). 288 Src Recv 289 `. ,-. 290 `. ,' `...... 1 291 `. ; : 292 `. ; : 293 ; :... 2 294 | | 295 : ; 296 : ;.... 3 297 : ; 298 `. ,' 299 `-'....... N 301 Figure 1: One-to-group points of interest 303 A candidate point of interest for spatial metrics is a host from the 304 set of hosts involved in the delivery of the packets from the source. 306 Src ------. Hosts 307 \ 308 `---X ... 1 309 \ 310 x 311 / 312 .---------X .... 2 313 / 314 x 315 \ 316 `---X .... 3 317 \ 318 \ 319 \ 320 X .... N 321 \ 322 \ 323 \ 324 `---- Dst 326 Note: 'x' are nodes which are not points of interest 328 Figure 2: Spatial points of interest 330 2.6. Reference point 332 A reference point is defined as the server where the statistical 333 calculations will be carried out. A centre/server in the 334 multimetrics measurement that is controlled by a network operator is 335 a good example of a reference point, where measurement data can be 336 collected for further processing. However, the actual measurements 337 have to be carried out at all points of interest. 339 2.7. Vector 341 A Vector is a set of singletons, which are a set of results of the 342 observation of the behaviour of the same packet at different places 343 of a network at different times. For instance, if one-way delay 344 singletons observed at N receivers for Packet P sent by the source 345 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 346 elements can be organized as {dT1, dT2,..., dTN}. The elements in 347 one vector are singletons distinct with each other in terms of both 348 measurement point and sending time. Given the vector V as an 349 example, the element dT1 is distinct from all others as the singleton 350 at receiver 1 in response to a packet sent from the source at time 351 T1. The complete Vector gives information over the dimension of 352 space. 354 2.8. Matrix 356 Several vectors form a Matrix, which contains results observed in a 357 sampling interval at different places in a network at different 358 times. For instance, given One-way delay vectors V1={dT11, dT12,..., 359 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 360 Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, 361 V2,...,Vm}. Additional to the information given by a Vector, a 362 Matrix is more powerful to present network performance in both space 363 and time dimensions. It normally corresponds to a sample in simple 364 point-to-point measurement. 366 The relation among Singleton, Vector and Matrix can be shown in the 367 following Figure 3. 369 Point of Singleton 370 interest / Samples 371 ,----. ^ / 372 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 373 / \ | | | 374 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 375 Src | || | | 376 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 377 | || | | 378 : ;| | | 379 \ / | | | 380 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 381 `-----' +-------------------------------------> time 383 Vector Matrix 384 (space) (time) 386 Figure 3: Relation beween Singletons, vectors and matrix 388 3. Motivations 390 All IPPM metrics are defined for end-to-end (source to destination) 391 measurement of point-to-point paths. It is a logical extension to 392 define metrics for multiparty measurements such as one to one 393 trajectory metrics and one to multipoint metrics. 395 3.1. Motivations for spatial metrics 397 Decomposition of instantaneous end-to-end measures is needed: 398 o Decomposing the performance of interdomain path is desirable to 399 quantify the per-AS contribution to the performance. It is 400 valuable to define standard spatial metrics before pursuing inter- 401 domain path performance specifications. 402 o Traffic engineering and troubleshooting applications benefit from 403 spatial views of one-way delay and ipdv consumption, and 404 identification of the location of the lost of packets. 405 o Monitoring the performance of a multicast tree composed of MPLS 406 point-to-multipoint and inter-domain communication require spatial 407 decomposition of the one-way delay, ipdv, and packet loss. 408 o Composition of metrics is needed to help measurement systems reach 409 large scale coverage. Spatial measures typically give the 410 individual performance of an intra domain segment and provide an 411 elementary piece of information needed to estimate interdomain 412 performance based on composition of metrics. 414 3.2. Motivations for One-to-group metrics 416 While the node-to-node based spatial measures can provide very useful 417 data in the view of each connection, we also need measures to present 418 the performance of a multiparty communication topology. A simple 419 one-way metric cannot completely describe the multiparty situation. 420 New one-to-group metrics assess performance of all the paths for 421 further statistical analysis. The new metrics proposed in this stage 422 are named one-to-group performance metrics, and they are based on the 423 unicast metrics defined in IPPM WG. One-to-group metrics are one-way 424 metrics from one source to a group of destinations. The metrics are 425 helpful for judging the network performance of multiparty 426 communications and can also be used to describe the variation of 427 performance delivered to a group of destination hosts and their 428 users. 430 One-to-group performance metrics are needed for several reasons: 432 o For designing and engineering multicast trees and MPLS point-to- 433 multipoint LSP; 434 o For evaluating and controlling of the quality of the multicast 435 services; 436 o For controlling the performance of the inter domain multicast 437 services; 438 o For presenting and evaluating the performance requirements for 439 multiparty communications and overlay multicast. 440 To understand the packet transfer performance between one source and 441 any one receiver in the multiparty communication group, we need to 442 collect instantaneous end-to-end metrics, or singletons. It will 443 give a very detailed insight into each branch of the multicast tree 444 in terms of end-to-end absolute performance. This detail can provide 445 clear and helpful information for engineers to identify the sub-path 446 with problems in a complex multiparty routing tree. 448 The one-to-group metrics described in this memo introduce the 449 multiparty topology to the IPPM working group; the goal is to measure 450 the performance delivered to a group of users who are receiving 451 packets from the same source. The concept extends the "path" in the 452 one-way measurement to "path tree" to cover both one-to-one and one- 453 to-many communications. If applied to one-to-one communications, the 454 one-to-group metrics provide exactly the same results as the 455 corresponding one-to-one metrics. 457 3.3. Discussion on Group-to-one and Group-to-group metrics 459 We note that points of interest can also be selected to define 460 measurements on group-to-one and group-to-group topologies. These 461 topologies are currently beyond the scope of this memo, because they 462 would involve multiple packets launched from different sources. 463 However, we can give some clues here on these two cases. 465 The measurements for group-to-one topology can be easily derived from 466 the one-to-group measurement. The measurement point is the reference 467 point that is acting as a receiver while all of clients/receivers 468 defined for one-to-group measurement act as sources in this case. 470 For the group-to-group connection topology, it is difficult to define 471 the reference point and therefore it is difficult to define the 472 measurement points. However, we can always avoid this confusion by 473 treating the connections as one-to-group or group-to-one in our 474 measurements without consideration on how the real communication will 475 be carried out. For example, if one group of hosts < ha, hb, hc, 476 ..., hn > are acting as sources to send data to another group of 477 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 478 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 479 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 480 ..., Hm >. 482 4. Spatial vectors metrics definitions 484 This section defines vectors for the decomposition of end-to-end 485 singleton metrics over a path. 487 Spatial vectors metrics are based on the decomposition of standard 488 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 489 [RFC3393] and [RFC3432]. 491 Definitions are coupled with the corresponding end-to-end metrics. 492 Methodology specificities are common to all the vectors defined and 493 are consequently discussed in a common section. 495 4.1. A Definition for Spatial One-way Delay Vector 497 This section is coupled with the definition of Type-P-One-way-Delay 498 of the section 3 of [RFC2679]. When a parameter of this definition 499 is first used in this section, it will be tagged with a trailing 500 asterisk. 502 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 503 statements for end-to-end one-way-delay measurements. They are 504 applicable to each point of interest Hi involved in the measure. 505 Spatial one-way-delay measurement SHOULD be respectful of them, 506 especially those related to methodology, clock, uncertainties and 507 reporting. 509 4.1.1. Metric Name 511 Type-P-Spatial-One-way-Delay-Vector 513 4.1.2. Metric Parameters 515 o Src*, the IP address of the sender. 516 o Dst*, the IP address of the receiver. 517 o i, An integer in the ordered list <1,2,...,n> of hosts in the 518 path. 519 o Hi, A host* of the path digest. 520 o T*, a time, the sending (or initial observation) time for a 521 measured packet. 522 o dT*, a delay, the one-way delay for a measured packet. 523 o a list of delay. 524 o P*, the specification of the packet type. 525 o , hosts path digest. 527 4.1.3. Metric Units 529 The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of 530 times. 532 4.1.4. Definition 534 Given a Type-P packet sent by the sender Src at wire-time (first bit) 535 T to the receiver Dst in the path . Given the 536 sequence of values such that dT is the 537 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 538 path, T+dTi is either a real number corresponding to the wire-time 539 the packet passes (last bit received) Hi, or undefined if the packet 540 never passes Hi. 542 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 543 as the sequence of values 544 . 546 4.1.5. Discussion 548 Following are specific issues which may occur: 549 o the delay looks to decrease: dTi > DTi+1. This may occur despite 550 it does not make sense per definition: 551 * This is frequently due to some clock synchronization issue. 552 This point is discussed in the section 3.7.1. "Errors or 553 uncertainties related to Clocks" of [RFC2679]. Consequently, 554 times of a measure at different hosts do not guaranty the 555 ordering of the hosts on the path of a measure. 556 * During some change of routes the order of 2 hosts may change on 557 the main path; 558 * The location of the point of interest in the device influences 559 the result. If the packet is not observed directly on the 560 input interface the delay includes buffering time and 561 consequently an uncertainty due to the difference between 'wire 562 time' and 'host time' 564 4.2. A Definition for Spatial One-way Packet Loss Vector 566 This section is coupled with the definition of Type-P-One-way-Packet- 567 Loss. Then when a parameter from the section 2 of [RFC2680] is first 568 used in this section, it will be tagged with a trailing asterisk. 570 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 571 statements for end-to-end one-way packet loss measurements. They are 572 applicable to each point of interest Hi involved in the measure. 573 Spatial packet loss measurement SHOULD be respectful of them, 574 especially those related to methodology, clock, uncertainties and 575 reporting. 577 Following we define the spatial metric, then we adapt some of the 578 points above and introduce points specific to spatial measurement. 580 4.2.1. Metric Name 582 Type-P-Spatial-One-way-Packet-Loss-Vector 584 4.2.2. Metric Parameters 586 o Src*, the IP address of the sender. 587 o Dst*, the IP address of the receiver. 588 o i, an integer which ordered the hosts in the path. 590 o Hi, points of interests of the path digest. 591 o T*, a time, the sending time for a measured packet. 592 o , a list of delay. 593 o P*, the specification of the packet type. 594 o , hosts path digest. 595 o , a list of Boolean values. 597 4.2.3. Metric Units 599 The value of Type-P-Spatial-One-way-Packet-Loss-Vector is a sequence 600 of Boolean values. 602 4.2.4. Definition 604 Given a Type-P packet sent by the sender Src at time T to the 605 receiver Dst in the path . Given the sequence of 606 times the packet passes in , 607 we define Type-P-One-way-Packet-Lost-Vector metric as the sequence of 608 values such that for each Hi of the path, a value 609 of 0 for Li means that dTi is a finite value, and a value of 1 means 610 that dTi is undefined. 612 4.2.5. Discussion 614 Following are specific issues which may occur: 615 o The result includes the sequence 1,0. This may occur under 616 specific situations: 617 * During some change of routes a packet may be seen by a host but 618 not by it successor on the main path; 619 * A packet may not be observed in a host due to some buffer or 620 CPU overflow in the point of interest; 622 4.3. A Definition for Spatial One-way Ipdv Vector 624 This section uses parameters from the definition of Type-P-One-way- 625 ipdv. When a parameter from section 2 of [RFC3393] is first used in 626 this section, it will be tagged with a trailing asterisk. 628 In the following we adapt some of them and introduce points specific 629 to spatial measurement. 631 4.3.1. Metric Name 633 Type-P-Spatial-One-way-ipdv-Vector 635 4.3.2. Metric Parameters 637 o Src*, the IP address of the sender. 638 o Dst*, the IP address of the receiver. 639 o i, An integer in the ordered list <1,2,...,n> of hosts in the 640 path. 641 o Hi, A host* of the path digest. 642 o T1*, a time, the sending time for a first measured packet. 643 o T2*, a time, the sending time for a second measured packet. 644 o dT*, a delay, the one-way delay for a measured packet. 645 o P*, the specification of the packets type. 646 o P1, the first packet sent at time T1. 647 o P2, the second packet sent at time T2. 648 o , hosts path digest. 649 o , the Type-P-Spatial-One-way- 650 Delay-Vector for packet sent at time T1. 651 o , the Type-P-Spatial-One-way- 652 Delay-Vector for packet sent at time T2. 653 o L*, a packet length in bits. The packets of a Type P packet 654 stream from which the Type-P-Spatial-One-way-Delay-Vector metric 655 is taken MUST all be of the same length. 657 4.3.3. Metric Units 659 The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of 660 times. 662 4.3.4. Definition 664 Given P1 the Type-P packet sent by the sender Src at wire-time (first 665 bit) T1 to the receiver Dst and 666 its Type-P-Spatial-One-way-Delay-Vector over the path . 669 Given P2 the Type-P packet sent by the sender Src at wire-time (first 670 bit) T2 to the receiver Dst and 671 its Type-P-Spatial-One-way-Delay-Vector over the same path. 673 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 674 of values such that for each Hi of the path , dT2.i-dT1.i 676 is either a real number if the packets P1 and P2 passe Hi at wire- 677 time (last bit) dT1.i, respectively dT2.i, or undefined if at least 678 one of them never passes Hi. T2-T1 is the inter-packet emission 679 interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. 681 4.4. Spatial Methodology 683 Methodology, reporting and uncertainties points specified in section 684 3 of [RFC2679] applies to each point of interest Hi measuring a 685 element of a spatial delay vector. 687 Methodology, reporting and uncertainties points specified in section 688 2 of [RFC2680] applies to each point of interest Hi measuring a 689 element of a spatial packet loss vector. 691 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 692 statements for end-to-end One-way ipdv measurements. They are 693 applicable to each point of interest Hi involved in the measure. 694 Spatial One-way ipdv measurement SHOULD be respectful of methodology, 695 clock, uncertainties and reporting aspects given in this section. 697 Generally, for a given Type-P of length L, in a given Hi, the 698 methodology for spatial vector metrics may proceed as follows: 699 o At each Hi, points of interest prepare to capture the packet sent 700 a time T, take a timestamp Ti', determine the internal delay 701 correction dTi' (See section 3.7.1. "Errors or uncertainties 702 related to Clocks" of [RFC2679]), 703 o Each Hi extracts the path ordering information from the packet 704 (e.g. time-to-live); 705 o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. 706 This arrival time is undefined (infinite) if the packet is not 707 detected after the 'loss threshold' duration; 708 o Each Hi extracts the timestamp T from the packet; 709 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 710 o The reference point gathers the result of each Hi and order them 711 according to the path ordering information received to build the 712 type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-Delay- 713 Vector metric ) over the path at time T. 716 4.4.1. Loss threshold 718 Loss threshold is the centrality of any methodology because it 719 determines the presence the packet in the measurement process of the 720 point of interest and consequently determines any ground truth metric 721 result. It determines the presence of an effective delay, and bias 722 the measure of ipdv, of packet loss and of the statistics. 724 This is consistent for end-to-end but impacts spatial measure: 725 depending on the consistency of the loss threshold among the points 726 of interest, a packet may be considered loss a one host but present 727 in another one, or may be observed by the last host (last hop) of the 728 path but considered lost by Dst. The analysis of such results is not 729 deterministic: Has the path change? Does the packet arrive at 730 destination or was it lost during the last mile? The same applies, 731 of course, for one-way-delay measures: a delay measured may be 732 infinite at one host but a real value in another one, or may be 733 measured as a real value by the last host of the path but observed as 734 infinite by Dst. The loss threshold should be set up with the same 735 value in each host of the path and in the destination. The loss 736 threshold must be systematically reported to permit careful 737 introspection and to avoid the introduction of any contradiction in 738 the statistic computation process. 740 4.4.2. Host Path Digest 742 The methodology given above relies on the order of the points of 743 interest over the path to [RFC2679] one's. 745 A test packets may cross several times the same host resulting in the 746 repetition of one or several hosts in the Path Digest. 748 As an example. This occurs typically during rerouting phases which 749 introduce temporary micro loops. During such an event the host path 750 digest for a packet crossing Ha and Hb may include the pattern meaning that Ha ended the computation of the new path 752 before Hb and that the initial path wath from Ha to Hb and that the 753 new path is from Hb to Ha. 755 Consequently, duplication of hosts in the Path Digest of a vectors 756 MUST be identified before statistics computation to avoid corrupted 757 results' production. 759 5. Spatial Segments metrics definitions 761 This section defines samples to measure the performance of a segment 762 of a path over time. Definitions rely on matrix of the spatial 763 vector metrics defined above. 765 Firstly it defines a sample of one-way delay, Type-P-Segment-One-way- 766 Delay-Stream, and a sample of packet loss, Type-P-segment-Packet- 767 loss-Stream. 769 Then it defines 2 different samples of ipdv. The first metric, Type- 770 P-Segment-One-way-ipdv-prev-Stream, uses the previous packet as the 771 selection function. The second metric, Type-P-Segment-One-way-ipdv- 772 min-Stream, uses the minimum delay as the selection. 774 5.1. A Definition of a sample of One-way Delay of a segment of the path 776 This metric defines a sample of One-way delays over time between a 777 pair of hosts of a path. 779 As its semantic is very close to the metric Type-P-Packet-loss-Stream 780 defined in section 4 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] 781 are part of the current definition. 783 5.1.1. Metric Name 785 Type-P-Segment-One-way-Delay-Stream 787 5.1.2. Metric Parameters 789 o Src*, the IP address of the sender. 790 o Dst*, the IP address of the receiver. 791 o P*, the specification of the packet type. 792 o i, an integer in the ordered list <1,2,...,n> of hosts in the 793 path. 794 o k, an integer which orders the packets sent. 795 o a and b, 2 integers where b > a. 796 o Hi, a host* of the path digest. 797 o , hosts path digest. 798 o , a list of times. 800 5.1.3. Metric Units 802 The value of a Type-P-Segment-One-way-Delay-Stream is a pair of 803 list of times ; 804 sequence of delays. 806 5.1.4. Definition 808 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 810 packets sent from Src to Dst at times : 811 ; 812 ; 813 ... 814 . 816 We define the sample Type-P-segment-One-way-Delay-Stream as the 817 sequence such that for 818 each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if 819 the packet send a time Tk passes Ha and Hb or undefined if this 820 packet never passes Ha or (inclusive) never passes Hb. 822 5.1.5. Discussion 824 Following are specific issues which may occur: 825 o the delay looks to decrease: dTi > DTi+1: 826 * This is typically due to clock synchronization issue. this 827 point is discussed in the section 3.7.1. "Errors or 828 uncertainties related to Clocks" of of [RFC2679]; 829 * This may occurs too when the clock resolution of one probe is 830 bigger than the minimum delay of a path. As an example this 831 happen when measuring the delay of a path which is 500 km long 832 with one probe synchronized using NTP having a clock resolution 833 of 8ms. 834 The metric can not be performed on < T1 , T2, ..., Tm-1, Tm> in the 835 following cases: 836 o Ha or Hb disappears from the path due to some change of routes; 837 o The order of Ha and Hb changes in the path; 839 5.2. A Definition of a sample of Packet Loss of a segment of the path 841 This metric defines a sample of packet lost over time between a pair 842 of hosts of a path. As its semantic is very close to the metric 843 Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], sections 844 3.5 to 3.8 of [RFC2680] are part of the current definition. 846 5.2.1. Metric Name 848 Type-P-segment-Packet-loss-Stream 850 5.2.2. Metric Parameters 852 o Src*, the IP address of the sender. 853 o Dst*, the IP address of the receiver. 854 o P*, the specification of the packet type. 855 o k, an integer which orders the packets sent. 856 o n, an integer which orders the hosts on the path. 857 o a and b, 2 integers where b > a. 858 o , hosts path digest. 859 o Hi, exchange points of the path digest. 860 o , a list of times. 861 o a list of boolean values. 863 5.2.3. Metric Units 865 The value of a Type-P-segment-Packet-loss-Stream is a pair of 866 The list of times ; 867 a sequence of booleans. 869 5.2.4. Definition 871 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-Packet-loss-Vector for the 873 packets sent from Src to Dst at times : 874 , 875 , 876 ..., 877 . 879 We define the value of the sample Type-P-segment-Packet-Lost-Stream 880 from Ha to Hb as the sequence of booleans such that for each Tk: 882 o A value of Lk of 0 means that Ha and Hb observed the packet sent 883 at time Tk (Lk.a and Lk.b have a value of 0); 884 o A value of Lk of 1 means that Ha observed the packet sent at time 885 Tk (Lk.a has a value of 0) and that Hb did not observed the packet 886 sent at time Tk (Lk.b have a value of 1); 887 o The value of Lk is undefined when Neither Ha or Hb observe the 888 packet; 890 5.2.5. Discussion 892 Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-loss-Stream 893 relies on the stability of the host path digest. The metric can not 894 be performed on < T1 , T2, ..., Tm-1, Tm> in the following cases: 895 o Ha or Hb disappears from the path due to some change of routes; 896 o the order of Ha and Hb changes in the path; 897 o Lk.a or Lk.b is undefined; 898 o Lk.a has the value 1 (not observed) and Lk.b has the value 0 899 (observed); 900 o L has the value 0 (the packet was received by Dst) and Lk.ab has 901 the value 1 (the packet was lost between Ha and Hb). 903 5.3. A Definition of a sample of ipdv of a segment using the previous 904 packet selection function 906 This metric defines a sample of ipdv [RFC3393] over time between a 907 pair of hosts using the previous packet as the selection function. 909 5.3.1. Metric Name 911 Type-P-Segment-One-way-ipdv-prev-Stream 913 5.3.2. Metric Parameters 914 o Src*, the IP address of the sender. 915 o Dst*, the IP address of the receiver. 916 o P*, the specification of the packet type. 917 o k, an integer which orders the packets sent. 918 o n, an integer which orders the hosts on the path. 919 o a and b, 2 integers where b > a. 920 o , the hosts path digest. 921 o , a list of times. 922 o , a 923 Type-P-Spatial-One-way-Delay-Vector. 925 5.3.3. Metric Units 927 The value of a Type-P-Segment-One-way-ipdv-prev-Stream is a pair of: 928 The list of ; 929 A list of pairs of interval of times and delays; 931 5.3.4. Definition 933 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 935 packets sent from Src to Dst at times : 936 , 937 , 938 ... 939 . 941 We define the Type-P-Segment-One-way-ipdv-prev-Stream as the sequence 942 of pair of packet intervals and delay variations <(dT2_1.a , dT2.ab - 943 dT1.ab) ,..., (dTk_k-1.a, dTk.ab - dTk-1.ab), ..., (dTm_m-1.a, dTm.ab 944 - dTm-1.ab)> such that for each Tk: 945 o dTk_k-1.a is either undefined if the delay dTk.a or the delay 946 dTk-1.a is undefined, or the interval of time, 'dTk.a - dTk-1.a', 947 between the 2 packets at Ha; 948 o dTk_k-1.ab, is either undefined if one of the delays dTk.b, dTk.a, 949 dTk-1.b or dTk-1.a is undefined, or , (dTk.b - dTk.a) - (dTk-1.b - 950 dTk-1.a), the delay variation from Ha to Hb between the 2 packets 951 sent at time Tk and Tk-1. 953 5.3.5. Discussion 955 This metric belongs to the family of inter packet delay variation 956 metrics (IPDV in upper case) which results can be extremely sensitive 957 to the inter-packet interval. 959 The inter-packet interval of a end-to-end IPDV metric is under the 960 control of the ingress point of interest which corresponds exactly to 961 the Source of the packet. Unlikely, the inter-packet interval of a 962 segment IPDV metric is not under the control the ingress point of 963 interest of the measure, Ha. However, the interval will vary if 964 there is delay variation between the Source and Ha. Therefore, the 965 actual inter-packet interval must be known at Ha in order to fully 966 comprehend the delay variation between Ha and Hb. 968 5.4. A Definition of a sample of ipdv of a segment using the minimum 969 delay selection function 971 This metric defines a sample of ipdv [RFC3393] over time between a 972 pair of hosts of a path using the shortest delay as the selection 973 function. 975 5.4.1. Metric Name 977 Type-P-Segment-One-way-ipdv-min-Stream 979 5.4.2. Metric Parameters 981 o Src*, the IP address of the sender. 982 o Dst*, the IP address of the receiver. 983 o P*, the specification of the packet type. 984 o k, an integer which orders the packets sent. 985 o i, an integer which identifies a packet sent. 986 o n, an integer which orders the hosts on the path. 987 o a and b, 2 integers where b > a. 988 o , the hosts path digest. 989 o , a list of times. 990 o , a 991 Type-P-Spatial-One-way-Delay-Vector. 993 5.4.3. Metric Units 995 The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: 996 The list of ; 997 A list of times; 999 5.4.4. Definition 1001 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 1003 packets sent from Src to Dst at times : 1004 , 1005 , 1006 ... 1007 . 1009 We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence 1010 of times such that: 1012 min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); 1013 for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) 1014 dTk.b is undefined, or the real number (dTk.b - dTk.a). 1016 5.4.5. Discussion 1018 This metric belongs to the family of packet delay variation metrics 1019 (PDV). PDV distributions are less sensitive to inter-packet interval 1020 variations than IPDV results. 1022 In principle, the PDV distribution reflects the variation over many 1023 different inter-packet intervals, from the smallest inter-packet 1024 interval, up to the length of the evaluation interval, Tm - T1. 1025 Therefore, when delay variation occurs and disturbs the packet 1026 spacing observed at Ha, the PDV results will likely compare favorably 1027 to a PDV measurement where the source is Ha and the destination is 1028 Hb. 1030 6. One-to-group metrics definitions 1032 This metric defines metrics to measure the performance between a 1033 source and a group of receivers. 1035 6.1. A Definition for One-to-group One-way Delay 1037 This metric defines a metric to measure one-way delay between a 1038 source and a group of receivers. 1040 6.1.1. Metric Name 1042 Type-P-One-to-group-One-way-Delay-Vector 1044 6.1.2. Metric Parameters 1046 o Src, the IP address of a host acting as the source. 1047 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1048 receivers. 1049 o T, a time. 1050 o dT1,...,dTn a list of time. 1051 o P, the specification of the packet type. 1052 o Gr, the receiving group identifier. The parameter Gr is the 1053 multicast group address if the measured packets are transmitted 1054 over IP multicast. This parameter is to differentiate the 1055 measured traffic from other unicast and multicast traffic. It is 1056 optional in the metric to avoid losing any generality, i.e. to 1057 make the metric also applicable to unicast measurement where there 1058 is only one receiver. 1060 6.1.3. Metric Units 1062 The value of a Type-P-One-to-group-One-way-Delay-Vector is a set of 1063 Type-P-One-way-Delay singletons [RFC2679]. 1065 6.1.4. Definition 1067 Given a Type P packet sent by the source Src at Time T, given the N 1068 hosts { Recv1,...,RecvN } which receive the packet at the time { 1069 T+dT1,...,T+dTn }, a Type-P-One-to-group-One-way-Delay-Vector is 1070 defined as the set of the Type-P-One-way-Delay singleton between Src 1071 and each receiver with value of { dT1, dT2,...,dTn }. 1073 6.2. A Definition for One-to-group One-way Packet Loss 1075 6.2.1. Metric Name 1077 Type-P-One-to-group-One-way-Packet-Loss-Vector 1079 6.2.2. Metric Parameters 1081 o Src, the IP address of a host acting as the source. 1082 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1083 receivers. 1084 o T, a time. 1085 o T1,...,Tn a list of time. 1086 o P, the specification of the packet type. 1087 o Gr, the receiving group identifier. 1089 6.2.3. Metric Units 1091 The value of a Type-P-One-to-group-One-way-Packet-Loss-Vector is a 1092 set of Type-P-One-way-Packet-Loss singletons [RFC2680]. 1094 6.2.4. Definition 1096 Given a Type P packet sent by the source Src at T and the N hosts, 1097 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 1098 Type-P-One-to-group-One-way-Packet-Loss-Vector is defined as a set of 1099 the Type-P-One-way-Packet-Loss singleton between Src and each of the 1100 receivers {,,..., }. 1102 6.3. A Definition for One-to-group One-way Ipdv 1104 6.3.1. Metric Name 1106 Type-P-One-to-group-One-way-ipdv-Vector 1108 6.3.2. Metric Parameters 1110 o Src, the IP address of a host acting as the source. 1111 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1112 receivers. 1113 o T1, a time. 1114 o T2, a time. 1115 o ddT1, ...,ddTn, a list of time. 1116 o P, the specification of the packet type. 1117 o F, a selection function defining unambiguously the two packets 1118 from the stream selected for the metric. 1119 o Gr, the receiving group identifier. The parameter Gr is the 1120 multicast group address if the measured packets are transmitted 1121 over IP multicast. This parameter is to differentiate the 1122 measured traffic from other unicast and multicast traffic. It is 1123 optional in the metric to avoid losing any generality, i.e. to 1124 make the metric also applicable to unicast measurement where there 1125 is only one receiver. 1127 6.3.3. Metric Units 1129 The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of 1130 Type-P-One-way-ipdv singletons [RFC3393]. 1132 6.3.4. Definition 1134 Given a Type P packet stream, Type-P-One-to-group-One-way-ipdv-Vector 1135 is defined for two packets from the source Src to the N hosts 1136 {Recv1,...,RecvN },which are selected by the selection function F, as 1137 the difference between the value of the Type-P-One-to-group-One-way- 1138 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1139 value of the Type-P-One-to-group-One-way-Delay-Vector from Src to { 1140 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1141 the first bit of the first packet, and T2 is the wire-time at which 1142 Src sent the first bit of the second packet. This metric is derived 1143 from the Type-P-One-to-group-One-way-Delay-Vector metric. 1145 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-One-to- 1146 group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 1147 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1148 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1149 and the packets were received by { Recv1,...,RecvN } at wire-time 1150 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1151 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1152 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1154 7. One-to-Group Sample Statistics 1156 The defined one-to-group metrics above can all be directly achieved 1157 from the relevant unicast one-way metrics. They collect all unicast 1158 measurement results of one-way metrics together in one profile and 1159 sort them by receivers and packets in a receiving group. They 1160 provide sufficient information regarding the network performance in 1161 terms of each receiver and guide engineers to identify potential 1162 problem happened on each branch of a multicast routing tree. 1163 However, these metrics cannot be directly used to conveniently 1164 present the performance in terms of a group and neither to identify 1165 the relative performance situation. 1167 From the performance point of view, the multiparty communication 1168 services not only require the absolute performance support but also 1169 the relative performance. The relative performance means the 1170 difference between absolute performance of all users. Directly using 1171 the one-way metrics cannot present the relative performance 1172 situation. However, if we use the variations of all users one-way 1173 parameters, we can have new metrics to measure the difference of the 1174 absolute performance and hence provide the threshold value of 1175 relative performance that a multiparty service might demand. A very 1176 good example of the high relative performance requirement is the 1177 online gaming. A very light difference in delay might result in 1178 failure in the game. We have to use multicast specific statistic 1179 metrics to define exactly how small the relative delay the online 1180 gaming requires. There are many other services, e.g. online biding, 1181 online stock market, etc., that require multicast metrics in order to 1182 evaluate the network against their requirements. Therefore, we can 1183 see the importance of new, multicast specific, statistic metrics to 1184 feed this need. 1186 We might also use some one-to-group statistic conceptions to present 1187 and report the group performance and relative performance to save the 1188 report transmission bandwidth. Statistics have been defined for One- 1189 way metrics in corresponding RFCs. They provide the foundation of 1190 definition for performance statistics. For instance, there are 1191 definitions for minimum and maximum One-way delay in [RFC2679]. 1192 However, there is a dramatic difference between the statistics for 1193 one-to-one communications and for one-to-many communications. The 1194 former one only has statistics over the time dimension while the 1195 later one can have statistics over both time and space dimensions. 1196 This space dimension is introduced by the Matrix concept as 1197 illustrated in Figure 4. For a Matrix M each row is a set of One-way 1198 singletons spreading over the time dimension and each column is 1199 another set of One-way singletons spreading over the space dimension. 1201 Receivers 1202 Space 1203 ^ 1204 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1205 | | | 1206 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1207 | | | 1208 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1209 . | | | 1210 . | | | 1211 . | | | 1212 n | \ RndT1 RndT2 RndT3 ... RndTk / 1213 +--------------------------------------------> time 1214 T0 1216 Figure 4: Matrix M (n*m) 1218 In Matrix M, each element is a one-way delay singleton. Each column 1219 is a delay vector contains the One-way delays of the same packet 1220 observed at M points of interest. It implies the geographical factor 1221 of the performance within a group. Each row is a set of One-way 1222 delays observed during a sampling interval at one of the points of 1223 interest. It presents the delay performance at a receiver over the 1224 time dimension. 1226 Therefore, one can either calculate statistics by rows over the space 1227 dimension or by columns over the time dimension. It's up to the 1228 operators or service provides which dimension they are interested in. 1229 For example, a TV broadcast service provider might want to know the 1230 statistical performance of each user in a long term run to make sure 1231 their services are acceptable and stable. While for an online gaming 1232 service provider, he might be more interested to know if all users 1233 are served fairly by calculating the statistics over the space 1234 dimension. This memo does not intend to recommend which of the 1235 statistics are better than the other. 1237 To save the report transmission bandwidth, each point of interest can 1238 send statistics in a pre-defined time interval to the reference point 1239 rather than sending every one-way singleton it observed. As long as 1240 an appropriate time interval is decided, appropriate statistics can 1241 represent the performance in a certain accurate scale. How to decide 1242 the time interval and how to bootstrap all points of interest and the 1243 reference point depend on applications. For instance, applications 1244 with lower transmission rate can have the time interval longer and 1245 ones with higher transmission rate can have the time interval 1246 shorter. However, this is out of the scope of this memo. 1248 Moreover, after knowing the statistics over the time dimension, one 1249 might want to know how this statistics distributed over the space 1250 dimension. For instance, a TV broadcast service provider had the 1251 performance Matrix M and calculated the One-way delay mean over the 1252 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1253 calculated the mean of all the elements in the Vector to see what 1254 level of delay he has served to all N users. This new delay mean 1255 gives information on how good the service has been delivered to a 1256 group of users during a sampling interval in terms of delay. It 1257 needs twice calculation to have this statistic over both time and 1258 space dimensions. We name this kind of statistics 2-level statistics 1259 to distinct with those 1-level statistics calculated over either 1260 space or time dimension. It can be easily prove that no matter over 1261 which dimension a 2-level statistic is calculated first, the results 1262 are the same. I.e. one can calculate the 2-level delay mean using 1263 the Matrix M by having the 1-level delay mean over the time dimension 1264 first and then calculate the mean of the obtained vector to find out 1265 the 2-level delay mean. Or, he can do the 1-level statistic 1266 calculation over the space dimension first and then have the 2-level 1267 delay mean. Both two results will be exactly the same. Therefore, 1268 when define a 2-level statistic, there is no need to specify in which 1269 procedure the calculation should follow. 1271 Comment: The above statement depends on whether the order of 1272 operations has any affect on the outcome. 1274 Many statistics can be defined for the proposed one-to-group metrics 1275 over either the space dimension or the time dimension or both. This 1276 memo treats the case where a stream of packets from the Source 1277 results in a sample at each of the Receivers in the Group, and these 1278 samples are each summarized with the usual statistics employed in 1279 one-to-one communication. New statistic definitions are presented, 1280 which summarize the one-to-one statistics over all the Receivers in 1281 the Group. 1283 7.1. Discussion on the Impact of packet loss on statistics 1285 The packet loss does have effects on one-way metrics and their 1286 statistics. For example, the lost packet can result an infinite one- 1287 way delay. It is easy to handle the problem by simply ignoring the 1288 infinite value in the metrics and in the calculation of the 1289 corresponding statistics. However, the packet loss has so strong 1290 impact on the statistics calculation for the one-to-group metrics 1291 that it can not be solved by the same method used for one-way 1292 metrics. This is due to the complex of building a Matrix, which is 1293 needed for calculation of the statistics proposed in this memo. 1295 The situation is that measurement results obtained by different end 1296 users might have different packet loss pattern. For example, for 1297 User1, packet A was observed lost. And for User2, packet A was 1298 successfully received but packet B was lost. If the method to 1299 overcome the packet loss for one-way metrics is applied, the two 1300 singleton sets reported by User1 and User2 will be different in terms 1301 of the transmitted packets. Moreover, if User1 and User2 have 1302 different number of lost packets, the size of the results will be 1303 different. Therefore, for the centralized calculation, the reference 1304 point will not be able to use these two results to build up the group 1305 Matrix and can not calculate the statistics. In an extreme 1306 situation, no single packet arrives all users in the measurement and 1307 the Matrix will be empty. One of the possible solutions is to 1308 replace the infinite/undefined delay value by the average of the two 1309 adjacent values. For example, if the result reported by user1 is { 1310 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1311 is an undefined value, the reference point can replace it by R1dTK = 1312 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1313 build up the group Matrix with an estimated value R1dTK. There are 1314 other possible solutions such as using the overall mean of the whole 1315 result to replace the infinite/undefined value, and so on. However 1316 this is out of the scope of this memo. 1318 For the distributed calculation, the reported statistics might have 1319 different "weight" to present the group performance, which is 1320 especially true for delay and ipdv relevant metrics. For example, 1321 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1322 in Figure. 8 without any packet loss and User2 calculates the R2DM 1323 with N-2 packet loss. The R1DM and R2DM should not be treated with 1324 equal weight because R2DM was calculated only based on 2 delay values 1325 in the whole sample interval. One possible solution is to use a 1326 weight factor to mark every statistic value sent by users and use 1327 this factor for further statistic calculation. 1329 7.2. General Metric Parameters 1331 o Src, the IP address of a host; 1332 o G, the receiving group identifier; 1333 o N, the number of Receivers (Recv1, Recv2, ... RecvN); 1334 o T, a time (start of test interval); 1335 o Tf, a time (end of test interval); 1336 o K, the number of packets sent from the source during the test 1337 interval; 1339 o J[n], the number of packets received at a particular Receiver, n, 1340 where 1<=n<=N; 1341 o lambda, a rate in reciprocal seconds (for Poisson Streams); 1342 o incT, the nominal duration of inter-packet interval, first bit to 1343 first bit (for Periodic Streams); 1344 o T0, a time that MUST be selected at random from the interval [T, 1345 T+I] to start generating packets and taking measurements (for 1346 Periodic Streams); 1347 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1348 Source Measurement Point); 1349 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1350 assigned to packets that arrive within a "reasonable" time; 1351 o Tmax, a maximum waiting time for packets at the destination, set 1352 sufficiently long to disambiguate packets with long delays from 1353 packets that are discarded (lost), thus the distribution of delay 1354 is not truncated; 1355 o dT, shorthand notation for a one-way delay singleton value; 1356 o L, shorthand notation for a one-way loss singleton value, either 1357 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1358 the destination within TstampSrc + Tmax, may be indexed over n 1359 Receivers; 1360 o DV, shorthand notation for a one-way delay variation singleton 1361 value; 1363 7.3. One-to-Group one-way Delay Statistics 1365 This section defines the overall one-way delay statistics for a 1366 receiver and for an entire group as illustrated by the matrix below. 1368 Recv /----------- Sample -------------\ Stats Group Stat 1370 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1371 | 1372 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 1373 | 1374 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > Group delay 1375 . | 1376 . | 1377 . | 1378 n RndT1 RndT2 RndT3 ... RndTk RnDM / 1380 Receiver-n 1381 delay 1383 Figure 5: One-to-Group Mean Delay 1385 Statistics are computed on the finite One-way delays of the matrix 1386 above. 1388 All One-to-group delay statistics are expressed in seconds with 1389 sufficient resolution to convey 3 significant digits. 1391 7.3.1. Type-P-One-to-Group-Receiver-n-Mean-Delay 1393 This section defines Type-P-One-to-Group-Receiver-n-Mean-Delay the 1394 Delay Mean at each Receiver N, also named RnDM. 1396 We obtain the value of Type-P-One-way-Delay singleton for all packets 1397 sent during the test interval at each Receiver (Destination), as per 1398 [RFC2679]. For each packet that arrives within Tmax of its sending 1399 time, TstampSrc, the one-way delay singleton (dT) will be the finite 1400 value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, 1401 the value of the singleton is Undefined. 1403 J[n] 1404 --- 1405 1 \ 1406 RnDM = --- * > TstampRecv[i] - TstampSrc[i] 1407 J[n] / 1408 --- 1409 i = 1 1411 Figure 6: Type-P-One-to-Group-Receiver-Mean-Delay 1413 where all packets i= 1 through J[n] have finite singleton delays. 1415 7.3.2. Type-P-One-to-Group-Mean-Delay 1417 This section defines Type-P-One-to-Group-Mean-Delay, the Mean One-way 1418 delay calculated over the entire Group, also named GMD. 1420 N 1421 --- 1422 1 \ 1423 GMD = - * > RnDM 1424 N / 1425 --- 1426 n = 1 1428 Figure 7: Type-P-One-to-Group-Mean-Delay 1430 Note that the Group Mean Delay can also be calculated by summing the 1431 Finite one-way Delay singletons in the Matrix, and dividing by the 1432 number of Finite One-way Delay singletons. 1434 7.3.3. Type-P-One-to-Group-Range-Mean-Delay 1436 This section defines a metric for the range of mean delays over all N 1437 receivers in the Group, (R1DM, R2DM,...RnDM). 1439 Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1441 7.3.4. Type-P-One-to-Group-Max-Mean-Delay 1443 This section defines a metric for the maximum of mean delays over all 1444 N receivers in the Group, (R1DM, R2DM,...RnDM). 1446 Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) 1448 7.4. One-to-Group one-way Loss Statistics 1450 This section defines the overall one-way loss statistics for a 1451 receiver and for an entire group as illustrated by the matrix below. 1453 Recv /----------- Sample ----------\ Stats Group Stat 1455 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1456 | 1457 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1458 | 1459 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio 1460 . | 1461 . | 1462 . | 1463 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1465 Receiver-n 1466 Loss Ratio 1468 Figure 8: One-to-Group Loss Ratio 1470 Statistics are computed on the sample of Type-P-One-way-Packet-Loss 1471 [RFC2680] of the matrix above. 1473 All loss ratios are expressed in units of packets lost to total 1474 packets sent. 1476 7.4.1. Type-P-One-to-Group-Receiver-n-Loss-Ratio 1478 Given a Matrix of loss singletons as illustrated above, determine the 1479 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1480 according to the definitions and method of [RFC2680]. The Type-P- 1481 One-way-Packet-Loss-Average and the Type-P-One-to-Group-Receiver-n- 1482 Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the 1483 parameters used here, these metrics definitions can be expressed as 1485 K 1486 --- 1487 1 \ 1488 RnLR = - * > RnLk 1489 K / 1490 --- 1491 k = 1 1493 Figure 9: Type-P-One-to-Group-Receiver-n-Loss-Ratio 1495 7.4.2. Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio 1497 Usually, the number of packets sent is used in the denominator of 1498 packet loss ratio metrics. For the comparative metrics defined here, 1499 the denominator is the maximum number of packets received at any 1500 receiver for the sample and test interval of interest. 1502 The Comparative Loss Ratio, also named, RnCLR, is defined as 1504 K 1505 --- 1506 \ 1507 > Ln(k) 1508 / 1509 --- 1510 k=1 1511 RnCLR = ----------------------------- 1512 / K \ 1513 | --- | 1514 | \ | 1515 K - Min | > Ln(k) | 1516 | / | 1517 | --- | 1518 \ k=1 / N 1520 Figure 10: Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio 1522 7.4.3. Type-P-One-to-Group-Loss-Ratio 1524 Type-P-One-to-Group-Loss-Ratio, the overall Group loss ratio, also 1525 named GLR, is defined as 1526 K,N 1527 --- 1528 1 \ 1529 GLR = --- * > L(k,n) 1530 K*N / 1531 --- 1532 k,n = 1 1534 Figure 11: Type-P-One-to-Group-Loss-Ratio 1536 7.4.4. Type-P-One-to-Group-Range-Loss-Ratio 1538 The One-to-Group Loss Ratio Range is defined as: 1540 Type-P-One-to-Group-Range-Loss-Ratio = max(RnLR) - min(RnLR) 1542 It is most effective to indicate the range by giving both the max and 1543 minimum loss ratios for the Group, rather than only reporting the 1544 difference between them. 1546 7.5. One-to-Group one-way Delay Variation Statistics 1548 This section defines one-way delay variation (DV) statistics for an 1549 entire group as illustrated by the matrix below. 1551 Recv /------------- Sample --------------\ Stats 1553 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ 1554 | 1555 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | 1556 | 1557 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat 1558 . | 1559 . | 1560 . | 1561 n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / 1563 Figure 12: One-to-Group Delay Variation Matrix (DVMa) 1565 Statistics are computed on the sample of Type-P-One-way-Delay- 1566 Variation singletons of the group delay variation matrix above where 1567 RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at 1568 Receiver n for the packet k and where RnDV is the point-to-point one- 1569 way packet delay variation for Receiver n. 1571 All One-to-group delay variation statistics are expressed in seconds 1572 with sufficient resolution to convey 3 significant digits. 1574 7.5.1. Type-P-One-to-Group-Delay-Variation-Range 1576 This section defines a metric for the range of delays variation over 1577 all N receivers in the Group. 1579 Maximum DV and minimum DV over all receivers summarize the 1580 performance over the Group (where DV is a point-to-point metric). 1581 For each receiver, the DV is usually expressed as the 1-10^(-3) 1582 quantile of one-way delay minus the minimum one-way delay. 1584 Type-P-One-to-Group-Delay-Variation-Range = GDVR = 1586 = max(RnDV) - min(RnDV) for all n receivers 1588 This range is determined from the minimum and maximum values of the 1589 point-to-point one-way IP Packet Delay Variation for the set of 1590 Destinations in the group and a population of interest, using the 1591 Packet Delay Variation expressed as the 1-10^-3 quantile of one-way 1592 delay minus the minimum one-way delay. If a more demanding service 1593 is considered, one alternative is to use the 1-10^-5 quantile, and in 1594 either case the quantile used should be recorded with the results. 1595 Both the minimum and the maximum delay variation are recorded, and 1596 both values are given to indicate the location of the range. 1598 8. Measurement Methods: Scalability and Reporting 1600 Virtually all the guidance on measurement processes supplied by the 1601 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1602 scenarios is applicable here in the spatial and multiparty 1603 measurement scenario. The main difference is that the spatial and 1604 multiparty configurations require multiple points of interest where a 1605 stream of singletons will be collected. The amount of information 1606 requiring storage grows with both the number of metrics and the 1607 points of interest, so the scale of the measurement architecture 1608 multiplies the number of singleton results that must be collected and 1609 processed. 1611 It is possible that the architecture for results collection involves 1612 a single reference point with connectivity to all the points of 1613 interest. In this case, the number of points of interest determines 1614 both storage capacity and packet transfer capacity of the host acting 1615 as the reference point. However, both the storage and transfer 1616 capacity can be reduced if the points of interest are capable of 1617 computing the summary statistics that describe each measurement 1618 interval. This is consistent with many operational monitoring 1619 architectures today, where even the individual singletons may not be 1620 stored at each point of interest. 1622 In recognition of the likely need to minimize form of the results for 1623 storage and communication, the Group metrics above have been 1624 constructed to allow some computations on a per-Receiver basis. This 1625 means that each Receiver's statistics would normally have an equal 1626 weight with all other Receivers in the Group (regardless of the 1627 number of packets received). 1629 8.1. Computation methods 1631 The scalability issue can be raised when there are thousands of 1632 points of interest in a group who are trying to send back the 1633 measurement results to the reference point for further processing and 1634 analysis. The points of interest can send either the whole measured 1635 sample or only the calculated statistics. The former one is a 1636 centralized statistic calculation method and the latter one is a 1637 distributed statistic calculation method. The sample should include 1638 all metrics parameters, the values and the corresponding sequence 1639 numbers. The transmission of the whole sample can cost much more 1640 bandwidth than the transmission of the statistics that should include 1641 all statistic parameters specified by policies and the additional 1642 information about the whole sample, such as the size of the sample, 1643 the group address, the address of the point of interest, the ID of 1644 the sample session, and so on. Apparently, the centralized 1645 calculation method can require much more bandwidth than the 1646 distributed calculation method when the sample size is big. This is 1647 especially true when the measurement has huge number of the points of 1648 interest. It can lead to a scalability issue at the reference point 1649 by over load the network resources. The distributed calculation 1650 method can save much more bandwidth and release the pressure of the 1651 scalability issue at the reference point side. However, it can 1652 result in the lack of information because not all measured singletons 1653 are obtained for building up the group matrix. The performance over 1654 time can be hidden from the analysis. For example, the loss pattern 1655 can be missed by simply accepting the loss ratio as well as the delay 1656 pattern. This tradeoff between the bandwidth consuming and the 1657 information acquiring has to be taken into account when design the 1658 measurement campaign to optimize the measurement results delivery. 1659 The possible solution could be to transit the statistic parameters to 1660 the reference point first to obtain the general information of the 1661 group performance. If the detail results are required, the reference 1662 point should send the requests to the points of interest, which could 1663 be particular ones or the whole group. This procedure can happen in 1664 the off peak time and can be well scheduled to avoid delivery of too 1665 many points of interest at the same time. Compression techniques can 1666 also be used to minimize the bandwidth required by the transmission. 1667 This could be a measurement protocol to report the measurement 1668 results. However, this is out of the scope of this memo. 1670 8.2. Measurement 1672 To prevent any bias in the result, the configuration of a one-to-many 1673 measure must take in consideration that implicitly more packets will 1674 to be routed than send and selects a test packets rate that will not 1675 impact the network performance. 1677 8.3. Effect of Time and Space Aggregation Order on Stats 1679 This section presents the impact of the aggregation order on the 1680 scalability of the reporting and of the computation. It makes the 1681 hypothesis that receivers are managed remotely and not co-located. 1683 multimetrics samples represented a matrix as illustrated below 1685 Point of 1686 interest 1687 1 R1S1 R1S1 R1S1 ... R1Sk \ 1688 | 1689 2 R2S1 R2S2 R2S3 ... R2Sk | 1690 | 1691 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1692 . | 1693 . | 1694 . | 1695 n RnS1 RnS2 RnS3 ... RnSk / 1697 S1M S2M S3M ... SnM Stats over space 1699 \------------- ------------/ 1700 \/ 1701 Stat over space and time 1703 Figure 13: Impact of space aggregation on multimetrics Stat 1705 2 methods are available to compute statistics on the resulting 1706 matrix: 1707 o metric is computed over time and then over space; 1708 o metric is computed over space and then over time. 1710 They differ only by the order of the time and of the space 1711 aggregation. View as a matrix this order is neutral as does not 1712 impact the result, but the impact on a measurement deployment is 1713 critical. 1715 In both cases the volume of data to report is proportional to the 1716 number of probes. But there is a major difference between these 2 1717 methods: 1719 method2: In space and time aggregation mode the volume of data to 1720 collect is proportional to the number of test packets received; 1721 Each received packet RiSi triggers out a block of data that must 1722 be reported to a common place for computing the stat over space; 1723 method1: In time and space aggregation mode the volume of data to 1724 collect is proportional to the period of aggregation, so it does 1725 not depend on the number of packet received; 1727 Method 2 property has severe drawbacks in terms of security and 1728 dimensioning: 1729 The increasing of the rate of the test packets may result in a 1730 sort of DoS toward the computation points; 1731 The dimensioning of a measurement system is quite impossible to 1732 validate. 1734 The time aggregation interval provides the reporting side with a 1735 control of various collecting aspects such as bandwidth and 1736 computation and storage capacities. So this draft defines metrics 1737 based on method 1. 1739 Note: In some specific cases one may need sample of singletons over 1740 space. To address this need it is suggested firstly to limit the 1741 number of test and the number of test packets per seconds. Then 1742 reducing the size of the sample over time to one packet give sample 1743 of singleton over space.. 1745 8.3.1. Impact on spatial statistics 1747 2 methods are available to compute spatial statistics: 1748 o method 1: spatial segment metrics and statistics are preferably 1749 computed over time by each points of interest; 1750 o method 2: Vectors metrics are intrinsically instantaneous space 1751 metrics which must be reported using method2 whenever 1752 instantaneous metrics information is needed. 1754 8.3.2. Impact on one-to-group statistics 1756 2 methods are available to compute group statistics: 1757 o method1: Figure 5 andFigure 8 illustrate the method chosen: the 1758 one-to-one statistic is computed per interval of time before the 1759 computation of the mean over the group of receivers; 1760 o method2: Figure 13 presents the second one, metric is computed 1761 over space and then over time. 1763 9. Manageability Considerations 1765 Usually IPPM WG documents defines each metric reporting within its 1766 definition. This document defines the reporting of all the metrics 1767 introduced in a single section to provide consistent information, to 1768 avoid repetitions and to conform to IESG recommendation of gathering 1769 manageability considerations in a dedicated section. 1771 Information models of spatial metrics and of one-to-group metrics are 1772 similar excepted that points of interests of spatial vectors must be 1773 ordered. 1775 The complexity of the reporting relies on the number of points of 1776 interests. 1778 9.1. Reporting spatial metric 1780 The reporting of spatial metrics shares a lot of aspects with 1781 RFC2679-80. New ones are common to all the definitions and are 1782 mostly related to the reporting of the path and of methodology 1783 parameters that may bias raw results analysis. This section presents 1784 these specific parameters and then lists exhaustively the parameters 1785 that shall be reported. 1787 9.1.1. Path 1789 End-to-end metrics can't determine the path of the measure despite 1790 IPPM RFCs recommend it to be reported (See Section 3.8.4 of 1791 [RFC2679]). Spatial metrics vectors provide this path. The report 1792 of a spatial vector must include the points of interests involved: 1793 the sub set of the hosts of the path participating to the 1794 instantaneous measure. 1796 9.1.2. Host order 1798 A spatial vector must order the points of interest according to their 1799 order in the path. It is highly suggested to use the TTL in IPv4, 1800 the Hop Limit in IPv6 or the corresponding information in MPLS. 1802 The report of a spatial vector must include the ordered list of the 1803 hosts involved in the instantaneous measure. 1805 9.1.3. Timestamping bias 1807 The location of the point of interest inside a node influences the 1808 timestamping skew and accuracy. As an example, consider that some 1809 internal machinery delays the timestamping up to 3 milliseconds then 1810 the minimal uncertainty reported be 3 ms if the internal delay is 1811 unknown at the time of the timestamping. 1813 The report of a spatial vector must include the uncertainty of the 1814 timestamping compared to wire time. 1816 9.1.4. Reporting spatial One-way Delay 1818 The reporting includes information to report for one-way-delay as the 1819 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1821 9.2. Reporting One-to-group metric 1823 All reporting rules described in RFC2679-80 apply to the 1824 corresponding One-to-group metrics. Following are specific 1825 parameters that should be reported. 1827 9.2.1. Path 1829 As suggested by the RFC2679-80, the path traversed by the packet 1830 SHOULD be reported, if possible. For One-to-group metrics, there is 1831 a path tree SHOULD be reported rather than A path. This is even more 1832 impractical. If, by anyway, partial information is available to 1833 report, it might not be as valuable as it is in the one-to-one case 1834 because the incomplete path might be difficult to identify its 1835 position in the path tree. For example, how many points of interest 1836 are reached by the packet traveled through this incomplete path? 1838 9.2.2. Group size 1840 The group size should be reported as one of the critical management 1841 parameters. Unlike the spatial metrics, there is no need of order of 1842 points of interests. 1844 9.2.3. Timestamping bias 1846 It is the same as described in section 9.1.3. 1848 9.2.4. Reporting One-to-group One-way Delay 1850 It is the same as described in section 9.1.4. 1852 9.2.5. Measurement method 1854 As explained in section 8, the measurement method will have impact on 1855 the analysis of the measurement result. Therefore, it should be 1856 reported. 1858 9.3. Metric identification 1860 IANA assigns each metric defined by the IPPM WG with a unique 1861 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1863 9.4. Information model 1865 This section presents the elements of information and the usage of 1866 the information reported for network performance analysis. It is out 1867 of the scope of this section to define how the information is 1868 reported. 1870 The information model is build with pieces of information introduced 1871 and explained in one-way delay definitions [RFC2679], in packet loss 1872 definitions [RFC2680] and in IPDV definitions of [RFC3393] and 1873 [RFC3432]. It includes not only information given by "Reporting the 1874 metric" sections but by sections "Methodology" and "Errors and 1875 Uncertainties" sections. 1877 Following are the elements of information taken from end-to-end 1878 definitions referred in this memo and from spatial and multicast 1879 metrics it defines: 1881 o Packet_type, The Type-P of test packets (Type-P); 1882 o Packet_length, a packet length in bits (L); 1883 o Src_host, the IP address of the sender; 1884 o Dst_host, the IP address of the receiver; 1885 o Hosts_serie: , a list of points of interest; 1886 o Loss_threshold: The threshold of infinite delay; 1887 o Systematic_error: constant delay between wire time and 1888 timestamping; 1889 o Calibration_error: maximal uncertainty; 1890 o Src_time, the sending time for a measured packet; 1891 o Dst_time, the receiving time for a measured packet; 1892 o Result_status : an indicator of usability of a result 'Resource 1893 exhaustion' 'infinite', 'lost'; 1894 o Delays_serie: a list of delays; 1895 o Losses_serie: , a list of Boolean values 1896 (spatial) or a set of Boolean values (one-to-group); 1897 o Result_status_serie: a list of results status; 1898 o dT: a delay; 1899 o Singleton_number: a number of singletons; 1900 o Observation_duration: An observation duration; 1901 o metric_identifier. 1903 Following is the information of each vector that should be available 1904 to compute samples: 1906 o Packet_type; 1907 o Packet_length; 1908 o Src_host, the sender of the packet; 1909 o Dst_host, the receiver of the packet, apply only for spatial 1910 vectors; 1911 o Hosts_serie: not ordered for one-to-group; 1912 o Src_time, the sending time for the measured packet; 1913 o dT, the end-to-end one-way delay for the measured packet, apply 1914 only for spatial vectors; 1915 o Delays_serie: apply only for delays and ipdv vector, not ordered 1916 for one-to-group; 1917 o Losses_serie: apply only for packets loss vector, not ordered for 1918 one-to-group; 1919 o Result_status_serie; 1920 o Observation_duration: the difference between the time of the last 1921 singleton and the time of the first singleton. 1922 o Following is the context information (measure, points of 1923 interests) that should be available to compute samples : 1924 * Loss threshold; 1925 * Systematic error: constant delay between wire time and 1926 timestamping; 1927 * Calibration error: maximal uncertainty; 1929 A spatial or a one-to-group sample is a collection of singletons 1930 giving the performance from the sender to a single point of interest. 1931 Following is the information that should be available for each sample 1932 to compute statistics: 1934 o Packet_type; 1935 o Packet_length; 1936 o Src_host, the sender of the packet; 1937 o Dst_host, the receiver of the packet; 1938 o Start_time, the sending time of the first packet; 1939 o Delays_serie: apply only for delays and ipdv samples; 1940 o Losses_serie: apply only for packets loss samples; 1941 o Result_status_serie; 1942 o Observation_duration: the difference between the time of the last 1943 singleton of the last sample and the time of the first singleton 1944 of the first sample. 1945 o Following is the context information (measure, points of 1946 interests) that should be available to compute statistics : 1947 * Loss threshold; 1948 * Systematic error: constant delay between wire time and 1949 timestamping; 1950 * Calibration error: maximal uncertainty; 1952 Following is the information of each statistic that should be 1953 reported: 1955 o Result; 1956 o Start_time; 1957 o Duration; 1958 o Result_status; 1959 o Singleton_number, the number of singletons the statistic is 1960 computed on; 1962 10. Security Considerations 1964 Spatial and one-to-group metrics are defined on the top of end-to-end 1965 metrics. Security considerations discussed in One-way delay metrics 1966 definitions of [RFC2679] , in packet loss metrics definitions of 1967 [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 1968 apply to metrics defined in this memo. 1970 10.1. Spatial metrics 1972 Malicious generation of packets with spoofing addresses may corrupt 1973 the results without any possibility to detect the spoofing. 1975 Malicious generation of packets which match systematically the hash 1976 function used to detect the packets may lead to a DoS attack toward 1977 the point of reference. 1979 10.2. one-to-group metric 1981 Reporting of measurement results from a huge number of probes may 1982 overload reference point ressources (network, network interfaces, 1983 computation capacities ...). 1985 The configuration of a measurement must take in consideration that 1986 implicitly more packets will to be routed than send and selects a 1987 test packets rate accordingly. Collecting statistics from a huge 1988 number of probes may overload any combination of the network where 1989 the measurement controller is attached to, measurement controller 1990 network interfaces and measurement controller computation capacities. 1992 One-to-group metrics measurement should consider using source 1993 authentication protocols, standardized in the MSEC group, to avoid 1994 fraud packet in the sampling interval. The test packet rate could be 1995 negotiated before any measurement session to avoid deny of service 1996 attacks. 1998 11. Acknowledgments 2000 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2001 of Surrey, for his instruction and helpful comments on this work. 2003 12. IANA Considerations 2005 Metrics defined in this memo Metrics defined in this memo are 2006 designed to be registered in the IANA IPPM METRICS REGISTRY as 2007 described in initial version of the registry [RFC4148] : 2009 IANA is asked to register the following metrics in the IANA-IPPM- 2010 METRICS-REGISTRY-MIB : 2012 ietfSpatialOneWayDelayVector OBJECT-IDENTITY 2013 STATUS current 2014 DESCRIPTION 2015 "Type-P-Spatial-One-way-Delay-Vector" 2016 REFERENCE 2017 "Reference "RFCyyyy, section 4.1." 2018 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2019 note 2020 := { ianaIppmMetrics nn } -- IANA assigns nn 2022 ietfSpatialPacketLossVector OBJECT-IDENTITY 2023 STATUS current 2024 DESCRIPTION 2025 "Type-P-Spatial-Packet-Loss-Vector" 2026 REFERENCE 2027 "Reference "RFCyyyy, section 4.2." 2028 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2029 note 2030 := { ianaIppmMetrics nn } -- IANA assigns nn 2032 ietfSpatialOneWayIpdvVector OBJECT-IDENTITY 2033 STATUS current 2034 DESCRIPTION 2035 "Type-P-Spatial-One-way-ipdv-Vector" 2036 REFERENCE 2037 "Reference "RFCyyyy, section 4.3." 2038 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2039 note 2040 := { ianaIppmMetrics nn } -- IANA assigns nn 2042 ietfSegmentOneWayDelayStream OBJECT-IDENTITY 2043 STATUS current 2044 DESCRIPTION 2045 "Type-P-Segment-One-way-Delay-Stream" 2046 REFERENCE 2047 "Reference "RFCyyyy, section 5.1." 2048 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2049 note 2050 := { ianaIppmMetrics nn } -- IANA assigns nn 2052 ietfSegmentPacketLossStream OBJECT-IDENTITY 2053 STATUS current 2054 DESCRIPTION 2055 "Type-P-Segment-Packet-Loss-Stream" 2056 REFERENCE 2057 "Reference "RFCyyyy, section 5.2." 2058 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2059 note 2060 := { ianaIppmMetrics nn } -- IANA assigns nn 2062 ietfSegmentOneWayIpdvPrevStream OBJECT-IDENTITY 2063 STATUS current 2064 DESCRIPTION 2065 "Type-P-Segment-One-way-ipdv-prev-Stream" 2066 REFERENCE 2067 "Reference "RFCyyyy, section 5.3." 2068 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2069 note 2070 := { ianaIppmMetrics nn } -- IANA assigns nn 2072 ietfSegmentOneWayIpdvMinStream OBJECT-IDENTITY 2073 STATUS current 2074 DESCRIPTION 2075 "Type-P-Segment-One-way-ipdv-min-Stream" 2076 REFERENCE 2077 "Reference "RFCyyyy, section 5.4." 2078 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2079 note 2080 := { ianaIppmMetrics nn } -- IANA assigns nn 2082 -- One-to-group metrics 2084 ietfOneToGroupOneWayDelayVector OBJECT-IDENTITY 2085 STATUS current 2086 DESCRIPTION 2087 "Type-P-One-to-group-One-way-Delay-Vector" 2088 REFERENCE 2089 "Reference "RFCyyyy, section 6.1." 2090 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2091 note 2092 := { ianaIppmMetrics nn } -- IANA assigns nn 2094 ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY 2095 STATUS current 2096 DESCRIPTION 2097 "Type-P-One-to-Group-One-way-Packet-Loss-Vector" 2098 REFERENCE 2099 "Reference "RFCyyyy, section 6.2." 2100 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2101 note 2102 := { ianaIppmMetrics nn } -- IANA assigns nn 2104 ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY 2105 STATUS current 2106 DESCRIPTION 2107 "Type-P-One-to-Group-One-way-ipdv-Vector" 2108 REFERENCE 2109 "Reference "RFCyyyy, section 6.3." 2110 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2111 note 2112 := { ianaIppmMetrics nn } -- IANA assigns nn 2114 -- One to group statistics 2116 -- 2118 ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY 2119 STATUS current 2120 DESCRIPTION 2121 "Type-P-One-to-Group-Receiver-n-Mean-Delay" 2122 REFERENCE 2123 "Reference "RFCyyyy, section 7.3.1." 2124 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2125 note 2126 := { ianaIppmMetrics nn } -- IANA assigns nn 2128 ietfOneToGroupMeanDelay OBJECT-IDENTITY 2129 STATUS current 2130 DESCRIPTION 2131 "Type-P-One-to-Group-Mean-Delay" 2132 REFERENCE 2133 "Reference "RFCyyyy, section 7.3.2." 2134 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2135 note 2136 := { ianaIppmMetrics nn } -- IANA assigns nn 2138 ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY 2139 STATUS current 2140 DESCRIPTION 2141 "Type-P-One-to-Group-Range-Mean-Delay" 2142 REFERENCE 2143 "Reference "RFCyyyy, section 7.3.3." 2144 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2145 note 2146 := { ianaIppmMetrics nn } -- IANA assigns nn 2148 ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY 2149 STATUS current 2150 DESCRIPTION 2151 "Type-P-One-to-Group-Max-Mean-Delay" 2152 REFERENCE 2153 "Reference "RFCyyyy, section 7.3.4." 2154 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2155 note 2156 := { ianaIppmMetrics nn } -- IANA assigns nn 2158 ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY 2159 STATUS current 2160 DESCRIPTION 2161 "Type-P-One-to-Group-Receiver-n-Loss-Ratio" 2162 REFERENCE 2163 "Reference "RFCyyyy, section 7.4.1." 2164 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2165 note 2166 := { ianaIppmMetrics nn } -- IANA assigns nn 2167 -- 2169 ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY 2170 STATUS current 2171 DESCRIPTION 2172 "Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio" 2173 REFERENCE 2174 "Reference "RFCyyyy, section 7.4.2." 2175 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2176 note 2177 := { ianaIppmMetrics nn } -- IANA assigns nn 2179 ietfOneToGroupLossRatio OBJECT-IDENTITY 2180 STATUS current 2181 DESCRIPTION 2182 "Type-P-One-to-Group-Loss-Ratio" 2183 REFERENCE 2184 "Reference "RFCyyyy, section 7.4.3." 2185 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2186 note 2187 := { ianaIppmMetrics nn } -- IANA assigns nn 2188 -- 2190 ietfOneToGroupRangeLossRatio OBJECT-IDENTITY 2191 STATUS current 2192 DESCRIPTION 2193 "Type-P-One-to-Group-Range-Loss-Ratio" 2194 REFERENCE 2195 "Reference "RFCyyyy, section 7.4.4." 2196 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2197 note 2198 := { ianaIppmMetrics nn } -- IANA assigns nn 2200 ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY 2201 STATUS current 2202 DESCRIPTION 2203 "Type-P-One-to-Group-Range-Delay-Variation" 2204 REFERENCE 2205 "Reference "RFCyyyy, section 7.5.1." 2206 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2207 note 2208 := { ianaIppmMetrics nn } -- IANA assigns nn 2210 -- 2212 13. References 2214 13.1. Normative References 2216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2217 Requirement Levels", BCP 14, RFC 2119, March 1997. 2219 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2220 Delay Metric for IPPM", RFC 2679, September 1999. 2222 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2223 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2225 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2226 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2227 November 2002. 2229 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2230 Registry", BCP 108, RFC 4148, August 2005. 2232 13.2. Informative References 2234 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2235 "Framework for IP Performance Metrics", RFC 2330, 2236 May 1998. 2238 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2239 performance measurement with periodic streams", RFC 3432, 2240 November 2002. 2242 Authors' Addresses 2244 Stephan Emile 2245 France Telecom Division R&D 2246 2 avenue Pierre Marzin 2247 Lannion, F-22307 2249 Fax: +33 2 96 05 18 52 2250 Email: emile.stephan@orange-ftgroup.com 2252 Lei Liang 2253 CCSR, University of Surrey 2254 Guildford 2255 Surrey, GU2 7XH 2257 Fax: +44 1483 683641 2258 Email: L.Liang@surrey.ac.uk 2260 Al Morton 2261 200 Laurel Ave. South 2262 Middletown, NJ 07748 2263 USA 2265 Phone: +1 732 420 1571 2266 Email: acmorton@att.com 2268 Full Copyright Statement 2270 Copyright (C) The IETF Trust (2008). 2272 This document is subject to the rights, licenses and restrictions 2273 contained in BCP 78, and except as set forth therein, the authors 2274 retain all their rights. 2276 This document and the information contained herein are provided on an 2277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2284 Intellectual Property 2286 The IETF takes no position regarding the validity or scope of any 2287 Intellectual Property Rights or other rights that might be claimed to 2288 pertain to the implementation or use of the technology described in 2289 this document or the extent to which any license under such rights 2290 might or might not be available; nor does it represent that it has 2291 made any independent effort to identify any such rights. Information 2292 on the procedures with respect to rights in RFC documents can be 2293 found in BCP 78 and BCP 79. 2295 Copies of IPR disclosures made to the IETF Secretariat and any 2296 assurances of licenses to be made available, or the result of an 2297 attempt made to obtain a general license or permission for the use of 2298 such proprietary rights by implementers or users of this 2299 specification can be obtained from the IETF on-line IPR repository at 2300 http://www.ietf.org/ipr. 2302 The IETF invites any interested party to bring to its attention any 2303 copyrights, patents or patent applications, or other proprietary 2304 rights that may cover technology that may be required to implement 2305 this standard. Please address the information to the IETF at 2306 ietf-ipr@ietf.org.