idnits 2.17.1 draft-ietf-ippm-multimetrics-12.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 997 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 (September 1, 2009) is 5351 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-09 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: March 5, 2010 University of Surrey 6 A. Morton 7 AT&T Labs 8 September 1, 2009 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-12 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 March 5, 2010. 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 . . . . . . . . . . . . . . . . 28 83 9. Measurement Methods: Scalability and Reporting . . . . . . . . 37 84 10. Manageability Considerations . . . . . . . . . . . . . . . . . 41 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 86 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 87 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 51 90 14.2. Informative References . . . . . . . . . . . . . . . . . 52 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 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 router: section 5 of RFC 2330 143 loss threshold: section 2.8.2 of RFC 2680 145 path: section 5 of RFC 2330 147 sample: section 11 of RFC 2330 149 singleton: section 11 of RFC 2330 151 2.3. Routers Digest 153 The list of the routers on the path from the source to the 154 destination which act as points of interest, also referred to as the 155 routers digest. 157 2.4. Multiparty metric 159 A metric is said to be multiparty if the topology involves more than 160 one measurement collection point. All multiparty metrics designate a 161 set of hosts as "points of interest", where one host is the source 162 and other hosts are the measurement collection points. For example, 163 if the set of points of interest is < ha, hb, hc, ..., hn >, where ha 164 is the source and < hb, hc, ..., hn > are the destinations, then 165 measurements may be conducted between < ha, hb>, < ha, hc>, ..., . 168 For the purposes of this memo (reflecting the scope of a single 169 source), the only multiparty metrics are one-to-group metrics. 171 2.5. Spatial metric 173 A metric is said to be spatial if one of the hosts (measurement 174 collection points) involved is neither the source nor a destination 175 of the measured packet(s). Such measurement hosts will usually be 176 routers member of the routers digest. 178 2.6. One-to-group metric 180 A metric is said to be one-to-group if the measured packet is sent by 181 one source and (potentially) received by more than one destination. 182 Thus, the topology of the communication group can be viewed as a 183 center-distributed or server-client topology with the source as the 184 center/server in the topology. 186 2.7. Points of interest 188 Points of interest are the hosts (as per the RFC 2330 definition, 189 "hosts" include routing nodes) that are measurement collection 190 points, a sub-set of the set of hosts involved in the delivery of the 191 packets (in addition to the source itself). 193 For spatial metrics, points of interest are a (possibly arbitrary) 194 sub-set of all the routers involved in the path. 196 Points of interest of one-to-group metrics are the intended 197 destination hosts for packets from the source (in addition to the 198 source itself). 200 Src Dst 201 `. ,-. 202 `. ,' `...... 1 203 `. ; : 204 `. ; : 205 ; :... 2 206 | | 207 : ; 208 : ;.... 3 209 : ; 210 `. ,' 211 `-'....... I 213 Figure 1: One-to-group points of interest 215 A candidate point of interest for spatial metrics is a router from 216 the set of routers involved in the delivery of the packets from 217 source to destination. 219 Src ------. Hosts 220 \ 221 `---X --- 1 222 \ 223 x 224 / 225 .---------X ---- 2 226 / 227 x 228 ... 229 `---X ---- ... 230 \ 231 \ 232 \ 233 X ---- J 234 \ 235 \ 236 \ 237 `---- Dst 239 Note: 'X' are nodes which are points of interest, 240 'x' are nodes which are not points of interest 242 Figure 2: Spatial points of interest 244 2.8. Reference point 246 A reference point is defined as the server where the statistical 247 calculations will be carried out. It is usually a centralized server 248 in the measurement architecture that is controlled by a network 249 operator, where measurement data can be collected for further 250 processing. The reference point is distinctly different from hosts 251 at measurement collection points, where the actual measurements are 252 carried out (e.g., points of interest). 254 2.9. Vector 256 A vector is a set of singletons (single atomic results) comprised of 257 observations corresponding to a single source packet at different 258 hosts in a network. For instance, if the one-way delay singletons 259 observed at N receivers for Packet P sent by the source Src are dT1, 260 dT2,..., dTN, then a vector V with N elements can be organized as 261 {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as 262 the singleton at receiver 1 in response to a packet sent from the 263 source at a specific time. The complete vector gives information 264 over the dimension of space; a set of N receivers in this example. 266 The singleton elements of any vector are distinctly different from 267 each other in terms of their measurement collection point. Different 268 vectors for common measurement points of interest are distinguished 269 by the source packet sending time. 271 2.10. Matrix 273 Several vectors form a matrix, which contains results observed over a 274 sampling interval at different places in a network at different 275 times. For example, the One-way delay vectors V1={dT11, dT12,..., 276 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 277 Packet P1, P2,...,Pm, form a One-way delay Matrix {V1, V2,...,Vm}. 278 The matrix organizes the vector information to present network 279 performance in both space and time. 281 A one-dimensional matrix (row) corresponds to a sample in simple 282 point-to-point measurement. 284 The relationship among singleton, sample, vector and matrix is 285 illustrated in the following Figure 3. 287 points of singleton 288 interest / samples(time) 289 ,----. ^ / 290 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 291 / \ | | | 292 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 293 Src | || | | 294 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 295 | || | | 296 : ;| | | 297 \ / | | | 298 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 299 `-----' +-------------------------------------> time 301 vector matrix 302 (space) (time and space) 304 Figure 3: Relationship between singletons, samples, vectors and 305 matrix 307 3. Brief Metric Descriptions 309 The metrics for spatial and one-to-group measurement are based on the 310 source-to-destination, or end-to-end metrics defined by IETF in 311 [RFC2679], [RFC2680], [RFC3393], [RFC3432]. 313 This memo defines seven new spatial metrics using the [RFC2330] 314 framework of parameters, units of measure, and measurement 315 methodologies. Each definition includes a section that describes 316 measurements constraints and issues, and provides guidance to 317 increase the accuracy of the results. 319 The spatial metrics are: 320 o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- 321 One-way-Delay [RFC2679] into a spatial vector of one-way delay 322 singletons. 323 o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end 324 Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of 325 packet loss singletons. 326 o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- 327 One-way-ipdv into a spatial vector of ipdv (IP Packet Delay 328 Variation) singletons. 329 o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, 330 a sample called Type-P-Segment-One-way-Delay-Stream collects one- 331 way delay metrics between two points of interest on the path over 332 time. 333 o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector 334 metric, a sample called Type-P-Segment-Packet-Loss-Stream collects 335 one-way delay metrics between two points of interest on the path 336 over time. 337 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a sample 338 called Type-P-Segment-ipdv-prev-Stream, will be introduced to 339 compute ipdv metrics (using the previous packet selection 340 function) between two points of interest on the path over time. 341 o Again using the Type-P-Spatial-One-way-Delay-Vector metric, a 342 sample called Type-P-Segment-ipdv-min-Stream will define another 343 set of ipdv metrics (using the minimum delay packet selection 344 function) between two points of interest on the path over time. 346 The memo also defines three one-to-group metrics to measure the one- 347 way performance between a source and a group of receivers. They are: 348 o Type-P-One-to-group-Delay-Vector collects the set of Type-P-one- 349 way-delay singletons between one sender and N receivers. 350 o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P- 351 One-way-Packet-Loss singletons between one sender and N receivers. 352 o Type-P-One-to-group-ipdv-Vector collects the set of Type-P-One- 353 way-ipdv singletons between one sender and N receivers. 355 Finally, based on the one-to-group vector metrics listed above, 356 statistics are defined to capture single receiver performance, group 357 performance and the relative performance for a multiparty 358 communication: 360 o Using the Type-P-One-to-group-Delay-Vector, a metric called Type- 361 P-One-to-group-Receiver-n-Mean-Delay or RnMD, presents the mean of 362 delays between one sender and a single receiver 'n'. From this 363 metric, 3 additional metrics are defined to characterize the mean 364 delay over the entire group of receivers during the same time 365 interval: 366 * Type-P-One-to-group-Mean-Delay or GMD, presents the mean of 367 delays; 368 * Type-P-One-to-group-Range-Mean-Delay or GRMD, presents the 369 range of mean delays; 370 * Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the 371 maximum of mean delays. 372 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 373 Type-P-One-to-group-Receiver-n-Loss-Ratio or RnLR, captures the 374 packet loss ratio between one sender and a single receiver 'n'. 375 Based on this definition, 2 more metrics are defined to 376 characterize packet loss over the entire group during the same 377 time interval: 378 * Type-P-One-to-group-Loss-Ratio or GLR, captures the overall 379 packet loss ratio for the entire group of receivers; 380 * Type-P-One-to-group-Range-Loss-Ratio, or GRLR, presents the 381 comparative packet loss ratio during the test interval between 382 one sender and N receivers. 383 o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called 384 Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes 385 a packet loss ratio using the maximum number of packets received 386 at any receiver. 387 o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One- 388 to-group-Range-Delay-Variation, or GRDV, presents the range of 389 delay variation between one sender and a group of receivers. 391 4. Motivations 393 All existing IPPM metrics are defined for end-to-end (source to 394 destination) measurement of point-to-point paths. It is logical to 395 extend them to multiparty situations such as one to one trajectory 396 metrics and one to multipoint metrics. 398 4.1. Motivations for spatial metrics 400 Spatial metrics are needed for: 401 o Decomposing the performance of an inter-domain path to quantify 402 the per-AS contribution to the end-to-end performance. 403 o Traffic engineering and troubleshooting, which benefit from 404 spatial views of one-way delay and ipdv consumption, or 405 identification of the path segment where packets were lost. 407 o Monitoring the decomposed performance of a multicast tree based on 408 MPLS point-to-multipoint communications. 409 o Dividing end-to-end metrics, so that some segment measurements can 410 be re-used and help measurement systems reach large-scale 411 coverage. Spatial measures could characterize the performance of 412 an intra-domain segment and provide an elementary piece of 413 information needed to estimate inter-domain performance to another 414 destination using Spatial Composition metrics 415 [I-D.ietf-ippm-spatial-composition]. 417 4.2. Motivations for One-to-group metrics 419 While the node-to-node based spatial measures can provide very useful 420 data in the view of each connection, we also need measures to present 421 the performance of a multiparty communication topology. A simple 422 point-to-point metric cannot completely describe the multiparty 423 situation. New one-to-group metrics assess performance of the 424 multiple paths for further statistical analysis. The new metrics are 425 named one-to-group performance metrics, and they are based on the 426 unicast metrics defined in IPPM RFCs. One-to-group metrics are one- 427 way metrics from one source to a group of destinations, or receivers. 428 The metrics are helpful for judging the overall performance of a 429 multiparty communications network, and for describing the performance 430 variation across a group of destinations. 432 One-to-group performance metrics are needed for: 434 o Designing and engineering multicast trees and MPLS point-to- 435 multipoint LSPs. 436 o Evaluating and controlling the quality of multicast services, 437 including inter-domain multicast. 438 o Presenting and evaluating the performance requirements for 439 multiparty communications and overlay multicast. 440 To understand the packet transfer performance between one source and 441 any one receiver in the multiparty communication group, we need to 442 collect instantaneous end-to-end metrics, or singletons. This gives 443 a very detailed view into the performance of each branch of the 444 multicast tree, and can provide clear and helpful information for 445 engineers to identify the branch with problems in a complex 446 multiparty routing tree. 448 The one-to-group metrics described in this memo introduce the 449 multiparty topology into the IPPM framework, and describe the 450 performance delivered to a group receiving packets from the same 451 source. The concept extends the "path" of the point-to-point 452 measurement to "path tree" to cover one-to-many topologies. If 453 applied to one-to-one topology, the one-to-group metrics provide 454 exactly the same results as the corresponding one-to-one metrics. 456 4.3. Discussion on Group-to-one and Group-to-group metrics 458 We note that points of interest can also be selected to define 459 measurements on group-to-one and group-to-group topologies. These 460 topologies are beyond the scope of this memo, because they would 461 involve multiple packets launched from different sources. However, 462 this section gives some insights on these two cases. 464 The measurements for group-to-one topology can be easily derived from 465 the one-to-group measurement. The measurement point is the host that 466 is acting as a receiver while all other hosts act as sources in this 467 case. 469 The group-to-group communication topology has no obvious focal point: 470 the sources and the measurement collection points can be anywhere. 471 However, it is possible to organize the problem by applying 472 measurements in one-to-group or group-to-one topologies for each host 473 in a uniform way (without taking account of how the real 474 communication might be carried out). For example, one group of hosts 475 < ha, hb, hc, ..., hn > might act as sources to send data to another 476 group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized 477 into n sets of points of interest for one-to-group communications: 479 < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, ..., Hm >. 482 5. Spatial vector metrics definitions 484 This section defines vectors for the spatial decomposition of end-to- 485 end singleton metrics over a path. 487 Spatial vector metrics are based on the decomposition of standard 488 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 489 [RFC3393] and [RFC3432]. 491 The spatial vector definitions are coupled with the corresponding 492 end-to-end metrics. Measurement methodology aspects are common to 493 all the vectors defined and are consequently discussed in a common 494 section. 496 5.1. A Definition for Spatial One-way Delay Vector 498 This section is coupled with the definition of Type-P-One-way-Delay 499 of the section 3 of [RFC2679]. When a parameter from the definition 500 in [RFC2679] is re-used in this section, the first instance will be 501 tagged with a trailing asterisk. 503 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 504 statements for end-to-end one-way-delay measurements. They are 505 applicable to each point of interest, Hi, involved in the measure. 506 Spatial one-way-delay measurement MUST respect them, especially those 507 related to methodology, clock, uncertainties and reporting. 509 5.1.1. Metric Name 511 Type-P-Spatial-One-way-Delay-Vector 513 5.1.2. Metric Parameters 515 o Src*, the IP address of the sender. 516 o Dst*, the IP address of the receiver. 517 o i, an integer in the ordered list <1,2,...,n> of routers in the 518 path. 519 o Hi, a router of the routers digest. 520 o T*, a time, the sending (or initial observation) time for a 521 measured packet. 522 o dT*, a delay, the one-way delay for a measured packet. 523 o dTi, a delay, the one-way delay for a measured packet from the 524 source to router Hi. 525 o a list of n delay singletons. 526 o Type-P*, the specification of the packet type. 527 o the routers digest. 529 5.1.3. Metric Units 531 The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of 532 times (a real number in the dimension of seconds with sufficient 533 resolution to convey the results). 535 5.1.4. Definition 537 Given a Type-P packet sent by the Src at wire-time (first bit) T to 538 the receiver Dst on the path . There is a sequence 539 of values such that dT is the Type-P- 540 One-way-Delay from Src to Dst, and for each Hi of the path, T+dTi is 541 either a real number corresponding to the wire-time the packet passes 542 (last bit received) Hi, or undefined if the packet does not pass Hi 543 within a specified loss threshold* time. 545 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 546 as the sequence of values 547 . 549 5.1.5. Discussion 551 Some specific issues that may occur are as follows: 552 o the delay singletons "appear" to decrease: dTi > dTi+1. This may 553 occur despite being physically impossible with the definition 554 used. 555 * This is frequently due to a measurement clock synchronization 556 issue. This point is discussed in the section 3.7.1. "Errors 557 or uncertainties related to Clocks" of [RFC2679]. 558 Consequently, the values of delays measured at multiple routers 559 may not match the order of those routers on the path. 560 * The actual order of routers on the path may change due to 561 reconvergence (e.g., recovery from a link failure). 562 * The location of the measurement collection point in the device 563 influences the result. If the packet is not observed directly 564 on the input interface the delay includes buffering time and 565 consequently an uncertainty due to the difference between 'wire 566 time' and 'host time'. 568 5.2. A Definition for Spatial Packet Loss Vector 570 This section is coupled with the definition of Type-P-One-way-Packet- 571 Loss. When a parameter from section 2 of [RFC2680] is used in this 572 section, the first instance will be tagged with a trailing asterisk. 574 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 575 statements for end-to-end one-way packet loss measurements. They are 576 applicable to each point of interest, Hi, involved in the measure. 577 Spatial packet loss measurement MUST respect them, especially those 578 related to methodology, clock, uncertainties and reporting. 580 The following sections define the spatial loss vector, adapt some of 581 the points above, and introduce points specific to spatial loss 582 measurement. 584 5.2.1. Metric Name 586 Type-P-Spatial-Packet-Loss-Vector 588 5.2.2. Metric Parameters 590 o Src*, the IP address of the sender. 591 o Dst*, the IP address of the receiver. 592 o i, an integer in the ordered list <1,2,...,n> of routers in the 593 path. 594 o Hi, a router of the routers digest. 596 o T*, a time, the sending time for a measured packet. 597 o dTi, a delay, the one-way delay for a measured packet from the 598 source to host Hi. 599 o , list of n delay singletons. 600 o Type-P*, the specification of packet type. 601 o , the routers digest. 602 o , a list of Boolean values. 604 5.2.3. Metric Units 606 The value of Type-P-Spatial-Packet-Loss-Vector is a sequence of 607 Boolean values. 609 5.2.4. Definition 611 Given a Type-P packet sent by the Src at time T to the receiver Dst 612 on the path . For the sequence of times the packet passes in , define the Type-P-Packet-Loss-Vector metric as the sequence 615 of values such that for each Hi of the path, a 616 value of 0 for Li means that dTi is a finite value, and a value of 1 617 means that dTi is undefined. 619 5.2.5. Discussion 621 Some specific issues that may occur are as follows: 622 o The result might include the sequence of values 1,0. Although 623 this appears physically impossible (a packet is lost, then re- 624 appears later on the path): 625 * The actual routers on the path may change due to reconvergence 626 (e.g., recovery from a link failure). 627 * The order of routers on the path may change due to 628 reconvergence. 629 * A packet may not be observed in a router due to some buffer or 630 CPU overflow at the measurement collection point. 632 5.3. A Definition for Spatial One-way Ipdv Vector 634 When a parameter from section 2 of [RFC3393] (the definition of Type- 635 P-One-way-ipdv) is used in this section, the first instance will be 636 tagged with a trailing asterisk. 638 The following sections define the spatial ipdv vector, adapt some of 639 the points above, and introduce points specific to spatial ipdv 640 measurement. 642 5.3.1. Metric Name 644 Type-P-Spatial-One-way-ipdv-Vector 646 5.3.2. Metric Parameters 648 o Src*, the IP address of the sender. 649 o Dst*, the IP address of the receiver. 650 o i, an integer in the ordered list <1,2,...,n> of routers in the 651 path. 652 o Hi, a router of the routers digest. 653 o T1*, a time, the sending time for a first measured packet. 654 o T2*, a time, the sending time for a second measured packet. 655 o dT*, a delay, the one-way delay for a measured packet. 656 o dTi, a delay, the one-way delay for a measured packet from the 657 source to router Hi. 658 o Type-P*, the specification of the packets type. 659 o P1, the first packet sent at time T1. 660 o P2, the second packet sent at time T2. 661 o , the routers digest. 662 o , the Type-P-Spatial-One-way- 663 Delay-Vector for packet sent at time T1. 664 o , the Type-P-Spatial-One-way- 665 Delay-Vector for packet sent at time T2. 666 o L*, a packet length in bits. The packets of a Type P packet 667 stream from which the Type-P-Spatial-One-way-Delay-Vector metric 668 is taken MUST all be of the same length. 670 5.3.3. Metric Units 672 The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of 673 times (a real number in the dimension of seconds with sufficient 674 resolution to convey the results). 676 5.3.4. Definition 678 Given P1 the Type-P packet sent by the sender Src at wire-time (first 679 bit) T1 to the receiver Dst and 680 its Type-P-Spatial-One-way-Delay-Vector over the sequence of routers 681 . 683 Given P2 the Type-P packet sent by the sender Src at wire-time (first 684 bit) T2 to the receiver Dst and 685 its Type-P-Spatial-One-way-Delay-Vector over the same path. 687 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 688 of values such that for each Hi of the sequence of routers , dT2.i-dT1.i is either a real number if the packets P1 and P2 691 pass Hi at wire-time (last bit) dT1.i and dT2.i respectively, or 692 undefined if at least one of them never passes Hi (and the respective 693 one-way delay is undefined). The T1,T2* pair indicates the inter- 694 packet emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv. 696 5.4. Spatial Methodology 698 The methodology, reporting specifications, and uncertainties 699 specified in section 3 of [RFC2679] apply to each point of interest 700 (or measurement collection point), Hi, measuring an element of a 701 spatial delay vector. 703 Likewise, the methodology, reporting specifications, and 704 uncertainties specified in section 2 of [RFC2680] apply to each point 705 of interest, Hi, measuring an element of a spatial packet loss 706 vector. 708 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 709 statements for end-to-end One-way ipdv measurements. They are 710 applicable to each point of interest, Hi, involved in the measure. 711 Spatial One-way ipdv measurement MUST respect the methodology, clock, 712 uncertainties and reporting aspects given there. 714 Generally, for a given Type-P packet of length L at a specific Hi, 715 the methodology for spatial vector metrics may proceed as follows: 716 o At each Hi, points of interest/measurement collection points 717 prepare to capture the packet sent at time T, record a timestamp 718 Ti', and determine the internal delay correction dTi' (See section 719 3.7.1. "Errors or uncertainties related to Clocks" of [RFC2679]); 720 o Each Hi extracts the path ordering information from the packet 721 (e.g. time-to-live); 722 o Each Hi computes the corrected wiretime from Src to Hi: Ti = Ti' - 723 dTi'. This arrival time is undefined if the packet is not 724 detected after the 'loss threshold' duration; 725 o Each Hi extracts the timestamp T from the packet; 726 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 727 o The reference point gathers the result of each Hi and arranges 728 them according to the path ordering information received to build 729 the type-P spatial one-way vector (e.g. Type-P-Spatial-One-way- 730 Delay-Vector metric ) over the path 731 at time T. 733 5.4.1. Packet Loss Detection 735 In a pure end-to-end measurement, packet losses are detected by the 736 receiver only. A packet is lost when Type-P-One-way-Delay is 737 undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and 738 section 3.5 of [RFC2680]). A packet is deemed lost by the receiver 739 after a duration which starts at the time the packet is sent. This 740 timeout value is chosen by a measurement process. It determines the 741 threshold between recording a long packet transfer time as a finite 742 value or an undefined value. 744 In a spatial measurement, packet losses may be detected at several 745 measurement collection points. Depending on the consistency of the 746 packet loss detections among the points of interest, a packet may be 747 considered as lost at one point despite having a finite delay at 748 another one, or may be observed by the last measurement collection 749 point of the path but considered lost by Dst. 751 There is a risk of misinterpreting such results: Has the path 752 changed? Did the packet arrive at the destination or was it lost on 753 the very last link? 755 The same concern applies to one-way-delay measures: a delay measured 756 may be computed as infinite by one observation point but as a real 757 value by another one, or may be measured as a real value by the last 758 observation point of the path but designated as undefined by Dst. 760 The observation/measurement collection points and the destination 761 SHOULD use consistent methods to detect packets losses. The methods 762 and parameters must be systematically reported to permit careful 763 comparison and to avoid introducing any confounding factors in the 764 analysis. 766 5.4.2. Routers Digest 768 The methodology given above relies on knowing the order of the 769 router/measurement collection points on the path [RFC2330]. 771 Path instability might cause a test packet to be observed more than 772 once by the same router, resulting in the repetition of one or more 773 routers in the routers digest. 775 For example, repeated observations may occur during rerouting phases 776 which introduce temporary micro loops. During such an event the 777 routers digest for a packet crossing Ha and Hb may include the 778 pattern meaning that Ha ended the computation of 779 the new path before Hb and that the initial path was from Ha to Hb 780 and that the new path is from Hb to Ha. 782 Consequently, duplication of routers in the routers digest of a 783 vector MUST be identified before computation of statistics to avoid 784 producing corrupted information. 786 6. Spatial Segment Metrics Definitions 788 This section defines samples to measure the performance of a segment 789 of a path over time. The definitions rely on the matrix of the 790 spatial vector metrics defined above. 792 Firstly this section defines a sample of one-way delay, Type-P- 793 Segment-One-way-Delay-Stream, and a sample of packet loss, Type-P- 794 segment-Packet-Loss-Stream. 796 Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv- 797 prev-Stream uses the current and previous packets as the selection 798 function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay 799 as one of the selected packets in every pair. 801 6.1. A Definition of a Sample of One-way Delay of a Segment of the Path 803 This metric defines a sample of One-way delays over time between a 804 pair of routers on a path. Since it is very close semantically to 805 the metric Type-P-One-way-Delay-Poisson-Stream defined in section 4 806 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of 807 the definition text below. 809 6.1.1. Metric Name 811 Type-P-Segment-One-way-Delay-Stream 813 6.1.2. Metric Parameters 815 o Src, the IP address of the sender. 816 o Dst, the IP address of the receiver. 817 o Type-P, the specification of the packet type. 818 o i, an integer in the ordered list <1,2,...,n> of routers in the 819 path. 820 o k, an integer which orders the packets sent. 821 o a and b, two integers where b > a. 822 o Hi, a router of the routers digest. 823 o , the routers digest. 824 o , a list of times. 826 6.1.3. Metric Units 828 The value of a Type-P-Segment-One-way-Delay-Stream is a pair of: 829 A list of times ; 830 A sequence of delays. 832 6.1.4. Definition 834 Given two routers, Ha and Hb, of the the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector 836 for the packets sent from Src to Dst at times 837 : 838 ; 839 ; 840 ... 841 . 843 We define the sample Type-P-segment-One-way-Delay-Stream as the 844 sequence such that for 845 each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if 846 the packet sent at time Tk passes Ha and Hb or undefined if this 847 packet never passes Ha or (inclusive) never passes Hb. 849 6.1.5. Discussion 851 Some specific issues that may occur are as follows: 852 o the delay singletons "appear" to decrease: dTi > DTi+1, and is 853 discussed in section 5.1.5. 854 * This could also occur when the clock resolution of one 855 measurement collection point is larger than the minimum delay 856 of a path. For example, the minimum delay of a 500 km path 857 through optical fiber facilities is 2.5ms, but the measurement 858 collection point has a clock resolution of 8ms. 859 The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if 860 the following conditions occur: 861 o Ha or Hb disappears from the path due to some routing change. 862 o The order of Ha and Hb changes in the path. 864 6.2. A Definition of a Sample of Packet Loss of a Segment of the Path 866 This metric defines a sample of packet loss over time between a pair 867 of routers of a path. Since it is very close semantically to the 868 metric Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], 869 sections 3.5 to 3.8 of [RFC2680] are integral parts of the definition 870 text below. 872 6.2.1. Metric Name 874 Type-P-segment-Packet-Loss-Stream 876 6.2.2. Metric Parameters 877 o Src, the IP address of the sender. 878 o Dst, the IP address of the receiver. 879 o Type-P, the specification of the packet type. 880 o k, an integer which orders the packets sent. 881 o n, an integer which orders the routers on the path. 882 o a and b, two integers where b > a. 883 o , the routers digest. 884 o Hi, a router of the routers digest. 885 o , a list of times. 886 o , a list of Boolean values. 888 6.2.3. Metric Units 890 The value of a Type-P-segment-Packet-Loss-Stream is a pair of: 891 A The list of times ; 892 A sequence of Boolean values. 894 6.2.4. Definition 896 Given two routers, Ha and Hb, of the the path , and the matrix of Type-P-Spatial-Packet-Loss-Vector for 898 the packets sent from Src to Dst at times : 899 , 900 , 901 ..., 902 . 904 We define the value of the sample Type-P-segment-Packet-Loss-Stream 905 from Ha to Hb as the sequence of Booleans such that for each Tk: 907 o A value of Lk of 0 means that Ha and Hb observed the packet sent 908 at time Tk (both Lk.a and Lk.b have a value of 0). 909 o A value of Lk of 1 means that Ha observed the packet sent at time 910 Tk (Lk.a has a value of 0) and that Hb did not observe the packet 911 sent at time Tk (Lk.b has a value of 1). 912 o The value of Lk is undefined when neither Ha nor Hb observed the 913 packet (both Lk.a and Lk.b have a value of 1). 915 6.2.5. Discussion 917 Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-Loss-Stream 918 relies on the stability of the routers digest. The metric SHALL be 919 invalid for times < T1 , T2, ..., Tm-1, Tm> if the following 920 conditions occur: 921 o Ha or Hb disappears from the path due to some routing change. 922 o The order of Ha and Hb changes in the path. 924 o Lk.a or Lk.b is undefined. 925 o Lk.a has the value 1 (not observed) and Lk.b has the value 0 926 (observed); 927 o L has the value 0 (the packet was received by Dst) and Lk.ab has 928 the value 1 (the packet was lost between Ha and Hb). 930 6.3. A Definition of a Sample of ipdv of a Segment using the Previous 931 Packet Selection Function 933 This metric defines a sample of ipdv [RFC3393] over time between a 934 pair of routers using the previous packet as the selection function. 936 6.3.1. Metric Name 938 Type-P-Segment-ipdv-prev-Stream 940 6.3.2. Metric Parameters 942 o Src, the IP address of the sender. 943 o Dst, the IP address of the receiver. 944 o Type-P, the specification of the packet type. 945 o k, an integer which orders the packets sent. 946 o n, an integer which orders the routers on the path. 947 o a and b, two integers where b > a. 948 o , the routers digest. 949 o , a list of times. 950 o , a 951 Type-P-Spatial-One-way-Delay-Vector. 953 6.3.3. Metric Units 955 The value of a Type-P-Segment-ipdv-prev-Stream is a pair of: 956 The list of ; 957 A list of pairs of interval of times and delays; 959 6.3.4. Definition 961 Given two routers, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 963 the packets sent from Src to Dst at times : 964 , 965 , 966 ... 967 . 969 We define the Type-P-Segment-ipdv-prev-Stream as the sequence of 970 packet time pairs and delay variations 971 <(T1, T2 , dT2.ab - dT1.ab) ,..., 973 (Tk-1, Tk, dTk.ab - dTk-1.ab), ..., 975 (Tm-1, Tm, dTm.ab - dTm-1.ab)> 977 For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk- 978 1.ab is undefined if: 979 o the delay dTk.a or the delay dTk-1.a is undefined, OR 980 o the delay dTk.b or the delay dTk-1.b is undefined. 982 6.3.5. Discussion 984 This metric belongs to the family of inter packet delay variation 985 metrics (IPDV in upper case) whose results are extremely sensitive to 986 the inter-packet interval in practice. 988 The inter-packet interval of an end-to-end IPDV metric is under the 989 control of the source (ingress point of interest). In contrast, the 990 inter-packet interval of a segment IPDV metric is not under the 991 control the ingress point of interest of the measure, Ha. The 992 interval will certainly vary if there is delay variation between the 993 Source and Ha. Therefore, the ingress inter-packet interval must be 994 known at Ha in order to fully comprehend the delay variation between 995 Ha and Hb. 997 6.4. A Definition of a Sample of ipdv of a Segment using the Minimum 998 Delay Selection Function 1000 This metric defines a sample of ipdv [RFC3393] over time between a 1001 pair of routers on a path using the minimum delay as one of the 1002 selected packets in every pair. 1004 6.4.1. Metric Name 1006 Type-P-Segment-One-way-ipdv-min-Stream 1008 6.4.2. Metric Parameters 1010 o Src, the IP address of the sender. 1011 o Dst, the IP address of the receiver. 1012 o Type-P, the specification of the packet type. 1013 o k, an integer which orders the packets sent. 1014 o i, an integer which identifies a packet sent. 1015 o n, an integer which orders the routers on the path. 1016 o a and b, two integers where b > a. 1018 o , the routers digest. 1019 o , a list of times. 1020 o , a 1021 Type-P-Spatial-One-way-Delay-Vector. 1023 6.4.3. Metric Units 1025 The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: 1026 The list of ; 1027 A list of times. 1029 6.4.4. Definition 1031 Given two routers, Ha and Hb, of the path , and the matrix of Type-P-Spatial-One-way-Delay-Vector for 1033 the packets sent from Src to Dst at times : 1034 , 1035 , 1036 ... 1037 . 1039 We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence 1040 of times where: 1042 o min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); 1043 o for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) 1044 dTk.b is undefined, or the real number (dTk.b - dTk.a) is 1045 undefined. 1047 6.4.5. Discussion 1049 This metric belongs to the family of packet delay variation metrics 1050 (PDV). PDV distributions have less sensitivity to inter-packet 1051 interval variations than IPDV values, as discussed above. 1053 In principle, the PDV distribution reflects the variation over many 1054 different inter-packet intervals, from the smallest inter-packet 1055 interval, up to the length of the evaluation interval, Tm - T1. 1056 Therefore, when delay variation occurs and disturbs the packet 1057 spacing observed at Ha, the PDV results will likely compare favorably 1058 to a PDV measurement where the source is Ha and the destination is 1059 Hb, because a wide range of spacings are reflected in any PDV 1060 distribution. 1062 7. One-to-group metrics definitions 1064 This section defines performance metrics between a source and a group 1065 of receivers. 1067 7.1. A Definition for One-to-group Delay 1069 This section defines a metric for one-way delay between a source and 1070 a group of receivers. 1072 7.1.1. Metric Name 1074 Type-P-One-to-group-Delay-Vector 1076 7.1.2. Metric Parameters 1078 o Src, the IP address of a host acting as the source. 1079 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1080 receivers. 1081 o T, a time. 1082 o dT1,...,dTn a list of times. 1083 o Type-P, the specification of the packet type. 1084 o Gr, the receiving group identifier. The parameter Gr is the 1085 multicast group address if the measured packets are transmitted 1086 over IP multicast. This parameter is to differentiate the 1087 measured traffic from other unicast and multicast traffic. It is 1088 OPTIONAL for this metric to avoid losing any generality, i.e. to 1089 make the metric also applicable to unicast measurement where there 1090 is only one receiver. 1092 7.1.3. Metric Units 1094 The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- 1095 One-way-Delay singletons [RFC2679], which is a sequence of times (a 1096 real number in the dimension of seconds with sufficient resolution to 1097 convey the results). 1099 7.1.4. Definition 1101 Given a Type-P packet sent by the source Src at time T, and the N 1102 hosts { Recv1,...,RecvN } which receive the packet at the time { 1103 T+dT1,...,T+dTn }, or the packet does not pass a receiver within a 1104 specified loss threshold time, then the Type-P-One-to-group-Delay- 1105 Vector is defined as the set of the Type-P-One-way-Delay singletons 1106 between Src and each receiver with value of { dT1, dT2,...,dTn }, 1107 where any of the singletons may be undefined if the packet did not 1108 pass the corresponding receiver within a specified loss threshold 1109 time. 1111 7.2. A Definition for One-to-group Packet Loss 1113 7.2.1. Metric Name 1115 Type-P-One-to-group-Packet-Loss-Vector 1117 7.2.2. Metric Parameters 1119 o Src, the IP address of a host acting as the source. 1120 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1121 receivers. 1122 o T, a time. 1123 o Type-P, the specification of the packet type. 1124 o Gr, the receiving group identifier, OPTIONAL. 1126 7.2.3. Metric Units 1128 The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of 1129 Type-P-One-way-Packet-Loss singletons [RFC2680]. 1131 o T, time the source packet was sent 1132 o L1,...,LN a list of boolean values 1134 7.2.4. Definition 1136 Given a Type P packet sent by the source Src at T and the N hosts, 1137 Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is 1138 defined as a set of the Type-P-One-way-Packet-Loss singletons between 1139 Src and each of the receivers 1141 {T, ,,..., }, 1143 where the boolean value 0|1 depends on receiving the packet at a 1144 particular receiver within a loss threshold time. 1146 7.3. A Definition for One-to-group ipdv 1148 7.3.1. Metric Name 1150 Type-P-One-to-group-ipdv-Vector 1152 7.3.2. Metric Parameters 1154 o Src, the IP address of a host acting as the source. 1155 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1156 receivers. 1158 o T1, a time. 1159 o T2, a time. 1160 o ddT1, ...,ddTn, a list of times. 1161 o Type-P, the specification of the packet type. 1162 o F, a selection function non-ambiguously defining the two packets 1163 from the stream selected for the metric. 1164 o Gr, the receiving group identifier. The parameter Gr is the 1165 multicast group address if the measured packets are transmitted 1166 over IP multicast. This parameter is to differentiate the 1167 measured traffic from other unicast and multicast traffic. It is 1168 OPTIONAL in the metric to avoid losing any generality, i.e. to 1169 make the metric also applicable to unicast measurement where there 1170 is only one receiver. 1172 7.3.3. Metric Units 1174 The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- 1175 One-way-ipdv singletons [RFC3393]. 1177 7.3.4. Definition 1179 Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is 1180 defined for two packets transferred from the source Src to the N 1181 hosts {Recv1,...,RecvN }, which are selected by the selection 1182 function F as the difference between the value of the Type-P-One-to- 1183 group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and 1184 the value of the Type-P-One-to-group-Delay-Vector from Src to { 1185 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1186 the first bit of the first packet, and T2 is the wire-time at which 1187 Src sent the first bit of the second packet. This metric is derived 1188 from the Type-P-One-to-group-Delay-Vector metric. 1190 For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- 1191 ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is 1192 {ddT1,...,ddTn} means that Src sent two packets, the first at wire- 1193 time T1 (first bit), and the second at wire-time T2 (first bit) and 1194 the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ 1195 T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ 1196 T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- 1197 dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1199 For any pair of selected packets, the difference dT'n-dTn is 1200 undefined if: 1201 o the delay dTn to Receiver n is undefined, OR 1202 o the delay dT'n to Receiver n is undefined. 1204 8. One-to-group Sample Statistics 1206 The one-to-group metrics defined above are directly achieved by 1207 collecting relevant unicast one-way metrics measurements results and 1208 by gathering them per group of receivers. They produce network 1209 performance information which guides engineers toward potential 1210 problems which may have happened on any branch of a multicast routing 1211 tree. 1213 The results of these metrics are not directly usable to present the 1214 performance of a group because each result is made of a huge number 1215 of singletons which are difficult to read and analyze. As an 1216 example, delays are not comparable because the distance between 1217 receiver and sender differs. Furthermore they don't capture relative 1218 performance situation a multiparty communication. 1220 From the performance point of view, the multiparty communication 1221 services not only require the support of absolute performance 1222 information but also information on "relative performance". The 1223 relative performance means the difference between absolute 1224 performance of all users. Directly using the one-way metrics cannot 1225 present the relative performance situation. However, if we use the 1226 variations of all users one-way parameters, we can have new metrics 1227 to measure the difference of the absolute performance and hence 1228 provide the threshold value of relative performance that a multiparty 1229 service might demand. A very good example of the high relative 1230 performance requirement is online gaming. A very small difference in 1231 delay might result in failure in the game. We have to use multicast 1232 specific statistic metrics to define the relative delay required by 1233 online gaming. There are many other services, e.g. online biding, 1234 online stock market, etc., that require multicast metrics in order to 1235 evaluate the network against their requirements. Therefore, we can 1236 see the importance of new, multicast specific, statistic metrics to 1237 feed this need. 1239 We might also use some one-to-group statistic conceptions to present 1240 and report the group performance and relative performance to save the 1241 report transmission bandwidth. Statistics have been defined for One- 1242 way metrics in corresponding RFCs. They provide the foundation of 1243 definition for performance statistics. For instance, there are 1244 definitions for minimum and maximum One-way delay in [RFC2679]. 1245 However, there is a dramatic difference between the statistics for 1246 one-to-one communications and for one-to-many communications. The 1247 former one only has statistics over the time dimension while the 1248 later one can have statistics over both time and space dimensions. 1249 This space dimension is introduced by the Matrix concept as 1250 illustrated in Figure 4. For a Matrix M each row is a set of One-way 1251 singletons spreading over the time dimension and each column is 1252 another set of One-way singletons spreading over the space dimension. 1254 Receivers 1255 Space 1256 ^ 1257 1 | / R1dT1 R1dT2 R1dT3 ... R1dTk \ 1258 | | | 1259 2 | | R2dT1 R2dT2 R2dT3 ... R2dTk | 1260 | | | 1261 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1262 . | | | 1263 . | | | 1264 . | | | 1265 n | \ RndT1 RndT2 RndT3 ... RndTk / 1266 +--------------------------------------------> time 1267 T0 1269 Figure 4: Matrix M (n*m) 1271 In Matrix M, each element is a one-way delay singleton. Each column 1272 is a delay vector. It contains the One-way delays of the same packet 1273 observed at n points of interest. It implies the geographical factor 1274 of the performance within a group. Each row is a set of One-way 1275 delays observed during a sampling interval at one of the points of 1276 interest. It presents the delay performance at a receiver over the 1277 time dimension. 1279 Therefore, one can either calculate statistics by rows over the space 1280 dimension or by columns over the time dimension. It's up to the 1281 operators or service provides which dimension they are interested in. 1282 For example, a TV broadcast service provider might want to know the 1283 statistical performance of each user in a long term run to make sure 1284 their services are acceptable and stable. While for an online gaming 1285 service provider, he might be more interested to know if all users 1286 are served fairly by calculating the statistics over the space 1287 dimension. This memo does not intend to recommend which of the 1288 statistics are better than the other. 1290 To save the report transmission bandwidth, each point of interest can 1291 send statistics in a pre-defined time interval to the reference point 1292 rather than sending every one-way singleton it observed. As long as 1293 an appropriate time interval is decided, appropriate statistics can 1294 represent the performance in a certain accurate scale. How to decide 1295 the time interval and how to bootstrap all points of interest and the 1296 reference point depend on applications. For instance, applications 1297 with lower transmission rate can have the time interval longer and 1298 ones with higher transmission rate can have the time interval 1299 shorter. However, this is out of the scope of this memo. 1301 Moreover, after knowing the statistics over the time dimension, one 1302 might want to know how these statistics are distributed over the 1303 space dimension. For instance, a TV broadcast service provider had 1304 the performance Matrix M and calculated the One-way delay mean over 1305 the time dimension to obtain a delay Vector as {V1,V2,..., VN}. He 1306 then calculated the mean of all the elements in the Vector to see 1307 what level of delay he has served to all N users. This new delay 1308 mean gives information on how good the service has been delivered to 1309 a group of users during a sampling interval in terms of delay. It 1310 requires twice as much calculation to have this statistic over both 1311 time and space dimensions. These kinds of statistics are referred to 1312 as 2-level statistics to distinguish them from 1-level statistics 1313 calculated over either space or time dimension. It can be easily 1314 proven that no matter over which dimension a 2-level statistic is 1315 calculated first, the results are the same. I.e. one can calculate 1316 the 2-level delay mean using the Matrix M by having the 1-level delay 1317 mean over the time dimension first and then calculate the mean of the 1318 obtained vector to find out the 2-level delay mean. Or, he can do 1319 the 1-level statistic calculation over the space dimension first and 1320 then have the 2-level delay mean. Both two results will be exactly 1321 the same. Therefore, when defining a 2-level statistic there is no 1322 need to specify the order in which the calculation is executed. 1324 Many statistics can be defined for the proposed one-to-group metrics 1325 over either the space dimension or the time dimension or both. This 1326 memo treats the case where a stream of packets from the Source 1327 results in a sample at each of the Receivers in the Group, and these 1328 samples are each summarized with the usual statistics employed in 1329 one-to-one communication. New statistic definitions are presented, 1330 which summarize the one-to-one statistics over all the Receivers in 1331 the Group. 1333 8.1. Discussion on the Impact of packet loss on statistics 1335 Packet loss does have effects on one-way metrics and their 1336 statistics. For example, a lost packet can result in an infinite 1337 one-way delay. It is easy to handle the problem by simply ignoring 1338 the infinite value in the metrics and in the calculation of the 1339 corresponding statistics. However, the packet loss has such a strong 1340 impact on the statistics calculation for the one-to-group metrics 1341 that it can not be solved by the same method used for one-way 1342 metrics. This is due to the complexity of building a matrix, which 1343 is needed for calculation of the statistics proposed in this memo. 1345 The situation is that measurement results obtained by different end 1346 users might have different packet loss pattern. For example, for 1347 User1, packet A was observed lost. And for User2, packet A was 1348 successfully received but packet B was lost. If the method to 1349 overcome the packet loss for one-way metrics is applied, the two 1350 singleton sets reported by User1 and User2 will be different in terms 1351 of the transmitted packets. Moreover, if User1 and User2 have 1352 different number of lost packets, the size of the results will be 1353 different. Therefore, for the centralized calculation, the reference 1354 point will not be able to use these two results to build up the group 1355 Matrix and can not calculate the statistics. The extreme situation 1356 being the case when no packets arrive at any user. One of the 1357 possible solutions is to replace the infinite/undefined delay value 1358 by the average of the two adjacent values. For example, if the 1359 result reported by user1 is { R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF 1360 R1dTK+1... R1DM } where "UNDEF" is an undefined value, the reference 1361 point can replace it by R1dTK = {(R1dTK-1)+( R1dTK+1)}/2. Therefore, 1362 this result can be used to build up the group Matrix with an 1363 estimated value R1dTK. There are other possible solutions such as 1364 using the overall mean of the whole result to replace the infinite/ 1365 undefined value, and so on. However this is out of the scope of this 1366 memo. 1368 For the distributed calculation, the reported statistics might have 1369 different "weight" to present the group performance, which is 1370 especially true for delay and ipdv relevant metrics. For example, 1371 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1372 in Figure. 8 without any packet loss and User2 calculates the R2DM 1373 with N-2 packet loss. The R1DM and R2DM should not be treated with 1374 equal weight because R2DM was calculated only based on 2 delay values 1375 in the whole sample interval. One possible solution is to use a 1376 weight factor to mark every statistic value sent by users and use 1377 this factor for further statistic calculation. 1379 8.2. General Metric Parameters 1381 o Src, the IP address of a host; 1382 o G, the receiving group identifier; 1383 o N, the number of Receivers (Recv1, Recv2, ... RecvN); 1384 o T, a time (start of test interval); 1385 o Tf, a time (end of test interval); 1386 o K, the number of packets sent from the source during the test 1387 interval; 1388 o J[n], the number of packets received at a particular Receiver, n, 1389 where 1<=n<=N; 1390 o lambda, a rate in reciprocal seconds (for Poisson Streams); 1391 o incT, the nominal duration of inter-packet interval, first bit to 1392 first bit (for Periodic Streams); 1394 o T0, a time that MUST be selected at random from the interval [T, 1395 T+I] to start generating packets and taking measurements (for 1396 Periodic Streams); 1397 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1398 Source Measurement Point); 1399 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1400 assigned to packets that arrive within a "reasonable" time; 1401 o Tmax, a maximum waiting time for packets at the destination, set 1402 sufficiently long to disambiguate packets with long delays from 1403 packets that are discarded (lost), thus the distribution of delay 1404 is not truncated; 1405 o dT, shorthand notation for a one-way delay singleton value; 1406 o L, shorthand notation for a one-way loss singleton value, either 1407 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1408 the destination within TstampSrc + Tmax, may be indexed over n 1409 Receivers; 1410 o DV, shorthand notation for a one-way delay variation singleton 1411 value. 1413 8.3. One-to-group Delay Statistics 1415 This section defines the overall one-way delay statistics for a 1416 receiver and for an entire group as illustrated by the matrix below. 1418 Recv /----------- Sample -------------\ Stats Group Stat 1420 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \ 1421 | 1422 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | 1423 | 1424 3 R3dT1 R3dT2 R3dT3 ... R3dTk R3MD > Group delay 1425 . | 1426 . | 1427 . | 1428 n RndT1 RndT2 RndT3 ... RndTk RnMD / 1430 Receiver-n 1431 delay 1433 Figure 5: One-to-group Mean Delay 1435 Statistics are computed on the finite One-way delays of the matrix 1436 above. 1438 All One-to-group delay statistics are expressed in seconds with 1439 sufficient resolution to convey 3 significant digits. 1441 8.3.1. Type-P-One-to-group-Receiver-n-Mean-Delay 1443 This section defines Type-P-One-to-group-Receiver-n-Mean-Delay the 1444 Delay Mean at each Receiver N, also named RnMD. 1446 We obtain the value of Type-P-One-way-Delay singleton for all packets 1447 sent during the test interval at each Receiver (Destination), as per 1448 [RFC2679]. For each packet that arrives within Tmax of its sending 1449 time, TstampSrc, the one-way delay singleton (dT) will be the finite 1450 value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, 1451 the value of the singleton is Undefined. 1453 J[n] 1454 --- 1455 1 \ 1456 RnMD = --- * > TstampRecv[i] - TstampSrc[i] 1457 J[n] / 1458 --- 1459 i = 1 1461 Note: RnMD value is Undefined when J[n] = 0 for all n. 1463 Figure 6: Type-P-One-to-group-Receiver-N-Mean-Delay 1465 where all packets i= 1 through J[n] have finite singleton delays. 1467 8.3.2. Type-P-One-to-group-Mean-Delay 1469 This section defines Type-P-One-to-group-Mean-Delay, the Mean One-way 1470 delay calculated over the entire Group, also named GMD. 1472 N 1473 --- 1474 1 \ 1475 GMD = - * > RnMD 1476 N / 1477 --- 1478 n = 1 1480 Figure 7: Type-P-One-to-group-Mean-Delay 1482 Note that the Group Mean Delay can also be calculated by summing the 1483 Finite one-way Delay singletons in the Matrix, and dividing by the 1484 number of Finite One-way Delay singletons. 1486 8.3.3. Type-P-One-to-group-Range-Mean-Delay 1488 This section defines a metric for the range of mean delays over all N 1489 receivers in the group (R1MD, R2MD...RnMD). 1491 Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnMD) - min(RnMD) 1493 8.3.4. Type-P-One-to-group-Max-Mean-Delay 1495 This section defines a metric for the maximum of mean delays over all 1496 N receivers in the group (R1MD, R2MD,...RnMD). 1498 Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnMD) 1500 8.4. One-to-group Packet Loss Statistics 1502 This section defines the overall one-way loss statistics for a 1503 receiver and for an entire group as illustrated by the matrix below. 1505 Recv /----------- Sample ----------\ Stats Group Stat 1507 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1508 | 1509 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1510 | 1511 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio 1512 . | 1513 . | 1514 . | 1515 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1517 Receiver-n 1518 Loss Ratio 1520 Figure 8: One-to-group Loss Ratio 1522 Statistics are computed on the sample of Type-P-One-way-Packet-Loss 1523 [RFC2680] of the matrix above. 1525 All loss ratios are expressed in units of packets lost to total 1526 packets sent. 1528 8.4.1. Type-P-One-to-group-Receiver-n-Loss-Ratio 1530 Given a Matrix of loss singletons as illustrated above, determine the 1531 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1532 according to the definitions and method of [RFC2680]. The Type-P- 1533 One-way-Packet-Loss-Average and the Type-P-One-to-group-Receiver-n- 1534 Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the 1535 parameters used here, these metrics definitions can be expressed as 1537 K 1538 --- 1539 1 \ 1540 RnLR = - * > RnLk 1541 K / 1542 --- 1543 k = 1 1545 Figure 9: Type-P-One-to-group-Receiver-n-Loss-Ratio 1547 8.4.2. Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1549 Usually, the number of packets sent is used in the denominator of 1550 packet loss ratio metrics. For the comparative metrics defined here, 1551 the denominator is the maximum number of packets received at any 1552 receiver for the sample and test interval of interest. The numerator 1553 is the sum of the losses at receiver n. 1555 The Comparative Loss Ratio, also named, RnCLR, is defined as 1557 K 1558 --- 1559 \ 1560 > Ln(k) 1561 / 1562 --- 1563 k=1 1564 RnCLR = ----------------------------- 1565 / K \ 1566 | --- | 1567 | \ | 1568 K - Min | > Ln(k) | 1569 | / | 1570 | --- | 1571 \ k=1 / N 1573 Note: Ln is a set of one-way loss values at receiver n. 1574 There is one value for each of the K packets sent. 1576 Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio 1578 8.4.3. Type-P-One-to-group-Loss-Ratio 1580 Type-P-One-to-group-Loss-Ratio, the overall Group loss ratio, also 1581 named GLR, is defined as 1583 K,N 1584 --- 1585 1 \ 1586 GLR = --- * > Ln(k) 1587 K*N / 1588 --- 1589 k,n = 1 1591 Figure 11: Type-P-One-to-group-Loss-Ratio 1593 Where the sum includes all of the Loss singletons, Ln(k), over the N 1594 receivers and K packets sent, in a ratio with the total packets over 1595 all receivers. 1597 8.4.4. Type-P-One-to-group-Range-Loss-Ratio 1599 The One-to-group Loss Ratio Range is defined as: 1601 Type-P-One-to-group-Range-Loss-Ratio = max(RnLR) - min(RnLR) 1603 It is most effective to indicate the range by giving both the max and 1604 minimum loss ratios for the Group, rather than only reporting the 1605 difference between them. 1607 8.5. One-to-group Delay Variation Statistics 1609 This section defines one-way delay variation (DV) statistics for an 1610 entire group as illustrated by the matrix below. 1612 Recv /------------- Sample --------------\ Stats 1614 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ 1615 | 1616 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | 1617 | 1618 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat 1619 . | 1620 . | 1621 . | 1622 n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / 1624 Figure 12: One-to-group Delay Variation Matrix (DVMa) 1626 Statistics are computed on the sample of Type-P-One-way-Delay- 1627 Variation singletons of the group delay variation matrix above where 1628 RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at 1629 Receiver n for the packet k and where RnDV is the point-to-point one- 1630 way packet delay variation for Receiver n. 1632 All One-to-group delay variation statistics are expressed in seconds 1633 with sufficient resolution to convey 3 significant digits. 1635 8.5.1. Type-P-One-to-group-Range-Delay-Variation 1637 This section defines a metric for the range of delays variation over 1638 all N receivers in the Group. 1640 Maximum DV and minimum DV over all receivers summarize the 1641 performance over the Group (where DV is a point-to-point metric). 1642 For each receiver, the DV is usually expressed as the 1-10^(-3) 1643 quantile of one-way delay minus the minimum one-way delay. 1645 Type-P-One-to-group-Range-Delay-Variation = GRDV = 1647 = max(RnDV) - min(RnDV) for all n receivers 1649 This range is determined from the minimum and maximum values of the 1650 point-to-point one-way IP Packet Delay Variation for the set of 1651 Destinations in the group and a population of interest, using the 1652 Packet Delay Variation expressed as the 1-10^-3 quantile of one-way 1653 delay minus the minimum one-way delay. If a more demanding service 1654 is considered, one alternative is to use the 1-10^-5 quantile, and in 1655 either case the quantile used should be recorded with the results. 1656 Both the minimum and the maximum delay variation are recorded, and 1657 both values are given to indicate the location of the range. 1659 9. Measurement Methods: Scalability and Reporting 1661 Virtually all the guidance on measurement processes supplied by the 1662 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1663 scenarios is applicable here in the spatial and multiparty 1664 measurement scenario. The main difference is that the spatial and 1665 multiparty configurations require multiple points of interest where a 1666 stream of singletons will be collected. The amount of information 1667 requiring storage grows with both the number of metrics and the 1668 points of interest, so the scale of the measurement architecture 1669 multiplies the number of singleton results that must be collected and 1670 processed. 1672 It is possible that the architecture for results collection involves 1673 a single reference point with connectivity to all the points of 1674 interest. In this case, the number of points of interest determines 1675 both storage capacity and packet transfer capacity of the host acting 1676 as the reference point. However, both the storage and transfer 1677 capacity can be reduced if the points of interest are capable of 1678 computing the summary statistics that describe each measurement 1679 interval. This is consistent with many operational monitoring 1680 architectures today, where even the individual singletons may not be 1681 stored at each point of interest. 1683 In recognition of the likely need to minimize the form of the results 1684 for storage and communication, the Group metrics above have been 1685 constructed to allow some computations on a per-Receiver basis. This 1686 means that each Receiver's statistics would normally have an equal 1687 weight with all other Receivers in the Group (regardless of the 1688 number of packets received). 1690 9.1. Computation methods 1692 The scalability issue can be raised when there are thousands of 1693 points of interest in a group who are trying to send back the 1694 measurement results to the reference point for further processing and 1695 analysis. The points of interest can send either the whole measured 1696 sample or only the calculated statistics. The former one is a 1697 centralized statistic calculation method and the latter one is a 1698 distributed statistic calculation method. The sample should include 1699 all metrics parameters, the values and the corresponding sequence 1700 numbers. The transmission of the whole sample can cost much more 1701 bandwidth than the transmission of the statistics that should include 1702 all statistic parameters specified by policies and the additional 1703 information about the whole sample, such as the size of the sample, 1704 the group address, the address of the point of interest, the ID of 1705 the sample session, and so on. Apparently, the centralized 1706 calculation method can require much more bandwidth than the 1707 distributed calculation method when the sample size is big. This is 1708 especially true when the measurement has a very large number of the 1709 points of interest. It can lead to a scalability issue at the 1710 reference point by overloading the network resources. 1712 The distributed calculation method can save much more bandwidth and 1713 mitigate issues arising from scalability at the reference point side. 1715 However, it may result in a loss of information. As not all measured 1716 singletons are available for building up the group matrix, the real 1717 performance over time can be hidden from the result. For example, 1718 the loss pattern can be missed by simply accepting the loss ratio. 1719 This tradeoff between bandwidth consumption and information 1720 acquisition has to be taken into account when designing the 1721 measurement approach. 1723 One possible solution could be to transmit the statistic parameters 1724 to the reference point first to obtain the general information of the 1725 group performance. If detailed results are required, the reference 1726 point should send the requests to the points of interest, which could 1727 be particular ones or the whole group. This procedure can happen in 1728 the off peak time and can be well scheduled to avoid delivery of too 1729 many points of interest at the same time. Compression techniques can 1730 also be used to minimize the bandwidth required by the transmission. 1731 This could be a measurement protocol to report the measurement 1732 results. However, this is out of the scope of this memo. 1734 9.2. Measurement 1736 To prevent any bias in the result, the configuration of a one-to-many 1737 measure must take in consideration that more packets will to be 1738 routed than sent (copies of a packet sent are expected to arrive at 1739 many destination points) and selects a test packets rate that will 1740 not impact the network performance. 1742 9.3. Effect of Time and Space Aggregation Order on Stats 1744 This section presents the impact of the aggregation order on the 1745 scalability of the reporting and of the computation. It makes the 1746 hypothesis that receivers are not co-located and that results are 1747 gathered in a point of reference for further usages. 1749 Multimetrics samples are represented in a matrix as illustrated below 1750 Point of 1751 interest 1752 1 R1S1 R1S1 R1S1 ... R1Sk \ 1753 | 1754 2 R2S1 R2S2 R2S3 ... R2Sk | 1755 | 1756 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1757 . | 1758 . | 1759 . | 1760 n RnS1 RnS2 RnS3 ... RnSk / 1762 S1M S2M S3M ... SnM Stats over space 1764 \------------- ------------/ 1765 \/ 1766 Stat over space and time 1768 Figure 13: Impact of space aggregation on multimetrics Stat 1770 Two methods are available to compute statistics on a matrix: 1771 o Method 1: The statistic metric is computed over time and then over 1772 space; 1773 o Method 2: The statistic metric is computed over space and then 1774 over time. 1776 These 2 methods differ only by the order of the aggregation. The 1777 order does not impact the computation resources required. It does 1778 not change the value of the result. However, it impacts severely the 1779 minimal volume of data to report: 1780 o Method 1: Each point of interest computes periodically statistics 1781 over time to lower the volume of data to report. They are 1782 reported to the reference point for for subsequent computations 1783 over the spatial dimension. This volume no longer depends on the 1784 number of samples. It is only proportional to the computation 1785 period; 1786 o Method 2: The volume of data to report is proportional to the 1787 number of samples. Each sample, RiSi, must be reported to the 1788 reference point for computing statistic over space and statistic 1789 over time. The volume increases with the number of samples. It 1790 is proportional to the number of test packets; 1792 Method 2 has severe drawbacks in terms of security and dimensioning: 1793 o Increasing the rate of the test packets may result in a Denial of 1794 Service toward the points of reference; 1795 o The dimensioning of a measurement system is quite impossible to 1796 validate because any increase of the rate of the test packets will 1797 increase the bandwidth requested to collect the raw results. 1799 The computation period over time period (commonly named aggregation 1800 period) provides the reporting side with a control of various 1801 collecting aspects such as bandwidth, computation and storage 1802 capacities. So this draft defines metrics based on method 1. 1804 9.3.1. Impact on spatial statistics 1806 Two methods are available to compute spatial statistics: 1807 o Method 1: spatial segment metrics and statistics are preferably 1808 computed over time for each points of interest; 1809 o Method 2: Vectors metrics are intrinsically instantaneous space 1810 metrics which must be reported using Method2 whenever 1811 instantaneous metrics information is needed. 1813 9.3.2. Impact on one-to-group statistics 1815 Two methods are available to compute group statistics: 1816 o Method1: Figure 5 and Figure 8 illustrate the method chosen: the 1817 one-to-one statistic is computed per interval of time before the 1818 computation of the mean over the group of receivers; 1819 o Method2: Figure 13 presents the second one, metric is computed 1820 over space and then over time. 1822 10. Manageability Considerations 1824 This section defines the reporting of all the metrics introduced in 1825 the document. 1827 Information models of spatial metrics and of one-to-group metrics are 1828 similar excepted that points of interests of spatial vectors MUST be 1829 ordered. 1831 The complexity of the reporting relies on the number of points of 1832 interests. 1834 10.1. Reporting spatial metric 1836 The reporting of spatial metrics shares a lot of aspects with 1837 RFC2679-80. New ones are common to all the definitions and are 1838 mostly related to the reporting of the path and of methodology 1839 parameters that may bias raw results analysis. This section presents 1840 these specific parameters and then lists exhaustively the parameters 1841 that SHOULD be reported. 1843 10.1.1. Path 1845 End-to-end metrics can't determine the path of the measure despite 1846 IPPM RFCs recommend it to be reported (See Section 3.8.4 of 1847 [RFC2679]). Spatial metrics vectors provide this path. The report 1848 of a spatial vector MUST include the points of interests involved: 1849 the sub set of the routers of the path participating to the 1850 instantaneous measure. 1852 10.1.2. Host order 1854 A spatial vector MUST order the points of interest according to their 1855 order in the path. The ordering MAY be based on information from the 1856 TTL in IPv4, the Hop Limit in IPv6 or the corresponding information 1857 in MPLS. 1859 The report of a spatial vector MUST include the ordered list of the 1860 hosts involved in the instantaneous measure. 1862 10.1.3. Timestamping bias 1864 The location of the point of interest inside a node influences the 1865 timestamping skew and accuracy. As an example, consider that some 1866 internal machinery delays the timestamping up to 3 milliseconds then 1867 the minimal uncertainty reported be 3 ms if the internal delay is 1868 unknown at the time of the timestamping. 1870 The report of a spatial vector MUST include the uncertainty of the 1871 timestamping compared to wire time. 1873 10.1.4. Reporting spatial One-way Delay 1875 The reporting includes information to report for one-way-delay as the 1876 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1878 10.2. Reporting One-to-group metric 1880 All reporting rules described in [RFC2679] and [RFC2680] apply to the 1881 corresponding One-to-group metrics. Following are specific 1882 parameters that SHOULD be reported. 1884 10.2.1. Path 1886 As suggested by the [RFC2679] and [RFC2680], the path traversed by 1887 the packet SHOULD be reported, if possible. For One-to-group 1888 metrics, the path tree between the source and the destinations or the 1889 set of paths between the source and each destination SHOULD be 1890 reported. 1892 Path tree might not be as valuable as individual paths because an 1893 incomplete path might be difficult to identify in the path tree. For 1894 example, how many points of interest are reached by a packet 1895 travelling along an incomplete path? 1897 10.2.2. Group size 1899 The group size SHOULD be reported as one of the critical management 1900 parameters. One-to-group metrics, unlike spatial metrics, don't 1901 require the ordering of the points of interests because group members 1902 receive the packets in parallel. 1904 10.2.3. Timestamping bias 1906 It is the same as described in section 10.1.3. 1908 10.2.4. Reporting One-to-group One-way Delay 1910 It is the same as described in section 10.1.4. 1912 10.2.5. Measurement method 1914 As explained in section 9, the measurement method will have impact on 1915 the analysis of the measurement result. Therefore, it SHOULD be 1916 reported. 1918 10.3. Metric identification 1920 IANA assigns each metric defined by the IPPM WG with a unique 1921 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1923 10.4. Information model 1925 This section presents the elements of information and the usage of 1926 the information reported for network performance analysis. It is out 1927 of the scope of this section to define how the information is 1928 reported. 1930 The information model is built with pieces of information introduced 1931 and explained in one-way delay definitions [RFC2679], in packet loss 1932 definitions [RFC2680] and in IPDV definitions of [RFC3393] and 1933 [RFC3432]. It includes not only information given by "Reporting the 1934 metric" sections but by sections "Methodology" and "Errors and 1935 Uncertainties". 1937 Following are the elements of information taken from end-to-end 1938 metrics definitions referred in this memo and from spatial and 1939 multicast metrics it defines: 1941 o Packet_type, The Type-P of test packets (Type-P); 1942 o Packet_length, a packet length in bits (L); 1943 o Src_host, the IP address of the sender; 1944 o Dst_host, the IP address of the receiver; 1945 o Hosts_serie: , a list of points of interest 1946 participating to the instantaneous measure. They are routers in 1947 the case of spatial metrics or receivers in the case of one-to- 1948 group metrics; 1949 o Loss_threshold: The threshold of infinite delay; 1950 o Systematic_error: constant delay between wire time and 1951 timestamping; 1952 o Calibration_error: maximal uncertainty; 1953 o Src_time, the sending time for a measured packet; 1954 o Dst_time, the receiving time for a measured packet; 1955 o Result_status : an indicator of usability of a result 'Resource 1956 exhaustion' 'infinite', 'lost'; 1957 o Delays_serie: a list of delays; 1958 o Losses_serie: , a list of Boolean values 1959 (spatial) or a set of Boolean values (one-to-group); 1960 o Result_status_serie: a list of results status; 1961 o dT: a delay; 1962 o Singleton_number: a number of singletons; 1963 o Observation_duration: An observation duration; 1964 o metric_identifier. 1966 Following is the information of each vector that SHOULD be available 1967 to compute samples: 1969 o Packet_type; 1970 o Packet_length; 1971 o Src_host, the sender of the packet; 1972 o Dst_host, the receiver of the packet, apply only for spatial 1973 vectors; 1974 o Hosts_serie: not ordered for one-to-group; 1975 o Src_time, the sending time for the measured packet; 1976 o dT, the end-to-end one-way delay for the measured packet, apply 1977 only for spatial vectors; 1978 o Delays_serie: apply only for delays and ipdv vector, not ordered 1979 for one-to-group; 1980 o Losses_serie: apply only for packets loss vector, not ordered for 1981 one-to-group; 1982 o Result_status_serie; 1983 o Observation_duration: the difference between the time of the last 1984 singleton and the time of the first singleton. 1985 o Following is the context information (measure, points of 1986 interests) that SHOULD be available to compute samples : 1988 * Loss threshold; 1989 * Systematic error: constant delay between wire time and 1990 timestamping; 1991 * Calibration error: maximal uncertainty; 1993 A spatial or a one-to-group sample is a collection of singletons 1994 giving the performance from the sender to a single point of interest. 1995 Following is the information that SHOULD be available for each sample 1996 to compute statistics: 1998 o Packet_type; 1999 o Packet_length; 2000 o Src_host, the sender of the packet; 2001 o Dst_host, the receiver of the packet; 2002 o Start_time, the sending time of the first packet; 2003 o Delays_serie: apply only for delays and ipdv samples; 2004 o Losses_serie: apply only for packets loss samples; 2005 o Result_status_serie; 2006 o Observation_duration: the difference between the time of the last 2007 singleton of the last sample and the time of the first singleton 2008 of the first sample. 2009 o Following is the context information (measure, points of 2010 interests) that SHOULD be available to compute statistics : 2011 * Loss threshold; 2012 * Systematic error: constant delay between wire time and 2013 timestamping; 2014 * Calibration error: maximal uncertainty; 2016 Following is the information of each statistic that SHOULD be 2017 reported: 2019 o Result; 2020 o Start_time; 2021 o Duration; 2022 o Result_status; 2023 o Singleton_number, the number of singletons the statistic is 2024 computed on; 2026 11. Security Considerations 2028 Spatial and one-to-group metrics are defined on the top of end-to-end 2029 metrics. Security considerations discussed in One-way delay metrics 2030 definitions of [RFC2679] , in packet loss metrics definitions of 2031 [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 2032 apply to metrics defined in this memo. 2034 Someone may spoof the identity of a Point of interest identity and 2035 intentionally send corrupt results in order to remotely orient the 2036 traffic engineering decisions. 2038 A point of interest could intentionally corrupt its results in order 2039 to remotely orient the traffic engineering decisions. 2041 11.1. Spatial metrics 2043 Malicious generation of packets which match systematically the hash 2044 function used to detect the packets may lead to a DoS attack toward 2045 the point of reference. 2047 Spatial measurement results carry the performance of individual 2048 segments of the path and the identity of nodes. An attacker may 2049 infer from this information the points of weakness of a network (e.g. 2050 congested node) which would require the least amount of additional 2051 attacking traffic to exploit. Therefore, monitoring information 2052 should be carried in a way which prevents unintended recipients from 2053 inspecting the measurement reports. A straight forward solution is 2054 to restrict access to the reports using encrypted sessions or secured 2055 networks. 2057 11.2. One-to-group metrics 2059 Reporting of measurement results from a huge number of probes may 2060 overload reference point resources (network, network interfaces, 2061 computation capacities ...). 2063 The configuration of a measurement must take in consideration that 2064 implicitly more packets will be routed than sent and selects a test 2065 packets rate accordingly. Collecting statistics from a huge number 2066 of probes may overload any combination of the network where the 2067 measurement controller is attached to, measurement controller network 2068 interfaces and measurement controller computation capacities. 2070 One-to-group metrics measurement should consider using source 2071 authentication protocols, standardized in the MSEC group, to avoid 2072 fraud packet in the sampling interval. The test packet rate could be 2073 negotiated before any measurement session to avoid deny of service 2074 attacks. 2076 A point of interest could intentionally degrade its results in order 2077 to remotely increase the quality of the network on the branches of 2078 the multicast tree it is connected to. 2080 12. Acknowledgments 2082 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2083 of Surrey, for his instruction and helpful comments on this work. 2085 13. IANA Considerations 2087 Metrics defined in this memo are designed to be registered in the 2088 IANA IPPM METRICS REGISTRY as described in initial version of the 2089 registry [RFC4148] : 2091 IANA is asked to register the following metrics in the IANA-IPPM- 2092 METRICS-REGISTRY-MIB : 2094 ietfSpatialOneWayDelayVector OBJECT-IDENTITY 2095 STATUS current 2096 DESCRIPTION 2097 "Type-P-Spatial-One-way-Delay-Vector" 2098 REFERENCE 2099 "Reference "RFCyyyy, section 5.1." 2100 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2101 note 2102 := { ianaIppmMetrics nn } -- IANA assigns nn 2104 ietfSpatialPacketLossVector OBJECT-IDENTITY 2105 STATUS current 2106 DESCRIPTION 2107 "Type-P-Spatial-Packet-Loss-Vector" 2108 REFERENCE 2109 "Reference "RFCyyyy, section 5.2." 2110 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2111 note 2112 := { ianaIppmMetrics nn } -- IANA assigns nn 2114 ietfSpatialOneWayIpdvVector OBJECT-IDENTITY 2115 STATUS current 2116 DESCRIPTION 2117 "Type-P-Spatial-One-way-ipdv-Vector" 2118 REFERENCE 2119 "Reference "RFCyyyy, section 5.3." 2120 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2121 note 2122 := { ianaIppmMetrics nn } -- IANA assigns nn 2124 ietfSegmentOneWayDelayStream OBJECT-IDENTITY 2125 STATUS current 2126 DESCRIPTION 2127 "Type-P-Segment-One-way-Delay-Stream" 2128 REFERENCE 2129 "Reference "RFCyyyy, section 6.1." 2130 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2131 note 2132 := { ianaIppmMetrics nn } -- IANA assigns nn 2134 ietfSegmentPacketLossStream OBJECT-IDENTITY 2135 STATUS current 2136 DESCRIPTION 2137 "Type-P-Segment-Packet-Loss-Stream" 2138 REFERENCE 2139 "Reference "RFCyyyy, section 6.2." 2140 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2141 note 2142 := { ianaIppmMetrics nn } -- IANA assigns nn 2144 ietfSegmentIpdvPrevStream OBJECT-IDENTITY 2145 STATUS current 2146 DESCRIPTION 2147 "Type-P-Segment-ipdv-prev-Stream" 2148 REFERENCE 2149 "Reference "RFCyyyy, section 6.3." 2150 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2151 note 2152 := { ianaIppmMetrics nn } -- IANA assigns nn 2154 ietfSegmentIpdvMinStream OBJECT-IDENTITY 2155 STATUS current 2156 DESCRIPTION 2157 "Type-P-Segment-ipdv-min-Stream" 2158 REFERENCE 2159 "Reference "RFCyyyy, section 6.4." 2160 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2161 note 2162 := { ianaIppmMetrics nn } -- IANA assigns nn 2164 -- One-to-group metrics 2166 ietfOneToGroupDelayVector OBJECT-IDENTITY 2167 STATUS current 2168 DESCRIPTION 2169 "Type-P-One-to-group-Delay-Vector" 2170 REFERENCE 2171 "Reference "RFCyyyy, section 7.1." 2172 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2173 note 2174 := { ianaIppmMetrics nn } -- IANA assigns nn 2176 ietfOneToGroupPacketLossVector OBJECT-IDENTITY 2177 STATUS current 2178 DESCRIPTION 2179 "Type-P-One-to-group-Packet-Loss-Vector" 2180 REFERENCE 2181 "Reference "RFCyyyy, section 7.2." 2182 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2183 note 2184 := { ianaIppmMetrics nn } -- IANA assigns nn 2186 ietfOneToGroupIpdvVector OBJECT-IDENTITY 2187 STATUS current 2188 DESCRIPTION 2189 "Type-P-One-to-group-ipdv-Vector" 2190 REFERENCE 2191 "Reference "RFCyyyy, section 7.3." 2192 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2193 note 2194 := { ianaIppmMetrics nn } -- IANA assigns nn 2196 -- One to group statistics 2198 -- 2200 ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY 2201 STATUS current 2202 DESCRIPTION 2203 "Type-P-One-to-group-Receiver-n-Mean-Delay" 2204 REFERENCE 2205 "Reference "RFCyyyy, section 8.3.1." 2206 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2207 note 2208 := { ianaIppmMetrics nn } -- IANA assigns nn 2210 ietfOneToGroupMeanDelay OBJECT-IDENTITY 2211 STATUS current 2212 DESCRIPTION 2213 "Type-P-One-to-group-Mean-Delay" 2214 REFERENCE 2215 "Reference "RFCyyyy, section 8.3.2." 2216 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2217 note 2218 := { ianaIppmMetrics nn } -- IANA assigns nn 2220 ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY 2221 STATUS current 2222 DESCRIPTION 2223 "Type-P-One-to-group-Range-Mean-Delay" 2224 REFERENCE 2225 "Reference "RFCyyyy, section 8.3.3." 2226 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2227 note 2228 := { ianaIppmMetrics nn } -- IANA assigns nn 2230 ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY 2231 STATUS current 2232 DESCRIPTION 2233 "Type-P-One-to-group-Max-Mean-Delay" 2234 REFERENCE 2235 "Reference "RFCyyyy, section 8.3.4." 2236 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2237 note 2238 := { ianaIppmMetrics nn } -- IANA assigns nn 2240 ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY 2241 STATUS current 2242 DESCRIPTION 2243 "Type-P-One-to-group-Receiver-n-Loss-Ratio" 2244 REFERENCE 2245 "Reference "RFCyyyy, section 8.4.1." 2246 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2247 note 2248 := { ianaIppmMetrics nn } -- IANA assigns nn 2249 -- 2251 ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY 2252 STATUS current 2253 DESCRIPTION 2254 "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio" 2255 REFERENCE 2256 "Reference "RFCyyyy, section 8.4.2." 2257 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2258 note 2259 := { ianaIppmMetrics nn } -- IANA assigns nn 2261 ietfOneToGroupLossRatio OBJECT-IDENTITY 2262 STATUS current 2263 DESCRIPTION 2264 "Type-P-One-to-group-Loss-Ratio" 2265 REFERENCE 2266 "Reference "RFCyyyy, section 8.4.3." 2267 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2268 note 2269 := { ianaIppmMetrics nn } -- IANA assigns nn 2270 -- 2272 ietfOneToGroupRangeLossRatio OBJECT-IDENTITY 2273 STATUS current 2274 DESCRIPTION 2275 "Type-P-One-to-group-Range-Loss-Ratio" 2276 REFERENCE 2277 "Reference "RFCyyyy, section 8.4.4." 2278 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2279 note 2280 := { ianaIppmMetrics nn } -- IANA assigns nn 2282 ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY 2283 STATUS current 2284 DESCRIPTION 2285 "Type-P-One-to-group-Range-Delay-Variation" 2286 REFERENCE 2287 "Reference "RFCyyyy, section 8.5.1." 2288 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2289 note 2290 := { ianaIppmMetrics nn } -- IANA assigns nn 2292 -- 2294 14. References 2296 14.1. Normative References 2298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2299 Requirement Levels", BCP 14, RFC 2119, March 1997. 2301 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2302 Delay Metric for IPPM", RFC 2679, September 1999. 2304 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2305 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2307 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2308 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2309 November 2002. 2311 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2312 Registry", BCP 108, RFC 4148, August 2005. 2314 14.2. Informative References 2316 [I-D.ietf-ippm-spatial-composition] 2317 Morton, A. and E. Stephan, "Spatial Composition of 2318 Metrics", draft-ietf-ippm-spatial-composition-09 (work in 2319 progress), June 2009. 2321 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2322 "Framework for IP Performance Metrics", RFC 2330, 2323 May 1998. 2325 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2326 performance measurement with periodic streams", RFC 3432, 2327 November 2002. 2329 Authors' Addresses 2331 Stephan Emile 2332 France Telecom Division R&D 2333 2 avenue Pierre Marzin 2334 Lannion, F-22307 2336 Fax: +33 2 96 05 18 52 2337 Email: emile.stephan@orange-ftgroup.com 2339 Lei Liang 2340 CCSR, University of Surrey 2341 Guildford 2342 Surrey, GU2 7XH 2344 Fax: +44 1483 683641 2345 Email: L.Liang@surrey.ac.uk 2347 Al Morton 2348 200 Laurel Ave. South 2349 Middletown, NJ 07748 2350 USA 2352 Phone: +1 732 420 1571 2353 Email: acmorton@att.com