idnits 2.17.1 draft-ietf-ippm-multimetrics-08.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 2309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2333. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 975 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 (September 30, 2008) is 5684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-07 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet-Draft France Telecom 4 Intended status: Standards Track L. Liang 5 Expires: April 3, 2009 University of Surrey 6 A. Morton 7 AT&T Labs 8 September 30, 2008 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-08 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 April 3, 2009. 38 Abstract 40 The IETF has standardized IP Performance Metrics (IPPM) for measuring 41 end-to-end performance between two points. This memo defines two new 42 categories of metrics that extend the coverage to multiple 43 measurement points. It defines spatial metrics for measuring the 44 performance of segments of a source to destination path, and metrics 45 for measuring the performance between a source and many destinations 46 in multiparty communications (e.g., a multicast tree). 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Brief Metric Descriptions . . . . . . . . . . . . . . . . . . 7 59 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5. Spatial vector metrics definitions . . . . . . . . . . . . . . 11 61 6. Spatial Segment Metrics Definitions . . . . . . . . . . . . . 18 62 7. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 63 8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26 64 9. Measurement Methods: Scalability and Reporting . . . . . . . . 36 65 10. Manageability Considerations . . . . . . . . . . . . . . . . . 39 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 67 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 49 71 14.2. Informative References . . . . . . . . . . . . . . . . . 50 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 73 Intellectual Property and Copyright Statements . . . . . . . . . . 51 75 1. Introduction and Scope 77 IETF has standardized IP Performance Metrics (IPPM) for measuring 78 end-to-end performance between two points. This memo defines two new 79 categories of metrics that extend the coverage to multiple 80 measurement points. It defines spatial metrics for measuring the 81 performance of segments of a source to destination path, and metrics 82 for measuring the performance between a source and many destinations 83 in multiparty communications (e.g., a multicast tree). 85 The purpose of the memo is to define metrics to fulfill the new 86 requirements of measurement involving multiple measurement points. 87 Spatial metrics measure the performance of each segment along a path. 88 One-to-group metrics measure the performance for a group of users. 89 These metrics are derived from one-way end-to-end metrics, all of 90 which follow the IPPM framework [RFC2330]. 92 This memo is organized as follows: Section 2 introduces new terms 93 that extend the original IPPM framework [RFC2330]. Section 3 94 motivates each metric category and briefly introduces the new 95 metrics. Sections 4 through 7 develop each category of metrics with 96 definitions and statistics. Then the memo discusses the impact of 97 the measurement methods on the scaleability and proposes an 98 information model for reporting the measurements. Finally, the memo 99 discusses security aspects related to measurement and registers the 100 metrics in the IANA IP Performance Metrics Registry [RFC4148]. 102 The scope of this memo is limited to metrics using a single source 103 packet or stream, and observations of corresponding packets along the 104 path (spatial), at one or more destinations (one-to-group), or both. 105 Note that all the metrics defined herein are based on observations of 106 packets dedicated to testing, a process which is called active 107 measurement. Passive measurement (for example, a spatial metric 108 based on the observation of user traffic) is beyond the scope of this 109 memo. 111 2. Terminology 113 2.1. Naming of the metrics 115 The names of the metrics, including capitalization letters, are as 116 close as possible of the names of the one-way end-to-end metrics they 117 are derived from. 119 2.2. Terms Defined Elsewhere 121 host: section 5 of RFC 2330 123 loss threshold: section 2.8.2 of RFC 2680 125 path: section 5 of RFC 2330 127 path digest: section 5 of RFC 2330 129 sample: section 11 of RFC 2330 131 singleton: section 11 of RFC 2330 133 2.3. Path Digest Hosts 135 The list of the hosts on a path from the source to the destination, 136 also referred to as the host path digest. 138 2.4. Multiparty metric 140 A metric is said to be multiparty if the topology involves more than 141 one measurement collection point. All multiparty metrics designate a 142 set of hosts as "points of interest", where one host is the source 143 and other hosts are the measurement collection points. For example, 144 if the set of points of interest is < ha, hb, hc, ..., hn >, where ha 145 is the source and < hb, hc, ..., hn > are the destinations, then 146 measurements may be conducted between < ha, hb>, < ha, hc>, ..., . 149 For the purposes of this memo (reflecting the scope of a single 150 source), the only multiparty metrics are one-to-group metrics. 152 2.5. Spatial metric 154 A metric is said to be spatial if one of the hosts (measurement 155 collection points) involved is neither the source nor a destination 156 of the measured packet(s). Such measurement hosts will usually be 157 members of the path digest. 159 2.6. One-to-group metric 161 A metric is said to be one-to-group if the measured packet is sent by 162 one source and (potentially) received by more than one destination. 163 Thus, the topology of the communication group can be viewed as a 164 center-distributed or server-client topology with the source as the 165 center/server in the topology. 167 2.7. Points of interest 169 Points of interest are the hosts (as per the RFC 2330 definition, 170 "hosts" include routing nodes) that are measurement collection 171 points, a sub-set of the set of hosts involved in the delivery of the 172 packets (in addition to the source itself). 174 For spatial metrics, points of interest are a (possibly arbitrary) 175 sub-set of all the hosts involved in the path. 177 Points of interest of one-to-group metrics are the intended 178 destination hosts for packets from the source (in addition to the 179 source itself). 181 Src Dst 182 `. ,-. 183 `. ,' `...... 1 184 `. ; : 185 `. ; : 186 ; :... 2 187 | | 188 : ; 189 : ;.... 3 190 : ; 191 `. ,' 192 `-'....... N 194 Figure 1: One-to-group points of interest 196 A candidate point of interest for spatial metrics is a host from the 197 set of hosts involved in the delivery of the packets from source to 198 destination. 200 Src ------. Hosts 201 \ 202 `---X ... 1 203 \ 204 x 205 / 206 .---------X .... 2 207 / 208 x 209 \ 210 `---X .... 3 211 \ 212 \ 213 \ 214 X .... N 215 \ 216 \ 217 \ 218 `---- Dst 220 Note: 'x' are nodes which are not points of interest 222 Figure 2: Spatial points of interest 224 2.8. Reference point 226 A reference point is defined as the server where the statistical 227 calculations will be carried out. It is usually a centralized server 228 in the measurement architecture that is controlled by a network 229 operator, where measurement data can be collected for further 230 processing. The reference point is distinctly different from hosts 231 at measurement collection points, where the actual measurements are 232 carried out (e.g., points of interest). 234 2.9. Vector 236 A vector is a set of singletons (single atomic results) comprised of 237 observations corresponding to a single source packet at different 238 hosts in a network. For instance, if the one-way delay singletons 239 observed at N receivers for Packet P sent by the source Src are dT1, 240 dT2,..., dTN, then a vector V with N elements can be organized as 241 {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as 242 the singleton at receiver 1 in response to a packet sent from the 243 source at a specific time. The complete vector gives information 244 over the dimension of space; a set of N receivers in this example. 246 The singleton elements of any vector are distinctly different from 247 each other in terms of their measurement collection point. Different 248 vectors for common measurement points of interest are distinguished 249 by the source packet sending time. 251 2.10. Matrix 253 Several vectors form a matrix, which contains results observed over a 254 sampling interval at different places in a network at different 255 times. For example, the One-way delay vectors V1={dT11, dT12,..., 256 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 257 Packet P1, P2,...,Pm, form a One-way delay Matrix {V1, V2,...,Vm}. 258 The matrix organizes the vector information to present network 259 performance in both space and time. 261 A one-dimensional matrix (row) corresponds to a sample in simple 262 point-to-point measurement. 264 The relationship among singleton, sample, vector and matrix is 265 illustrated in the following Figure 3. 267 points of singleton 268 interest / samples(time) 269 ,----. ^ / 270 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 271 / \ | | | 272 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 273 Src | || | | 274 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 275 | || | | 276 : ;| | | 277 \ / | | | 278 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 279 `-----' +-------------------------------------> time 281 vector matrix 282 (space) (time and space) 284 Figure 3: Relationship between singletons, samples, vectors and 285 matrix 287 3. Brief Metric Descriptions 289 The metrics for spatial and one-to-group measurement are based on the 290 source-to-destination, or end-to-end metrics defined by IETF in 291 [[RFC2679], [RFC2680], [RFC3393], [RFC3432]. 293 This memo defines seven new spatial metrics using the [RFC2330] 294 framework of parameters, units of measure, and measurement 295 methodologies. Each definition includes a section that describes 296 measurements constraints and issues, and provides guidance to 297 increase the accuracy of the results. 299 The spatial metrics are: 300 o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- 301 One-way-Delay [RFC2679] into a spatial vector of one-way delay 302 singletons. 303 o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end 304 Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of 305 packet loss singletons. 306 o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- 307 One-way-ipdv into a spatial vector of ipdv singletons. 308 o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, 309 a sample called Type-P-Segment-One-way-Delay-Stream collects one- 310 way delay metrics between two points of interest on the path over 311 time. 312 o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector 313 metric, a sample called Type-P-Segment-Packet-Loss-Stream collects 314 one-way delay metrics between two points of interest on the path 315 over time. 316 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a sample 317 called Type-P-Segment-ipdv-prev-Stream, will be introduced to 318 compute ipdv metrics (using the previous packet selection 319 function) between two points of interest on the path over time. 320 o Again using the Type-P-Spatial-One-way-Delay-Vector metric, a 321 sample called Type-P-Segment-ipdv-min-Stream will define another 322 set of ipdv metrics (using the minimum delay packet selection 323 function) between two points of interest on the path over time. 325 The memo also defines three one-to-group metrics to measure the one- 326 way performance between a source and a group of receivers. They are: 327 o Type-P-One-to-group-Delay-Vector collects the set of Type-P-one- 328 way-delay singletons between one sender and N receivers. 329 o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P- 330 One-way-Packet-Loss singletons between one sender and N receivers. 331 o Type-P-One-to-group-ipdv-Vector collects the set of Type-P-One- 332 way-ipdv singletons between one sender and N receivers. 334 Finally, based on the one-to-group vector metrics listed above, 335 statistics are defined to capture single receiver performance, group 336 performance and the relative performance for a multiparty 337 communication: 338 o Using the Type-P-One-to-group-Delay-Vector, a metric called Type- 339 P-One-to-group-Receiver-n-Mean-Delay or RnMD, presents the mean of 340 delays between one sender and a single receiver 'n'. From this 341 metric, 3 additional metrics are defined to characterize the mean 342 delay over the entire group of receivers during the same time 343 interval: 344 * Type-P-One-to-group-Mean-Delay or GMD, presents the mean of 345 delays; 346 * Type-P-One-to-group-Range-Mean-Delay or GRMD, presents the 347 range of mean delays; 348 * Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the 349 maximum of mean delays. 350 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 351 Type-P-One-to-group-Receiver-n-Loss-Ratio or RnLR, captures the 352 packet loss ratio between one sender and a single receiver 'n'. 353 Based on this definition, 2 more metrics are defined to 354 characterize packet loss over the entire group during the same 355 time interval: 356 * Type-P-One-to-group-Loss-Ratio or GLR, captures the overall 357 packet loss ratio for the entire group of receivers; 358 * Type-P-One-to-group-Range-Loss-Ratio, or GRLR, presents the 359 comparative packet loss ratio during the test interval between 360 one sender and N receivers. 361 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 362 Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes 363 a packet loss ratio using the maximum number of packets received 364 at any receiver. 365 o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One- 366 to-group-Range-Delay-Variation, or GRDV, presents the range of 367 delay variation between one sender and a group of receivers. 369 4. Motivations 371 All existing IPPM metrics are defined for end-to-end (source to 372 destination) measurement of point-to-point paths. It is logical to 373 extend them to multiparty situations such as one to one trajectory 374 metrics and one to multipoint metrics. 376 4.1. Motivations for spatial metrics 378 Spatial metrics are needed for: 379 o Decomposing the performance of an inter-domain path to quantify 380 the per-AS contribution to the end-to-end performance. 381 o Traffic engineering and troubleshooting, which benefit from 382 spatial views of one-way delay and ipdv consumption, or 383 identification of the path segment where packets were lost. 384 o Monitoring the decomposed performance of a multicast tree based on 385 of MPLS point-to-multipoint communications. 386 o Dividing end-to-end metrics, so that some segment measurements can 387 be re-used and help measurement systems reach large-scale 388 coverage. Spatial measures could characterize the performance of 389 an intra-domain segment and provide an elementary piece of 390 information needed to estimate inter-domain performance to another 391 destination using Spatial Composition metrics 392 [I-D.ietf-ippm-spatial-composition]. 394 4.2. Motivations for One-to-group metrics 396 While the node-to-node based spatial measures can provide very useful 397 data in the view of each connection, we also need measures to present 398 the performance of a multiparty communication topology. A simple 399 point-to-point metric cannot completely describe the multiparty 400 situation. New one-to-group metrics assess performance of the 401 multiple paths for further statistical analysis. The new metrics are 402 named one-to-group performance metrics, and they are based on the 403 unicast metrics defined in IPPM RFCs. One-to-group metrics are one- 404 way metrics from one source to a group of destinations, or receivers. 405 The metrics are helpful for judging the overall performance of a 406 multiparty communications network, and for describing the performance 407 variation across a group of destinations. 409 One-to-group performance metrics are needed for: 411 o Designing and engineering multicast trees and MPLS point-to- 412 multipoint LSPs. 413 o Evaluating and controlling the quality of multicast services, 414 including inter-domain multicast. 415 o Presenting and evaluating the performance requirements for 416 multiparty communications and overlay multicast. 417 To understand the packet transfer performance between one source and 418 any one receiver in the multiparty communication group, we need to 419 collect instantaneous end-to-end metrics, or singletons. This gives 420 a very detailed view into the performance of each branch of the 421 multicast tree, and can provide clear and helpful information for 422 engineers to identify the branch with problems in a complex 423 multiparty routing tree. 425 The one-to-group metrics described in this memo introduce the 426 multiparty topology into the IPPM framework, and describe the 427 performance delivered to a group receiving packets from the same 428 source. The concept extends the "path" of the point-to-point 429 measurement to "path tree" to cover one-to-many topologies. If 430 applied to one-to-one topology, the one-to-group metrics provide 431 exactly the same results as the corresponding one-to-one metrics. 433 4.3. Discussion on Group-to-one and Group-to-group metrics 435 We note that points of interest can also be selected to define 436 measurements on group-to-one and group-to-group topologies. These 437 topologies are beyond the scope of this memo, because they would 438 involve multiple packets launched from different sources. However, 439 this section gives some insights on these two cases. 441 The measurements for group-to-one topology can be easily derived from 442 the one-to-group measurement. The measurement point is the host that 443 is acting as a receiver while all other hosts act as sources in this 444 case. 446 The group-to-group communication topology has no obvious focal point: 447 the sources and the measurement collection points can be anywhere. 448 However, it is possible to organize the problem by applying 449 measurements in one-to-group or group-to-one topologies for each host 450 in a uniform way (without taking account of how the real 451 communication might be carried out). For example, one group of hosts 452 < ha, hb, hc, ..., hn > might act as sources to send data to another 453 group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized 454 into n sets of points of interest for one-to-group communications: 456 < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, ..., Hm >. 459 5. Spatial vector metrics definitions 461 This section defines vectors for the spatial decomposition of end-to- 462 end singleton metrics over a path. 464 Spatial vector metrics are based on the decomposition of standard 465 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 466 [RFC3393] and [RFC3432]. 468 The spatial vector definitions are coupled with the corresponding 469 end-to-end metrics. Measurement methodology aspects are common to 470 all the vectors defined and are consequently discussed in a common 471 section. 473 5.1. A Definition for Spatial One-way Delay Vector 475 This section is coupled with the definition of Type-P-One-way-Delay 476 of the section 3 of [RFC2679]. When a parameter from the definition 477 in [RFC2679] is re-used in this section, the first instance will be 478 tagged with a trailing asterisk. 480 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 481 statements for end-to-end one-way-delay measurements. They are 482 applicable to each point of interest, Hi, involved in the measure. 483 Spatial one-way-delay measurement MUST respect them, especially those 484 related to methodology, clock, uncertainties and reporting. 486 5.1.1. Metric Name 488 Type-P-Spatial-One-way-Delay-Vector 490 5.1.2. Metric Parameters 492 o Src*, the IP address of the sender. 493 o Dst*, the IP address of the receiver. 494 o i, an integer in the ordered list <1,2,...,n> of hosts in the 495 path. 496 o Hi, a host in the path digest. 497 o T*, a time, the sending (or initial observation) time for a 498 measured packet. 499 o dT*, a delay, the one-way delay for a measured packet. 500 o dTi, a delay, the one-way delay for a measured packet from the 501 source to host Hi. 502 o a list of n delay singletons. 503 o Type-P*, the specification of the packet type. 504 o , a path host digest. 506 5.1.3. Metric Units 508 The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of 509 times (a real number in the dimension of seconds with sufficient 510 resolution to convey the results). 512 5.1.4. Definition 514 Given a Type-P packet sent by the Src at wire-time (first bit) T to 515 the receiver Dst on the path . There is a sequence 516 of values such that dT is the Type-P- 517 One-way-Delay from Src to Dst, and for each Hi of the path, T+dTi is 518 either a real number corresponding to the wire-time the packet passes 519 (last bit received) Hi, or undefined if the packet does not pass Hi 520 within a specified loss threshold* time. 522 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 523 as the sequence of values 524 . 526 5.1.5. Discussion 528 Some specific issues that may occur are as follows: 529 o the delay singletons "appear" to decrease: dTi > DTi+1. This may 530 occur despite being physically impossible with the definition 531 used. 532 * This is frequently due to a measurement clock synchronization 533 issue. This point is discussed in the section 3.7.1. "Errors 534 or uncertainties related to Clocks" of [RFC2679]. 535 Consequently, the values of delays measured at multiple hosts 536 may not match the order of those hosts on the path. 537 * The actual order of hosts on the path may change due to 538 reconvergence (e.g., recovery from a link failure). 539 * The location of the measurement collection point in the device 540 influences the result. If the packet is not observed directly 541 on the input interface the delay includes buffering time and 542 consequently an uncertainty due to the difference between 'wire 543 time' and 'host time'. 545 5.2. A Definition for Spatial Packet Loss Vector 547 This section is coupled with the definition of Type-P-One-way-Packet- 548 Loss. When a parameter from the section 2 of [RFC2680] is used in 549 this section, the first instance will be tagged with a trailing 550 asterisk. 552 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 553 statements for end-to-end one-way packet loss measurements. They are 554 applicable to each point of interest, Hi, involved in the measure. 555 Spatial packet loss measurement MUST respect them, especially those 556 related to methodology, clock, uncertainties and reporting. 558 The following sections define the spatial loss vector, adapt some of 559 the points above, and introduce points specific to spatial loss 560 measurement. 562 5.2.1. Metric Name 564 Type-P-Spatial-Packet-Loss-Vector 566 5.2.2. Metric Parameters 568 o Src*, the IP address of the sender. 569 o Dst*, the IP address of the receiver. 570 o i, an integer in the ordered list <1,2,...,n> of hosts in the 571 path. 573 o Hi, points of interest from the path digest. 574 o T*, a time, the sending time for a measured packet. 575 o dTi, a delay, the one-way delay for a measured packet from the 576 source to host Hi. 577 o , list of n delay singletons. 578 o Type-P*, the specification of packet type. 579 o , a host path digest. 580 o , a list of Boolean values. 582 5.2.3. Metric Units 584 The value of Type-P-Spatial-Packet-Loss-Vector is a sequence of 585 Boolean values. 587 5.2.4. Definition 589 Given a Type-P packet sent by the Src at time T to the receiver Dst 590 on the path . For the sequence of times the packet passes in , define the Type-P-Packet-Loss-Vector metric as the sequence 593 of values such that for each Hi of the path, a 594 value of 0 for Li means that dTi is a finite value, and a value of 1 595 means that dTi is undefined. 597 5.2.5. Discussion 599 Some specific issues that may occur are as follows: 600 o The result might include the sequence of values 1,0. Although 601 this appears physically impossible (a packet is lost, then re- 602 appears later on the path): 603 * The actual hosts on the path may change due to reconvergence 604 (e.g., recovery from a link failure). 605 * The order of hosts on the path may change due to reconvergence. 606 * A packet may not be observed in a host due to some buffer or 607 CPU overflow at the measurement collection point. 609 5.3. A Definition for Spatial One-way Ipdv Vector 611 When a parameter from section 2 of [RFC3393] (the definition of Type- 612 P-One-way-ipdv) is used in this section, the first instance will be 613 tagged with a trailing asterisk. 615 The following sections define the spatial ipdv vector, adapt some of 616 the points above, and introduce points specific to spatial ipdv 617 measurement. 619 5.3.1. Metric Name 621 Type-P-Spatial-One-way-ipdv-Vector 623 5.3.2. Metric Parameters 625 o Src*, the IP address of the sender. 626 o Dst*, the IP address of the receiver. 627 o i, an integer in the ordered list <1,2,...,n> of hosts in the 628 path. 629 o Hi, a host of the path digest. 630 o T1*, a time, the sending time for a first measured packet. 631 o T2*, a time, the sending time for a second measured packet. 632 o dT*, a delay, the one-way delay for a measured packet. 633 o dTi, a delay, the one-way delay for a measured packet from the 634 source to host Hi. 635 o Type-P*, the specification of the packets type. 636 o P1, the first packet sent at time T1. 637 o P2, the second packet sent at time T2. 638 o , a host path digest. 639 o , the Type-P-Spatial-One-way- 640 Delay-Vector for packet sent at time T1. 641 o , the Type-P-Spatial-One-way- 642 Delay-Vector for packet sent at time T2. 643 o L*, a packet length in bits. The packets of a Type P packet 644 stream from which the Type-P-Spatial-One-way-Delay-Vector metric 645 is taken MUST all be of the same length. 647 5.3.3. Metric Units 649 The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of 650 times (a real number in the dimension of seconds with sufficient 651 resolution to convey the results). 653 5.3.4. Definition 655 Given P1 the Type-P packet sent by the sender Src at wire-time (first 656 bit) T1 to the receiver Dst and 657 its Type-P-Spatial-One-way-Delay-Vector over the path . 660 Given P2 the Type-P packet sent by the sender Src at wire-time (first 661 bit) T2 to the receiver Dst and 662 its Type-P-Spatial-One-way-Delay-Vector over the same path. 664 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 665 of values such that for each Hi of the path , dT2.i-dT1.i 667 is either a real number if the packets P1 and P2 pass Hi at wire-time 668 (last bit) dT1.i and dT2.i respectively, or undefined if at least one 669 of them never passes Hi (and the respective one-way delay is 670 undefined). The T1,T2* pair indicates the inter-packet emission 671 interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv. 673 5.4. Spatial Methodology 675 The methodology, reporting specifications, and uncertainties 676 specified in section 3 of [RFC2679] apply to each point of interest 677 (or measurement collection point), Hi, measuring an element of a 678 spatial delay vector. 680 Likewise, the methodology, reporting specifications, and 681 uncertainties specified in section 2 of [RFC2680] apply to each point 682 of interest, Hi, measuring an element of a spatial packet loss 683 vector. 685 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 686 statements for end-to-end One-way ipdv measurements. They are 687 applicable to each point of interest, Hi, involved in the measure. 688 Spatial One-way ipdv measurement MUST respect the methodology, clock, 689 uncertainties and reporting aspects given there. 691 Generally, for a given Type-P packet of length L at a specific Hi, 692 the methodology for spatial vector metrics may proceed as follows: 693 o At each Hi, points of interest/measurement collection points 694 prepare to capture the packet sent at time T, record a timestamp 695 Ti', and determine the internal delay correction dTi' (See section 696 3.7.1. "Errors or uncertainties related to Clocks" of [RFC2679]); 697 o Each Hi extracts the path ordering information from the packet 698 (e.g. time-to-live); 699 o Each Hi computes the corrected wiretime from Src to Hi: Ti = Ti' - 700 dTi'. This arrival time is undefined if the packet is not 701 detected after the 'loss threshold' duration; 702 o Each Hi extracts the timestamp T from the packet; 703 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 704 o The reference point gathers the result of each Hi and arranges 705 them according to the path ordering information received to build 706 the type-P spatial one-way vector (e.g. Type-P-Spatial-One-way- 707 Delay-Vector metric ) over the path 708 at time T. 710 5.4.1. Packet Loss Detection 712 In an pure end-to-end measurement, packet losses are detected by the 713 receiver only. A packet is lost when Type-P-One-way-Delay is 714 undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and 715 section 3.5 of [RFC2680]). A packet is deemed lost by the receiver 716 after a duration which starts at the time the packet is sent. This 717 timeout value is chosen by a measurement process; It determines the 718 threshold between recording a long packet transfer time as a finite 719 value or an undefined value. 721 In a spatial measurement, packet losses may be detected at several 722 measurement collection points. Depending on the consistency of the 723 packet loss detections among the points of interest, a packet may be 724 considered as lost at one point despite having a finite delay at 725 another one, or may be observed by the last measurement collection 726 point of the path but considered lost by Dst. 728 There is a risk of misinterpreting such results: Has the path 729 changed? Did the packet arrive at the destination or was it lost on 730 the very last link? 732 The same concern applies to one-way-delay measures: a delay measured 733 may be computed as infinite by one observation point but as a real 734 value by another one, or may be measured as a real value by the last 735 observation point of the path but designated as undefined by Dst. 737 The observation/measurement collection points and the destination 738 SHOULD use consistent methods to detect packets losses. The methods 739 and parameters must be systematically reported to permit careful 740 comparison and to avoid introducing any confounding factors in the 741 analysis. 743 5.4.2. Host Path Digest 745 The methodology given above relies on knowing the order of the hosts/ 746 measurement collection points on the path [RFC2330]. 748 Path instability might cause a test packet to be observed more than 749 once by the same host, resulting in the repetition of one or more 750 hosts in the Path Digest. 752 For example, repeated observations may occur during rerouting phases 753 which introduce temporary micro loops. During such an event the host 754 path digest for a packet crossing Ha and Hb may include the pattern 755 meaning that Ha ended the computation of the new 756 path before Hb and that the initial path was from Ha to Hb and that 757 the new path is from Hb to Ha. 759 Consequently, duplication of hosts in the path digest of a vector 760 MUST be identified before computation of statistics to avoid 761 producing corrupted information. 763 6. Spatial Segment Metrics Definitions 765 This section defines samples to measure the performance of a segment 766 of a path over time. The definitions rely on the matrix of the 767 spatial vector metrics defined above. 769 Firstly this section defines a sample of one-way delay, Type-P- 770 Segment-One-way-Delay-Stream, and a sample of packet loss, Type-P- 771 segment-Packet-Loss-Stream. 773 Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv- 774 prev-Stream uses the current and previous packets as the selection 775 function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay 776 as one of the selected packets in every pair. 778 6.1. A Definition of a Sample of One-way Delay of a Segment of the Path 780 This metric defines a sample of One-way delays over time between a 781 pair of hosts on a path. Since it is very close semantically to the 782 metric Type-P-One-way-Delay-Poisson-Stream defined in section 4 of 783 [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of the 784 definition text below. 786 6.1.1. Metric Name 788 Type-P-Segment-One-way-Delay-Stream 790 6.1.2. Metric Parameters 792 o Src, the IP address of the sender. 793 o Dst, the IP address of the receiver. 794 o Type-P, the specification of the packet type. 795 o i, an integer in the ordered list <1,2,...,n> of hosts in the 796 path. 797 o k, an integer which orders the packets sent. 798 o a and b, two integers where b > a. 799 o Hi, a host of the path digest. 800 o , a host path digest. 801 o , a list of times. 803 6.1.3. Metric Units 805 The value of a Type-P-Segment-One-way-Delay-Stream is a pair of: 806 A list of times ; 807 A sequence of delays. 809 6.1.4. Definition 811 Given 2 hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for the 813 packets sent from Src to Dst at times : 814 ; 815 ; 816 ... 817 . 819 We define the sample Type-P-segment-One-way-Delay-Stream as the 820 sequence such that for 821 each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if 822 the packet sent at time Tk passes Ha and Hb or undefined if this 823 packet never passes Ha or (inclusive) never passes Hb. 825 6.1.5. Discussion 827 Some specific issues that may occur are as follows: 828 o the delay singletons "appear" to decrease: dTi > DTi+1, and is 829 discussed in section 5.1.5. 830 * This could also occur when the clock resolution of one 831 measurement collection point is larger than the minimum delay 832 of a path. For example, the minimum delay of a 500 km path 833 through optical fiber facilities is 2.5ms, but the measurement 834 collection point has a clock resolution of 8ms. 835 The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if 836 the following conditions occur: 837 o Ha or Hb disappears from the path due to some routing change. 838 o The order of Ha and Hb changes in the path. 840 6.2. A Definition of a Sample of Packet Loss of a Segment of the Path 842 This metric defines a sample of packet loss over time between a pair 843 of hosts of a path. Since it is very close semantically to the 844 metric Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], 845 sections 3.5 to 3.8 of [RFC2680] are integral parts of the definition 846 text below. 848 6.2.1. Metric Name 850 Type-P-segment-Packet-Loss-Stream 852 6.2.2. Metric Parameters 854 o Src, the IP address of the sender. 856 o Dst, the IP address of the receiver. 857 o Type-P, the specification of the packet type. 858 o k, an integer which orders the packets sent. 859 o n, an integer which orders the hosts on the path. 860 o a and b, two integers where b > a. 861 o , a host path digest. 862 o Hi, exchange points of the path digest. 863 o , a list of times. 864 o , a list of Boolean values. 866 6.2.3. Metric Units 868 The value of a Type-P-segment-Packet-Loss-Stream is a pair of: 869 A The list of times ; 870 A sequence of Boolean values. 872 6.2.4. Definition 874 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-Packet-Loss-Vector for the 876 packets sent from Src to Dst at times : 877 , 878 , 879 ..., 880 . 882 We define the value of the sample Type-P-segment-Packet-Lost-Stream 883 from Ha to Hb as the sequence of Booleans such that for each Tk: 885 o A value of Lk of 0 means that Ha and Hb observed the packet sent 886 at time Tk (both Lk.a and Lk.b have a value of 0). 887 o A value of Lk of 1 means that Ha observed the packet sent at time 888 Tk (Lk.a has a value of 0) and that Hb did not observe the packet 889 sent at time Tk (Lk.b has a value of 1). 890 o The value of Lk is undefined when neither Ha nor Hb observed the 891 packet (both Lk.a and Lk.b have a value of 1). 893 6.2.5. Discussion 895 Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-Loss-Stream 896 relies on the stability of the host path digest. The metric SHALL be 897 invalid for times < T1 , T2, ..., Tm-1, Tm> if the following 898 conditions occur: 899 o Ha or Hb disappears from the path due to some routing change. 900 o The order of Ha and Hb changes in the path. 901 o Lk.a or Lk.b is undefined. 903 o Lk.a has the value 1 (not observed) and Lk.b has the value 0 904 (observed); 905 o L has the value 0 (the packet was received by Dst) and Lk.ab has 906 the value 1 (the packet was lost between Ha and Hb). 908 6.3. A Definition of a Sample of ipdv of a Segment using the Previous 909 Packet Selection Function 911 This metric defines a sample of ipdv [RFC3393] over time between a 912 pair of hosts using the previous packet as the selection function. 914 6.3.1. Metric Name 916 Type-P-Segment-ipdv-prev-Stream 918 6.3.2. Metric Parameters 920 o Src, the IP address of the sender. 921 o Dst, the IP address of the receiver. 922 o Type-P, the specification of the packet type. 923 o k, an integer which orders the packets sent. 924 o n, an integer which orders the hosts on the path. 925 o a and b, two integers where b > a. 926 o , the hosts path digest. 927 o , a list of times. 928 o , a 929 Type-P-Spatial-One-way-Delay-Vector. 931 6.3.3. Metric Units 933 The value of a Type-P-Segment-ipdv-prev-Stream is a pair of: 934 The list of ; 935 A list of pairs of interval of times and delays; 937 6.3.4. Definition 939 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 941 the packets sent from Src to Dst at times : 942 , 943 , 944 ... 945 . 947 We define the Type-P-Segment-ipdv-prev-Stream as the sequence of 948 packet time pairs and delay variations 950 <(T1, T2 , dT2.ab - dT1.ab) ,..., 951 (Tk-1, Tk, dTk.ab - dTk-1.ab), ..., 953 (Tm-1, Tm, dTm.ab - dTm-1.ab)> 955 For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk- 956 1.ab is undefined if: 957 o the delay dTk.a or the delay dTk-1.a is undefined, OR 958 o the delay dTk.b or the delay dTk-1.b is undefined. 960 6.3.5. Discussion 962 This metric belongs to the family of inter packet delay variation 963 metrics (IPDV in upper case) whose results are extremely sensitive to 964 the inter-packet interval in practice. 966 The inter-packet interval of an end-to-end IPDV metric is under the 967 control of the source (ingress point of interest). In contrast, the 968 inter-packet interval of a segment IPDV metric is not under the 969 control the ingress point of interest of the measure, Ha. The 970 interval will certainly vary if there is delay variation between the 971 Source and Ha. Therefore, the ingress inter-packet interval must be 972 known at Ha in order to fully comprehend the delay variation between 973 Ha and Hb. 975 6.4. A Definition of a Sample of ipdv of a Segment using the Minimum 976 Delay Selection Function 978 This metric defines a sample of ipdv [RFC3393] over time between a 979 pair of hosts on a path using the minimum delay as one of the 980 selected packets in every pair. 982 6.4.1. Metric Name 984 Type-P-Segment-One-way-ipdv-min-Stream 986 6.4.2. Metric Parameters 988 o Src, the IP address of the sender. 989 o Dst, the IP address of the receiver. 990 o Type-P, the specification of the packet type. 991 o k, an integer which orders the packets sent. 992 o i, an integer which identifies a packet sent. 993 o n, an integer which orders the hosts on the path. 994 o a and b, two integers where b > a. 995 o , the host path digest. 996 o , a list of times. 998 o , a 999 Type-P-Spatial-One-way-Delay-Vector. 1001 6.4.3. Metric Units 1003 The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: 1004 The list of ; 1005 A list of times. 1007 6.4.4. Definition 1009 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 1011 the packets sent from Src to Dst at times : 1012 , 1013 , 1014 ... 1015 . 1017 We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence 1018 of times where: 1020 o min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); 1021 o for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) 1022 dTk.b is undefined, or the real number (dTk.b - dTk.a) is 1023 undefined. 1025 6.4.5. Discussion 1027 This metric belongs to the family of packet delay variation metrics 1028 (PDV). PDV distributions have less sensitivity to inter-packet 1029 interval variations than IPDV values, as discussed above. 1031 In principle, the PDV distribution reflects the variation over many 1032 different inter-packet intervals, from the smallest inter-packet 1033 interval, up to the length of the evaluation interval, Tm - T1. 1034 Therefore, when delay variation occurs and disturbs the packet 1035 spacing observed at Ha, the PDV results will likely compare favorably 1036 to a PDV measurement where the source is Ha and the destination is 1037 Hb, because a wide range of spacings are reflected in any PDV 1038 distribution. 1040 7. One-to-group metrics definitions 1042 This section defines performance metrics between a source and a group 1043 of receivers. 1045 7.1. A Definition for One-to-group Delay 1047 This section defines a metric for one-way delay between a source and 1048 a group of receivers. 1050 7.1.1. Metric Name 1052 Type-P-One-to-group-Delay-Vector 1054 7.1.2. Metric Parameters 1056 o Src, the IP address of a host acting as the source. 1057 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1058 receivers. 1059 o T, a time. 1060 o dT1,...,dTn a list of times. 1061 o Type-P, the specification of the packet type. 1062 o Gr, the receiving group identifier. The parameter Gr is the 1063 multicast group address if the measured packets are transmitted 1064 over IP multicast. This parameter is to differentiate the 1065 measured traffic from other unicast and multicast traffic. It is 1066 OPTIONAL for this metric to avoid losing any generality, i.e. to 1067 make the metric also applicable to unicast measurement where there 1068 is only one receiver. 1070 7.1.3. Metric Units 1072 The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- 1073 One-way-Delay singletons [RFC2679], which is a sequence of times (a 1074 real number in the dimension of seconds with sufficient resolution to 1075 convey the results). 1077 7.1.4. Definition 1079 Given a Type-P packet sent by the source Src at time T, and the N 1080 hosts { Recv1,...,RecvN } which receive the packet at the time { 1081 T+dT1,...,T+dTn }, or the packet does not pass a receiver within a 1082 specified loss threshold time, then the Type-P-One-to-group-Delay- 1083 Vector is defined as the set of the Type-P-One-way-Delay singletons 1084 between Src and each receiver with value of { dT1, dT2,...,dTn }, 1085 where any of the singletons may be undefined if the packet did not 1086 pass the corresponding receiver within a specified loss threshold 1087 time. 1089 7.2. A Definition for One-to-group Packet Loss 1090 7.2.1. Metric Name 1092 Type-P-One-to-group-Packet-Loss-Vector 1094 7.2.2. Metric Parameters 1096 o Src, the IP address of a host acting as the source. 1097 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1098 receivers. 1099 o T, a time. 1100 o Type-P, the specification of the packet type. 1101 o Gr, the receiving group identifier, OPTIONAL. 1103 7.2.3. Metric Units 1105 The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of 1106 Type-P-One-way-Packet-Loss singletons [RFC2680]. 1108 o T, time the source packet was sent 1109 o L1,...,LN a list of boolean values 1111 7.2.4. Definition 1113 Given a Type P packet sent by the source Src at T and the N hosts, 1114 Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is 1115 defined as a set of the Type-P-One-way-Packet-Loss singletons between 1116 Src and each of the receivers 1118 {T, ,,..., }, 1120 where the boolean value 0|1 depends on receiving the packet at a 1121 particular receiver within a loss threshold time. 1123 7.3. A Definition for One-to-group ipdv 1125 7.3.1. Metric Name 1127 Type-P-One-to-group-ipdv-Vector 1129 7.3.2. Metric Parameters 1131 o Src, the IP address of a host acting as the source. 1132 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1133 receivers. 1134 o T1, a time. 1135 o T2, a time. 1137 o ddT1, ...,ddTn, a list of times. 1138 o Type-P, the specification of the packet type. 1139 o F, a selection function non-ambiguously defining the two packets 1140 from the stream selected for the metric. 1141 o Gr, the receiving group identifier. The parameter Gr is the 1142 multicast group address if the measured packets are transmitted 1143 over IP multicast. This parameter is to differentiate the 1144 measured traffic from other unicast and multicast traffic. It is 1145 OPTIONAL in the metric to avoid losing any generality, i.e. to 1146 make the metric also applicable to unicast measurement where there 1147 is only one receiver. 1149 7.3.3. Metric Units 1151 The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- 1152 One-way-ipdv singletons [RFC3393]. 1154 7.3.4. Definition 1156 Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is 1157 defined for two packets transferred from the source Src to the N 1158 hosts {Recv1,...,RecvN }, which are selected by the selection 1159 function F as the difference between the value of the Type-P-One-to- 1160 group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and 1161 the value of the Type-P-One-to-group-Delay-Vector from Src to { 1162 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1163 the first bit of the first packet, and T2 is the wire-time at which 1164 Src sent the first bit of the second packet. This metric is derived 1165 from the Type-P-One-to-group-Delay-Vector metric. 1167 For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- 1168 ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is 1169 {ddT1,...,ddTn} means that Src sent two packets, the first at wire- 1170 time T1 (first bit), and the second at wire-time T2 (first bit) and 1171 the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ 1172 T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ 1173 T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- 1174 dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1176 For any pair of selected packets, the difference dT'n-dTn is 1177 undefined if: 1178 o the delay dTn to Receiver n is undefined, OR 1179 o the delay dT'n to Receiver n is undefined. 1181 8. One-to-group Sample Statistics 1183 The one-to-group metrics defined above are directly achieved by 1184 collecting relevant unicast one-way metrics measurements results and 1185 by gathering them per group of receivers. They produce network 1186 performance information which guides engineers toward potential 1187 problems which may have happened on any branch of a multicast routing 1188 tree. 1190 The results of these metrics are not directly usable to present the 1191 performance of a group because each result is made of a huge number 1192 of singletons which are difficult to read and analyze. As an 1193 example, delay are not comparable because the distance between 1194 receiver and sender differs. Furthermore they don't capture relative 1195 performance situation a multiparty communication. 1197 From the performance point of view, the multiparty communication 1198 services not only require the support of absolute performance 1199 information but also information on "relative performance". The 1200 relative performance means the difference between absolute 1201 performance of all users. Directly using the one-way metrics cannot 1202 present the relative performance situation. However, if we use the 1203 variations of all users one-way parameters, we can have new metrics 1204 to measure the difference of the absolute performance and hence 1205 provide the threshold value of relative performance that a multiparty 1206 service might demand. A very good example of the high relative 1207 performance requirement is the online gaming. A very light 1208 difference in delay might result in failure in the game. We have to 1209 use multicast specific statistic metrics to define exactly how small 1210 the relative delay the online gaming requires. There are many other 1211 services, e.g. online biding, online stock market, etc., that require 1212 multicast metrics in order to evaluate the network against their 1213 requirements. Therefore, we can see the importance of new, multicast 1214 specific, statistic metrics to feed this need. 1216 We might also use some one-to-group statistic conceptions to present 1217 and report the group performance and relative performance to save the 1218 report transmission bandwidth. Statistics have been defined for One- 1219 way metrics in corresponding RFCs. They provide the foundation of 1220 definition for performance statistics. For instance, there are 1221 definitions for minimum and maximum One-way delay in [RFC2679]. 1222 However, there is a dramatic difference between the statistics for 1223 one-to-one communications and for one-to-many communications. The 1224 former one only has statistics over the time dimension while the 1225 later one can have statistics over both time and space dimensions. 1226 This space dimension is introduced by the Matrix concept as 1227 illustrated in Figure 4. For a Matrix M each row is a set of One-way 1228 singletons spreading over the time dimension and each column is 1229 another set of One-way singletons spreading over the space dimension. 1231 Receivers 1232 Space 1233 ^ 1234 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1235 | | | 1236 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1237 | | | 1238 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1239 . | | | 1240 . | | | 1241 . | | | 1242 n | \ RndT1 RndT2 RndT3 ... RndTk / 1243 +--------------------------------------------> time 1244 T0 1246 Figure 4: Matrix M (n*m) 1248 In Matrix M, each element is a one-way delay singleton. Each column 1249 is a delay vector contains the One-way delays of the same packet 1250 observed at M points of interest. It implies the geographical factor 1251 of the performance within a group. Each row is a set of One-way 1252 delays observed during a sampling interval at one of the points of 1253 interest. It presents the delay performance at a receiver over the 1254 time dimension. 1256 Therefore, one can either calculate statistics by rows over the space 1257 dimension or by columns over the time dimension. It's up to the 1258 operators or service provides which dimension they are interested in. 1259 For example, a TV broadcast service provider might want to know the 1260 statistical performance of each user in a long term run to make sure 1261 their services are acceptable and stable. While for an online gaming 1262 service provider, he might be more interested to know if all users 1263 are served fairly by calculating the statistics over the space 1264 dimension. This memo does not intend to recommend which of the 1265 statistics are better than the other. 1267 To save the report transmission bandwidth, each point of interest can 1268 send statistics in a pre-defined time interval to the reference point 1269 rather than sending every one-way singleton it observed. As long as 1270 an appropriate time interval is decided, appropriate statistics can 1271 represent the performance in a certain accurate scale. How to decide 1272 the time interval and how to bootstrap all points of interest and the 1273 reference point depend on applications. For instance, applications 1274 with lower transmission rate can have the time interval longer and 1275 ones with higher transmission rate can have the time interval 1276 shorter. However, this is out of the scope of this memo. 1278 Moreover, after knowing the statistics over the time dimension, one 1279 might want to know how this statistics distributed over the space 1280 dimension. For instance, a TV broadcast service provider had the 1281 performance Matrix M and calculated the One-way delay mean over the 1282 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1283 calculated the mean of all the elements in the Vector to see what 1284 level of delay he has served to all N users. This new delay mean 1285 gives information on how good the service has been delivered to a 1286 group of users during a sampling interval in terms of delay. It 1287 needs twice calculation to have this statistic over both time and 1288 space dimensions. We name this kind of statistics 2-level statistics 1289 to distinct with those 1-level statistics calculated over either 1290 space or time dimension. It can be easily prove that no matter over 1291 which dimension a 2-level statistic is calculated first, the results 1292 are the same. I.e. one can calculate the 2-level delay mean using 1293 the Matrix M by having the 1-level delay mean over the time dimension 1294 first and then calculate the mean of the obtained vector to find out 1295 the 2-level delay mean. Or, he can do the 1-level statistic 1296 calculation over the space dimension first and then have the 2-level 1297 delay mean. Both two results will be exactly the same. Therefore, 1298 when define a 2-level statistic, there is no need to specify in which 1299 procedure the calculation should follow. 1301 Many statistics can be defined for the proposed one-to-group metrics 1302 over either the space dimension or the time dimension or both. This 1303 memo treats the case where a stream of packets from the Source 1304 results in a sample at each of the Receivers in the Group, and these 1305 samples are each summarized with the usual statistics employed in 1306 one-to-one communication. New statistic definitions are presented, 1307 which summarize the one-to-one statistics over all the Receivers in 1308 the Group. 1310 8.1. Discussion on the Impact of packet loss on statistics 1312 The packet loss does have effects on one-way metrics and their 1313 statistics. For example, the lost packet can result in an infinite 1314 one-way delay. It is easy to handle the problem by simply ignoring 1315 the infinite value in the metrics and in the calculation of the 1316 corresponding statistics. However, the packet loss has so strong 1317 impact on the statistics calculation for the one-to-group metrics 1318 that it can not be solved by the same method used for one-way 1319 metrics. This is due to the complexity of building a matrix, which 1320 is needed for calculation of the statistics proposed in this memo. 1322 The situation is that measurement results obtained by different end 1323 users might have different packet loss pattern. For example, for 1324 User1, packet A was observed lost. And for User2, packet A was 1325 successfully received but packet B was lost. If the method to 1326 overcome the packet loss for one-way metrics is applied, the two 1327 singleton sets reported by User1 and User2 will be different in terms 1328 of the transmitted packets. Moreover, if User1 and User2 have 1329 different number of lost packets, the size of the results will be 1330 different. Therefore, for the centralized calculation, the reference 1331 point will not be able to use these two results to build up the group 1332 Matrix and can not calculate the statistics. In an extreme 1333 situation, no single packet arrives all users in the measurement and 1334 the Matrix will be empty. One of the possible solutions is to 1335 replace the infinite/undefined delay value by the average of the two 1336 adjacent values. For example, if the result reported by user1 is { 1337 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1338 is an undefined value, the reference point can replace it by R1dTK = 1339 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1340 build up the group Matrix with an estimated value R1dTK. There are 1341 other possible solutions such as using the overall mean of the whole 1342 result to replace the infinite/undefined value, and so on. However 1343 this is out of the scope of this memo. 1345 For the distributed calculation, the reported statistics might have 1346 different "weight" to present the group performance, which is 1347 especially true for delay and ipdv relevant metrics. For example, 1348 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1349 in Figure. 8 without any packet loss and User2 calculates the R2DM 1350 with N-2 packet loss. The R1DM and R2DM should not be treated with 1351 equal weight because R2DM was calculated only based on 2 delay values 1352 in the whole sample interval. One possible solution is to use a 1353 weight factor to mark every statistic value sent by users and use 1354 this factor for further statistic calculation. 1356 8.2. General Metric Parameters 1358 o Src, the IP address of a host; 1359 o G, the receiving group identifier; 1360 o N, the number of Receivers (Recv1, Recv2, ... RecvN); 1361 o T, a time (start of test interval); 1362 o Tf, a time (end of test interval); 1363 o K, the number of packets sent from the source during the test 1364 interval; 1365 o J[n], the number of packets received at a particular Receiver, n, 1366 where 1<=n<=N; 1367 o lambda, a rate in reciprocal seconds (for Poisson Streams); 1368 o incT, the nominal duration of inter-packet interval, first bit to 1369 first bit (for Periodic Streams); 1370 o T0, a time that MUST be selected at random from the interval [T, 1371 T+I] to start generating packets and taking measurements (for 1372 Periodic Streams); 1374 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1375 Source Measurement Point); 1376 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1377 assigned to packets that arrive within a "reasonable" time; 1378 o Tmax, a maximum waiting time for packets at the destination, set 1379 sufficiently long to disambiguate packets with long delays from 1380 packets that are discarded (lost), thus the distribution of delay 1381 is not truncated; 1382 o dT, shorthand notation for a one-way delay singleton value; 1383 o L, shorthand notation for a one-way loss singleton value, either 1384 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1385 the destination within TstampSrc + Tmax, may be indexed over n 1386 Receivers; 1387 o DV, shorthand notation for a one-way delay variation singleton 1388 value. 1390 8.3. One-to-group Delay Statistics 1392 This section defines the overall one-way delay statistics for a 1393 receiver and for an entire group as illustrated by the matrix below. 1395 Recv /----------- Sample -------------\ Stats Group Stat 1397 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \ 1398 | 1399 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | 1400 | 1401 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2MD > Group delay 1402 . | 1403 . | 1404 . | 1405 n RndT1 RndT2 RndT3 ... RndTk RnMD / 1407 Receiver-n 1408 delay 1410 Figure 5: One-to-group Mean Delay 1412 Statistics are computed on the finite One-way delays of the matrix 1413 above. 1415 All One-to-group delay statistics are expressed in seconds with 1416 sufficient resolution to convey 3 significant digits. 1418 8.3.1. Type-P-One-to-group-Receiver-n-Mean-Delay 1420 This section defines Type-P-One-to-group-Receiver-n-Mean-Delay the 1421 Delay Mean at each Receiver N, also named RnDM. 1423 We obtain the value of Type-P-One-way-Delay singleton for all packets 1424 sent during the test interval at each Receiver (Destination), as per 1425 [RFC2679]. For each packet that arrives within Tmax of its sending 1426 time, TstampSrc, the one-way delay singleton (dT) will be the finite 1427 value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, 1428 the value of the singleton is Undefined. 1430 J[n] 1431 --- 1432 1 \ 1433 RnMD = --- * > TstampRecv[i] - TstampSrc[i] 1434 J[n] / 1435 --- 1436 i = 1 1438 Figure 6: Type-P-One-to-group-Receiver-N-Mean-Delay 1440 where all packets i= 1 through J[n] have finite singleton delays. 1442 8.3.2. Type-P-One-to-group-Mean-Delay 1444 This section defines Type-P-One-to-group-Mean-Delay, the Mean One-way 1445 delay calculated over the entire Group, also named GMD. 1447 N 1448 --- 1449 1 \ 1450 GMD = - * > RnDM 1451 N / 1452 --- 1453 n = 1 1455 Figure 7: Type-P-One-to-group-Mean-Delay 1457 Note that the Group Mean Delay can also be calculated by summing the 1458 Finite one-way Delay singletons in the Matrix, and dividing by the 1459 number of Finite One-way Delay singletons. 1461 8.3.3. Type-P-One-to-group-Range-Mean-Delay 1463 This section defines a metric for the range of mean delays over all N 1464 receivers in the group (R1DM, R2DM,...RnDM). 1466 Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1468 8.3.4. Type-P-One-to-group-Max-Mean-Delay 1470 This section defines a metric for the maximum of mean delays over all 1471 N receivers in the group (R1DM, R2DM,...RnDM). 1473 Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnDM) 1475 8.4. One-to-group Packet Loss Statistics 1477 This section defines the overall one-way loss statistics for a 1478 receiver and for an entire group as illustrated by the matrix below. 1480 Recv /----------- Sample ----------\ Stats Group Stat 1482 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1483 | 1484 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1485 | 1486 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio 1487 . | 1488 . | 1489 . | 1490 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1492 Receiver-n 1493 Loss Ratio 1495 Figure 8: One-to-group Loss Ratio 1497 Statistics are computed on the sample of Type-P-One-way-Packet-Loss 1498 [RFC2680] of the matrix above. 1500 All loss ratios are expressed in units of packets lost to total 1501 packets sent. 1503 8.4.1. Type-P-One-to-group-Receiver-n-Loss-Ratio 1505 Given a Matrix of loss singletons as illustrated above, determine the 1506 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1507 according to the definitions and method of [RFC2680]. The Type-P- 1508 One-way-Packet-Loss-Average and the Type-P-One-to-group-Receiver-n- 1509 Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the 1510 parameters used here, these metrics definitions can be expressed as 1511 K 1512 --- 1513 1 \ 1514 RnLR = - * > RnLk 1515 K / 1516 --- 1517 k = 1 1519 Figure 9: Type-P-One-to-group-Receiver-n-Loss-Ratio 1521 8.4.2. Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1523 Usually, the number of packets sent is used in the denominator of 1524 packet loss ratio metrics. For the comparative metrics defined here, 1525 the denominator is the maximum number of packets received at any 1526 receiver for the sample and test interval of interest. 1528 The Comparative Loss Ratio, also named, RnCLR, is defined as 1530 K 1531 --- 1532 \ 1533 > Ln(k) 1534 / 1535 --- 1536 k=1 1537 RnCLR = ----------------------------- 1538 / K \ 1539 | --- | 1540 | \ | 1541 K - Min | > Ln(k) | 1542 | / | 1543 | --- | 1544 \ k=1 / N 1546 Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1548 8.4.3. Type-P-One-to-group-Loss-Ratio 1550 Type-P-One-to-group-Loss-Ratio, the overall Group loss ratio, also 1551 named GLR, is defined as 1552 K,N 1553 --- 1554 1 \ 1555 GLR = --- * > L(k,n) 1556 K*N / 1557 --- 1558 k,n = 1 1560 Figure 11: Type-P-One-to-group-Loss-Ratio 1562 8.4.4. Type-P-One-to-group-Range-Loss-Ratio 1564 The One-to-group Loss Ratio Range is defined as: 1566 Type-P-One-to-group-Range-Loss-Ratio = max(RnLR) - min(RnLR) 1568 It is most effective to indicate the range by giving both the max and 1569 minimum loss ratios for the Group, rather than only reporting the 1570 difference between them. 1572 8.5. One-to-group Delay Variation Statistics 1574 This section defines one-way delay variation (DV) statistics for an 1575 entire group as illustrated by the matrix below. 1577 Recv /------------- Sample --------------\ Stats 1579 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ 1580 | 1581 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | 1582 | 1583 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat 1584 . | 1585 . | 1586 . | 1587 n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / 1589 Figure 12: One-to-group Delay Variation Matrix (DVMa) 1591 Statistics are computed on the sample of Type-P-One-way-Delay- 1592 Variation singletons of the group delay variation matrix above where 1593 RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at 1594 Receiver n for the packet k and where RnDV is the point-to-point one- 1595 way packet delay variation for Receiver n. 1597 All One-to-group delay variation statistics are expressed in seconds 1598 with sufficient resolution to convey 3 significant digits. 1600 8.5.1. Type-P-One-to-group-Range-Delay-Variation 1602 This section defines a metric for the range of delays variation over 1603 all N receivers in the Group. 1605 Maximum DV and minimum DV over all receivers summarize the 1606 performance over the Group (where DV is a point-to-point metric). 1607 For each receiver, the DV is usually expressed as the 1-10^(-3) 1608 quantile of one-way delay minus the minimum one-way delay. 1610 Type-P-One-to-group-Range-Delay-Variation = GRDV = 1612 = max(RnDV) - min(RnDV) for all n receivers 1614 This range is determined from the minimum and maximum values of the 1615 point-to-point one-way IP Packet Delay Variation for the set of 1616 Destinations in the group and a population of interest, using the 1617 Packet Delay Variation expressed as the 1-10^-3 quantile of one-way 1618 delay minus the minimum one-way delay. If a more demanding service 1619 is considered, one alternative is to use the 1-10^-5 quantile, and in 1620 either case the quantile used should be recorded with the results. 1621 Both the minimum and the maximum delay variation are recorded, and 1622 both values are given to indicate the location of the range. 1624 9. Measurement Methods: Scalability and Reporting 1626 Virtually all the guidance on measurement processes supplied by the 1627 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1628 scenarios is applicable here in the spatial and multiparty 1629 measurement scenario. The main difference is that the spatial and 1630 multiparty configurations require multiple points of interest where a 1631 stream of singletons will be collected. The amount of information 1632 requiring storage grows with both the number of metrics and the 1633 points of interest, so the scale of the measurement architecture 1634 multiplies the number of singleton results that must be collected and 1635 processed. 1637 It is possible that the architecture for results collection involves 1638 a single reference point with connectivity to all the points of 1639 interest. In this case, the number of points of interest determines 1640 both storage capacity and packet transfer capacity of the host acting 1641 as the reference point. However, both the storage and transfer 1642 capacity can be reduced if the points of interest are capable of 1643 computing the summary statistics that describe each measurement 1644 interval. This is consistent with many operational monitoring 1645 architectures today, where even the individual singletons may not be 1646 stored at each point of interest. 1648 In recognition of the likely need to minimize form of the results for 1649 storage and communication, the Group metrics above have been 1650 constructed to allow some computations on a per-Receiver basis. This 1651 means that each Receiver's statistics would normally have an equal 1652 weight with all other Receivers in the Group (regardless of the 1653 number of packets received). 1655 9.1. Computation methods 1657 The scalability issue can be raised when there are thousands of 1658 points of interest in a group who are trying to send back the 1659 measurement results to the reference point for further processing and 1660 analysis. The points of interest can send either the whole measured 1661 sample or only the calculated statistics. The former one is a 1662 centralized statistic calculation method and the latter one is a 1663 distributed statistic calculation method. The sample should include 1664 all metrics parameters, the values and the corresponding sequence 1665 numbers. The transmission of the whole sample can cost much more 1666 bandwidth than the transmission of the statistics that should include 1667 all statistic parameters specified by policies and the additional 1668 information about the whole sample, such as the size of the sample, 1669 the group address, the address of the point of interest, the ID of 1670 the sample session, and so on. Apparently, the centralized 1671 calculation method can require much more bandwidth than the 1672 distributed calculation method when the sample size is big. This is 1673 especially true when the measurement has huge number of the points of 1674 interest. It can lead to a scalability issue at the reference point 1675 by over load the network resources. The distributed calculation 1676 method can save much more bandwidth and release the pressure of the 1677 scalability issue at the reference point side. However, it can 1678 result in the lack of information because not all measured singletons 1679 are obtained for building up the group matrix. The performance over 1680 time can be hidden from the analysis. For example, the loss pattern 1681 can be missed by simply accepting the loss ratio as well as the delay 1682 pattern. This tradeoff between the bandwidth consuming and the 1683 information acquiring has to be taken into account when design the 1684 measurement campaign to optimize the measurement results delivery. 1685 The possible solution could be to transit the statistic parameters to 1686 the reference point first to obtain the general information of the 1687 group performance. If the detail results are required, the reference 1688 point should send the requests to the points of interest, which could 1689 be particular ones or the whole group. This procedure can happen in 1690 the off peak time and can be well scheduled to avoid delivery of too 1691 many points of interest at the same time. Compression techniques can 1692 also be used to minimize the bandwidth required by the transmission. 1693 This could be a measurement protocol to report the measurement 1694 results. However, this is out of the scope of this memo. 1696 9.2. Measurement 1698 To prevent any bias in the result, the configuration of a one-to-many 1699 measure must take in consideration that implicitly more packets will 1700 to be routed than send and selects a test packets rate that will not 1701 impact the network performance. 1703 9.3. Effect of Time and Space Aggregation Order on Stats 1705 This section presents the impact of the aggregation order on the 1706 scalability of the reporting and of the computation. It makes the 1707 hypothesis that receivers are not co-located and that results are 1708 gathered in a point of reference for further usages. 1710 Multimetrics samples are represented in a matrix as illustrated below 1712 Point of 1713 interest 1714 1 R1S1 R1S1 R1S1 ... R1Sk \ 1715 | 1716 2 R2S1 R2S2 R2S3 ... R2Sk | 1717 | 1718 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1719 . | 1720 . | 1721 . | 1722 n RnS1 RnS2 RnS3 ... RnSk / 1724 S1M S2M S3M ... SnM Stats over space 1726 \------------- ------------/ 1727 \/ 1728 Stat over space and time 1730 Figure 13: Impact of space aggregation on multimetrics Stat 1732 2 methods are available to compute statistics on a matrix: 1733 o Method 1: The statistic metric is computed over time and then over 1734 space; 1735 o Method 2: The statistic metric is computed over space and then 1736 over time. 1738 These 2 methods differ only by the order of the aggregation. The 1739 order does not impact the computation resources required. It does 1740 not change the value of the result. However, it impacts severely the 1741 minimal volume of data to report: 1743 o Method 1: Each point of interest computes periodically statistics 1744 over time to lower the volume of data to report. They are 1745 reported to the reference point for computing the stat over space. 1746 This volume no longer depends on the number of samples. It is 1747 only proportional to the computation period; 1748 o Method 2: The volume of data to report is proportional to the 1749 number of samples. Each sample, RiSi, must be reported to the 1750 reference point for computing statistic over space and statistic 1751 over time. The volume increases with the number of samples. It 1752 is proportional to the number of test packets; 1754 Method 2 has severe drawbacks in terms of security and dimensioning: 1755 o Increasing the rate of the test packets may result in a Denial of 1756 Service toward the points of reference; 1757 o The dimensioning of a measurement system is quite impossible to 1758 validate because any increase of the rate of the test packets will 1759 increase the bandwidth requested to collect the raw results. 1761 The computation period over time period (commonly named aggregation 1762 period) provides the reporting side with a control of various 1763 collecting aspects such as bandwidth, computation and storage 1764 capacities. So this draft defines metrics based on method 1. 1766 9.3.1. Impact on spatial statistics 1768 2 methods are available to compute spatial statistics: 1769 o Method 1: spatial segment metrics and statistics are preferably 1770 computed over time by each points of interest; 1771 o Method 2: Vectors metrics are intrinsically instantaneous space 1772 metrics which must be reported using method2 whenever 1773 instantaneous metrics information is needed. 1775 9.3.2. Impact on one-to-group statistics 1777 2 methods are available to compute group statistics: 1778 o Method1: Figure 5 and Figure 8 illustrate the method chosen: the 1779 one-to-one statistic is computed per interval of time before the 1780 computation of the mean over the group of receivers; 1781 o Method2: Figure 13 presents the second one, metric is computed 1782 over space and then over time. 1784 10. Manageability Considerations 1786 Usually IPPM WG documents defines each metric reporting within its 1787 definition. This document defines the reporting of all the metrics 1788 introduced in a single section to provide consistent information, to 1789 avoid repetitions and to conform to IESG recommendation of gathering 1790 manageability considerations in a dedicated section. 1792 Information models of spatial metrics and of one-to-group metrics are 1793 similar excepted that points of interests of spatial vectors must be 1794 ordered. 1796 The complexity of the reporting relies on the number of points of 1797 interests. 1799 10.1. Reporting spatial metric 1801 The reporting of spatial metrics shares a lot of aspects with 1802 RFC2679-80. New ones are common to all the definitions and are 1803 mostly related to the reporting of the path and of methodology 1804 parameters that may bias raw results analysis. This section presents 1805 these specific parameters and then lists exhaustively the parameters 1806 that shall be reported. 1808 10.1.1. Path 1810 End-to-end metrics can't determine the path of the measure despite 1811 IPPM RFCs recommend it to be reported (See Section 3.8.4 of 1812 [RFC2679]). Spatial metrics vectors provide this path. The report 1813 of a spatial vector must include the points of interests involved: 1814 the sub set of the hosts of the path participating to the 1815 instantaneous measure. 1817 10.1.2. Host order 1819 A spatial vector must order the points of interest according to their 1820 order in the path. It is highly suggested to use the TTL in IPv4, 1821 the Hop Limit in IPv6 or the corresponding information in MPLS. 1823 The report of a spatial vector must include the ordered list of the 1824 hosts involved in the instantaneous measure. 1826 10.1.3. Timestamping bias 1828 The location of the point of interest inside a node influences the 1829 timestamping skew and accuracy. As an example, consider that some 1830 internal machinery delays the timestamping up to 3 milliseconds then 1831 the minimal uncertainty reported be 3 ms if the internal delay is 1832 unknown at the time of the timestamping. 1834 The report of a spatial vector must include the uncertainty of the 1835 timestamping compared to wire time. 1837 10.1.4. Reporting spatial One-way Delay 1839 The reporting includes information to report for one-way-delay as the 1840 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1842 10.2. Reporting One-to-group metric 1844 All reporting rules described in [RFC2679] and [RFC2680] apply to the 1845 corresponding One-to-group metrics. Following are specific 1846 parameters that should be reported. 1848 10.2.1. Path 1850 As suggested by the [RFC2679] and [RFC2680] , the path traversed by 1851 the packet SHOULD be reported, if possible. For One-to-group 1852 metrics, there is a path tree SHOULD be reported rather than A path. 1853 This is even more impractical. If, by anyway, partial information is 1854 available to report, it might not be as valuable as it is in the one- 1855 to-one case because the incomplete path might be difficult to 1856 identify its position in the path tree. For example, how many points 1857 of interest are reached by the packet travelled through this 1858 incomplete path? 1860 10.2.2. Group size 1862 The group size should be reported as one of the critical management 1863 parameters. Unlike the spatial metrics, there is no need of order of 1864 points of interests. 1866 10.2.3. Timestamping bias 1868 It is the same as described in section 10.1.3. 1870 10.2.4. Reporting One-to-group One-way Delay 1872 It is the same as described in section 10.1.4. 1874 10.2.5. Measurement method 1876 As explained in section 9, the measurement method will have impact on 1877 the analysis of the measurement result. Therefore, it should be 1878 reported. 1880 10.3. Metric identification 1882 IANA assigns each metric defined by the IPPM WG with a unique 1883 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1885 10.4. Information model 1887 This section presents the elements of information and the usage of 1888 the information reported for network performance analysis. It is out 1889 of the scope of this section to define how the information is 1890 reported. 1892 The information model is build with pieces of information introduced 1893 and explained in one-way delay definitions [RFC2679], in packet loss 1894 definitions [RFC2680] and in IPDV definitions of [RFC3393] and 1895 [RFC3432]. It includes not only information given by "Reporting the 1896 metric" sections but by sections "Methodology" and "Errors and 1897 Uncertainties" sections. 1899 Following are the elements of information taken from end-to-end 1900 definitions referred in this memo and from spatial and multicast 1901 metrics it defines: 1903 o Packet_type, The Type-P of test packets (Type-P); 1904 o Packet_length, a packet length in bits (L); 1905 o Src_host, the IP address of the sender; 1906 o Dst_host, the IP address of the receiver; 1907 o Hosts_serie: , a list of points of interest; 1908 o Loss_threshold: The threshold of infinite delay; 1909 o Systematic_error: constant delay between wire time and 1910 timestamping; 1911 o Calibration_error: maximal uncertainty; 1912 o Src_time, the sending time for a measured packet; 1913 o Dst_time, the receiving time for a measured packet; 1914 o Result_status : an indicator of usability of a result 'Resource 1915 exhaustion' 'infinite', 'lost'; 1916 o Delays_serie: a list of delays; 1917 o Losses_serie: , a list of Boolean values 1918 (spatial) or a set of Boolean values (one-to-group); 1919 o Result_status_serie: a list of results status; 1920 o dT: a delay; 1921 o Singleton_number: a number of singletons; 1922 o Observation_duration: An observation duration; 1923 o metric_identifier. 1925 Following is the information of each vector that should be available 1926 to compute samples: 1928 o Packet_type; 1929 o Packet_length; 1930 o Src_host, the sender of the packet; 1931 o Dst_host, the receiver of the packet, apply only for spatial 1932 vectors; 1933 o Hosts_serie: not ordered for one-to-group; 1934 o Src_time, the sending time for the measured packet; 1935 o dT, the end-to-end one-way delay for the measured packet, apply 1936 only for spatial vectors; 1937 o Delays_serie: apply only for delays and ipdv vector, not ordered 1938 for one-to-group; 1939 o Losses_serie: apply only for packets loss vector, not ordered for 1940 one-to-group; 1941 o Result_status_serie; 1942 o Observation_duration: the difference between the time of the last 1943 singleton and the time of the first singleton. 1944 o Following is the context information (measure, points of 1945 interests) that should be available to compute samples : 1946 * Loss threshold; 1947 * Systematic error: constant delay between wire time and 1948 timestamping; 1949 * Calibration error: maximal uncertainty; 1951 A spatial or a one-to-group sample is a collection of singletons 1952 giving the performance from the sender to a single point of interest. 1953 Following is the information that should be available for each sample 1954 to compute statistics: 1956 o Packet_type; 1957 o Packet_length; 1958 o Src_host, the sender of the packet; 1959 o Dst_host, the receiver of the packet; 1960 o Start_time, the sending time of the first packet; 1961 o Delays_serie: apply only for delays and ipdv samples; 1962 o Losses_serie: apply only for packets loss samples; 1963 o Result_status_serie; 1964 o Observation_duration: the difference between the time of the last 1965 singleton of the last sample and the time of the first singleton 1966 of the first sample. 1967 o Following is the context information (measure, points of 1968 interests) that should be available to compute statistics : 1969 * Loss threshold; 1970 * Systematic error: constant delay between wire time and 1971 timestamping; 1972 * Calibration error: maximal uncertainty; 1974 Following is the information of each statistic that should be 1975 reported: 1977 o Result; 1978 o Start_time; 1979 o Duration; 1980 o Result_status; 1981 o Singleton_number, the number of singletons the statistic is 1982 computed on; 1984 11. Security Considerations 1986 Spatial and one-to-group metrics are defined on the top of end-to-end 1987 metrics. Security considerations discussed in One-way delay metrics 1988 definitions of [RFC2679] , in packet loss metrics definitions of 1989 [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 1990 apply to metrics defined in this memo. 1992 11.1. Spatial metrics 1994 Malicious generation of packets with spoofing addresses may corrupt 1995 the results without any possibility to detect the spoofing. 1997 Malicious generation of packets which match systematically the hash 1998 function used to detect the packets may lead to a DoS attack toward 1999 the point of reference. 2001 11.2. One-to-group metrics 2003 Reporting of measurement results from a huge number of probes may 2004 overload reference point resources (network, network interfaces, 2005 computation capacities ...). 2007 The configuration of a measurement must take in consideration that 2008 implicitly more packets will to be routed than send and selects a 2009 test packets rate accordingly. Collecting statistics from a huge 2010 number of probes may overload any combination of the network where 2011 the measurement controller is attached to, measurement controller 2012 network interfaces and measurement controller computation capacities. 2014 One-to-group metrics measurement should consider using source 2015 authentication protocols, standardized in the MSEC group, to avoid 2016 fraud packet in the sampling interval. The test packet rate could be 2017 negotiated before any measurement session to avoid deny of service 2018 attacks. 2020 12. Acknowledgments 2022 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2023 of Surrey, for his instruction and helpful comments on this work. 2025 13. IANA Considerations 2027 Metrics defined in this memo Metrics defined in this memo are 2028 designed to be registered in the IANA IPPM METRICS REGISTRY as 2029 described in initial version of the registry [RFC4148] : 2031 IANA is asked to register the following metrics in the IANA-IPPM- 2032 METRICS-REGISTRY-MIB : 2034 ietfSpatialOneWayDelayVector OBJECT-IDENTITY 2035 STATUS current 2036 DESCRIPTION 2037 "Type-P-Spatial-One-way-Delay-Vector" 2038 REFERENCE 2039 "Reference "RFCyyyy, section 5.1." 2040 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2041 note 2042 := { ianaIppmMetrics nn } -- IANA assigns nn 2044 ietfSpatialPacketLossVector OBJECT-IDENTITY 2045 STATUS current 2046 DESCRIPTION 2047 "Type-P-Spatial-Packet-Loss-Vector" 2048 REFERENCE 2049 "Reference "RFCyyyy, section 5.2." 2050 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2051 note 2052 := { ianaIppmMetrics nn } -- IANA assigns nn 2054 ietfSpatialOneWayIpdvVector OBJECT-IDENTITY 2055 STATUS current 2056 DESCRIPTION 2057 "Type-P-Spatial-One-way-ipdv-Vector" 2058 REFERENCE 2059 "Reference "RFCyyyy, section 5.3." 2060 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2061 note 2062 := { ianaIppmMetrics nn } -- IANA assigns nn 2064 ietfSegmentOneWayDelayStream OBJECT-IDENTITY 2065 STATUS current 2066 DESCRIPTION 2067 "Type-P-Segment-One-way-Delay-Stream" 2068 REFERENCE 2069 "Reference "RFCyyyy, section 6.1." 2070 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2071 note 2072 := { ianaIppmMetrics nn } -- IANA assigns nn 2074 ietfSegmentPacketLossStream OBJECT-IDENTITY 2075 STATUS current 2076 DESCRIPTION 2077 "Type-P-Segment-Packet-Loss-Stream" 2078 REFERENCE 2079 "Reference "RFCyyyy, section 6.2." 2080 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2081 note 2082 := { ianaIppmMetrics nn } -- IANA assigns nn 2084 ietfSegmentIpdvPrevStream OBJECT-IDENTITY 2085 STATUS current 2086 DESCRIPTION 2087 "Type-P-Segment-ipdv-prev-Stream" 2088 REFERENCE 2089 "Reference "RFCyyyy, section 6.3." 2090 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2091 note 2092 := { ianaIppmMetrics nn } -- IANA assigns nn 2094 ietfSegmentIpdvMinStream OBJECT-IDENTITY 2095 STATUS current 2096 DESCRIPTION 2097 "Type-P-Segment-ipdv-min-Stream" 2098 REFERENCE 2099 "Reference "RFCyyyy, section 6.4." 2100 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2101 note 2102 := { ianaIppmMetrics nn } -- IANA assigns nn 2104 -- One-to-group metrics 2106 ietfOneToGroupDelayVector OBJECT-IDENTITY 2107 STATUS current 2108 DESCRIPTION 2109 "Type-P-One-to-group-Delay-Vector" 2110 REFERENCE 2111 "Reference "RFCyyyy, section 7.1." 2112 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2113 note 2114 := { ianaIppmMetrics nn } -- IANA assigns nn 2116 ietfOneToGroupPacketLossVector OBJECT-IDENTITY 2117 STATUS current 2118 DESCRIPTION 2119 "Type-P-One-to-group-Packet-Loss-Vector" 2120 REFERENCE 2121 "Reference "RFCyyyy, section 7.2." 2122 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2123 note 2124 := { ianaIppmMetrics nn } -- IANA assigns nn 2126 ietfOneToGroupIpdvVector OBJECT-IDENTITY 2127 STATUS current 2128 DESCRIPTION 2129 "Type-P-One-to-group-ipdv-Vector" 2130 REFERENCE 2131 "Reference "RFCyyyy, section 7.3." 2132 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2133 note 2134 := { ianaIppmMetrics nn } -- IANA assigns nn 2136 -- One to group statistics 2138 -- 2140 ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY 2141 STATUS current 2142 DESCRIPTION 2143 "Type-P-One-to-group-Receiver-n-Mean-Delay" 2144 REFERENCE 2145 "Reference "RFCyyyy, section 8.3.1." 2146 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2147 note 2148 := { ianaIppmMetrics nn } -- IANA assigns nn 2150 ietfOneToGroupMeanDelay OBJECT-IDENTITY 2151 STATUS current 2152 DESCRIPTION 2153 "Type-P-One-to-group-Mean-Delay" 2154 REFERENCE 2155 "Reference "RFCyyyy, section 8.3.2." 2156 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2157 note 2158 := { ianaIppmMetrics nn } -- IANA assigns nn 2160 ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY 2161 STATUS current 2162 DESCRIPTION 2163 "Type-P-One-to-group-Range-Mean-Delay" 2164 REFERENCE 2165 "Reference "RFCyyyy, section 8.3.3." 2166 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2167 note 2168 := { ianaIppmMetrics nn } -- IANA assigns nn 2170 ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY 2171 STATUS current 2172 DESCRIPTION 2173 "Type-P-One-to-group-Max-Mean-Delay" 2174 REFERENCE 2175 "Reference "RFCyyyy, section 8.3.4." 2176 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2177 note 2178 := { ianaIppmMetrics nn } -- IANA assigns nn 2180 ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY 2181 STATUS current 2182 DESCRIPTION 2183 "Type-P-One-to-group-Receiver-n-Loss-Ratio" 2184 REFERENCE 2185 "Reference "RFCyyyy, section 8.4.1." 2186 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2187 note 2188 := { ianaIppmMetrics nn } -- IANA assigns nn 2189 -- 2191 ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY 2192 STATUS current 2193 DESCRIPTION 2194 "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio" 2195 REFERENCE 2196 "Reference "RFCyyyy, section 8.4.2." 2197 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2198 note 2199 := { ianaIppmMetrics nn } -- IANA assigns nn 2201 ietfOneToGroupLossRatio OBJECT-IDENTITY 2202 STATUS current 2203 DESCRIPTION 2204 "Type-P-One-to-group-Loss-Ratio" 2205 REFERENCE 2206 "Reference "RFCyyyy, section 8.4.3." 2207 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2208 note 2209 := { ianaIppmMetrics nn } -- IANA assigns nn 2210 -- 2212 ietfOneToGroupRangeLossRatio OBJECT-IDENTITY 2213 STATUS current 2214 DESCRIPTION 2215 "Type-P-One-to-group-Range-Loss-Ratio" 2216 REFERENCE 2217 "Reference "RFCyyyy, section 8.4.4." 2218 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2219 note 2220 := { ianaIppmMetrics nn } -- IANA assigns nn 2222 ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY 2223 STATUS current 2224 DESCRIPTION 2225 "Type-P-One-to-group-Range-Delay-Variation" 2226 REFERENCE 2227 "Reference "RFCyyyy, section 8.5.1." 2228 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2229 note 2230 := { ianaIppmMetrics nn } -- IANA assigns nn 2232 -- 2234 14. References 2236 14.1. Normative References 2238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2239 Requirement Levels", BCP 14, RFC 2119, March 1997. 2241 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2242 Delay Metric for IPPM", RFC 2679, September 1999. 2244 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2245 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2247 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2248 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2249 November 2002. 2251 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2252 Registry", BCP 108, RFC 4148, August 2005. 2254 14.2. Informative References 2256 [I-D.ietf-ippm-spatial-composition] 2257 Morton, A. and E. Stephan, "Spatial Composition of 2258 Metrics", draft-ietf-ippm-spatial-composition-07 (work in 2259 progress), July 2008. 2261 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2262 "Framework for IP Performance Metrics", RFC 2330, 2263 May 1998. 2265 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2266 performance measurement with periodic streams", RFC 3432, 2267 November 2002. 2269 Authors' Addresses 2271 Stephan Emile 2272 France Telecom Division R&D 2273 2 avenue Pierre Marzin 2274 Lannion, F-22307 2276 Fax: +33 2 96 05 18 52 2277 Email: emile.stephan@orange-ftgroup.com 2279 Lei Liang 2280 CCSR, University of Surrey 2281 Guildford 2282 Surrey, GU2 7XH 2284 Fax: +44 1483 683641 2285 Email: L.Liang@surrey.ac.uk 2287 Al Morton 2288 200 Laurel Ave. South 2289 Middletown, NJ 07748 2290 USA 2292 Phone: +1 732 420 1571 2293 Email: acmorton@att.com 2295 Full Copyright Statement 2297 Copyright (C) The IETF Trust (2008). 2299 This document is subject to the rights, licenses and restrictions 2300 contained in BCP 78, and except as set forth therein, the authors 2301 retain all their rights. 2303 This document and the information contained herein are provided on an 2304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2311 Intellectual Property 2313 The IETF takes no position regarding the validity or scope of any 2314 Intellectual Property Rights or other rights that might be claimed to 2315 pertain to the implementation or use of the technology described in 2316 this document or the extent to which any license under such rights 2317 might or might not be available; nor does it represent that it has 2318 made any independent effort to identify any such rights. Information 2319 on the procedures with respect to rights in RFC documents can be 2320 found in BCP 78 and BCP 79. 2322 Copies of IPR disclosures made to the IETF Secretariat and any 2323 assurances of licenses to be made available, or the result of an 2324 attempt made to obtain a general license or permission for the use of 2325 such proprietary rights by implementers or users of this 2326 specification can be obtained from the IETF on-line IPR repository at 2327 http://www.ietf.org/ipr. 2329 The IETF invites any interested party to bring to its attention any 2330 copyrights, patents or patent applications, or other proprietary 2331 rights that may cover technology that may be required to implement 2332 this standard. Please address the information to the IETF at 2333 ietf-ipr@ietf.org.