idnits 2.17.1 draft-ietf-ippm-multimetrics-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 983 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 (April 22, 2009) is 5482 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-08 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: October 24, 2009 University of Surrey 6 A. Morton 7 AT&T Labs 8 April 22, 2009 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-10 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 24, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The IETF has standardized IP Performance Metrics (IPPM) for measuring 50 end-to-end performance between two points. This memo defines two new 51 categories of metrics that extend the coverage to multiple 52 measurement points. It defines spatial metrics for measuring the 53 performance of segments of a source to destination path, and metrics 54 for measuring the performance between a source and many destinations 55 in multiparty communications (e.g., a multicast tree). 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Brief Metric Descriptions . . . . . . . . . . . . . . . . . . 7 68 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Spatial vector metrics definitions . . . . . . . . . . . . . . 11 70 6. Spatial Segment Metrics Definitions . . . . . . . . . . . . . 18 71 7. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 72 8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26 73 9. Measurement Methods: Scalability and Reporting . . . . . . . . 36 74 10. Manageability Considerations . . . . . . . . . . . . . . . . . 39 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 76 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 77 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 49 80 14.2. Informative References . . . . . . . . . . . . . . . . . 50 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 83 1. Introduction and Scope 85 IETF has standardized IP Performance Metrics (IPPM) for measuring 86 end-to-end performance between two points. This memo defines two new 87 categories of metrics that extend the coverage to multiple 88 measurement points. It defines spatial metrics for measuring the 89 performance of segments of a source to destination path, and metrics 90 for measuring the performance between a source and many destinations 91 in multiparty communications (e.g., a multicast tree). 93 The purpose of the memo is to define metrics to fulfill the new 94 requirements of measurement involving multiple measurement points. 95 Spatial metrics measure the performance of each segment along a path. 96 One-to-group metrics measure the performance for a group of users. 97 These metrics are derived from one-way end-to-end metrics, all of 98 which follow the IPPM framework [RFC2330]. 100 This memo is organized as follows: Section 2 introduces new terms 101 that extend the original IPPM framework [RFC2330]. Section 3 102 motivates each metric category and briefly introduces the new 103 metrics. Sections 4 through 7 develop each category of metrics with 104 definitions and statistics. Then the memo discusses the impact of 105 the measurement methods on the scalability and proposes an 106 information model for reporting the measurements. Finally, the memo 107 discusses security aspects related to measurement and registers the 108 metrics in the IANA IP Performance Metrics Registry [RFC4148]. 110 The scope of this memo is limited to metrics using a single source 111 packet or stream, and observations of corresponding packets along the 112 path (spatial), at one or more destinations (one-to-group), or both. 113 Note that all the metrics defined herein are based on observations of 114 packets dedicated to testing, a process which is called active 115 measurement. Passive measurement (for example, a spatial metric 116 based on the observation of user traffic) is beyond the scope of this 117 memo. 119 2. Terminology 121 2.1. Naming of the metrics 123 The names of the metrics, including capitalization letters, are as 124 close as possible of the names of the one-way end-to-end metrics they 125 are derived from. 127 2.2. Terms Defined Elsewhere 129 host: section 5 of RFC 2330 131 loss threshold: section 2.8.2 of RFC 2680 133 path: section 5 of RFC 2330 135 path digest: section 5 of RFC 2330 137 sample: section 11 of RFC 2330 139 singleton: section 11 of RFC 2330 141 2.3. Path Digest Hosts 143 The list of the hosts on a path from the source to the destination, 144 also referred to as the host path digest. 146 2.4. Multiparty metric 148 A metric is said to be multiparty if the topology involves more than 149 one measurement collection point. All multiparty metrics designate a 150 set of hosts as "points of interest", where one host is the source 151 and other hosts are the measurement collection points. For example, 152 if the set of points of interest is < ha, hb, hc, ..., hn >, where ha 153 is the source and < hb, hc, ..., hn > are the destinations, then 154 measurements may be conducted between < ha, hb>, < ha, hc>, ..., . 157 For the purposes of this memo (reflecting the scope of a single 158 source), the only multiparty metrics are one-to-group metrics. 160 2.5. Spatial metric 162 A metric is said to be spatial if one of the hosts (measurement 163 collection points) involved is neither the source nor a destination 164 of the measured packet(s). Such measurement hosts will usually be 165 members of the path digest. 167 2.6. One-to-group metric 169 A metric is said to be one-to-group if the measured packet is sent by 170 one source and (potentially) received by more than one destination. 171 Thus, the topology of the communication group can be viewed as a 172 center-distributed or server-client topology with the source as the 173 center/server in the topology. 175 2.7. Points of interest 177 Points of interest are the hosts (as per the RFC 2330 definition, 178 "hosts" include routing nodes) that are measurement collection 179 points, a sub-set of the set of hosts involved in the delivery of the 180 packets (in addition to the source itself). 182 For spatial metrics, points of interest are a (possibly arbitrary) 183 sub-set of all the hosts involved in the path. 185 Points of interest of one-to-group metrics are the intended 186 destination hosts for packets from the source (in addition to the 187 source itself). 189 Src Dst 190 `. ,-. 191 `. ,' `...... 1 192 `. ; : 193 `. ; : 194 ; :... 2 195 | | 196 : ; 197 : ;.... 3 198 : ; 199 `. ,' 200 `-'....... I 202 Figure 1: One-to-group points of interest 204 A candidate point of interest for spatial metrics is a host from the 205 set of hosts involved in the delivery of the packets from source to 206 destination. 208 Src ------. Hosts 209 \ 210 `---X ... 1 211 \ 212 x 213 / 214 .---------X .... 2 215 / 216 x 217 \ 218 `---X .... 3 219 \ 220 \ 221 \ 222 X .... J 223 \ 224 \ 225 \ 226 `---- Dst 228 Note: 'x' are nodes which are not points of interest 230 Figure 2: Spatial points of interest 232 2.8. Reference point 234 A reference point is defined as the server where the statistical 235 calculations will be carried out. It is usually a centralized server 236 in the measurement architecture that is controlled by a network 237 operator, where measurement data can be collected for further 238 processing. The reference point is distinctly different from hosts 239 at measurement collection points, where the actual measurements are 240 carried out (e.g., points of interest). 242 2.9. Vector 244 A vector is a set of singletons (single atomic results) comprised of 245 observations corresponding to a single source packet at different 246 hosts in a network. For instance, if the one-way delay singletons 247 observed at N receivers for Packet P sent by the source Src are dT1, 248 dT2,..., dTN, then a vector V with N elements can be organized as 249 {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as 250 the singleton at receiver 1 in response to a packet sent from the 251 source at a specific time. The complete vector gives information 252 over the dimension of space; a set of N receivers in this example. 254 The singleton elements of any vector are distinctly different from 255 each other in terms of their measurement collection point. Different 256 vectors for common measurement points of interest are distinguished 257 by the source packet sending time. 259 2.10. Matrix 261 Several vectors form a matrix, which contains results observed over a 262 sampling interval at different places in a network at different 263 times. For example, the One-way delay vectors V1={dT11, dT12,..., 264 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 265 Packet P1, P2,...,Pm, form a One-way delay Matrix {V1, V2,...,Vm}. 266 The matrix organizes the vector information to present network 267 performance in both space and time. 269 A one-dimensional matrix (row) corresponds to a sample in simple 270 point-to-point measurement. 272 The relationship among singleton, sample, vector and matrix is 273 illustrated in the following Figure 3. 275 points of singleton 276 interest / samples(time) 277 ,----. ^ / 278 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 279 / \ | | | 280 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 281 Src | || | | 282 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 283 | || | | 284 : ;| | | 285 \ / | | | 286 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 287 `-----' +-------------------------------------> time 289 vector matrix 290 (space) (time and space) 292 Figure 3: Relationship between singletons, samples, vectors and 293 matrix 295 3. Brief Metric Descriptions 297 The metrics for spatial and one-to-group measurement are based on the 298 source-to-destination, or end-to-end metrics defined by IETF in 299 [[RFC2679], [RFC2680], [RFC3393], [RFC3432]. 301 This memo defines seven new spatial metrics using the [RFC2330] 302 framework of parameters, units of measure, and measurement 303 methodologies. Each definition includes a section that describes 304 measurements constraints and issues, and provides guidance to 305 increase the accuracy of the results. 307 The spatial metrics are: 308 o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- 309 One-way-Delay [RFC2679] into a spatial vector of one-way delay 310 singletons. 311 o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end 312 Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of 313 packet loss singletons. 314 o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- 315 One-way-ipdv into a spatial vector of ipdv singletons. 316 o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, 317 a sample called Type-P-Segment-One-way-Delay-Stream collects one- 318 way delay metrics between two points of interest on the path over 319 time. 320 o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector 321 metric, a sample called Type-P-Segment-Packet-Loss-Stream collects 322 one-way delay metrics between two points of interest on the path 323 over time. 324 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a sample 325 called Type-P-Segment-ipdv-prev-Stream, will be introduced to 326 compute ipdv metrics (using the previous packet selection 327 function) between two points of interest on the path over time. 328 o Again using the Type-P-Spatial-One-way-Delay-Vector metric, a 329 sample called Type-P-Segment-ipdv-min-Stream will define another 330 set of ipdv metrics (using the minimum delay packet selection 331 function) between two points of interest on the path over time. 333 The memo also defines three one-to-group metrics to measure the one- 334 way performance between a source and a group of receivers. They are: 335 o Type-P-One-to-group-Delay-Vector collects the set of Type-P-one- 336 way-delay singletons between one sender and N receivers. 337 o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P- 338 One-way-Packet-Loss singletons between one sender and N receivers. 339 o Type-P-One-to-group-ipdv-Vector collects the set of Type-P-One- 340 way-ipdv singletons between one sender and N receivers. 342 Finally, based on the one-to-group vector metrics listed above, 343 statistics are defined to capture single receiver performance, group 344 performance and the relative performance for a multiparty 345 communication: 346 o Using the Type-P-One-to-group-Delay-Vector, a metric called Type- 347 P-One-to-group-Receiver-n-Mean-Delay or RnMD, presents the mean of 348 delays between one sender and a single receiver 'n'. From this 349 metric, 3 additional metrics are defined to characterize the mean 350 delay over the entire group of receivers during the same time 351 interval: 352 * Type-P-One-to-group-Mean-Delay or GMD, presents the mean of 353 delays; 354 * Type-P-One-to-group-Range-Mean-Delay or GRMD, presents the 355 range of mean delays; 356 * Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the 357 maximum of mean delays. 358 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 359 Type-P-One-to-group-Receiver-n-Loss-Ratio or RnLR, captures the 360 packet loss ratio between one sender and a single receiver 'n'. 361 Based on this definition, 2 more metrics are defined to 362 characterize packet loss over the entire group during the same 363 time interval: 364 * Type-P-One-to-group-Loss-Ratio or GLR, captures the overall 365 packet loss ratio for the entire group of receivers; 366 * Type-P-One-to-group-Range-Loss-Ratio, or GRLR, presents the 367 comparative packet loss ratio during the test interval between 368 one sender and N receivers. 369 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 370 Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes 371 a packet loss ratio using the maximum number of packets received 372 at any receiver. 373 o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One- 374 to-group-Range-Delay-Variation, or GRDV, presents the range of 375 delay variation between one sender and a group of receivers. 377 4. Motivations 379 All existing IPPM metrics are defined for end-to-end (source to 380 destination) measurement of point-to-point paths. It is logical to 381 extend them to multiparty situations such as one to one trajectory 382 metrics and one to multipoint metrics. 384 4.1. Motivations for spatial metrics 386 Spatial metrics are needed for: 387 o Decomposing the performance of an inter-domain path to quantify 388 the per-AS contribution to the end-to-end performance. 389 o Traffic engineering and troubleshooting, which benefit from 390 spatial views of one-way delay and ipdv consumption, or 391 identification of the path segment where packets were lost. 392 o Monitoring the decomposed performance of a multicast tree based on 393 of MPLS point-to-multipoint communications. 394 o Dividing end-to-end metrics, so that some segment measurements can 395 be re-used and help measurement systems reach large-scale 396 coverage. Spatial measures could characterize the performance of 397 an intra-domain segment and provide an elementary piece of 398 information needed to estimate inter-domain performance to another 399 destination using Spatial Composition metrics 400 [I-D.ietf-ippm-spatial-composition]. 402 4.2. Motivations for One-to-group metrics 404 While the node-to-node based spatial measures can provide very useful 405 data in the view of each connection, we also need measures to present 406 the performance of a multiparty communication topology. A simple 407 point-to-point metric cannot completely describe the multiparty 408 situation. New one-to-group metrics assess performance of the 409 multiple paths for further statistical analysis. The new metrics are 410 named one-to-group performance metrics, and they are based on the 411 unicast metrics defined in IPPM RFCs. One-to-group metrics are one- 412 way metrics from one source to a group of destinations, or receivers. 413 The metrics are helpful for judging the overall performance of a 414 multiparty communications network, and for describing the performance 415 variation across a group of destinations. 417 One-to-group performance metrics are needed for: 419 o Designing and engineering multicast trees and MPLS point-to- 420 multipoint LSPs. 421 o Evaluating and controlling the quality of multicast services, 422 including inter-domain multicast. 423 o Presenting and evaluating the performance requirements for 424 multiparty communications and overlay multicast. 425 To understand the packet transfer performance between one source and 426 any one receiver in the multiparty communication group, we need to 427 collect instantaneous end-to-end metrics, or singletons. This gives 428 a very detailed view into the performance of each branch of the 429 multicast tree, and can provide clear and helpful information for 430 engineers to identify the branch with problems in a complex 431 multiparty routing tree. 433 The one-to-group metrics described in this memo introduce the 434 multiparty topology into the IPPM framework, and describe the 435 performance delivered to a group receiving packets from the same 436 source. The concept extends the "path" of the point-to-point 437 measurement to "path tree" to cover one-to-many topologies. If 438 applied to one-to-one topology, the one-to-group metrics provide 439 exactly the same results as the corresponding one-to-one metrics. 441 4.3. Discussion on Group-to-one and Group-to-group metrics 443 We note that points of interest can also be selected to define 444 measurements on group-to-one and group-to-group topologies. These 445 topologies are beyond the scope of this memo, because they would 446 involve multiple packets launched from different sources. However, 447 this section gives some insights on these two cases. 449 The measurements for group-to-one topology can be easily derived from 450 the one-to-group measurement. The measurement point is the host that 451 is acting as a receiver while all other hosts act as sources in this 452 case. 454 The group-to-group communication topology has no obvious focal point: 455 the sources and the measurement collection points can be anywhere. 456 However, it is possible to organize the problem by applying 457 measurements in one-to-group or group-to-one topologies for each host 458 in a uniform way (without taking account of how the real 459 communication might be carried out). For example, one group of hosts 460 < ha, hb, hc, ..., hn > might act as sources to send data to another 461 group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized 462 into n sets of points of interest for one-to-group communications: 464 < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, ..., Hm >. 467 5. Spatial vector metrics definitions 469 This section defines vectors for the spatial decomposition of end-to- 470 end singleton metrics over a path. 472 Spatial vector metrics are based on the decomposition of standard 473 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 474 [RFC3393] and [RFC3432]. 476 The spatial vector definitions are coupled with the corresponding 477 end-to-end metrics. Measurement methodology aspects are common to 478 all the vectors defined and are consequently discussed in a common 479 section. 481 5.1. A Definition for Spatial One-way Delay Vector 483 This section is coupled with the definition of Type-P-One-way-Delay 484 of the section 3 of [RFC2679]. When a parameter from the definition 485 in [RFC2679] is re-used in this section, the first instance will be 486 tagged with a trailing asterisk. 488 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 489 statements for end-to-end one-way-delay measurements. They are 490 applicable to each point of interest, Hi, involved in the measure. 491 Spatial one-way-delay measurement MUST respect them, especially those 492 related to methodology, clock, uncertainties and reporting. 494 5.1.1. Metric Name 496 Type-P-Spatial-One-way-Delay-Vector 498 5.1.2. Metric Parameters 500 o Src*, the IP address of the sender. 501 o Dst*, the IP address of the receiver. 502 o i, an integer in the ordered list <1,2,...,n> of hosts in the 503 path. 504 o Hi, a host in the path digest. 505 o T*, a time, the sending (or initial observation) time for a 506 measured packet. 507 o dT*, a delay, the one-way delay for a measured packet. 508 o dTi, a delay, the one-way delay for a measured packet from the 509 source to host Hi. 510 o a list of n delay singletons. 511 o Type-P*, the specification of the packet type. 512 o , a path host digest. 514 5.1.3. Metric Units 516 The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of 517 times (a real number in the dimension of seconds with sufficient 518 resolution to convey the results). 520 5.1.4. Definition 522 Given a Type-P packet sent by the Src at wire-time (first bit) T to 523 the receiver Dst on the path . There is a sequence 524 of values such that dT is the Type-P- 525 One-way-Delay from Src to Dst, and for each Hi of the path, T+dTi is 526 either a real number corresponding to the wire-time the packet passes 527 (last bit received) Hi, or undefined if the packet does not pass Hi 528 within a specified loss threshold* time. 530 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 531 as the sequence of values 532 . 534 5.1.5. Discussion 536 Some specific issues that may occur are as follows: 537 o the delay singletons "appear" to decrease: dTi > DTi+1. This may 538 occur despite being physically impossible with the definition 539 used. 540 * This is frequently due to a measurement clock synchronization 541 issue. This point is discussed in the section 3.7.1. "Errors 542 or uncertainties related to Clocks" of [RFC2679]. 543 Consequently, the values of delays measured at multiple hosts 544 may not match the order of those hosts on the path. 545 * The actual order of hosts on the path may change due to 546 reconvergence (e.g., recovery from a link failure). 547 * The location of the measurement collection point in the device 548 influences the result. If the packet is not observed directly 549 on the input interface the delay includes buffering time and 550 consequently an uncertainty due to the difference between 'wire 551 time' and 'host time'. 553 5.2. A Definition for Spatial Packet Loss Vector 555 This section is coupled with the definition of Type-P-One-way-Packet- 556 Loss. When a parameter from the section 2 of [RFC2680] is used in 557 this section, the first instance will be tagged with a trailing 558 asterisk. 560 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 561 statements for end-to-end one-way packet loss measurements. They are 562 applicable to each point of interest, Hi, involved in the measure. 563 Spatial packet loss measurement MUST respect them, especially those 564 related to methodology, clock, uncertainties and reporting. 566 The following sections define the spatial loss vector, adapt some of 567 the points above, and introduce points specific to spatial loss 568 measurement. 570 5.2.1. Metric Name 572 Type-P-Spatial-Packet-Loss-Vector 574 5.2.2. Metric Parameters 576 o Src*, the IP address of the sender. 577 o Dst*, the IP address of the receiver. 578 o i, an integer in the ordered list <1,2,...,n> of hosts in the 579 path. 581 o Hi, points of interest from the path digest. 582 o T*, a time, the sending time for a measured packet. 583 o dTi, a delay, the one-way delay for a measured packet from the 584 source to host Hi. 585 o , list of n delay singletons. 586 o Type-P*, the specification of packet type. 587 o , a host path digest. 588 o , a list of Boolean values. 590 5.2.3. Metric Units 592 The value of Type-P-Spatial-Packet-Loss-Vector is a sequence of 593 Boolean values. 595 5.2.4. Definition 597 Given a Type-P packet sent by the Src at time T to the receiver Dst 598 on the path . For the sequence of times the packet passes in , define the Type-P-Packet-Loss-Vector metric as the sequence 601 of values such that for each Hi of the path, a 602 value of 0 for Li means that dTi is a finite value, and a value of 1 603 means that dTi is undefined. 605 5.2.5. Discussion 607 Some specific issues that may occur are as follows: 608 o The result might include the sequence of values 1,0. Although 609 this appears physically impossible (a packet is lost, then re- 610 appears later on the path): 611 * The actual hosts on the path may change due to reconvergence 612 (e.g., recovery from a link failure). 613 * The order of hosts on the path may change due to reconvergence. 614 * A packet may not be observed in a host due to some buffer or 615 CPU overflow at the measurement collection point. 617 5.3. A Definition for Spatial One-way Ipdv Vector 619 When a parameter from section 2 of [RFC3393] (the definition of Type- 620 P-One-way-ipdv) is used in this section, the first instance will be 621 tagged with a trailing asterisk. 623 The following sections define the spatial ipdv vector, adapt some of 624 the points above, and introduce points specific to spatial ipdv 625 measurement. 627 5.3.1. Metric Name 629 Type-P-Spatial-One-way-ipdv-Vector 631 5.3.2. Metric Parameters 633 o Src*, the IP address of the sender. 634 o Dst*, the IP address of the receiver. 635 o i, an integer in the ordered list <1,2,...,n> of hosts in the 636 path. 637 o Hi, a host of the path digest. 638 o T1*, a time, the sending time for a first measured packet. 639 o T2*, a time, the sending time for a second measured packet. 640 o dT*, a delay, the one-way delay for a measured packet. 641 o dTi, a delay, the one-way delay for a measured packet from the 642 source to host Hi. 643 o Type-P*, the specification of the packets type. 644 o P1, the first packet sent at time T1. 645 o P2, the second packet sent at time T2. 646 o , a host path digest. 647 o , the Type-P-Spatial-One-way- 648 Delay-Vector for packet sent at time T1. 649 o , the Type-P-Spatial-One-way- 650 Delay-Vector for packet sent at time T2. 651 o L*, a packet length in bits. The packets of a Type P packet 652 stream from which the Type-P-Spatial-One-way-Delay-Vector metric 653 is taken MUST all be of the same length. 655 5.3.3. Metric Units 657 The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of 658 times (a real number in the dimension of seconds with sufficient 659 resolution to convey the results). 661 5.3.4. Definition 663 Given P1 the Type-P packet sent by the sender Src at wire-time (first 664 bit) T1 to the receiver Dst and 665 its Type-P-Spatial-One-way-Delay-Vector over the path . 668 Given P2 the Type-P packet sent by the sender Src at wire-time (first 669 bit) T2 to the receiver Dst and 670 its Type-P-Spatial-One-way-Delay-Vector over the same path. 672 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 673 of values such that for each Hi of the path , dT2.i-dT1.i 675 is either a real number if the packets P1 and P2 pass Hi at wire-time 676 (last bit) dT1.i and dT2.i respectively, or undefined if at least one 677 of them never passes Hi (and the respective one-way delay is 678 undefined). The T1,T2* pair indicates the inter-packet emission 679 interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv. 681 5.4. Spatial Methodology 683 The methodology, reporting specifications, and uncertainties 684 specified in section 3 of [RFC2679] apply to each point of interest 685 (or measurement collection point), Hi, measuring an element of a 686 spatial delay vector. 688 Likewise, the methodology, reporting specifications, and 689 uncertainties specified in section 2 of [RFC2680] apply to each point 690 of interest, Hi, measuring an element of a spatial packet loss 691 vector. 693 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 694 statements for end-to-end One-way ipdv measurements. They are 695 applicable to each point of interest, Hi, involved in the measure. 696 Spatial One-way ipdv measurement MUST respect the methodology, clock, 697 uncertainties and reporting aspects given there. 699 Generally, for a given Type-P packet of length L at a specific Hi, 700 the methodology for spatial vector metrics may proceed as follows: 701 o At each Hi, points of interest/measurement collection points 702 prepare to capture the packet sent at time T, record a timestamp 703 Ti', and determine the internal delay correction dTi' (See section 704 3.7.1. "Errors or uncertainties related to Clocks" of [RFC2679]); 705 o Each Hi extracts the path ordering information from the packet 706 (e.g. time-to-live); 707 o Each Hi computes the corrected wiretime from Src to Hi: Ti = Ti' - 708 dTi'. This arrival time is undefined if the packet is not 709 detected after the 'loss threshold' duration; 710 o Each Hi extracts the timestamp T from the packet; 711 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 712 o The reference point gathers the result of each Hi and arranges 713 them according to the path ordering information received to build 714 the type-P spatial one-way vector (e.g. Type-P-Spatial-One-way- 715 Delay-Vector metric ) over the path 716 at time T. 718 5.4.1. Packet Loss Detection 720 In a pure end-to-end measurement, packet losses are detected by the 721 receiver only. A packet is lost when Type-P-One-way-Delay is 722 undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and 723 section 3.5 of [RFC2680]). A packet is deemed lost by the receiver 724 after a duration which starts at the time the packet is sent. This 725 timeout value is chosen by a measurement process. It determines the 726 threshold between recording a long packet transfer time as a finite 727 value or an undefined value. 729 In a spatial measurement, packet losses may be detected at several 730 measurement collection points. Depending on the consistency of the 731 packet loss detections among the points of interest, a packet may be 732 considered as lost at one point despite having a finite delay at 733 another one, or may be observed by the last measurement collection 734 point of the path but considered lost by Dst. 736 There is a risk of misinterpreting such results: Has the path 737 changed? Did the packet arrive at the destination or was it lost on 738 the very last link? 740 The same concern applies to one-way-delay measures: a delay measured 741 may be computed as infinite by one observation point but as a real 742 value by another one, or may be measured as a real value by the last 743 observation point of the path but designated as undefined by Dst. 745 The observation/measurement collection points and the destination 746 SHOULD use consistent methods to detect packets losses. The methods 747 and parameters must be systematically reported to permit careful 748 comparison and to avoid introducing any confounding factors in the 749 analysis. 751 5.4.2. Host Path Digest 753 The methodology given above relies on knowing the order of the hosts/ 754 measurement collection points on the path [RFC2330]. 756 Path instability might cause a test packet to be observed more than 757 once by the same host, resulting in the repetition of one or more 758 hosts in the Path Digest. 760 For example, repeated observations may occur during rerouting phases 761 which introduce temporary micro loops. During such an event the host 762 path digest for a packet crossing Ha and Hb may include the pattern 763 meaning that Ha ended the computation of the new 764 path before Hb and that the initial path was from Ha to Hb and that 765 the new path is from Hb to Ha. 767 Consequently, duplication of hosts in the path digest of a vector 768 MUST be identified before computation of statistics to avoid 769 producing corrupted information. 771 6. Spatial Segment Metrics Definitions 773 This section defines samples to measure the performance of a segment 774 of a path over time. The definitions rely on the matrix of the 775 spatial vector metrics defined above. 777 Firstly this section defines a sample of one-way delay, Type-P- 778 Segment-One-way-Delay-Stream, and a sample of packet loss, Type-P- 779 segment-Packet-Loss-Stream. 781 Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv- 782 prev-Stream uses the current and previous packets as the selection 783 function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay 784 as one of the selected packets in every pair. 786 6.1. A Definition of a Sample of One-way Delay of a Segment of the Path 788 This metric defines a sample of One-way delays over time between a 789 pair of hosts on a path. Since it is very close semantically to the 790 metric Type-P-One-way-Delay-Poisson-Stream defined in section 4 of 791 [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of the 792 definition text below. 794 6.1.1. Metric Name 796 Type-P-Segment-One-way-Delay-Stream 798 6.1.2. Metric Parameters 800 o Src, the IP address of the sender. 801 o Dst, the IP address of the receiver. 802 o Type-P, the specification of the packet type. 803 o i, an integer in the ordered list <1,2,...,n> of hosts in the 804 path. 805 o k, an integer which orders the packets sent. 806 o a and b, two integers where b > a. 807 o Hi, a host of the path digest. 808 o , a host path digest. 809 o , a list of times. 811 6.1.3. Metric Units 813 The value of a Type-P-Segment-One-way-Delay-Stream is a pair of: 814 A list of times ; 815 A sequence of delays. 817 6.1.4. Definition 819 Given 2 hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for the 821 packets sent from Src to Dst at times : 822 ; 823 ; 824 ... 825 . 827 We define the sample Type-P-segment-One-way-Delay-Stream as the 828 sequence such that for 829 each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if 830 the packet sent at time Tk passes Ha and Hb or undefined if this 831 packet never passes Ha or (inclusive) never passes Hb. 833 6.1.5. Discussion 835 Some specific issues that may occur are as follows: 836 o the delay singletons "appear" to decrease: dTi > DTi+1, and is 837 discussed in section 5.1.5. 838 * This could also occur when the clock resolution of one 839 measurement collection point is larger than the minimum delay 840 of a path. For example, the minimum delay of a 500 km path 841 through optical fiber facilities is 2.5ms, but the measurement 842 collection point has a clock resolution of 8ms. 843 The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if 844 the following conditions occur: 845 o Ha or Hb disappears from the path due to some routing change. 846 o The order of Ha and Hb changes in the path. 848 6.2. A Definition of a Sample of Packet Loss of a Segment of the Path 850 This metric defines a sample of packet loss over time between a pair 851 of hosts of a path. Since it is very close semantically to the 852 metric Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], 853 sections 3.5 to 3.8 of [RFC2680] are integral parts of the definition 854 text below. 856 6.2.1. Metric Name 858 Type-P-segment-Packet-Loss-Stream 860 6.2.2. Metric Parameters 862 o Src, the IP address of the sender. 864 o Dst, the IP address of the receiver. 865 o Type-P, the specification of the packet type. 866 o k, an integer which orders the packets sent. 867 o n, an integer which orders the hosts on the path. 868 o a and b, two integers where b > a. 869 o , a host path digest. 870 o Hi, exchange points of the path digest. 871 o , a list of times. 872 o , a list of Boolean values. 874 6.2.3. Metric Units 876 The value of a Type-P-segment-Packet-Loss-Stream is a pair of: 877 A The list of times ; 878 A sequence of Boolean values. 880 6.2.4. Definition 882 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-Packet-Loss-Vector for the 884 packets sent from Src to Dst at times : 885 , 886 , 887 ..., 888 . 890 We define the value of the sample Type-P-segment-Packet-Lost-Stream 891 from Ha to Hb as the sequence of Booleans such that for each Tk: 893 o A value of Lk of 0 means that Ha and Hb observed the packet sent 894 at time Tk (both Lk.a and Lk.b have a value of 0). 895 o A value of Lk of 1 means that Ha observed the packet sent at time 896 Tk (Lk.a has a value of 0) and that Hb did not observe the packet 897 sent at time Tk (Lk.b has a value of 1). 898 o The value of Lk is undefined when neither Ha nor Hb observed the 899 packet (both Lk.a and Lk.b have a value of 1). 901 6.2.5. Discussion 903 Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-Loss-Stream 904 relies on the stability of the host path digest. The metric SHALL be 905 invalid for times < T1 , T2, ..., Tm-1, Tm> if the following 906 conditions occur: 907 o Ha or Hb disappears from the path due to some routing change. 908 o The order of Ha and Hb changes in the path. 909 o Lk.a or Lk.b is undefined. 911 o Lk.a has the value 1 (not observed) and Lk.b has the value 0 912 (observed); 913 o L has the value 0 (the packet was received by Dst) and Lk.ab has 914 the value 1 (the packet was lost between Ha and Hb). 916 6.3. A Definition of a Sample of ipdv of a Segment using the Previous 917 Packet Selection Function 919 This metric defines a sample of ipdv [RFC3393] over time between a 920 pair of hosts using the previous packet as the selection function. 922 6.3.1. Metric Name 924 Type-P-Segment-ipdv-prev-Stream 926 6.3.2. Metric Parameters 928 o Src, the IP address of the sender. 929 o Dst, the IP address of the receiver. 930 o Type-P, the specification of the packet type. 931 o k, an integer which orders the packets sent. 932 o n, an integer which orders the hosts on the path. 933 o a and b, two integers where b > a. 934 o , the hosts path digest. 935 o , a list of times. 936 o , a 937 Type-P-Spatial-One-way-Delay-Vector. 939 6.3.3. Metric Units 941 The value of a Type-P-Segment-ipdv-prev-Stream is a pair of: 942 The list of ; 943 A list of pairs of interval of times and delays; 945 6.3.4. Definition 947 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 949 the packets sent from Src to Dst at times : 950 , 951 , 952 ... 953 . 955 We define the Type-P-Segment-ipdv-prev-Stream as the sequence of 956 packet time pairs and delay variations 958 <(T1, T2 , dT2.ab - dT1.ab) ,..., 959 (Tk-1, Tk, dTk.ab - dTk-1.ab), ..., 961 (Tm-1, Tm, dTm.ab - dTm-1.ab)> 963 For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk- 964 1.ab is undefined if: 965 o the delay dTk.a or the delay dTk-1.a is undefined, OR 966 o the delay dTk.b or the delay dTk-1.b is undefined. 968 6.3.5. Discussion 970 This metric belongs to the family of inter packet delay variation 971 metrics (IPDV in upper case) whose results are extremely sensitive to 972 the inter-packet interval in practice. 974 The inter-packet interval of an end-to-end IPDV metric is under the 975 control of the source (ingress point of interest). In contrast, the 976 inter-packet interval of a segment IPDV metric is not under the 977 control the ingress point of interest of the measure, Ha. The 978 interval will certainly vary if there is delay variation between the 979 Source and Ha. Therefore, the ingress inter-packet interval must be 980 known at Ha in order to fully comprehend the delay variation between 981 Ha and Hb. 983 6.4. A Definition of a Sample of ipdv of a Segment using the Minimum 984 Delay Selection Function 986 This metric defines a sample of ipdv [RFC3393] over time between a 987 pair of hosts on a path using the minimum delay as one of the 988 selected packets in every pair. 990 6.4.1. Metric Name 992 Type-P-Segment-One-way-ipdv-min-Stream 994 6.4.2. Metric Parameters 996 o Src, the IP address of the sender. 997 o Dst, the IP address of the receiver. 998 o Type-P, the specification of the packet type. 999 o k, an integer which orders the packets sent. 1000 o i, an integer which identifies a packet sent. 1001 o n, an integer which orders the hosts on the path. 1002 o a and b, two integers where b > a. 1003 o , the host path digest. 1004 o , a list of times. 1006 o , a 1007 Type-P-Spatial-One-way-Delay-Vector. 1009 6.4.3. Metric Units 1011 The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: 1012 The list of ; 1013 A list of times. 1015 6.4.4. Definition 1017 Given two hosts, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 1019 the packets sent from Src to Dst at times : 1020 , 1021 , 1022 ... 1023 . 1025 We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence 1026 of times where: 1028 o min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); 1029 o for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) 1030 dTk.b is undefined, or the real number (dTk.b - dTk.a) is 1031 undefined. 1033 6.4.5. Discussion 1035 This metric belongs to the family of packet delay variation metrics 1036 (PDV). PDV distributions have less sensitivity to inter-packet 1037 interval variations than IPDV values, as discussed above. 1039 In principle, the PDV distribution reflects the variation over many 1040 different inter-packet intervals, from the smallest inter-packet 1041 interval, up to the length of the evaluation interval, Tm - T1. 1042 Therefore, when delay variation occurs and disturbs the packet 1043 spacing observed at Ha, the PDV results will likely compare favorably 1044 to a PDV measurement where the source is Ha and the destination is 1045 Hb, because a wide range of spacings are reflected in any PDV 1046 distribution. 1048 7. One-to-group metrics definitions 1050 This section defines performance metrics between a source and a group 1051 of receivers. 1053 7.1. A Definition for One-to-group Delay 1055 This section defines a metric for one-way delay between a source and 1056 a group of receivers. 1058 7.1.1. Metric Name 1060 Type-P-One-to-group-Delay-Vector 1062 7.1.2. Metric Parameters 1064 o Src, the IP address of a host acting as the source. 1065 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1066 receivers. 1067 o T, a time. 1068 o dT1,...,dTn a list of times. 1069 o Type-P, the specification of the packet type. 1070 o Gr, the receiving group identifier. The parameter Gr is the 1071 multicast group address if the measured packets are transmitted 1072 over IP multicast. This parameter is to differentiate the 1073 measured traffic from other unicast and multicast traffic. It is 1074 OPTIONAL for this metric to avoid losing any generality, i.e. to 1075 make the metric also applicable to unicast measurement where there 1076 is only one receiver. 1078 7.1.3. Metric Units 1080 The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- 1081 One-way-Delay singletons [RFC2679], which is a sequence of times (a 1082 real number in the dimension of seconds with sufficient resolution to 1083 convey the results). 1085 7.1.4. Definition 1087 Given a Type-P packet sent by the source Src at time T, and the N 1088 hosts { Recv1,...,RecvN } which receive the packet at the time { 1089 T+dT1,...,T+dTn }, or the packet does not pass a receiver within a 1090 specified loss threshold time, then the Type-P-One-to-group-Delay- 1091 Vector is defined as the set of the Type-P-One-way-Delay singletons 1092 between Src and each receiver with value of { dT1, dT2,...,dTn }, 1093 where any of the singletons may be undefined if the packet did not 1094 pass the corresponding receiver within a specified loss threshold 1095 time. 1097 7.2. A Definition for One-to-group Packet Loss 1098 7.2.1. Metric Name 1100 Type-P-One-to-group-Packet-Loss-Vector 1102 7.2.2. Metric Parameters 1104 o Src, the IP address of a host acting as the source. 1105 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1106 receivers. 1107 o T, a time. 1108 o Type-P, the specification of the packet type. 1109 o Gr, the receiving group identifier, OPTIONAL. 1111 7.2.3. Metric Units 1113 The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of 1114 Type-P-One-way-Packet-Loss singletons [RFC2680]. 1116 o T, time the source packet was sent 1117 o L1,...,LN a list of boolean values 1119 7.2.4. Definition 1121 Given a Type P packet sent by the source Src at T and the N hosts, 1122 Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is 1123 defined as a set of the Type-P-One-way-Packet-Loss singletons between 1124 Src and each of the receivers 1126 {T, ,,..., }, 1128 where the boolean value 0|1 depends on receiving the packet at a 1129 particular receiver within a loss threshold time. 1131 7.3. A Definition for One-to-group ipdv 1133 7.3.1. Metric Name 1135 Type-P-One-to-group-ipdv-Vector 1137 7.3.2. Metric Parameters 1139 o Src, the IP address of a host acting as the source. 1140 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1141 receivers. 1142 o T1, a time. 1143 o T2, a time. 1145 o ddT1, ...,ddTn, a list of times. 1146 o Type-P, the specification of the packet type. 1147 o F, a selection function non-ambiguously defining the two packets 1148 from the stream selected for the metric. 1149 o Gr, the receiving group identifier. The parameter Gr is the 1150 multicast group address if the measured packets are transmitted 1151 over IP multicast. This parameter is to differentiate the 1152 measured traffic from other unicast and multicast traffic. It is 1153 OPTIONAL in the metric to avoid losing any generality, i.e. to 1154 make the metric also applicable to unicast measurement where there 1155 is only one receiver. 1157 7.3.3. Metric Units 1159 The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- 1160 One-way-ipdv singletons [RFC3393]. 1162 7.3.4. Definition 1164 Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is 1165 defined for two packets transferred from the source Src to the N 1166 hosts {Recv1,...,RecvN }, which are selected by the selection 1167 function F as the difference between the value of the Type-P-One-to- 1168 group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and 1169 the value of the Type-P-One-to-group-Delay-Vector from Src to { 1170 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1171 the first bit of the first packet, and T2 is the wire-time at which 1172 Src sent the first bit of the second packet. This metric is derived 1173 from the Type-P-One-to-group-Delay-Vector metric. 1175 For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- 1176 ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is 1177 {ddT1,...,ddTn} means that Src sent two packets, the first at wire- 1178 time T1 (first bit), and the second at wire-time T2 (first bit) and 1179 the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ 1180 T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ 1181 T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- 1182 dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1184 For any pair of selected packets, the difference dT'n-dTn is 1185 undefined if: 1186 o the delay dTn to Receiver n is undefined, OR 1187 o the delay dT'n to Receiver n is undefined. 1189 8. One-to-group Sample Statistics 1191 The one-to-group metrics defined above are directly achieved by 1192 collecting relevant unicast one-way metrics measurements results and 1193 by gathering them per group of receivers. They produce network 1194 performance information which guides engineers toward potential 1195 problems which may have happened on any branch of a multicast routing 1196 tree. 1198 The results of these metrics are not directly usable to present the 1199 performance of a group because each result is made of a huge number 1200 of singletons which are difficult to read and analyze. As an 1201 example, delays are not comparable because the distance between 1202 receiver and sender differs. Furthermore they don't capture relative 1203 performance situation a multiparty communication. 1205 From the performance point of view, the multiparty communication 1206 services not only require the support of absolute performance 1207 information but also information on "relative performance". The 1208 relative performance means the difference between absolute 1209 performance of all users. Directly using the one-way metrics cannot 1210 present the relative performance situation. However, if we use the 1211 variations of all users one-way parameters, we can have new metrics 1212 to measure the difference of the absolute performance and hence 1213 provide the threshold value of relative performance that a multiparty 1214 service might demand. A very good example of the high relative 1215 performance requirement is online gaming. A very small difference in 1216 delay might result in failure in the game. We have to use multicast 1217 specific statistic metrics to define the relative delay required by 1218 online gaming. There are many other services, e.g. online biding, 1219 online stock market, etc., that require multicast metrics in order to 1220 evaluate the network against their requirements. Therefore, we can 1221 see the importance of new, multicast specific, statistic metrics to 1222 feed this need. 1224 We might also use some one-to-group statistic conceptions to present 1225 and report the group performance and relative performance to save the 1226 report transmission bandwidth. Statistics have been defined for One- 1227 way metrics in corresponding RFCs. They provide the foundation of 1228 definition for performance statistics. For instance, there are 1229 definitions for minimum and maximum One-way delay in [RFC2679]. 1230 However, there is a dramatic difference between the statistics for 1231 one-to-one communications and for one-to-many communications. The 1232 former one only has statistics over the time dimension while the 1233 later one can have statistics over both time and space dimensions. 1234 This space dimension is introduced by the Matrix concept as 1235 illustrated in Figure 4. For a Matrix M each row is a set of One-way 1236 singletons spreading over the time dimension and each column is 1237 another set of One-way singletons spreading over the space dimension. 1239 Receivers 1240 Space 1241 ^ 1242 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1243 | | | 1244 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1245 | | | 1246 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1247 . | | | 1248 . | | | 1249 . | | | 1250 n | \ RndT1 RndT2 RndT3 ... RndTk / 1251 +--------------------------------------------> time 1252 T0 1254 Figure 4: Matrix M (n*m) 1256 In Matrix M, each element is a one-way delay singleton. Each column 1257 is a delay vector contains the One-way delays of the same packet 1258 observed at M points of interest. It implies the geographical factor 1259 of the performance within a group. Each row is a set of One-way 1260 delays observed during a sampling interval at one of the points of 1261 interest. It presents the delay performance at a receiver over the 1262 time dimension. 1264 Therefore, one can either calculate statistics by rows over the space 1265 dimension or by columns over the time dimension. It's up to the 1266 operators or service provides which dimension they are interested in. 1267 For example, a TV broadcast service provider might want to know the 1268 statistical performance of each user in a long term run to make sure 1269 their services are acceptable and stable. While for an online gaming 1270 service provider, he might be more interested to know if all users 1271 are served fairly by calculating the statistics over the space 1272 dimension. This memo does not intend to recommend which of the 1273 statistics are better than the other. 1275 To save the report transmission bandwidth, each point of interest can 1276 send statistics in a pre-defined time interval to the reference point 1277 rather than sending every one-way singleton it observed. As long as 1278 an appropriate time interval is decided, appropriate statistics can 1279 represent the performance in a certain accurate scale. How to decide 1280 the time interval and how to bootstrap all points of interest and the 1281 reference point depend on applications. For instance, applications 1282 with lower transmission rate can have the time interval longer and 1283 ones with higher transmission rate can have the time interval 1284 shorter. However, this is out of the scope of this memo. 1286 Moreover, after knowing the statistics over the time dimension, one 1287 might want to know how these statistics are distributed over the 1288 space dimension. For instance, a TV broadcast service provider had 1289 the performance Matrix M and calculated the One-way delay mean over 1290 the time dimension to obtain a delay Vector as {V1,V2,..., VN}. He 1291 then calculated the mean of all the elements in the Vector to see 1292 what level of delay he has served to all N users. This new delay 1293 mean gives information on how good the service has been delivered to 1294 a group of users during a sampling interval in terms of delay. It 1295 requires twice as much calculation to have this statistic over both 1296 time and space dimensions. This kind of statistics is referred to as 1297 2-level statistics to distinguish them from 1-level statistics 1298 calculated over either space or time dimension. It can be easily 1299 proven that no matter over which dimension a 2-level statistic is 1300 calculated first, the results are the same. I.e. one can calculate 1301 the 2-level delay mean using the Matrix M by having the 1-level delay 1302 mean over the time dimension first and then calculate the mean of the 1303 obtained vector to find out the 2-level delay mean. Or, he can do 1304 the 1-level statistic calculation over the space dimension first and 1305 then have the 2-level delay mean. Both two results will be exactly 1306 the same. Therefore, when defining a 2-level statistic there is no 1307 need to specify the order in which the calculation is executed. 1309 Many statistics can be defined for the proposed one-to-group metrics 1310 over either the space dimension or the time dimension or both. This 1311 memo treats the case where a stream of packets from the Source 1312 results in a sample at each of the Receivers in the Group, and these 1313 samples are each summarized with the usual statistics employed in 1314 one-to-one communication. New statistic definitions are presented, 1315 which summarize the one-to-one statistics over all the Receivers in 1316 the Group. 1318 8.1. Discussion on the Impact of packet loss on statistics 1320 The packet loss does have effects on one-way metrics and their 1321 statistics. For example, a lost packet can result in an infinite 1322 one-way delay. It is easy to handle the problem by simply ignoring 1323 the infinite value in the metrics and in the calculation of the 1324 corresponding statistics. However, the packet loss has such a strong 1325 impact on the statistics calculation for the one-to-group metrics 1326 that it can not be solved by the same method used for one-way 1327 metrics. This is due to the complexity of building a matrix, which 1328 is needed for calculation of the statistics proposed in this memo. 1330 The situation is that measurement results obtained by different end 1331 users might have different packet loss pattern. For example, for 1332 User1, packet A was observed lost. And for User2, packet A was 1333 successfully received but packet B was lost. If the method to 1334 overcome the packet loss for one-way metrics is applied, the two 1335 singleton sets reported by User1 and User2 will be different in terms 1336 of the transmitted packets. Moreover, if User1 and User2 have 1337 different number of lost packets, the size of the results will be 1338 different. Therefore, for the centralized calculation, the reference 1339 point will not be able to use these two results to build up the group 1340 Matrix and can not calculate the statistics. The extreme situation 1341 being the case when no packets arrive at any user. One of the 1342 possible solutions is to replace the infinite/undefined delay value 1343 by the average of the two adjacent values. For example, if the 1344 result reported by user1 is { R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF 1345 R1dTK+1... R1DM } where "UNDEF" is an undefined value, the reference 1346 point can replace it by R1dTK = {(R1dTK-1)+( R1dTK+1)}/2. Therefore, 1347 this result can be used to build up the group Matrix with an 1348 estimated value R1dTK. There are other possible solutions such as 1349 using the overall mean of the whole result to replace the infinite/ 1350 undefined value, and so on. However this is out of the scope of this 1351 memo. 1353 For the distributed calculation, the reported statistics might have 1354 different "weight" to present the group performance, which is 1355 especially true for delay and ipdv relevant metrics. For example, 1356 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1357 in Figure. 8 without any packet loss and User2 calculates the R2DM 1358 with N-2 packet loss. The R1DM and R2DM should not be treated with 1359 equal weight because R2DM was calculated only based on 2 delay values 1360 in the whole sample interval. One possible solution is to use a 1361 weight factor to mark every statistic value sent by users and use 1362 this factor for further statistic calculation. 1364 8.2. General Metric Parameters 1366 o Src, the IP address of a host; 1367 o G, the receiving group identifier; 1368 o N, the number of Receivers (Recv1, Recv2, ... RecvN); 1369 o T, a time (start of test interval); 1370 o Tf, a time (end of test interval); 1371 o K, the number of packets sent from the source during the test 1372 interval; 1373 o J[n], the number of packets received at a particular Receiver, n, 1374 where 1<=n<=N; 1375 o lambda, a rate in reciprocal seconds (for Poisson Streams); 1376 o incT, the nominal duration of inter-packet interval, first bit to 1377 first bit (for Periodic Streams); 1378 o T0, a time that MUST be selected at random from the interval [T, 1379 T+I] to start generating packets and taking measurements (for 1380 Periodic Streams); 1382 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1383 Source Measurement Point); 1384 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1385 assigned to packets that arrive within a "reasonable" time; 1386 o Tmax, a maximum waiting time for packets at the destination, set 1387 sufficiently long to disambiguate packets with long delays from 1388 packets that are discarded (lost), thus the distribution of delay 1389 is not truncated; 1390 o dT, shorthand notation for a one-way delay singleton value; 1391 o L, shorthand notation for a one-way loss singleton value, either 1392 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1393 the destination within TstampSrc + Tmax, may be indexed over n 1394 Receivers; 1395 o DV, shorthand notation for a one-way delay variation singleton 1396 value. 1398 8.3. One-to-group Delay Statistics 1400 This section defines the overall one-way delay statistics for a 1401 receiver and for an entire group as illustrated by the matrix below. 1403 Recv /----------- Sample -------------\ Stats Group Stat 1405 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \ 1406 | 1407 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | 1408 | 1409 3 R3dT1 R3dT2 R3dT3 ... R3dTk R3MD > Group delay 1410 . | 1411 . | 1412 . | 1413 n RndT1 RndT2 RndT3 ... RndTk RnMD / 1415 Receiver-n 1416 delay 1418 Figure 5: One-to-group Mean Delay 1420 Statistics are computed on the finite One-way delays of the matrix 1421 above. 1423 All One-to-group delay statistics are expressed in seconds with 1424 sufficient resolution to convey 3 significant digits. 1426 8.3.1. Type-P-One-to-group-Receiver-n-Mean-Delay 1428 This section defines Type-P-One-to-group-Receiver-n-Mean-Delay the 1429 Delay Mean at each Receiver N, also named RnDM. 1431 We obtain the value of Type-P-One-way-Delay singleton for all packets 1432 sent during the test interval at each Receiver (Destination), as per 1433 [RFC2679]. For each packet that arrives within Tmax of its sending 1434 time, TstampSrc, the one-way delay singleton (dT) will be the finite 1435 value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, 1436 the value of the singleton is Undefined. 1438 J[n] 1439 --- 1440 1 \ 1441 RnMD = --- * > TstampRecv[i] - TstampSrc[i] 1442 J[n] / 1443 --- 1444 i = 1 1446 Figure 6: Type-P-One-to-group-Receiver-N-Mean-Delay 1448 where all packets i= 1 through J[n] have finite singleton delays. 1450 8.3.2. Type-P-One-to-group-Mean-Delay 1452 This section defines Type-P-One-to-group-Mean-Delay, the Mean One-way 1453 delay calculated over the entire Group, also named GMD. 1455 N 1456 --- 1457 1 \ 1458 GMD = - * > RnDM 1459 N / 1460 --- 1461 n = 1 1463 Figure 7: Type-P-One-to-group-Mean-Delay 1465 Note that the Group Mean Delay can also be calculated by summing the 1466 Finite one-way Delay singletons in the Matrix, and dividing by the 1467 number of Finite One-way Delay singletons. 1469 8.3.3. Type-P-One-to-group-Range-Mean-Delay 1471 This section defines a metric for the range of mean delays over all N 1472 receivers in the group (R1DM, R2DM,...RnDM). 1474 Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1476 8.3.4. Type-P-One-to-group-Max-Mean-Delay 1478 This section defines a metric for the maximum of mean delays over all 1479 N receivers in the group (R1DM, R2DM,...RnDM). 1481 Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnDM) 1483 8.4. One-to-group Packet Loss Statistics 1485 This section defines the overall one-way loss statistics for a 1486 receiver and for an entire group as illustrated by the matrix below. 1488 Recv /----------- Sample ----------\ Stats Group Stat 1490 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1491 | 1492 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1493 | 1494 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio 1495 . | 1496 . | 1497 . | 1498 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1500 Receiver-n 1501 Loss Ratio 1503 Figure 8: One-to-group Loss Ratio 1505 Statistics are computed on the sample of Type-P-One-way-Packet-Loss 1506 [RFC2680] of the matrix above. 1508 All loss ratios are expressed in units of packets lost to total 1509 packets sent. 1511 8.4.1. Type-P-One-to-group-Receiver-n-Loss-Ratio 1513 Given a Matrix of loss singletons as illustrated above, determine the 1514 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1515 according to the definitions and method of [RFC2680]. The Type-P- 1516 One-way-Packet-Loss-Average and the Type-P-One-to-group-Receiver-n- 1517 Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the 1518 parameters used here, these metrics definitions can be expressed as 1519 K 1520 --- 1521 1 \ 1522 RnLR = - * > RnLk 1523 K / 1524 --- 1525 k = 1 1527 Figure 9: Type-P-One-to-group-Receiver-n-Loss-Ratio 1529 8.4.2. Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1531 Usually, the number of packets sent is used in the denominator of 1532 packet loss ratio metrics. For the comparative metrics defined here, 1533 the denominator is the maximum number of packets received at any 1534 receiver for the sample and test interval of interest. 1536 The Comparative Loss Ratio, also named, RnCLR, is defined as 1538 K 1539 --- 1540 \ 1541 > Ln(k) 1542 / 1543 --- 1544 k=1 1545 RnCLR = ----------------------------- 1546 / K \ 1547 | --- | 1548 | \ | 1549 K - Min | > Ln(k) | 1550 | / | 1551 | --- | 1552 \ k=1 / N 1554 Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1556 8.4.3. Type-P-One-to-group-Loss-Ratio 1558 Type-P-One-to-group-Loss-Ratio, the overall Group loss ratio, also 1559 named GLR, is defined as 1560 K,N 1561 --- 1562 1 \ 1563 GLR = --- * > L(k,n) 1564 K*N / 1565 --- 1566 k,n = 1 1568 Figure 11: Type-P-One-to-group-Loss-Ratio 1570 8.4.4. Type-P-One-to-group-Range-Loss-Ratio 1572 The One-to-group Loss Ratio Range is defined as: 1574 Type-P-One-to-group-Range-Loss-Ratio = max(RnLR) - min(RnLR) 1576 It is most effective to indicate the range by giving both the max and 1577 minimum loss ratios for the Group, rather than only reporting the 1578 difference between them. 1580 8.5. One-to-group Delay Variation Statistics 1582 This section defines one-way delay variation (DV) statistics for an 1583 entire group as illustrated by the matrix below. 1585 Recv /------------- Sample --------------\ Stats 1587 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ 1588 | 1589 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | 1590 | 1591 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat 1592 . | 1593 . | 1594 . | 1595 n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / 1597 Figure 12: One-to-group Delay Variation Matrix (DVMa) 1599 Statistics are computed on the sample of Type-P-One-way-Delay- 1600 Variation singletons of the group delay variation matrix above where 1601 RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at 1602 Receiver n for the packet k and where RnDV is the point-to-point one- 1603 way packet delay variation for Receiver n. 1605 All One-to-group delay variation statistics are expressed in seconds 1606 with sufficient resolution to convey 3 significant digits. 1608 8.5.1. Type-P-One-to-group-Range-Delay-Variation 1610 This section defines a metric for the range of delays variation over 1611 all N receivers in the Group. 1613 Maximum DV and minimum DV over all receivers summarize the 1614 performance over the Group (where DV is a point-to-point metric). 1615 For each receiver, the DV is usually expressed as the 1-10^(-3) 1616 quantile of one-way delay minus the minimum one-way delay. 1618 Type-P-One-to-group-Range-Delay-Variation = GRDV = 1620 = max(RnDV) - min(RnDV) for all n receivers 1622 This range is determined from the minimum and maximum values of the 1623 point-to-point one-way IP Packet Delay Variation for the set of 1624 Destinations in the group and a population of interest, using the 1625 Packet Delay Variation expressed as the 1-10^-3 quantile of one-way 1626 delay minus the minimum one-way delay. If a more demanding service 1627 is considered, one alternative is to use the 1-10^-5 quantile, and in 1628 either case the quantile used should be recorded with the results. 1629 Both the minimum and the maximum delay variation are recorded, and 1630 both values are given to indicate the location of the range. 1632 9. Measurement Methods: Scalability and Reporting 1634 Virtually all the guidance on measurement processes supplied by the 1635 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1636 scenarios is applicable here in the spatial and multiparty 1637 measurement scenario. The main difference is that the spatial and 1638 multiparty configurations require multiple points of interest where a 1639 stream of singletons will be collected. The amount of information 1640 requiring storage grows with both the number of metrics and the 1641 points of interest, so the scale of the measurement architecture 1642 multiplies the number of singleton results that must be collected and 1643 processed. 1645 It is possible that the architecture for results collection involves 1646 a single reference point with connectivity to all the points of 1647 interest. In this case, the number of points of interest determines 1648 both storage capacity and packet transfer capacity of the host acting 1649 as the reference point. However, both the storage and transfer 1650 capacity can be reduced if the points of interest are capable of 1651 computing the summary statistics that describe each measurement 1652 interval. This is consistent with many operational monitoring 1653 architectures today, where even the individual singletons may not be 1654 stored at each point of interest. 1656 In recognition of the likely need to minimize the form of the results 1657 for storage and communication, the Group metrics above have been 1658 constructed to allow some computations on a per-Receiver basis. This 1659 means that each Receiver's statistics would normally have an equal 1660 weight with all other Receivers in the Group (regardless of the 1661 number of packets received). 1663 9.1. Computation methods 1665 The scalability issue can be raised when there are thousands of 1666 points of interest in a group who are trying to send back the 1667 measurement results to the reference point for further processing and 1668 analysis. The points of interest can send either the whole measured 1669 sample or only the calculated statistics. The former one is a 1670 centralized statistic calculation method and the latter one is a 1671 distributed statistic calculation method. The sample should include 1672 all metrics parameters, the values and the corresponding sequence 1673 numbers. The transmission of the whole sample can cost much more 1674 bandwidth than the transmission of the statistics that should include 1675 all statistic parameters specified by policies and the additional 1676 information about the whole sample, such as the size of the sample, 1677 the group address, the address of the point of interest, the ID of 1678 the sample session, and so on. Apparently, the centralized 1679 calculation method can require much more bandwidth than the 1680 distributed calculation method when the sample size is big. This is 1681 especially true when the measurement has a very large number of the 1682 points of interest. It can lead to a scalability issue at the 1683 reference point by overloading the network resources. 1685 The distributed calculation method can save much more bandwidth and 1686 mitigate issues arising from scalability at the reference point side. 1688 However, it may result in a lost of information. As all measured 1689 singletons are not available for building up the group matrix, the 1690 real performance over time can be hidden from the result. For 1691 example, the loss pattern can be missed by simply accepting the loss 1692 ratio. This tradeoff between bandwidth consumption and information 1693 acquisition has to be taken into account when designing the 1694 measurement approach. 1696 One possible solution could be to transit the statistic parameters to 1697 the reference point first to obtain the general information of the 1698 group performance. If detailed results are required, the reference 1699 point should send the requests to the points of interest, which could 1700 be particular ones or the whole group. This procedure can happen in 1701 the off peak time and can be well scheduled to avoid delivery of too 1702 many points of interest at the same time. Compression techniques can 1703 also be used to minimize the bandwidth required by the transmission. 1705 This could be a measurement protocol to report the measurement 1706 results. However, this is out of the scope of this memo. 1708 9.2. Measurement 1710 To prevent any bias in the result, the configuration of a one-to-many 1711 measure must take in consideration that intrically more packets will 1712 to be routed than sent (copies of a packet sent are expected to 1713 arrive at many destination points) and selects a test packets rate 1714 that will not impact the network performance. 1716 9.3. Effect of Time and Space Aggregation Order on Stats 1718 This section presents the impact of the aggregation order on the 1719 scalability of the reporting and of the computation. It makes the 1720 hypothesis that receivers are not co-located and that results are 1721 gathered in a point of reference for further usages. 1723 Multimetrics samples are represented in a matrix as illustrated below 1725 Point of 1726 interest 1727 1 R1S1 R1S1 R1S1 ... R1Sk \ 1728 | 1729 2 R2S1 R2S2 R2S3 ... R2Sk | 1730 | 1731 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1732 . | 1733 . | 1734 . | 1735 n RnS1 RnS2 RnS3 ... RnSk / 1737 S1M S2M S3M ... SnM Stats over space 1739 \------------- ------------/ 1740 \/ 1741 Stat over space and time 1743 Figure 13: Impact of space aggregation on multimetrics Stat 1745 Two methods are available to compute statistics on a matrix: 1746 o Method 1: The statistic metric is computed over time and then over 1747 space; 1748 o Method 2: The statistic metric is computed over space and then 1749 over time. 1751 These 2 methods differ only by the order of the aggregation. The 1752 order does not impact the computation resources required. It does 1753 not change the value of the result. However, it impacts severely the 1754 minimal volume of data to report: 1755 o Method 1: Each point of interest computes periodically statistics 1756 over time to lower the volume of data to report. They are 1757 reported to the reference point for for subsequent computations 1758 over the spatial dimension. This volume no longer depends on the 1759 number of samples. It is only proportional to the computation 1760 period; 1761 o Method 2: The volume of data to report is proportional to the 1762 number of samples. Each sample, RiSi, must be reported to the 1763 reference point for computing statistic over space and statistic 1764 over time. The volume increases with the number of samples. It 1765 is proportional to the number of test packets; 1767 Method 2 has severe drawbacks in terms of security and dimensioning: 1768 o Increasing the rate of the test packets may result in a Denial of 1769 Service toward the points of reference; 1770 o The dimensioning of a measurement system is quite impossible to 1771 validate because any increase of the rate of the test packets will 1772 increase the bandwidth requested to collect the raw results. 1774 The computation period over time period (commonly named aggregation 1775 period) provides the reporting side with a control of various 1776 collecting aspects such as bandwidth, computation and storage 1777 capacities. So this draft defines metrics based on method 1. 1779 9.3.1. Impact on spatial statistics 1781 Two methods are available to compute spatial statistics: 1782 o Method 1: spatial segment metrics and statistics are preferably 1783 computed over time for each points of interest; 1784 o Method 2: Vectors metrics are intrinsically instantaneous space 1785 metrics which must be reported using Method2 whenever 1786 instantaneous metrics information is needed. 1788 9.3.2. Impact on one-to-group statistics 1790 Two methods are available to compute group statistics: 1791 o Method1: Figure 5 and Figure 8 illustrate the method chosen: the 1792 one-to-one statistic is computed per interval of time before the 1793 computation of the mean over the group of receivers; 1794 o Method2: Figure 13 presents the second one, metric is computed 1795 over space and then over time. 1797 10. Manageability Considerations 1799 Usually IPPM WG documents defines each metric reporting within its 1800 definition. This document defines the reporting of all the metrics 1801 introduced in a single section to provide consistent information, to 1802 avoid repetitions and to conform to IESG recommendation of gathering 1803 manageability considerations in a dedicated section. 1805 Information models of spatial metrics and of one-to-group metrics are 1806 similar excepted that points of interests of spatial vectors must be 1807 ordered. 1809 The complexity of the reporting relies on the number of points of 1810 interests. 1812 10.1. Reporting spatial metric 1814 The reporting of spatial metrics shares a lot of aspects with 1815 RFC2679-80. New ones are common to all the definitions and are 1816 mostly related to the reporting of the path and of methodology 1817 parameters that may bias raw results analysis. This section presents 1818 these specific parameters and then lists exhaustively the parameters 1819 that shall be reported. 1821 10.1.1. Path 1823 End-to-end metrics can't determine the path of the measure despite 1824 IPPM RFCs recommend it to be reported (See Section 3.8.4 of 1825 [RFC2679]). Spatial metrics vectors provide this path. The report 1826 of a spatial vector must include the points of interests involved: 1827 the sub set of the hosts of the path participating to the 1828 instantaneous measure. 1830 10.1.2. Host order 1832 A spatial vector must order the points of interest according to their 1833 order in the path. It is highly suggested to use the TTL in IPv4, 1834 the Hop Limit in IPv6 or the corresponding information in MPLS. 1836 The report of a spatial vector must include the ordered list of the 1837 hosts involved in the instantaneous measure. 1839 10.1.3. Timestamping bias 1841 The location of the point of interest inside a node influences the 1842 timestamping skew and accuracy. As an example, consider that some 1843 internal machinery delays the timestamping up to 3 milliseconds then 1844 the minimal uncertainty reported be 3 ms if the internal delay is 1845 unknown at the time of the timestamping. 1847 The report of a spatial vector must include the uncertainty of the 1848 timestamping compared to wire time. 1850 10.1.4. Reporting spatial One-way Delay 1852 The reporting includes information to report for one-way-delay as the 1853 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1855 10.2. Reporting One-to-group metric 1857 All reporting rules described in [RFC2679] and [RFC2680] apply to the 1858 corresponding One-to-group metrics. Following are specific 1859 parameters that should be reported. 1861 10.2.1. Path 1863 As suggested by the [RFC2679] and [RFC2680], the path traversed by 1864 the packet SHOULD be reported, if possible. For One-to-group 1865 metrics, the path tree between the source and the destinations or the 1866 set of paths between the source and each destination SHOULD be 1867 reported. 1869 Path tree might not be as valuable as individual paths because an 1870 incomplete path might be difficult to identify in the path tree. For 1871 example, how many points of interest are reached by a packet 1872 travelling along an incomplete path? 1874 10.2.2. Group size 1876 The group size should be reported as one of the critical management 1877 parameters. One-to-group metrics, unlike spatial metrics, don't 1878 require the ordering of the points of interests because group members 1879 receive the packets in parallel. 1881 10.2.3. Timestamping bias 1883 It is the same as described in section 10.1.3. 1885 10.2.4. Reporting One-to-group One-way Delay 1887 It is the same as described in section 10.1.4. 1889 10.2.5. Measurement method 1891 As explained in section 9, the measurement method will have impact on 1892 the analysis of the measurement result. Therefore, it should be 1893 reported. 1895 10.3. Metric identification 1897 IANA assigns each metric defined by the IPPM WG with a unique 1898 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1900 10.4. Information model 1902 This section presents the elements of information and the usage of 1903 the information reported for network performance analysis. It is out 1904 of the scope of this section to define how the information is 1905 reported. 1907 The information model is built with pieces of information introduced 1908 and explained in one-way delay definitions [RFC2679], in packet loss 1909 definitions [RFC2680] and in IPDV definitions of [RFC3393] and 1910 [RFC3432]. It includes not only information given by "Reporting the 1911 metric" sections but by sections "Methodology" and "Errors and 1912 Uncertainties". 1914 Following are the elements of information taken from end-to-end 1915 metrics definitions referred in this memo and from spatial and 1916 multicast metrics it defines: 1918 o Packet_type, The Type-P of test packets (Type-P); 1919 o Packet_length, a packet length in bits (L); 1920 o Src_host, the IP address of the sender; 1921 o Dst_host, the IP address of the receiver; 1922 o Hosts_serie: , a list of points of interest; 1923 o Loss_threshold: The threshold of infinite delay; 1924 o Systematic_error: constant delay between wire time and 1925 timestamping; 1926 o Calibration_error: maximal uncertainty; 1927 o Src_time, the sending time for a measured packet; 1928 o Dst_time, the receiving time for a measured packet; 1929 o Result_status : an indicator of usability of a result 'Resource 1930 exhaustion' 'infinite', 'lost'; 1931 o Delays_serie: a list of delays; 1932 o Losses_serie: , a list of Boolean values 1933 (spatial) or a set of Boolean values (one-to-group); 1934 o Result_status_serie: a list of results status; 1935 o dT: a delay; 1936 o Singleton_number: a number of singletons; 1937 o Observation_duration: An observation duration; 1938 o metric_identifier. 1940 Following is the information of each vector that should be available 1941 to compute samples: 1943 o Packet_type; 1944 o Packet_length; 1945 o Src_host, the sender of the packet; 1946 o Dst_host, the receiver of the packet, apply only for spatial 1947 vectors; 1948 o Hosts_serie: not ordered for one-to-group; 1949 o Src_time, the sending time for the measured packet; 1950 o dT, the end-to-end one-way delay for the measured packet, apply 1951 only for spatial vectors; 1952 o Delays_serie: apply only for delays and ipdv vector, not ordered 1953 for one-to-group; 1954 o Losses_serie: apply only for packets loss vector, not ordered for 1955 one-to-group; 1956 o Result_status_serie; 1957 o Observation_duration: the difference between the time of the last 1958 singleton and the time of the first singleton. 1959 o Following is the context information (measure, points of 1960 interests) that should be available to compute samples : 1961 * Loss threshold; 1962 * Systematic error: constant delay between wire time and 1963 timestamping; 1964 * Calibration error: maximal uncertainty; 1966 A spatial or a one-to-group sample is a collection of singletons 1967 giving the performance from the sender to a single point of interest. 1968 Following is the information that should be available for each sample 1969 to compute statistics: 1971 o Packet_type; 1972 o Packet_length; 1973 o Src_host, the sender of the packet; 1974 o Dst_host, the receiver of the packet; 1975 o Start_time, the sending time of the first packet; 1976 o Delays_serie: apply only for delays and ipdv samples; 1977 o Losses_serie: apply only for packets loss samples; 1978 o Result_status_serie; 1979 o Observation_duration: the difference between the time of the last 1980 singleton of the last sample and the time of the first singleton 1981 of the first sample. 1982 o Following is the context information (measure, points of 1983 interests) that should be available to compute statistics : 1984 * Loss threshold; 1985 * Systematic error: constant delay between wire time and 1986 timestamping; 1987 * Calibration error: maximal uncertainty; 1989 Following is the information of each statistic that should be 1990 reported: 1992 o Result; 1993 o Start_time; 1994 o Duration; 1995 o Result_status; 1996 o Singleton_number, the number of singletons the statistic is 1997 computed on; 1999 11. Security Considerations 2001 Spatial and one-to-group metrics are defined on the top of end-to-end 2002 metrics. Security considerations discussed in One-way delay metrics 2003 definitions of [RFC2679] , in packet loss metrics definitions of 2004 [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 2005 apply to metrics defined in this memo. 2007 11.1. Spatial metrics 2009 Malicious generation of packets with spoofing addresses may corrupt 2010 the results without any possibility to detect the spoofing. 2012 Malicious generation of packets which match systematically the hash 2013 function used to detect the packets may lead to a DoS attack toward 2014 the point of reference. 2016 11.2. One-to-group metrics 2018 Reporting of measurement results from a huge number of probes may 2019 overload reference point resources (network, network interfaces, 2020 computation capacities ...). 2022 The configuration of a measurement must take in consideration that 2023 implicitly more packets will be routed than sent and selects a test 2024 packets rate accordingly. Collecting statistics from a huge number 2025 of probes may overload any combination of the network where the 2026 measurement controller is attached to, measurement controller network 2027 interfaces and measurement controller computation capacities. 2029 One-to-group metrics measurement should consider using source 2030 authentication protocols, standardized in the MSEC group, to avoid 2031 fraud packet in the sampling interval. The test packet rate could be 2032 negotiated before any measurement session to avoid deny of service 2033 attacks. 2035 12. Acknowledgments 2037 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2038 of Surrey, for his instruction and helpful comments on this work. 2040 13. IANA Considerations 2042 Metrics defined in this memo Metrics defined in this memo are 2043 designed to be registered in the IANA IPPM METRICS REGISTRY as 2044 described in initial version of the registry [RFC4148] : 2046 IANA is asked to register the following metrics in the IANA-IPPM- 2047 METRICS-REGISTRY-MIB : 2049 ietfSpatialOneWayDelayVector OBJECT-IDENTITY 2050 STATUS current 2051 DESCRIPTION 2052 "Type-P-Spatial-One-way-Delay-Vector" 2053 REFERENCE 2054 "Reference "RFCyyyy, section 5.1." 2055 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2056 note 2057 := { ianaIppmMetrics nn } -- IANA assigns nn 2059 ietfSpatialPacketLossVector OBJECT-IDENTITY 2060 STATUS current 2061 DESCRIPTION 2062 "Type-P-Spatial-Packet-Loss-Vector" 2063 REFERENCE 2064 "Reference "RFCyyyy, section 5.2." 2065 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2066 note 2067 := { ianaIppmMetrics nn } -- IANA assigns nn 2069 ietfSpatialOneWayIpdvVector OBJECT-IDENTITY 2070 STATUS current 2071 DESCRIPTION 2072 "Type-P-Spatial-One-way-ipdv-Vector" 2073 REFERENCE 2074 "Reference "RFCyyyy, section 5.3." 2075 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2076 note 2077 := { ianaIppmMetrics nn } -- IANA assigns nn 2079 ietfSegmentOneWayDelayStream OBJECT-IDENTITY 2080 STATUS current 2081 DESCRIPTION 2082 "Type-P-Segment-One-way-Delay-Stream" 2083 REFERENCE 2084 "Reference "RFCyyyy, section 6.1." 2085 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2086 note 2087 := { ianaIppmMetrics nn } -- IANA assigns nn 2089 ietfSegmentPacketLossStream OBJECT-IDENTITY 2090 STATUS current 2091 DESCRIPTION 2092 "Type-P-Segment-Packet-Loss-Stream" 2093 REFERENCE 2094 "Reference "RFCyyyy, section 6.2." 2095 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2096 note 2097 := { ianaIppmMetrics nn } -- IANA assigns nn 2099 ietfSegmentIpdvPrevStream OBJECT-IDENTITY 2100 STATUS current 2101 DESCRIPTION 2102 "Type-P-Segment-ipdv-prev-Stream" 2103 REFERENCE 2104 "Reference "RFCyyyy, section 6.3." 2105 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2106 note 2107 := { ianaIppmMetrics nn } -- IANA assigns nn 2109 ietfSegmentIpdvMinStream OBJECT-IDENTITY 2110 STATUS current 2111 DESCRIPTION 2112 "Type-P-Segment-ipdv-min-Stream" 2113 REFERENCE 2114 "Reference "RFCyyyy, section 6.4." 2115 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2116 note 2117 := { ianaIppmMetrics nn } -- IANA assigns nn 2119 -- One-to-group metrics 2121 ietfOneToGroupDelayVector OBJECT-IDENTITY 2122 STATUS current 2123 DESCRIPTION 2124 "Type-P-One-to-group-Delay-Vector" 2125 REFERENCE 2126 "Reference "RFCyyyy, section 7.1." 2127 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2128 note 2129 := { ianaIppmMetrics nn } -- IANA assigns nn 2131 ietfOneToGroupPacketLossVector OBJECT-IDENTITY 2132 STATUS current 2133 DESCRIPTION 2134 "Type-P-One-to-group-Packet-Loss-Vector" 2135 REFERENCE 2136 "Reference "RFCyyyy, section 7.2." 2137 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2138 note 2139 := { ianaIppmMetrics nn } -- IANA assigns nn 2141 ietfOneToGroupIpdvVector OBJECT-IDENTITY 2142 STATUS current 2143 DESCRIPTION 2144 "Type-P-One-to-group-ipdv-Vector" 2145 REFERENCE 2146 "Reference "RFCyyyy, section 7.3." 2147 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2148 note 2149 := { ianaIppmMetrics nn } -- IANA assigns nn 2151 -- One to group statistics 2153 -- 2155 ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY 2156 STATUS current 2157 DESCRIPTION 2158 "Type-P-One-to-group-Receiver-n-Mean-Delay" 2159 REFERENCE 2160 "Reference "RFCyyyy, section 8.3.1." 2161 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2162 note 2163 := { ianaIppmMetrics nn } -- IANA assigns nn 2165 ietfOneToGroupMeanDelay OBJECT-IDENTITY 2166 STATUS current 2167 DESCRIPTION 2168 "Type-P-One-to-group-Mean-Delay" 2169 REFERENCE 2170 "Reference "RFCyyyy, section 8.3.2." 2171 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2172 note 2173 := { ianaIppmMetrics nn } -- IANA assigns nn 2175 ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY 2176 STATUS current 2177 DESCRIPTION 2178 "Type-P-One-to-group-Range-Mean-Delay" 2179 REFERENCE 2180 "Reference "RFCyyyy, section 8.3.3." 2181 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2182 note 2183 := { ianaIppmMetrics nn } -- IANA assigns nn 2185 ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY 2186 STATUS current 2187 DESCRIPTION 2188 "Type-P-One-to-group-Max-Mean-Delay" 2189 REFERENCE 2190 "Reference "RFCyyyy, section 8.3.4." 2191 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2192 note 2193 := { ianaIppmMetrics nn } -- IANA assigns nn 2195 ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY 2196 STATUS current 2197 DESCRIPTION 2198 "Type-P-One-to-group-Receiver-n-Loss-Ratio" 2199 REFERENCE 2200 "Reference "RFCyyyy, section 8.4.1." 2201 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2202 note 2203 := { ianaIppmMetrics nn } -- IANA assigns nn 2204 -- 2206 ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY 2207 STATUS current 2208 DESCRIPTION 2209 "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio" 2210 REFERENCE 2211 "Reference "RFCyyyy, section 8.4.2." 2212 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2213 note 2214 := { ianaIppmMetrics nn } -- IANA assigns nn 2216 ietfOneToGroupLossRatio OBJECT-IDENTITY 2217 STATUS current 2218 DESCRIPTION 2219 "Type-P-One-to-group-Loss-Ratio" 2220 REFERENCE 2221 "Reference "RFCyyyy, section 8.4.3." 2222 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2223 note 2224 := { ianaIppmMetrics nn } -- IANA assigns nn 2225 -- 2227 ietfOneToGroupRangeLossRatio OBJECT-IDENTITY 2228 STATUS current 2229 DESCRIPTION 2230 "Type-P-One-to-group-Range-Loss-Ratio" 2231 REFERENCE 2232 "Reference "RFCyyyy, section 8.4.4." 2233 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2234 note 2235 := { ianaIppmMetrics nn } -- IANA assigns nn 2237 ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY 2238 STATUS current 2239 DESCRIPTION 2240 "Type-P-One-to-group-Range-Delay-Variation" 2241 REFERENCE 2242 "Reference "RFCyyyy, section 8.5.1." 2243 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2244 note 2245 := { ianaIppmMetrics nn } -- IANA assigns nn 2247 -- 2249 14. References 2251 14.1. Normative References 2253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2254 Requirement Levels", BCP 14, RFC 2119, March 1997. 2256 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2257 Delay Metric for IPPM", RFC 2679, September 1999. 2259 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2260 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2262 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2263 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2264 November 2002. 2266 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2267 Registry", BCP 108, RFC 4148, August 2005. 2269 14.2. Informative References 2271 [I-D.ietf-ippm-spatial-composition] 2272 Morton, A. and E. Stephan, "Spatial Composition of 2273 Metrics", draft-ietf-ippm-spatial-composition-08 (work in 2274 progress), March 2009. 2276 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2277 "Framework for IP Performance Metrics", RFC 2330, 2278 May 1998. 2280 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2281 performance measurement with periodic streams", RFC 3432, 2282 November 2002. 2284 Authors' Addresses 2286 Stephan Emile 2287 France Telecom Division R&D 2288 2 avenue Pierre Marzin 2289 Lannion, F-22307 2291 Fax: +33 2 96 05 18 52 2292 Email: emile.stephan@orange-ftgroup.com 2294 Lei Liang 2295 CCSR, University of Surrey 2296 Guildford 2297 Surrey, GU2 7XH 2299 Fax: +44 1483 683641 2300 Email: L.Liang@surrey.ac.uk 2302 Al Morton 2303 200 Laurel Ave. South 2304 Middletown, NJ 07748 2305 USA 2307 Phone: +1 732 420 1571 2308 Email: acmorton@att.com