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