idnits 2.17.1 draft-ietf-ippm-multimetrics-06.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 2559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2583. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 498: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 578: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 683: '... is taken MUST all be of the same...' RFC 2119 keyword, line 722: '...ipdv measurement SHOULD be respectful ...' RFC 2119 keyword, line 790: '... MUST be identified before statistic...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 81 has weird spacing: '...segment using...' == Line 1062 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 (February 14, 2008) is 5909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4601' is mentioned on line 1962, but not defined ** Obsolete undefined reference: RFC 4601 (Obsoleted by RFC 7761) ** 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) == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-05 Summary: 6 errors (**), 0 flaws (~~), 5 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: Informational L. Liang 5 Expires: August 17, 2008 University of Surrey 6 A. Morton 7 AT&T Labs 8 February 14, 2008 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-06 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 August 17, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The IETF IP Performance Metrics (IPPM) working group has standardized 45 metrics for measuring end-to-end performance between two points. 46 This memo defines two new categories of metrics that extend the 47 coverage to multiple measurement points. It defines spatial metrics 48 for measuring the performance of segments of a source to destination 49 path, and metrics for measuring the performance between a source and 50 many destinations in multiparty communications (e.g., a multicast 51 tree). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6 61 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 62 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 63 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 67 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 68 3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 69 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 70 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 71 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 72 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15 73 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16 74 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 18 75 5.1. A Definition of a sample of One-way Delay of a segment 76 of the path . . . . . . . . . . . . . . . . . . . . . . . 18 77 5.2. A Definition of a sample of Packet Loss of a segment 78 of the path . . . . . . . . . . . . . . . . . . . . . . . 20 79 5.3. A Definition of a sample of ipdv of a segment using 80 the previous packet selection function . . . . . . . . . . 22 81 5.4. A Definition of a sample of ipdv of a segment using 82 the minimum delay selection function . . . . . . . . . . . 24 83 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 25 84 6.1. A Definition for One-to-group One-way Delay . . . . . . . 26 85 6.2. A Definition for One-to-group One-way Packet Loss . . . . 26 86 6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 27 87 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 28 88 7.1. Discussion on the Impact of packet loss on statistics . . 31 89 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 32 90 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 33 91 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 36 92 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 38 93 8. Measurement Methods: Scalability and Reporting . . . . . . . . 38 94 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 39 95 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 40 96 8.3. Effect of Time and Space Aggregation Order on Stats . . . 40 97 9. Manageability Considerations . . . . . . . . . . . . . . . . . 42 98 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 42 99 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 43 100 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44 101 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44 102 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 47 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 104 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48 105 11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48 106 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 107 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 108 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 109 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 110 14.2. Informative References . . . . . . . . . . . . . . . . . . 55 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 112 Intellectual Property and Copyright Statements . . . . . . . . . . 57 114 1. Introduction 116 The IP Performance Metrics (IPPM) WG has defined a framework for 117 metric definitions and end-to-end, or source to destination 118 measurements: 120 o A general framework for defining performance metrics, described in 121 the Framework for IP Performance Metrics [RFC2330]; 123 The Working Group has specified a set of end-to-end metrics using the 124 framework, and a registry for the metrics: 126 o The IPPM Metrics for Measuring Connectivity [RFC2678]; 128 o The One-way Delay Metric for IPPM [RFC2679]; 130 o The One-way Packet Loss Metric for IPPM [RFC2680]; 132 o The Round-trip Delay Metric for IPPM [RFC2681]; 134 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 135 [RFC3148]; 137 o One-way Loss Pattern Sample Metrics [RFC3357]; 139 o IP Packet Delay Variation Metric for IPPM [RFC3393]; 141 o Network performance measurement for periodic streams [RFC3432]; 143 o Packet Reordering Metrics [RFC4737]; 145 o An IP Performance Metrics Registry [RFC4148]; 147 IPPM has also developed a protocol for one-way source to destination 148 measurements 150 o A One-way Active Measurement Protocol Requirements [RFC3763]; 152 o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; 154 This memo defines two new categories of metrics that extend the 155 coverage to multiple measurement points. It first defines spatial 156 metrics for measuring the performance of segments of a source to 157 destination path: 159 o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be 160 introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679] 161 into a spatial sequence of one-way delay metrics. 163 o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 164 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 165 [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. 172 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 173 called Type-P-Segment-One-way-Delay-Stream, will be introduced to 174 collect one-way delay metrics over time between two points of 175 interest of the path; 177 o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', 178 called Type-P-Segment-Packet-Loss-Stream, will be introduced to 179 collect packet loss metrics over time between two points of 180 interest of the path; 182 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 183 called Type-P-Segment-ipdv-prev-Stream, will be introduced to 184 compute ipdv metrics over time between two points of interest of 185 the path using the previous packet selection function; 187 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 188 called Type-P-Segment-ipdv-min-Stream, will be introduced to 189 compute ipdv metrics over time between two points of interest of 190 the path using the shortest delay selection function; 192 Note that all these metrics are based on observations of packets 193 dedicated to testing, a process which is called Active measurement. 194 Purely passive spatial measurement (for example, a spatial metric 195 based on the observation of user traffic) is beyond the scope of this 196 document and the current IPPM charter. 198 Next, this memo defines one-to-group metrics. 200 o Using one test packet sent from one sender to a group of 201 receivers, a metric called Type-P-one-to-group-One-way-Delay- 202 Vector will be introduced to collect the set of Type-P-one-way- 203 delay [RFC2679] singletons between this sender and the group of 204 receivers. 206 o Using one test packet sent from one sender to a group of 207 receivers, a metric called Type-P-one-to-group-One-way-Packet- 208 Loss-Vector, will be introduced to collect the set of Type-P-One- 209 way-Packet-Loss [RFC2680] singletons between this sender and the 210 group of receivers 212 o Using one test packet sent from one sender to a group of 213 receivers, a metric called Type-P-one-to-group-One-way-ipdv- 214 Vector, will be introduced to collect the set of Type-P-One-way- 215 ipdv singletons between this sender and the group of receivers 217 o A discussion section presents the set of statistics that may be 218 computed using these metrics to present the network performance in 219 the view of a group of users. The statistics may be the basis for 220 requirements (e.g. fairness) on multiparty communications. . 222 Metric Reporting is defined in the "Manageability Considerations" 223 section. 225 2. Terminology 227 2.1. Path Digest Hosts 229 The list of the hosts on a path from the source to the destination. 231 2.2. Multiparty metric 233 A metric is said to be multiparty if the topology involves more than 234 one measurement collection point. All multiparty metrics define a 235 set of hosts called "points of interest", where one host is the 236 source and other hosts are the measurement collection points. For 237 example, if the set of points of interest is < ha, hb, hc, ..., hn >, 238 where ha is the source and < hb, hc, ..., hn > are the destinations, 239 then measurements may be conducted between < ha, hb>, < ha, hc>, ..., 240 . 242 For the purposes of this memo (reflecting the scope of a single 243 source), the only multiparty metrics are one-to-group metrics. 245 2.3. Spatial metric 247 A metric is said to be spatial if one of the hosts (measurement 248 collection points) involved is neither the source nor a destination 249 of the measured packet. 251 2.4. One-to-group metric 253 A metric is said to be one-to-group if the measured packet is sent by 254 one source and (potentially) received by several destinations. Thus, 255 the topology of the communication group can be viewed as a centre- 256 distributed or server-client topology with the source as the centre/ 257 server in the topology. 259 2.5. Points of interest 261 Points of interest are the hosts* (as per RFC2330 definition, that 262 includes routing nodes) that are measurement collection points, a 263 sub-set of the set of hosts involved in the delivery of the packets 264 (in addition to the source itself). Note that the points of interest 265 are a possibly arbitrary sub-set of all the hosts involved in the 266 path. 268 Points of interest of one-to-group metrics are the intended 269 destination hosts for packets from the source (in addition to the 270 source itself). 272 Src Recv 273 `. ,-. 274 `. ,' `...... 1 275 `. ; : 276 `. ; : 277 ; :... 2 278 | | 279 : ; 280 : ;.... 3 281 : ; 282 `. ,' 283 `-'....... N 285 Figure 1: One-to-group points of interest 287 A candidate point of interest for spatial metrics is a host from the 288 set of hosts involved in the delivery of the packets from the source. 290 Src ------. Hosts 291 \ 292 `---X ... 1 293 \ 294 x 295 / 296 .---------X .... 2 297 / 298 x 299 \ 300 `---X .... 3 301 \ 302 \ 303 \ 304 X .... N 305 \ 306 \ 307 \ 308 `---- Dst 310 Note: 'x' are nodes which are not points of interest 312 Figure 2: Spatial points of interest 314 2.6. Reference point 316 A reference point is defined as the server where the statistical 317 calculations will be carried out. A centre/server in the 318 multimetrics measurement that is controlled by a network operator is 319 a good example of a reference point, where measurement data can be 320 collected for further processing. However, the actual measurements 321 have to be carried out at all points of interest. 323 2.7. Vector 325 A Vector is a set of singletons, which are a set of results of the 326 observation of the behaviour of the same packet at different places 327 of a network at different times. For instance, if one-way delay 328 singletons observed at N receivers for Packet P sent by the source 329 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 330 elements can be organized as {dT1, dT2,..., dTN}. The elements in 331 one vector are singletons distinct with each other in terms of both 332 measurement point and sending time. Given the vector V as an 333 example, the element dT1 is distinct from all others as the singleton 334 at receiver 1 in response to a packet sent from the source at time 335 T1. The complete Vector gives information over the dimension of 336 space. 338 2.8. Matrix 340 Several vectors form a Matrix, which contains results observed in a 341 sampling interval at different places in a network at different 342 times. For instance, given One-way delay vectors V1={dT11, dT12,..., 343 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 344 Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, 345 V2,...,Vm}. Additional to the information given by a Vector, a 346 Matrix is more powerful to present network performance in both space 347 and time dimensions. It normally corresponds to a sample in simple 348 point-to-point measurement. 350 The relation among Singleton, Vector and Matrix can be shown in the 351 following Figure 3. 353 Point of Singleton 354 interest / Samples 355 ,----. ^ / 356 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 357 / \ | | | 358 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 359 Src | || | | 360 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 361 | || | | 362 : ;| | | 363 \ / | | | 364 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 365 `-----' +-------------------------------------> time 367 Vector Matrix 368 (space) (time) 370 Figure 3: Relation beween Singletons, vectors and matrix 372 3. Motivations 374 All IPPM metrics are defined for end-to-end (source to destination) 375 measurement of point-to-point paths. It is a logical extension to 376 define metrics for multiparty measurements such as one to one 377 trajectory metrics and one to multipoint metrics. 379 3.1. Motivations for spatial metrics 381 Decomposition of instantaneous end-to-end measures is needed: 383 o Decomposing the performance of interdomain path is desirable to 384 quantify the per-AS contribution to the performance. It is 385 valuable to define standard spatial metrics before pursuing inter- 386 domain path performance specifications. 388 o Traffic engineering and troubleshooting applications benefit from 389 spatial views of one-way delay and ipdv consumption, and 390 identification of the location of the lost of packets. 392 o Monitoring the performance of a multicast tree composed of MPLS 393 point-to-multipoint and inter-domain communication require spatial 394 decomposition of the one-way delay, ipdv, and packet loss. 396 o Composition of metrics [I-D.ietf-ippm-spatial-composition] is 397 needed to help measurement systems reach large scale coverage. 398 Spatial measures typically give the individual performance of an 399 intra domain segment and provide an elementary piece of 400 information needed to estimate interdomain performance based on 401 composition of metrics. 403 3.2. Motivations for One-to-group metrics 405 While the node-to-node based spatial measures can provide very useful 406 data in the view of each connection, we also need measures to present 407 the performance of a multiparty communication topology. A simple 408 one-way metric cannot completely describe the multiparty situation. 409 New one-to-group metrics assess performance of all the paths for 410 further statistical analysis. The new metrics proposed in this stage 411 are named one-to-group performance metrics, and they are based on the 412 unicast metrics defined in IPPM WG. One-to-group metrics are one-way 413 metrics from one source to a group of destinations. The metrics are 414 helpful for judging the network performance of multiparty 415 communications and can also be used to describe the variation of 416 performance delivered to a group of destination hosts and their 417 users. 419 One-to-group performance metrics are needed for several reasons: 421 o For designing and engineering multicast trees and MPLS point-to- 422 multipoint LSP; 424 o For evaluating and controlling of the quality of the multicast 425 services; 427 o For controlling the performance of the inter domain multicast 428 services; 430 o For presenting and evaluating the performance requirements for 431 multiparty communications and overlay multicast. 433 To understand the packet transfer performance between one source and 434 any one receiver in the multiparty communication group, we need to 435 collect instantaneous end-to-end metrics, or singletons. It will 436 give a very detailed insight into each branch of the multicast tree 437 in terms of end-to-end absolute performance. This detail can provide 438 clear and helpful information for engineers to identify the sub-path 439 with problems in a complex multiparty routing tree. 441 The one-to-group metrics described in this memo introduce the 442 multiparty topology to the IPPM working group; the goal is to measure 443 the performance delivered to a group of users who are receiving 444 packets from the same source. The concept extends the "path" in the 445 one-way measurement to "path tree" to cover both one-to-one and one- 446 to-many communications. If applied to one-to-one communications, the 447 one-to-group metrics provide exactly the same results as the 448 corresponding one-to-one metrics. 450 3.3. Discussion on Group-to-one and Group-to-group metrics 452 We note that points of interest can also be selected to define 453 measurements on group-to-one and group-to-group topologies. These 454 topologies are currently beyond the scope of this memo, because they 455 would involve multiple packets launched from different sources. 456 However, we can give some clues here on these two cases. 458 The measurements for group-to-one topology can be easily derived from 459 the one-to-group measurement. The measurement point is the reference 460 point that is acting as a receiver while all of clients/receivers 461 defined for one-to-group measurement act as sources in this case. 463 For the group-to-group connection topology, it is difficult to define 464 the reference point and therefore it is difficult to define the 465 measurement points. However, we can always avoid this confusion by 466 treating the connections as one-to-group or group-to-one in our 467 measurements without consideration on how the real communication will 468 be carried out. For example, if one group of hosts < ha, hb, hc, 469 ..., hn > are acting as sources to send data to another group of 470 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 471 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 472 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 473 ..., Hm >. 475 4. Spatial vectors metrics definitions 477 This section defines vectors for the decomposition of end-to-end 478 singleton metrics over a path. 480 Spatial vectors metrics are based on the decomposition of standard 481 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 482 [RFC3393] and [RFC3432]. 484 Definitions are coupled with the corresponding end-to-end metrics. 485 Methodology specificities are common to all the vectors defined and 486 are consequently discussed in a common section. 488 4.1. A Definition for Spatial One-way Delay Vector 490 This section is coupled with the definition of Type-P-One-way-Delay 491 of the section 3 of [RFC2679]. When a parameter of this definitionis 492 first used in this section, it will be tagged with a trailing 493 asterisk. 495 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 496 statements for end-to-end one-way-delay measurements. They are 497 applicable to each point of interest Hi involved in the measure. 498 Spatial one-way-delay measurement SHOULD be respectful of them, 499 especially those related to methodology, clock, uncertainties and 500 reporting. 502 4.1.1. Metric Name 504 Type-P-Spatial-One-way-Delay-Vector 506 4.1.2. Metric Parameters 508 o Src*, the IP address of the sender. 510 o Dst*, the IP address of the receiver. 512 o i, An integer in the ordered list <1,2,...,n> of hosts in the 513 path. 515 o Hi, A host* of the path digest. 517 o T*, a time, the sending (or initial observation) time for a 518 measured packet. 520 o dT*, a delay, the one-way delay for a measured packet. 522 o a list of delay. 524 o P*, the specification of the packet type. 526 o , hosts path digest. 528 4.1.3. Metric Units 530 The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of 531 times. 533 4.1.4. Definition 535 Given a Type-P packet sent by the sender Src at wire-time (first bit) 536 T to the receiver Dst in the path . Given the 537 sequence of values such that dT is the 538 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 539 path, T+dTi is either a real number corresponding to the wire-time 540 the packet passes (last bit received) Hi, or undefined if the packet 541 never passes Hi. 543 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 544 as the sequence of values 545 . 547 4.1.5. Discussion 549 Following are specific issues which may occur: 551 o the delay looks to decrease: dTi > DTi+1. This may occur despite 552 it does not make sense per definition: 554 * This is frequently due to some clock synchronization issue. 555 This point is discussed in the section 3.7.1. "Errors or 556 uncertainties related to Clocks" of [RFC2679]. Consequently, 557 times of a measure at different hosts do not guaranty the 558 ordering of the hosts on the path of a measure. 560 * During some change of routes the order of 2 hosts may change on 561 the main path; 563 * The location of the point of interest in the device influences 564 the result. If the packet is not observed directly on the 565 input interface the delay includes buffering time and 566 consequently an uncertainty due to the difference between 'wire 567 time' and 'host time' 569 4.2. A Definition for Spatial One-way Packet Loss Vector 571 This section is coupled with the definition of Type-P-One-way-Packet- 572 Loss. Then when a parameter from the section 2 of [RFC2680] is first 573 used in this section, it will be tagged with a trailing asterisk. 575 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 576 statements for end-to-end one-way packet loss measurements. They are 577 applicable to each point of interest Hi involved in the measure. 578 Spatial packet loss measurement SHOULD be respectful of them, 579 especially those related to methodology, clock, uncertainties and 580 reporting. 582 Following we define the spatial metric, then we adapt some of the 583 points above and introduce points specific to spatial measurement. 585 4.2.1. Metric Name 587 Type-P-Spatial-One-way-Packet-Loss-Vector 589 4.2.2. Metric Parameters 591 o Src*, the IP address of the sender. 593 o Dst*, the IP address of the receiver. 595 o i, an integer which ordered the hosts in the path. 597 o Hi, points of interests of the path digest. 599 o T*, a time, the sending time for a measured packet. 601 o , a list of delay. 603 o P*, the specification of the packet type. 605 o , hosts path digest. 607 o , a list of Boolean values. 609 4.2.3. Metric Units 611 The value of Type-P-Spatial-One-way-Packet-Loss-Vector is a sequence 612 of Boolean values. 614 4.2.4. Definition 616 Given a Type-P packet sent by the sender Src at time T to the 617 receiver Dst in the path . Given the sequence of 618 times the packet passes in , 619 we define Type-P-One-way-Packet-Lost-Vector metric as the sequence of 620 values such that for each Hi of the path, a value 621 of 0 for Li means that dTi is a finite value, and a value of 1 means 622 that dTi is undefined. 624 4.2.5. Discussion 626 Following are specific issues which may occur: 628 o The result includes the sequence 1,0. This may occur under 629 specific situations: 631 * During some change of routes a packet may be seen by a host but 632 not by it successor on the main path; 634 * A packet may not be observed in a host due to some buffer or 635 CPU overflow in the point of interest; 637 4.3. A Definition for Spatial One-way Ipdv Vector 639 This section uses parameters from the definition of Type-P-One-way- 640 ipdv. When a parameter from section 2 of [RFC3393] is first used in 641 this section, it will be tagged with a trailing asterisk. 643 In the following we adapt some of them and introduce points specific 644 to spatial measurement. 646 4.3.1. Metric Name 648 Type-P-Spatial-One-way-ipdv-Vector 650 4.3.2. Metric Parameters 652 o Src*, the IP address of the sender. 654 o Dst*, the IP address of the receiver. 656 o i, An integer in the ordered list <1,2,...,n> of hosts in the 657 path. 659 o Hi, A host* of the path digest. 661 o T1*, a time, the sending time for a first measured packet. 663 o T2*, a time, the sending time for a second measured packet. 665 o dT*, a delay, the one-way delay for a measured packet. 667 o P*, the specification of the packets type. 669 o P1, the first packet sent at time T1. 671 o P2, the second packet sent at time T2. 673 o , hosts path digest. 675 o , the Type-P-Spatial-One-way- 676 Delay-Vector for packet sent at time T1. 678 o , the Type-P-Spatial-One-way- 679 Delay-Vector for packet sent at time T2. 681 o L*, a packet length in bits. The packets of a Type P packet 682 stream from which the Type-P-Spatial-One-way-Delay-Vector metric 683 is taken MUST all be of the same length. 685 4.3.3. Metric Units 687 The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of 688 times. 690 4.3.4. Definition 692 Given P1 the Type-P packet sent by the sender Src at wire-time (first 693 bit) T1 to the receiver Dst and 694 its Type-P-Spatial-One-way-Delay-Vector over the path . 697 Given P2 the Type-P packet sent by the sender Src at wire-time (first 698 bit) T2 to the receiver Dst and 699 its Type-P-Spatial-One-way-Delay-Vector over the same path. 701 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 702 of values such that for each Hi of the path , dT2.i-dT1.i 704 is either a real number if the packets P1 and P2 passe Hi at wire- 705 time (last bit) dT1.i, respectively dT2.i, or undefined if at least 706 one of them never passes Hi. T2-T1 is the inter-packet emission 707 interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. 709 4.4. Spatial Methodology 711 Methodology, reporting and uncertainties points specified in section 712 3 of [RFC2679] applies to each point of interest Hi measuring a 713 element of a spatial delay vector. 715 Methodology, reporting and uncertainties points specified in section 716 2 of [RFC2680] applies to each point of interest Hi measuring a 717 element of a spatial packet loss vector. 719 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 720 statements for end-to-end One-way ipdv measurements. They are 721 applicable to each point of interest Hi involved in the measure. 722 Spatial One-way ipdv measurement SHOULD be respectful of methodology, 723 clock, uncertainties and reporting aspects given in this section. 725 Generally, for a given Type-P of length L, in a given Hi, the 726 methodology for spatial vector metrics may proceed as follows: 728 o At each Hi, points of interest prepare to capture the packet sent 729 a time T, take a timestamp Ti', determine the internal delay 730 correction dTi' (See section 3.7.1. "Errors or uncertainties 731 related to Clocks" of [RFC2679]), 733 o Each Hi extracts the path ordering information from the packet 734 (e.g. time-to-live); 736 o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. 737 This arrival time is undefined (infinite) if the packet is not 738 detected after the 'loss threshold' duration; 740 o Each Hi extracts the timestamp T from the packet; 742 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 744 o The reference point gathers the result of each Hi and order them 745 according to the path ordering information received to build the 746 type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-Delay- 747 Vector metric ) over the path at time T. 750 4.4.1. Loss threshold 752 Loss threshold is the centrality of any methodology because it 753 determines the presence the packet in the measurement process of the 754 point of interest and consequently determines any ground truth metric 755 result. It determines the presence of an effective delay, and bias 756 the measure of ipdv, of packet loss and of the statistics. 758 This is consistent for end-to-end but impacts spatial measure: 759 depending on the consistency of the loss threshold among the points 760 of interest, a packet may be considered loss a one host but present 761 in another one, or may be observed by the last host (last hop) of the 762 path but considered lost by Dst. The analysis of such results is not 763 deterministic: Has the path change? Does the packet arrive at 764 destination or was it lost during the last mile? The same applies, 765 of course, for one-way-delay measures: a delay measured may be 766 infinite at one host but a real value in another one, or may be 767 measured as a real value by the last host of the path but observed as 768 infinite by Dst. The loss threshold should be set up with the same 769 value in each host of the path and in the destination. The loss 770 threshold must be systematically reported to permit careful 771 introspection and to avoid the introduction of any contradiction in 772 the statistic computation process. 774 4.4.2. Host Path Digest 776 The methodology given above relies on the order of the points of 777 interest over the path to [RFC2679] one's. 779 A test packets may cross several times the same host resulting in the 780 repetition of one or several hosts in the Path Digest. 782 As an example. This occurs typically during rerouting phases which 783 introduce temporary micro loops. During such an event the host path 784 digest for a packet crossing Ha and Hb may include the pattern meaning that Ha ended the computation of the new path 786 before Hb and that the initial path wath from Ha to Hb and that the 787 new path is from Hb to Ha. 789 Consequently, duplication of hosts in the Path Digest of a vectors 790 MUST be identified before statistics computation to avoid corrupted 791 results' production. 793 5. Spatial Segments metrics definitions 795 This section defines samples to measure the performance of a segment 796 of a path over time. Definitions rely on matrix of the spatial 797 vector metrics defined above. 799 Firstly it defines a sample of one-way delay, Type-P-Segment-One-way- 800 Delay-Stream, and a sample of packet loss, Type-P-segment-Packet- 801 loss-Stream. 803 Then it defines 2 different samples of ipdv. The first metric, Type- 804 P-Segment-One-way-ipdv-prev-Stream, uses the previous packet as the 805 selection function. The second metric, Type-P-Segment-One-way-ipdv- 806 min-Stream, uses the minimum delay as the selection. 808 5.1. A Definition of a sample of One-way Delay of a segment of the path 810 This metric defines a sample of One-way delays over time between a 811 pair of hosts of a path. 813 As its semantic is very close to the metric Type-P-Packet-loss-Stream 814 defined in section 4 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] 815 are part of the current definition. 817 5.1.1. Metric Name 819 Type-P-Segment-One-way-Delay-Stream 821 5.1.2. Metric Parameters 823 o Src*, the IP address of the sender. 825 o Dst*, the IP address of the receiver. 827 o P*, the specification of the packet type. 829 o i, an integer in the ordered list <1,2,...,n> of hosts in the 830 path. 832 o k, an integer which orders the packets sent. 834 o a and b, 2 integers where b > a. 836 o Hi, a host* of the path digest. 838 o , hosts path digest. 840 o , a list of times. 842 5.1.3. Metric Units 844 The value of a Type-P-Segment-One-way-Delay-Stream is a pair of 846 list of times ; 848 sequence of delays. 850 5.1.4. Definition 852 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 854 packets sent from Src to Dst at times : 856 ; 858 ; 860 ... 862 . 864 We define the sample Type-P-segment-One-way-Delay-Stream as the 865 sequence such that for 866 each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if 867 the packet send a time Tk passes Ha and Hb or undefined if this 868 packet never passes Ha or (inclusive) never passes Hb. 870 5.1.5. Discussion 872 Following are specific issues which may occur: 874 o the delay looks to decrease: dTi > DTi+1: 876 * This is typically due to clock synchronization issue. this 877 point is discussed in the section 3.7.1. "Errors or 878 uncertainties related to Clocks" of of [RFC2679]; 880 * This may occurs too when the clock resolution of one probe is 881 bigger than the minimum delay of a path. As an example this 882 happen when measuring the delay of a path which is 500 km long 883 with one probe synchronized using NTP having a clock resolution 884 of 8ms. 886 The metric can not be performed on < T1 , T2, ..., Tm-1, Tm> in the 887 following cases: 889 o Ha or Hb disappears from the path due to some change of routes; 891 o The order of Ha and Hb changes in the path; 893 5.2. A Definition of a sample of Packet Loss of a segment of the path 895 This metric defines a sample of packet lost over time between a pair 896 of hosts of a path. As its semantic is very close to the metric 897 Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], sections 898 3.5 to 3.8 of [RFC2680] are part of the current definition. 900 5.2.1. Metric Name 902 Type-P-segment-Packet-loss-Stream 904 5.2.2. Metric Parameters 906 o Src*, the IP address of the sender. 908 o Dst*, the IP address of the receiver. 910 o P*, the specification of the packet type. 912 o k, an integer which orders the packets sent. 914 o n, an integer which orders the hosts on the path. 916 o a and b, 2 integers where b > a. 918 o , hosts path digest. 920 o Hi, exchange points of the path digest. 922 o , a list of times. 924 o a list of boolean values. 926 5.2.3. Metric Units 928 The value of a Type-P-segment-Packet-loss-Stream is a pair of 930 The list of times ; 932 a sequence of booleans. 934 5.2.4. Definition 936 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-Packet-loss-Vector for the 938 packets sent from Src to Dst at times : 940 , 942 , 944 ..., 946 . 948 We define the value of the sample Type-P-segment-Packet-Lost-Stream 949 from Ha to Hb as the sequence of booleans such that for each Tk: 952 o A value of Lk of 0 means that Ha and Hb observed the packet sent 953 at time Tk (Lk.a and Lk.b have a value of 0); 955 o A value of Lk of 1 means that Ha observed the packet sent at time 956 Tk (Lk.a has a value of 0) and that Hb did not observed the packet 957 sent at time Tk (Lk.b have a value of 1); 959 o The value of Lk is undefined when Neither Ha or Hb observe the 960 packet; 962 5.2.5. Discussion 964 Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-loss-Stream 965 relies on the stability of the host path digest. The metric can not 966 be performed on < T1 , T2, ..., Tm-1, Tm> in the following cases: 968 o Ha or Hb disappears from the path due to some change of routes; 970 o the order of Ha and Hb changes in the path; 972 o Lk.a or Lk.b is undefined; 974 o Lk.a has the value 1 (not observed) and Lk.b has the value 0 975 (observed); 977 o L has the value 0 (the packet was received by Dst) and Lk.ab has 978 the value 1 (the packet was lost between Ha and Hb). 980 5.3. A Definition of a sample of ipdv of a segment using the previous 981 packet selection function 983 This metric defines a sample of ipdv [RFC3393] over time between a 984 pair of hosts using the previous packet as the selection function. 986 5.3.1. Metric Name 988 Type-P-Segment-One-way-ipdv-prev-Stream 990 5.3.2. Metric Parameters 992 o Src*, the IP address of the sender. 994 o Dst*, the IP address of the receiver. 996 o P*, the specification of the packet type. 998 o k, an integer which orders the packets sent. 1000 o n, an integer which orders the hosts on the path. 1002 o a and b, 2 integers where b > a. 1004 o , the hosts path digest. 1006 o , a list of times. 1008 o , a 1009 Type-P-Spatial-One-way-Delay-Vector. 1011 5.3.3. Metric Units 1013 The value of a Type-P-Segment-One-way-ipdv-prev-Stream is a pair of: 1015 The list of ; 1017 A list of pairs of interval of times and delays; 1019 5.3.4. Definition 1021 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 1023 packets sent from Src to Dst at times : 1025 , 1027 , 1029 ... 1031 . 1033 We define the Type-P-Segment-One-way-ipdv-prev-Stream as the sequence 1034 of pair of packet intervals and delay variations <(dT2_1.a , dT2.ab - 1035 dT1.ab) ,..., (dTk_k-1.a, dTk.ab - dTk-1.ab), ..., (dTm_m-1.a, dTm.ab 1036 - dTm-1.ab)> such that for each Tk: 1038 o dTk_k-1.a is either undefined if the delay dTk.a or the delay 1039 dTk-1.a is undefined, or the interval of time, 'dTk.a - dTk-1.a', 1040 between the 2 packets at Ha; 1042 o dTk_k-1.ab, is either undefined if one of the delays dTk.b, dTk.a, 1043 dTk-1.b or dTk-1.a is undefined, or , (dTk.b - dTk.a) - (dTk-1.b - 1044 dTk-1.a), the delay variation from Ha to Hb between the 2 packets 1045 sent at time Tk and Tk-1. 1047 5.3.5. Discussion 1049 This metric belongs to the family of inter packet delay variation 1050 metrics (IPDV in upper case) which results can be extremely sensitive 1051 to the inter-packet interval. 1053 The inter-packet interval of a end-to-end IPDV metric is under the 1054 control of the ingress point of interest which corresponds exactly to 1055 the Source of the packet. Unlikely, the inter-packet interval of a 1056 segment IPDV metric is not under the control the ingress point of 1057 interest of the measure, Ha. However, the interval will vary if 1058 there is delay variation between the Source and Ha. Therefore, the 1059 actual inter-packet interval must be known at Ha in order to fully 1060 comprehend the delay variation between Ha and Hb. 1062 5.4. A Definition of a sample of ipdv of a segment using the minimum 1063 delay selection function 1065 This metric defines a sample of ipdv [RFC3393] over time between a 1066 pair of hosts of a path using the shortest delay as the selection 1067 function. 1069 5.4.1. Metric Name 1071 Type-P-Segment-One-way-ipdv-min-Stream 1073 5.4.2. Metric Parameters 1075 o Src*, the IP address of the sender. 1077 o Dst*, the IP address of the receiver. 1079 o P*, the specification of the packet type. 1081 o k, an integer which orders the packets sent. 1083 o i, an integer which identifies a packet sent. 1085 o n, an integer which orders the hosts on the path. 1087 o a and b, 2 integers where b > a. 1089 o , the hosts path digest. 1091 o , a list of times. 1093 o , a 1094 Type-P-Spatial-One-way-Delay-Vector. 1096 5.4.3. Metric Units 1098 The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: 1100 The list of ; 1101 A list of times; 1103 5.4.4. Definition 1105 Given 2 hosts, Ha and Hb, of the path , given the matrix of Type-P-Spatial-One-way-Delay-Vector for the 1107 packets sent from Src to Dst at times : 1109 , 1111 , 1113 ... 1115 . 1117 We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence 1118 of times such that: 1121 min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); 1123 for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) 1124 dTk.b is undefined, or the real number (dTk.b - dTk.a). 1126 5.4.5. Discussion 1128 This metric belongs to the family of packet delay variation metrics 1129 (PDV). PDV distributions are less sensitive to inter-packet interval 1130 variations than IPDV results. 1132 In principle, the PDV distribution reflects the variation over many 1133 different inter-packet intervals, from the smallest inter-packet 1134 interval, up to the length of the evaluation interval, Tm - T1. 1135 Therefore, when delay variation occurs and disturbs the packet 1136 spacing observed at Ha, the PDV results will likely compare favorably 1137 to a PDV measurement where the source is Ha and the destination is 1138 Hb. 1140 6. One-to-group metrics definitions 1142 This metric defines metrics to measure the performance between a 1143 source and a group of receivers. 1145 6.1. A Definition for One-to-group One-way Delay 1147 This metric defines a metric to measure one-way delay between a 1148 source and a group of receivers. 1150 6.1.1. Metric Name 1152 Type-P-One-to-group-One-way-Delay-Vector 1154 6.1.2. Metric Parameters 1156 o Src, the IP address of a host acting as the source. 1158 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1159 receivers. 1161 o T, a time. 1163 o dT1,...,dTn a list of time. 1165 o P, the specification of the packet type. 1167 o Gr, the receiving group identifier. The parameter Gr is the 1168 multicast group address if the measured packets are transmitted 1169 over IP multicast. This parameter is to differentiate the 1170 measured traffic from other unicast and multicast traffic. It is 1171 optional in the metric to avoid losing any generality, i.e. to 1172 make the metric also applicable to unicast measurement where there 1173 is only one receiver. 1175 6.1.3. Metric Units 1177 The value of a Type-P-One-to-group-One-way-Delay-Vector is a set of 1178 Type-P-One-way-Delay singletons [RFC2679]. 1180 6.1.4. Definition 1182 Given a Type P packet sent by the source Src at Time T, given the N 1183 hosts { Recv1,...,RecvN } which receive the packet at the time { 1184 T+dT1,...,T+dTn }, a Type-P-One-to-group-One-way-Delay-Vector is 1185 defined as the set of the Type-P-One-way-Delay singleton between Src 1186 and each receiver with value of { dT1, dT2,...,dTn }. 1188 6.2. A Definition for One-to-group One-way Packet Loss 1189 6.2.1. Metric Name 1191 Type-P-One-to-group-One-way-Packet-Loss-Vector 1193 6.2.2. Metric Parameters 1195 o Src, the IP address of a host acting as the source. 1197 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1198 receivers. 1200 o T, a time. 1202 o T1,...,Tn a list of time. 1204 o P, the specification of the packet type. 1206 o Gr, the receiving group identifier. 1208 6.2.3. Metric Units 1210 The value of a Type-P-One-to-group-One-way-Packet-Loss-Vector is a 1211 set of Type-P-One-way-Packet-Loss singletons [RFC2680]. 1213 6.2.4. Definition 1215 Given a Type P packet sent by the source Src at T and the N hosts, 1216 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 1217 Type-P-One-to-group-One-way-Packet-Loss-Vector is defined as a set of 1218 the Type-P-One-way-Packet-Loss singleton between Src and each of the 1219 receivers {,,..., }. 1221 6.3. A Definition for One-to-group One-way Ipdv 1223 6.3.1. Metric Name 1225 Type-P-One-to-group-One-way-ipdv-Vector 1227 6.3.2. Metric Parameters 1229 o Src, the IP address of a host acting as the source. 1231 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1232 receivers. 1234 o T1, a time. 1236 o T2, a time. 1238 o ddT1, ...,ddTn, a list of time. 1240 o P, the specification of the packet type. 1242 o F, a selection function defining unambiguously the two packets 1243 from the stream selected for the metric. 1245 o Gr, the receiving group identifier. 1247 6.3.3. Metric Units 1249 The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of 1250 Type-P-One-way-ipdv singletons [RFC3393]. 1252 6.3.4. Definition 1254 Given a Type P packet stream, Type-P-One-to-group-One-way-ipdv-Vector 1255 is defined for two packets from the source Src to the N hosts 1256 {Recv1,...,RecvN },which are selected by the selection function F, as 1257 the difference between the value of the Type-P-One-to-group-One-way- 1258 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1259 value of the Type-P-One-to-group-One-way-Delay-Vector from Src to { 1260 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1261 the first bit of the first packet, and T2 is the wire-time at which 1262 Src sent the first bit of the second packet. This metric is derived 1263 from the Type-P-One-to-group-One-way-Delay-Vector metric. 1265 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-One-to- 1266 group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 1267 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1268 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1269 and the packets were received by { Recv1,...,RecvN } at wire-time 1270 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1271 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1272 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1274 7. One-to-Group Sample Statistics 1276 The defined one-to-group metrics above can all be directly achieved 1277 from the relevant unicast one-way metrics. They collect all unicast 1278 measurement results of one-way metrics together in one profile and 1279 sort them by receivers and packets in a receiving group. They 1280 provide sufficient information regarding the network performance in 1281 terms of each receiver and guide engineers to identify potential 1282 problem happened on each branch of a multicast routing tree. 1284 However, these metrics cannot be directly used to conveniently 1285 present the performance in terms of a group and neither to identify 1286 the relative performance situation. 1288 From the performance point of view, the multiparty communication 1289 services not only require the absolute performance support but also 1290 the relative performance. The relative performance means the 1291 difference between absolute performance of all users. Directly using 1292 the one-way metrics cannot present the relative performance 1293 situation. However, if we use the variations of all users one-way 1294 parameters, we can have new metrics to measure the difference of the 1295 absolute performance and hence provide the threshold value of 1296 relative performance that a multiparty service might demand. A very 1297 good example of the high relative performance requirement is the 1298 online gaming. A very light difference in delay might result in 1299 failure in the game. We have to use multicast specific statistic 1300 metrics to define exactly how small the relative delay the online 1301 gaming requires. There are many other services, e.g. online biding, 1302 online stock market, etc., that require multicast metrics in order to 1303 evaluate the network against their requirements. Therefore, we can 1304 see the importance of new, multicast specific, statistic metrics to 1305 feed this need. 1307 We might also use some one-to-group statistic conceptions to present 1308 and report the group performance and relative performance to save the 1309 report transmission bandwidth. Statistics have been defined for One- 1310 way metrics in corresponding RFCs. They provide the foundation of 1311 definition for performance statistics. For instance, there are 1312 definitions for minimum and maximum One-way delay in [RFC2679]. 1313 However, there is a dramatic difference between the statistics for 1314 one-to-one communications and for one-to-many communications. The 1315 former one only has statistics over the time dimension while the 1316 later one can have statistics over both time and space dimensions. 1317 This space dimension is introduced by the Matrix concept as 1318 illustrated in Figure 4. For a Matrix M each row is a set of One-way 1319 singletons spreading over the time dimension and each column is 1320 another set of One-way singletons spreading over the space dimension. 1322 Receivers 1323 Space 1324 ^ 1325 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1326 | | | 1327 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1328 | | | 1329 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1330 . | | | 1331 . | | | 1332 . | | | 1333 n | \ RndT1 RndT2 RndT3 ... RndTk / 1334 +--------------------------------------------> time 1335 T0 1337 Figure 4: Matrix M (n*m) 1339 In Matrix M, each element is a one-way delay singleton. Each column 1340 is a delay vector contains the One-way delays of the same packet 1341 observed at M points of interest. It implies the geographical factor 1342 of the performance within a group. Each row is a set of One-way 1343 delays observed during a sampling interval at one of the points of 1344 interest. It presents the delay performance at a receiver over the 1345 time dimension. 1347 Therefore, one can either calculate statistics by rows over the space 1348 dimension or by columns over the time dimension. It's up to the 1349 operators or service provides which dimension they are interested in. 1350 For example, a TV broadcast service provider might want to know the 1351 statistical performance of each user in a long term run to make sure 1352 their services are acceptable and stable. While for an online gaming 1353 service provider, he might be more interested to know if all users 1354 are served fairly by calculating the statistics over the space 1355 dimension. This memo does not intend to recommend which of the 1356 statistics are better than the other. 1358 To save the report transmission bandwidth, each point of interest can 1359 send statistics in a pre-defined time interval to the reference point 1360 rather than sending every one-way singleton it observed. As long as 1361 an appropriate time interval is decided, appropriate statistics can 1362 represent the performance in a certain accurate scale. How to decide 1363 the time interval and how to bootstrap all points of interest and the 1364 reference point depend on applications. For instance, applications 1365 with lower transmission rate can have the time interval longer and 1366 ones with higher transmission rate can have the time interval 1367 shorter. However, this is out of the scope of this memo. 1369 Moreover, after knowing the statistics over the time dimension, one 1370 might want to know how this statistics distributed over the space 1371 dimension. For instance, a TV broadcast service provider had the 1372 performance Matrix M and calculated the One-way delay mean over the 1373 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1374 calculated the mean of all the elements in the Vector to see what 1375 level of delay he has served to all N users. This new delay mean 1376 gives information on how good the service has been delivered to a 1377 group of users during a sampling interval in terms of delay. It 1378 needs twice calculation to have this statistic over both time and 1379 space dimensions. We name this kind of statistics 2-level statistics 1380 to distinct with those 1-level statistics calculated over either 1381 space or time dimension. It can be easily prove that no matter over 1382 which dimension a 2-level statistic is calculated first, the results 1383 are the same. I.e. one can calculate the 2-level delay mean using 1384 the Matrix M by having the 1-level delay mean over the time dimension 1385 first and then calculate the mean of the obtained vector to find out 1386 the 2-level delay mean. Or, he can do the 1-level statistic 1387 calculation over the space dimension first and then have the 2-level 1388 delay mean. Both two results will be exactly the same. Therefore, 1389 when define a 2-level statistic, there is no need to specify in which 1390 procedure the calculation should follow. 1392 Comment: The above statement depends on whether the order of 1393 operations has any affect on the outcome. 1395 Many statistics can be defined for the proposed one-to-group metrics 1396 over either the space dimension or the time dimension or both. This 1397 memo treats the case where a stream of packets from the Source 1398 results in a sample at each of the Receivers in the Group, and these 1399 samples are each summarized with the usual statistics employed in 1400 one-to-one communication. New statistic definitions are presented, 1401 which summarize the one-to-one statistics over all the Receivers in 1402 the Group. 1404 7.1. Discussion on the Impact of packet loss on statistics 1406 The packet loss does have effects on one-way metrics and their 1407 statistics. For example, the lost packet can result an infinite one- 1408 way delay. It is easy to handle the problem by simply ignoring the 1409 infinite value in the metrics and in the calculation of the 1410 corresponding statistics. However, the packet loss has so strong 1411 impact on the statistics calculation for the one-to-group metrics 1412 that it can not be solved by the same method used for one-way 1413 metrics. This is due to the complex of building a Matrix, which is 1414 needed for calculation of the statistics proposed in this memo. 1416 The situation is that measurement results obtained by different end 1417 users might have different packet loss pattern. For example, for 1418 User1, packet A was observed lost. And for User2, packet A was 1419 successfully received but packet B was lost. If the method to 1420 overcome the packet loss for one-way metrics is applied, the two 1421 singleton sets reported by User1 and User2 will be different in terms 1422 of the transmitted packets. Moreover, if User1 and User2 have 1423 different number of lost packets, the size of the results will be 1424 different. Therefore, for the centralized calculation, the reference 1425 point will not be able to use these two results to build up the group 1426 Matrix and can not calculate the statistics. In an extreme 1427 situation, no single packet arrives all users in the measurement and 1428 the Matrix will be empty. One of the possible solutions is to 1429 replace the infinite/undefined delay value by the average of the two 1430 adjacent values. For example, if the result reported by user1 is { 1431 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1432 is an undefined value, the reference point can replace it by R1dTK = 1433 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1434 build up the group Matrix with an estimated value R1dTK. There are 1435 other possible solutions such as using the overall mean of the whole 1436 result to replace the infinite/undefined value, and so on. It is out 1437 of the scope of this memo. 1439 For the distributed calculation, the reported statistics might have 1440 different "weight" to present the group performance, which is 1441 especially true for delay and ipdv relevant metrics. For example, 1442 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1443 in Figure. 8 without any packet loss and User2 calculates the R2DM 1444 with N-2 packet loss. The R1DM and R2DM should not be treated with 1445 equal weight because R2DM was calculated only based on 2 delay values 1446 in the whole sample interval. One possible solution is to use a 1447 weight factor to mark every statistic value sent by users and use 1448 this factor for further statistic calculation. 1450 7.2. General Metric Parameters 1452 o Src, the IP address of a host; 1454 o G, the receiving group identifier; 1456 o N, the number of Receivers (Recv1, Recv2, ... RecvN); 1458 o T, a time (start of test interval); 1460 o Tf, a time (end of test interval); 1462 o K, the number of packets sent from the source during the test 1463 interval; 1465 o J[n], the number of packets received at a particular Receiver, n, 1466 where 1<=n<=N; 1468 o lambda, a rate in reciprocal seconds (for Poisson Streams); 1470 o incT, the nominal duration of inter-packet interval, first bit to 1471 first bit (for Periodic Streams); 1473 o T0, a time that MUST be selected at random from the interval [T, 1474 T+I] to start generating packets and taking measurements (for 1475 Periodic Streams); 1477 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1478 Source Measurement Point); 1480 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1481 assigned to packets that arrive within a "reasonable" time; 1483 o Tmax, a maximum waiting time for packets at the destination, set 1484 sufficiently long to disambiguate packets with long delays from 1485 packets that are discarded (lost), thus the distribution of delay 1486 is not truncated; 1488 o dT, shorthand notation for a one-way delay singleton value; 1490 o L, shorthand notation for a one-way loss singleton value, either 1491 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1492 the destination within TstampSrc + Tmax, may be indexed over n 1493 Receivers; 1495 o DV, shorthand notation for a one-way delay variation singleton 1496 value; 1498 7.3. One-to-Group one-way Delay Statistics 1500 This section defines the overall one-way delay statistics for an 1501 entire Group or receivers. For example, we can define the group mean 1502 delay, as illustrated below. This is a metric designed to summarize 1503 the whole matrix. 1505 Recv /----------- Sample -------------\ Stats Group Stat 1507 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1508 | 1509 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 1510 | 1511 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD 1512 . | 1513 . | 1514 . | 1515 n RndT1 RndT2 RndT3 ... RndTk RnDM / 1517 Figure 5: One-to-Group Mean Delay 1519 where: 1521 R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at 1522 Receiver 1 for packet 1. 1524 R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 1525 for the sample of packets (1,...K). 1527 GMD is the mean of the sample means over all Receivers (1, ...N). 1529 7.3.1. Definition and Metric Units 1531 Using the parameters above, we obtain the value of Type-P-One-way- 1532 Delay singleton for all packets sent during the test interval at each 1533 Receiver (Destination), as per [RFC2679]. For each packet that 1534 arrives within Tmax of its sending time, TstampSrc, the one-way delay 1535 singleton (dT) will be a finite value in units of seconds. 1536 Otherwise, the value of the singleton is Undefined. 1538 For each packet [i] that has a finite One-way Delay at Receiver n (in 1539 other words, excluding packets which have undefined one-way delay): 1541 Type-P-Finite-One-way-Delay-Receiver-n-[i] = 1543 = TstampRecv[i] - TstampSrc[i] 1545 The units of Finite one-way delay are seconds, with sufficient 1546 resolution to convey 3 significant digits. 1548 7.3.2. Sample Mean Statistic 1550 This section defines the Sample Mean at each of N Receivers. 1552 Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = 1553 J[n] 1554 --- 1555 1 \ 1556 --- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] 1557 J[n] / 1558 --- 1559 i = 1 1561 Figure 6: Type-P-Finite-One-way-Delay-Mean-Receiver-n 1563 where all packets i= 1 through J[n] have finite singleton delays. 1565 7.3.3. One-to-Group Mean Delay Statistic 1567 This section defines the Mean One-way Delay calculated over the 1568 entire Group (or Matrix). 1570 Type-P-One-to-Group-Mean-Delay = GMD = 1571 N 1572 --- 1573 1 \ 1574 - * > RnDM 1575 N / 1576 --- 1577 n = 1 1579 Figure 7: Type-P-One-to-Group-Mean-Delay 1581 Note that the Group Mean Delay can also be calculated by summing the 1582 Finite one-way Delay singletons in the Matrix, and dividing by the 1583 number of Finite One-way Delay singletons. 1585 7.3.4. One-to-Group Range of Mean Delays 1587 This section defines a metric for the range of mean delays over all N 1588 receivers in the Group, (R1DM, R2DM,...RnDM). 1590 Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1592 7.3.5. One-to-Group Maximum of Mean Delays 1594 This section defines a metrics for the maximum of mean delays over 1595 all N receivers in the Group, (R1DM, R2DM,...RnDM). 1597 Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) 1599 7.4. One-to-Group one-way Loss Statistics 1601 This section defines the overall 1-way loss statistics for an entire 1602 Group. For example, we can define the group loss ratio, as 1603 illustrated below. This is a metric designed to summarize the entire 1604 Matrix. 1606 Recv /----------- Sample ----------\ Stats Group Stat 1608 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1609 | 1610 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1611 | 1612 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR 1613 . | 1614 . | 1615 . | 1616 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1618 Figure 8: One-to-Group Loss Ratio 1620 where: 1622 R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 1623 for packet 1. 1625 R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the 1626 sample of packets (1,...K). 1628 GLR is the loss ratio over all Receivers (1, ..., N). 1630 7.4.1. One-to-Group Loss Ratio 1632 The overall Group loss ratio id defined as 1634 Type-P-One-to-Group-Loss-Ratio = 1635 K,N 1636 --- 1637 1 \ 1638 = --- * > L(k,n) 1639 K*N / 1640 --- 1641 k,n = 1 1643 Figure 9 1645 ALL Loss ratios are expressed in units of packets lost to total 1646 packets sent. 1648 7.4.2. One-to-Group Loss Ratio Range 1650 Given a Matrix of loss singletons as illustrated above, determine the 1651 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1652 according to the definitions and method of [RFC2680]. The Type-P- 1653 One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- 1654 way-Loss-Ratio illustrated above are equivalent metrics. In terms of 1655 the parameters used here, these metrics definitions can be expressed 1656 as 1658 Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = 1659 K 1660 --- 1661 1 \ 1662 - * > RnLk 1663 K / 1664 --- 1665 k = 1 1667 Figure 10: Type-P-One-way-Loss-Ratio-Receiver-n 1669 The One-to-Group Loss Ratio Range is defined as 1671 Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) 1673 It is most effective to indicate the range by giving both the max and 1674 minimum loss ratios for the Group, rather than only reporting the 1675 difference between them. 1677 7.4.3. Comparative Loss Ratio 1679 Usually, the number of packets sent is used in the denominator of 1680 packet loss ratio metrics. For the comparative metrics defined here, 1681 the denominator is the maximum number of packets received at any 1682 receiver for the sample and test interval of interest. 1684 The Comparative Loss Ratio is defined as 1686 Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = 1687 K 1688 --- 1689 \ 1690 > Ln(k) 1691 / 1692 --- 1693 k=1 1694 = ----------------------------- 1695 / K \ 1696 | --- | 1697 | \ | 1698 K - Min | > Ln(k) | 1699 | / | 1700 | --- | 1701 \ k=1 / N 1703 Figure 11: Type-P-Comp-Loss-Ratio-Receiver-n 1705 7.5. One-to-Group one-way Delay Variation Statistics 1707 There are two delay variation (DV) statistics that summarize the 1708 performance over the Group: the maximum DV over all receivers and the 1709 minimum DV over all receivers (where DV is a point-to-point metric). 1710 For each receiver, the DV is usually expressed as the 1-10^(-3) 1711 quantile of one-way delay minus the minimum one-way delay. 1713 8. Measurement Methods: Scalability and Reporting 1715 Virtually all the guidance on measurement processes supplied by the 1716 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1717 scenarios is applicable here in the spatial and multiparty 1718 measurement scenario. The main difference is that the spatial and 1719 multiparty configurations require multiple measurement points where a 1720 stream of singletons will be collected. The amount of information 1721 requiring storage grows with both the number of metrics and the 1722 number of measurement points, so the scale of the measurement 1723 architecture multiplies the number of singleton results that must be 1724 collected and processed. 1726 It is possible that the architecture for results collection involves 1727 a single aggregation point with connectivity to all the measurement 1728 points. In this case, the number of measurement points determines 1729 both storage capacity and packet transfer capacity of the host acting 1730 as the aggregation point. However, both the storage and transfer 1731 capacity can be reduced if the measurement points are capable of 1732 computing the summary statistics that describe each measurement 1733 interval. This is consistent with many operational monitoring 1734 architectures today, where even the individual singletons may not be 1735 stored at each measurement point. 1737 In recognition of the likely need to minimize form of the results for 1738 storage and communication, the Group metrics above have been 1739 constructed to allow some computations on a per-Receiver basis. This 1740 means that each Receiver's statistics would normally have an equal 1741 weight with all other Receivers in the Group (regardless of the 1742 number of packets received). 1744 8.1. Computation methods 1746 The scalability issue can be raised when there are thousands of 1747 points of interest in a group who are trying to send back the 1748 measurement results to the reference point for further processing and 1749 analysis. The points of interest can send either the whole measured 1750 sample or only the calculated statistics. The former one is a 1751 centralized statistic calculation method and the latter one is a 1752 distributed statistic calculation method. The sample should include 1753 all metrics parameters, the values and the corresponding sequence 1754 numbers. The transmission of the whole sample can cost much more 1755 bandwidth than the transmission of the statistics that should include 1756 all statistic parameters specified by policies and the additional 1757 information about the whole sample, such as the size of the sample, 1758 the group address, the address of the point of interest, the ID of 1759 the sample session, and so on. Apparently, the centralized 1760 calculation method can require much more bandwidth than the 1761 distributed calculation method when the sample size is big. This is 1762 especially true when the measurement has huge number of the points of 1763 interest. It can lead to a scalability issue at the reference point 1764 by over load the network resources. The distributed calculation 1765 method can save much more bandwidth and release the pressure of the 1766 scalability issue at the reference point side. However, it can 1767 result in the lack of information because not all measured singletons 1768 are obtained for building up the group matrix. The performance over 1769 time can be hidden from the analysis. For example, the loss pattern 1770 can be missed by simply accepting the loss ratio as well as the delay 1771 pattern. This tradeoff between the bandwidth consuming and the 1772 information acquiring has to be taken into account when design the 1773 measurement campaign to optimize the measurement results delivery. 1774 The possible solution could be to transit the statistic parameters to 1775 the reference point first to obtain the general information of the 1776 group performance. If the detail results are required, the reference 1777 point should send the requests to the points of interest, which could 1778 be particular ones or the whole group. This procedure can happen in 1779 the off peak time and can be well scheduled to avoid delivery of too 1780 many points of interest at the same time. Compression techniques can 1781 also be used to minimize the bandwidth required by the transmission. 1782 This could be a measurement protocol to report the measurement 1783 results. It is out of the scope of this memo. 1785 8.2. Measurement 1787 To prevent any bias in the result, the configuration of a one-to-many 1788 measure must take in consideration that implicitly more packets will 1789 to be routed than send and selects a test packets rate that will not 1790 impact the network performance. 1792 8.3. Effect of Time and Space Aggregation Order on Stats 1794 This section presents the impact of the aggregation order on the 1795 scalability of the reporting and of the computation. It makes the 1796 hypothesis that receivers are managed remotely and not co-located. 1798 multimetrics samples represented a matrix as illustrated below 1800 Point of 1801 interest 1802 1 R1S1 R1S1 R1S1 ... R1Sk \ 1803 | 1804 2 R2S1 R2S2 R2S3 ... R2Sk | 1805 | 1806 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1807 . | 1808 . | 1809 . | 1810 n RnS1 RnS2 RnS3 ... RnSk / 1812 S1M S2M S3M ... SnM Stats over space 1814 \------------- ------------/ 1815 \/ 1816 Stat over space and time 1818 Figure 12: Impact of space aggregation on multimetrics Stat 1820 2 methods are available to compute statistics on the resulting 1821 matrix: 1823 o metric is computed over time and then over space; 1824 o metric is computed over space and then over time. 1826 They differ only by the order of the time and of the space 1827 aggregation. View as a matrix this order is neutral as does not 1828 impact the result, but the impact on a measurement deployment is 1829 critical. 1831 In both cases the volume of data to report is proportional to the 1832 number of probes. But there is a major difference between these 2 1833 methods: 1835 method2: In space and time aggregation mode the volume of data to 1836 collect is proportional to the number of test packets received; 1837 Each received packet RiSi triggers out a block of data that must 1838 be reported to a common place for computing the stat over space; 1840 method1: In time and space aggregation mode the volume of data to 1841 collect is proportional to the period of aggregation, so it does 1842 not depend on the number of packet received; 1844 Method 2 property has severe drawbacks in terms of security and 1845 dimensioning: 1847 The increasing of the rate of the test packets may result in a 1848 sort of DoS toward the computation points; 1850 The dimensioning of a measurement system is quite impossible to 1851 validate. 1853 The time aggregation interval provides the reporting side with a 1854 control of various collecting aspects such as bandwidth and 1855 computation and storage capacities. So this draft defines metrics 1856 based on method 1. 1858 Note: In some specific cases one may need sample of singletons over 1859 space. To address this need it is suggested firstly to limit the 1860 number of test and the number of test packets per seconds. Then 1861 reducing the size of the sample over time to one packet give sample 1862 of singleton over space.. 1864 8.3.1. Impact on group stats 1866 2 methods are available to compute group statistics: 1868 o method1: Figure 5 andFigure 8 illustrate the method chosen: the 1869 one-to-one statistic is computed per interval of time before the 1870 computation of the mean over the group of receivers; 1872 o method2: Figure 12 presents the second one, metric is computed 1873 over space and then over time. 1875 8.3.2. Impact on spatial stats 1877 2 methods are available to compute spatial statistics: 1879 o method 1: spatial segment metrics and statistics are preferably 1880 computed over time by each points of interest; 1882 o method 2: Vectors metrics are intrinsically instantaneous space 1883 metrics which must be reported using method2 whenever 1884 instantaneous metrics information is needed. 1886 9. Manageability Considerations 1888 Usually IPPM WG documents defines each metric reporting within its 1889 definition. This document defines the reporting of all the metrics 1890 introduced in a single section to provide consistent information 1891 while avoiding repetitions. The aim is to contribute to the work of 1892 the WG on the reporting and to satisfy IESG recommendation of 1893 gathering manageability considerations in a dedicated section. 1895 Data models of spatial and one-to-group metrics are similar excepted 1896 that points of interests of spatial vectors must be ordered. 1898 The complexity of the reporting relies on the number of points of 1899 interests. 1901 9.1. Reporting spatial metric 1903 The reporting of spatial metrics shares a lot of aspects with 1904 RFC2679-80. New ones are common to all the definitions and are 1905 mostly related to the reporting of the path and of methodology 1906 parameters that may bias raw results analysis. This section presents 1907 these specific parameters and then lists exhaustively the parameters 1908 that shall be reported. 1910 9.1.1. Path 1912 End-to-end metrics can't determine the path of the measure despite 1913 IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]). 1914 Spatial metrics vectors provide this path. The report of a spatial 1915 vector must include the points of interests involved: the sub set of 1916 the hosts of the path participating to the instantaneous measure. 1918 9.1.2. Host order 1920 A spatial vector must order the points of interest according to their 1921 order in the path. It is highly suggested to use the TTL in IPv4, 1922 the Hop Limit in IPv6 or the corresponding information in MPLS. 1924 The report of a spatial vector must include the ordered list of the 1925 hosts involved in the instantaneous measure. 1927 9.1.3. Timestamping bias 1929 The location of the point of interest inside a node influences the 1930 timestamping skew and accuracy. As an example, consider that some 1931 internal machinery delays the timestamping up to 3 milliseconds then 1932 the minimal uncertainty reported be 3 ms if the internal delay is 1933 unknown at the time of the timestamping. 1935 The report of a spatial vector must include the uncertainty of the 1936 timestamping compared to wire time. 1938 9.1.4. Reporting spatial One-way Delay 1940 The reporting includes information to report for one-way-delay as the 1941 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1943 9.2. Reporting One-to-group metric 1945 All reporting rules described in RFC2679-80 apply to the 1946 corresponding One-to-group metrics RFC2679-80. In addition, several 1947 new parameters are needed to report which are common to all the 1948 metrics and are presented here. 1950 9.2.1. Path 1952 As suggested by the RFC2679-80, the path traversed by the packet 1953 SHOULD be reported, if possible. For One-to-group metrics, there is 1954 a path tree SHOULD be reported rather than A path. This is even more 1955 impractical. If, by anyway, partial information is available to 1956 report, it might not be as valuable as it is in the one-to-one case 1957 because the incomplete path might be difficult to identify its 1958 position in the path tree. For example, how many points of interest 1959 are reached by the packet traveled through this incomplete path? 1960 However, the multicast path tree is normally more stable than 1961 unicast, which is dependant on multicast routing protocols. For 1962 example, the PIM-SM protocol [RFC4601] initializes the multicast 1963 route before any data packets are sent to the receivers. 1965 9.2.2. Group size 1967 The group size should be reported as one of the critical management 1968 parameters. Unlike the spatial metrics, there is no need of order of 1969 points of interests. 1971 9.2.3. Timestamping bias 1973 It is the same as described in section 9.1.3. 1975 9.2.4. Reporting One-to-group One-way Delay 1977 It is the same as described in section 9.1.4. 1979 9.2.5. Measurement method 1981 As explained in section 8, the measurement method will have impact on 1982 the analysis of the measurement result. Therefore, it should be 1983 reported. 1985 9.3. Metric identification 1987 IANA assigns each metric defined by the IPPM WG with a unique 1988 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1990 9.4. Reporting data model 1992 This section presents the elements of the datamodel and the usage of 1993 the information reported for real network performance analysis. It 1994 is out of the scope of this section to define how the information is 1995 reported. 1997 The data model is build with pieces of information introduced and 1998 explained in one-way delay definitions [RFC2679], in packet loss 1999 definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It 2000 includes not only information given by "Reporting the metric" 2001 sections but by sections "Methodology" and "Errors and Uncertainties" 2002 sections. 2004 Following are the elements of the datamodel taken from end-to-end 2005 definitions referred in this memo and from spatial and multicast 2006 metrics it defines: 2008 o Packet_type, The Type-P of test packets (Type-P); 2010 o Packet_length, a packet length in bits (L); 2011 o Src_host, the IP address of the sender; 2013 o Dst_host, the IP address of the receiver; 2015 o Hosts_serie: , a list of points of interest; 2017 o Loss_threshold: The threshold of infinite delay; 2019 o Systematic_error: constant delay between wire time and 2020 timestamping; 2022 o Calibration_error: maximal uncertainty; 2024 o Src_time, the sending time for a measured packet; 2026 o Dst_time, the receiving time for a measured packet; 2028 o Result_status : an indicator of usability of a result 'Resource 2029 exhaustion' 'infinite', 'lost'; 2031 o Delays_serie: a list of delays; 2033 o Losses_serie: , a list of Boolean values 2034 (spatial) or a set of Boolean values (one-to-group); 2036 o Result_status_serie: a list of results status; 2038 o dT: a delay; 2040 o Singleton_number: a number of singletons; 2042 o Observation_duration: An observation duration; 2044 o metric_identifier. 2046 Following is the information of each vector that should be available 2047 to compute samples: 2049 o Packet_type; 2051 o Packet_length; 2053 o Src_host, the sender of the packet; 2055 o Dst_host, the receiver of the packet, apply only for spatial 2056 vectors; 2058 o Hosts_serie: not ordered for one-to-group; 2060 o Src_time, the sending time for the measured packet; 2062 o dT, the end-to-end one-way delay for the measured packet, apply 2063 only for spatial vectors; 2065 o Delays_serie: apply only for delays and ipdv vector, not ordered 2066 for one-to-group; 2068 o Losses_serie: apply only for packets loss vector, not ordered for 2069 one-to-group; 2071 o Result_status_serie; 2073 o Observation_duration: the difference between the time of the last 2074 singleton and the time of the first singleton. 2076 o Following is the context information (measure, points of 2077 interests) that should be available to compute samples : 2079 * Loss threshold; 2081 * Systematic error: constant delay between wire time and 2082 timestamping; 2084 * Calibration error: maximal uncertainty; 2086 A spatial or a one-to-group sample is a collection of singletons 2087 giving the performance from the sender to a single point of interest. 2088 Following is the information that should be available for each sample 2089 to compute statistics: 2091 o Packet_type; 2093 o Packet_length; 2095 o Src_host, the sender of the packet; 2097 o Dst_host, the receiver of the packet; 2099 o Start_time, the sending time of the first packet; 2101 o Delays_serie: apply only for delays and ipdv samples; 2103 o Losses_serie: apply only for packets loss samples; 2104 o Result_status_serie; 2106 o Observation_duration: the difference between the time of the last 2107 singleton of the last sample and the time of the first singleton 2108 of the first sample. 2110 o Following is the context information (measure, points of 2111 interests) that should be available to compute statistics : 2113 * Loss threshold; 2115 * Systematic error: constant delay between wire time and 2116 timestamping; 2118 * Calibration error: maximal uncertainty; 2120 Following is the information of each statistic that should be 2121 reported: 2123 o Result; 2125 o Start_time; 2127 o Duration; 2129 o Result_status; 2131 o Singleton_number, the number of singletons the statistic is 2132 computed on; 2134 10. Open issues 2136 Do we define min, max, avg of for each segment metrics ? 2138 having the maximum loss metric value could be interesting. Say, 2139 the segment between router A and B always contributes loss metric 2140 value of "1" means it could be the potential problem segment. 2142 Uploading dTi of each Hi consume a lot of bandwidth. Computing 2143 statistics (min, max and avg) of dTi locally in each Hi reduce the 2144 bandwidth consumption. 2146 11. Security Considerations 2148 Spatial and one-to-group metrics are defined on the top of end-to-end 2149 metrics. Security considerations discussed in One-way delay metrics 2150 definitions of [RFC2679] , in packet loss metrics definitions 2151 of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 2152 apply to multimetrics. 2154 11.1. Spatial metrics 2156 Malicious generation of packets with spoofing addresses may corrupt 2157 the results without any possibility to detect the spoofing. 2159 Malicious generation of packets which match systematically the hash 2160 function used to detect the packets may lead to a DoS attack toward 2161 the point of reference. 2163 11.2. one-to-group metric 2165 The reporting of measurement results from a huge number of probes may 2166 overload the network the reference point is attach to, the reference 2167 point network interfaces and the reference point computation 2168 capacities. 2170 The configuration of a measure must take in consideration that 2171 implicitly more packets will to be routed than send and selects a 2172 test packets rate accordingly. Collecting statistics from a huge 2173 number of probes may overload any combination of the network where 2174 the measurement controller is attach to, measurement controller 2175 network interfaces and measurement controller computation capacities. 2177 one-to-group metrics measurement should consider using source 2178 authentication protocols, standardized in the MSEC group, to avoid 2179 fraud packet in the sampling interval. The test packet rate could be 2180 negotiated before any measurement session to avoid deny of service 2181 attacks. 2183 12. Acknowledgments 2185 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2186 of Surrey, for his instruction and helpful comments on this work. 2188 13. IANA Considerations 2190 Metrics defined in this memo Metrics defined in this memo are 2191 designed to be registered in the IANA IPPM METRICS REGISTRY as 2192 described in initial version of the registry [RFC4148] : 2194 IANA is asked to register the following metrics in the IANA-IPPM- 2195 METRICS-REGISTRY-MIB : 2197 ietfSpatialOneWayDelayVector OBJECT-IDENTITY 2199 STATUS current 2201 DESCRIPTION 2203 "Type-P-Spatial-One-way-Delay-Vector" 2205 REFERENCE 2207 "Reference "RFCyyyy, section 4.1." 2209 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2210 note 2212 := { ianaIppmMetrics nn } -- IANA assigns nn 2214 ietfSpatialPacketLossVector OBJECT-IDENTITY 2216 STATUS current 2218 DESCRIPTION 2220 "Type-P-Spatial-Packet-Loss-Vector" 2222 REFERENCE 2224 "Reference "RFCyyyy, section 4.2." 2226 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2227 note 2229 := { ianaIppmMetrics nn } -- IANA assigns nn 2231 ietfSpatialOneWayIpdvVector OBJECT-IDENTITY 2233 STATUS current 2235 DESCRIPTION 2237 "Type-P-Spatial-One-way-ipdv-Vector" 2239 REFERENCE 2241 "Reference "RFCyyyy, section 4.3." 2242 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2243 note 2245 := { ianaIppmMetrics nn } -- IANA assigns nn 2247 ietfSpatialSegmentOnewayDelayStream OBJECT-IDENTITY 2249 STATUS current 2251 DESCRIPTION 2253 "Type-P-Spatial-Segment-One-way-Delay-Stream" 2255 REFERENCE 2257 "Reference "RFCyyyy, section 5.1." 2259 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2260 note 2262 := { ianaIppmMetrics nn } -- IANA assigns nn 2264 ietfSpatialSegmentPacketLossStream OBJECT-IDENTITY 2266 STATUS current 2268 DESCRIPTION 2270 "Type-P-Spatial-Segment-Packet-Loss-Stream" 2272 REFERENCE 2274 "Reference "RFCyyyy, section 5.2." 2276 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2277 note 2279 := { ianaIppmMetrics nn } -- IANA assigns nn 2281 ietfSpatialSegmentOneWayIpdvPrevStream OBJECT-IDENTITY 2283 STATUS current 2285 DESCRIPTION 2287 "Type-P-Spatial-Segment-ipdv-prev-Stream" 2289 REFERENCE 2291 "Reference "RFCyyyy, section 5.3." 2293 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2294 note 2296 := { ianaIppmMetrics nn } -- IANA assigns nn 2298 ietfSpatialSegmentOneWayIpdvMinStream OBJECT-IDENTITY 2300 STATUS current 2302 DESCRIPTION 2304 "Type-P-Spatial-Segment-ipdv-minStream" 2306 REFERENCE 2308 "Reference "RFCyyyy, section 5.4." 2310 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2311 note 2313 := { ianaIppmMetrics nn } -- IANA assigns nn 2315 -- One-to-group metrics 2317 ietfOneToGroupOneWayDelayVector OBJECT-IDENTITY 2319 STATUS current 2321 DESCRIPTION 2323 "Type-P-one-to-group-One-way-Delay-Vector" 2325 REFERENCE 2327 "Reference "RFCyyyy, section 6.1." 2329 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2330 note 2332 := { ianaIppmMetrics nn } -- IANA assigns nn 2334 ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY 2335 STATUS current 2337 DESCRIPTION 2339 "Type-P-one-to-group-One-way-Packet-Loss-Vector" 2341 REFERENCE 2343 "Reference "RFCyyyy, section 6.2." 2345 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2346 note 2348 := { ianaIppmMetrics nn } -- IANA assigns nn 2350 ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY 2352 STATUS current 2354 DESCRIPTION 2356 "Type-P-one-to-group-One-way-ipdv-Vector" 2358 REFERENCE 2360 "Reference "RFCyyyy, section 6.3." 2362 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2363 note 2365 := { ianaIppmMetrics nn } -- IANA assigns nn 2367 -- One to group statistics 2369 -- 2371 ietfOneToGroupMeanDelay OBJECT-IDENTITY 2373 STATUS current 2375 DESCRIPTION 2377 "Type-P-One-to-Group-Mean-Delay" 2379 REFERENCE 2381 "Reference "RFCyyyy, section 6.3.3." 2382 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2383 note 2385 := { ianaIppmMetrics nn } -- IANA assigns nn 2387 ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY 2389 STATUS current 2391 DESCRIPTION 2393 "Type-P-One-to-Group-Range-Mean-Delay" 2395 REFERENCE 2397 "Reference "RFCyyyy, section 6.3.4." 2399 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2400 note 2402 := { ianaIppmMetrics nn } -- IANA assigns nn 2404 ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY 2406 STATUS current 2408 DESCRIPTION 2410 "Type-P-One-to-Group-Max-Mean-Delay" 2412 REFERENCE 2414 "Reference "RFCyyyy, section 6.3.5." 2416 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2417 note 2419 := { ianaIppmMetrics nn } -- IANA assigns nn 2421 ietfOneToGroupLossRatio OBJECT-IDENTITY 2423 STATUS current 2425 DESCRIPTION 2427 "Type-P-One-to-Group-Loss-Ratio" 2429 REFERENCE 2431 "Reference "RFCyyyy, section 6.4.1." 2433 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2434 note 2436 := { ianaIppmMetrics nn } -- IANA assigns nn 2438 -- 2440 ietfOneToGroupLossRatioRange OBJECT-IDENTITY 2442 STATUS current 2444 DESCRIPTION 2446 "Type-P-One-to-Group-Loss-Ratio-Range" 2448 REFERENCE 2450 "Reference "RFCyyyy, section 6.4.2." 2452 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2453 note 2455 := { ianaIppmMetrics nn } -- IANA assigns nn 2457 -- 2459 14. References 2461 14.1. Normative References 2463 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2464 "Framework for IP Performance Metrics", RFC 2330, 2465 May 1998. 2467 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2468 Delay Metric for IPPM", RFC 2679, September 1999. 2470 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2471 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2473 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2474 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2475 November 2002. 2477 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2478 Registry", BCP 108, RFC 4148, August 2005. 2480 14.2. Informative References 2482 [I-D.ietf-ippm-spatial-composition] 2483 Morton, A. and E. Stephan, "Spatial Composition of 2484 Metrics", draft-ietf-ippm-spatial-composition-05 (work in 2485 progress), November 2007. 2487 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 2488 Connectivity", RFC 2678, September 1999. 2490 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2491 Delay Metric for IPPM", RFC 2681, September 1999. 2493 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 2494 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 2495 July 2001. 2497 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 2498 Metrics", RFC 3357, August 2002. 2500 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2501 performance measurement with periodic streams", RFC 3432, 2502 November 2002. 2504 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 2505 Measurement Protocol (OWAMP) Requirements", RFC 3763, 2506 April 2004. 2508 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2509 Zekauskas, "A One-way Active Measurement Protocol 2510 (OWAMP)", RFC 4656, September 2006. 2512 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2513 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2514 November 2006. 2516 [passive_metrics] 2517 "", 2005. 2519 Authors' Addresses 2521 Stephan Emile 2522 France Telecom Division R&D 2523 2 avenue Pierre Marzin 2524 Lannion, F-22307 2526 Fax: +33 2 96 05 18 52 2527 Email: emile.stephan@orange-ftgroup.com 2529 Lei Liang 2530 CCSR, University of Surrey 2531 Guildford 2532 Surrey, GU2 7XH 2534 Fax: +44 1483 683641 2535 Email: L.Liang@surrey.ac.uk 2537 Al Morton 2538 200 Laurel Ave. South 2539 Middletown, NJ 07748 2540 USA 2542 Phone: +1 732 420 1571 2543 Email: acmorton@att.com 2545 Full Copyright Statement 2547 Copyright (C) The IETF Trust (2008). 2549 This document is subject to the rights, licenses and restrictions 2550 contained in BCP 78, and except as set forth therein, the authors 2551 retain all their rights. 2553 This document and the information contained herein are provided on an 2554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2561 Intellectual Property 2563 The IETF takes no position regarding the validity or scope of any 2564 Intellectual Property Rights or other rights that might be claimed to 2565 pertain to the implementation or use of the technology described in 2566 this document or the extent to which any license under such rights 2567 might or might not be available; nor does it represent that it has 2568 made any independent effort to identify any such rights. Information 2569 on the procedures with respect to rights in RFC documents can be 2570 found in BCP 78 and BCP 79. 2572 Copies of IPR disclosures made to the IETF Secretariat and any 2573 assurances of licenses to be made available, or the result of an 2574 attempt made to obtain a general license or permission for the use of 2575 such proprietary rights by implementers or users of this 2576 specification can be obtained from the IETF on-line IPR repository at 2577 http://www.ietf.org/ipr. 2579 The IETF invites any interested party to bring to its attention any 2580 copyrights, patents or patent applications, or other proprietary 2581 rights that may cover technology that may be required to implement 2582 this standard. Please address the information to the IETF at 2583 ietf-ipr@ietf.org. 2585 Acknowledgment 2587 Funding for the RFC Editor function is provided by the IETF 2588 Administrative Support Activity (IASA).