idnits 2.17.1 draft-ietf-ippm-multimetrics-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2558. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 475: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 551: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 657: '...-way-Delay-Vector metric is taken MUST...' RFC 2119 keyword, line 700: '...ipdv measurement SHOULD be respectful ...' RFC 2119 keyword, line 779: '... These cases MUST be identified befo...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering of Ha and Hb over the path coming either from the configuration (asumption on the path) or from the processing of the vectors: bad scrutening of the path ordering information, or some other mistake in the measure or the reporting. It is not in the scope of this document to go in further details which are mostly implementation dependent. This value MUST not be used to compute packet lost statistics. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPPM framework relies on the mesure of the behavior of packets of the same size. Consequently a passive metric sample MUST not mix information of packets of different sizes. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2007) is 6132 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Stephan 2 Internet-Draft France Telecom 3 Intended status: Informational L. Liang 4 Expires: January 7, 2008 University of Surrey 5 A. Morton 6 AT&T Labs 7 July 6, 2007 9 IP Performance Metrics (IPPM) for spatial and multicast 10 draft-ietf-ippm-multimetrics-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 7, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The IETF IP Performance Metrics (IPPM) working group has standardized 44 metrics for measuring end-to-end performance between 2 points. This 45 memo defines 2 sets of metrics to extend these end-to-end ones. It 46 defines spatial metrics for measuring the performance of segments 47 along a path and metrics for measuring the performance of a group of 48 users in multiparty communications. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 55 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 56 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 57 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6 58 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6 59 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 60 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 64 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 65 3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 66 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 67 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 68 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 69 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15 70 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17 71 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19 72 5.1. A Definition of a sample of One-way Delay of a segment 73 of the path . . . . . . . . . . . . . . . . . . . . . . . 19 74 5.2. A Definition of a sample of Packet Loss of a segment 75 of the path . . . . . . . . . . . . . . . . . . . . . . . 21 76 5.3. A Definition of a sample of One-way Ipdv of a segment 77 of the path . . . . . . . . . . . . . . . . . . . . . . . 24 78 5.4. Discussion on Passive Segment Metrics . . . . . . . . . . 24 79 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 27 80 6.1. A Definition for one-to-group One-way Delay . . . . . . . 27 81 6.2. A Definition for one-to-group One-way Packet Loss . . . . 28 82 6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 28 83 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 30 84 7.1. Discussion on the Impact of packet loss on statistics . . 32 85 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 33 86 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 34 87 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 37 88 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 39 89 8. Measurement Methods: Scaleability and Reporting . . . . . . . 39 90 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 40 91 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 41 92 8.3. Effect of Time and Space Aggregation Order on Stats . . . 41 93 9. Manageability Considerations . . . . . . . . . . . . . . . . . 43 94 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 43 95 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 44 96 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44 97 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44 98 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 48 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 100 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48 101 11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48 102 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 103 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 105 14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 106 14.2. Informative References . . . . . . . . . . . . . . . . . . 56 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 108 Intellectual Property and Copyright Statements . . . . . . . . . . 58 110 1. Introduction 112 The IPPM WG defined a framework for metric definitions and end-to-end 113 measurements: 115 o A general framework for defining performance metrics, described in 116 the Framework for IP Performance Metrics [RFC2330]; 118 o A One-way Active Measurement Protocol Requirements [RFC3763]; 120 o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; 122 o An IP Performance Metrics Registry [RFC4148]; 124 It specified a set of end-to-end metrics, which conform to this 125 framework: 127 o The IPPM Metrics for Measuring Connectivity [RFC2678]; 129 o The One-way Delay Metric for IPPM [RFC2679]; 131 o The One-way Packet Loss Metric for IPPM [RFC2680]; 133 o The Round-trip Delay Metric for IPPM [RFC2681]; 135 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 136 [RFC3148]; 138 o One-way Loss Pattern Sample Metrics [RFC3357]; 140 o IP Packet Delay Variation Metric for IPPM [RFC3393]; 142 o Network performance measurement for periodic streams [RFC3432]; 144 o Packet Reordering Metric for IPPM [RFC4737]; 146 This memo defines spatial and one-to-group metrics based on the 147 framework and on the end-to-end metrics defined in these documents. 149 Firstly it defines spatial metrics: 151 o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be 152 introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679] 153 in a spatial sequence of one-way delays. 155 o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 156 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 157 [RFC2680] in a spatial sequence of packet loss. 159 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector', 160 called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to 161 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of 162 ipdv. 164 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 165 called Type-P-Segment-One-way-Delay-Stream, will be introduced to 166 define a set of one-way delays between a pair of host of the path; 168 o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', 169 called Type-P-Segment-Packet-Loss-Stream, will be introduced to 170 define a set of packet losses between a pair of host of the path; 172 o Using the Type-P-Spatial-ipdv-Vector metric, a 'sample', called 173 Type-P-Segment-ipdv-Stream, will be introduced to define a set of 174 ipdvs between a pair of host of the path; 176 Then it defines one-to-group metrics. 178 o Using one test packet sent from one sender to a group of 179 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 180 Vector, will be introduced to define the list of Type-P-one-way- 181 delay [RFC2679] between this sender and the group of receivers. 183 o Using one test packet sent from one sender to a group of 184 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 185 Loss-Vector, will be introduced to define the list of Type-P-One- 186 way-Packet-Loss [RFC2680] between this sender and the group of 187 receivers 189 o Using one test packet sent from one sender to a group of 190 receivers, a 'sample', called Type-P-one-to-group-One-way-ipdv- 191 Vector, will be introduced to define the list of Type-P-One-way- 192 ipdv between this sender and the group of receivers 194 o Then a discussion section presents the set of statistics that may 195 be computed using these metrics to present the network performance 196 in the view of a group of users. The statistics may be the basis 197 for requirements (e.g. fairness) on multiparty communications. . 199 Reporting of metrics is defined in the section "Manageability 200 Consideration". 202 2. Terminology 203 2.1. Path Digest Hosts 205 The list of the hosts of a path from a source to a destination. 207 2.2. Multiparty metric 209 A metric is said to be multiparty if the topology involves more than 210 one source or destination in the measurements. All multiparty 211 metrics define a set of hosts called "points of interest", where one 212 host is the source and other hosts are the measurement collection 213 points. For example, if the set of points of interest is < ha, hb, 214 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 215 destinations, then measurements may be conducted between < ha, hb>, < 216 ha, hc>, ..., . 218 For the purposes of this memo (reflecting the scope of a single 219 source), the only multiparty metrics are one-to-group metrics. 221 2.3. Spatial metric 223 A metric is said to be spatial if one of the hosts involved is 224 neither the source nor the destination of the measured packet. 226 2.4. One-to-group metric 228 A metric is said to be one-to-group if the measured packet is sent by 229 one source and (potentially) received by several destinations. Thus, 230 the topology of the communication group can be viewed as a centre- 231 distributed or server-client topology with the source as the centre/ 232 server in the topology. 234 2.5. Points of interest 236 Points of interest are the set of hosts* (as per RFC2330 definition, 237 that is including nodes) of the set of hosts involved in the delivery 238 of the packets (in addition to the source itself). Note that the set 239 of the points of interest are (a possibly arbitrary) subset of all 240 the hosts involved in the path. Points of interest of One-to-group 241 metrics are the hosts receiving packets from the source (in addition 242 to the source itself). 244 Src Recv 245 `. ,-. 246 `. ,' `...... 1 247 `. ; : 248 `. ; : 249 ; :... 2 250 | | 251 : ; 252 : ;.... 3 253 : ; 254 `. ,' 255 `-'....... N 257 Figure 1: One-to-group points of interest 259 A points of interest of spatial metrics is a host of the set of hosts 260 involved in the delivery of the packets from the source. 262 Src ------. Hosts 263 \ 264 `---X ... 1 265 \ 266 x 267 / 268 .---------X .... 2 269 / 270 x 271 \ 272 `---X .... 3 273 \ 274 \ 275 \ 276 X .... N 277 \ 278 \ 279 \ 280 `---- Dst 282 Note: 'x' are nodes which are not points of interest 284 Figure 2: Spatial points of interest 286 2.6. Reference point 288 The centre/server in the multimetrics measurement that is controlled 289 by network operators can be a very good reference point where 290 measurement data can be collected for further processing although the 291 actual measurements have to be carried out at all points of interest. 292 Thus, we can define the reference point as the server where the 293 statistic calculation will be carried out. 295 2.7. Vector 297 A Vector is a set of singletons, which are a set of results of the 298 observation of the behaviour of the same packet at different places 299 of a network at different time. For instance, if One-way delay 300 singletons observed at N receivers for Packet P sent by the source 301 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 302 elements can be organized as {dT1, dT2,..., dTN}. The elements in 303 one vector are singletons distinct with each other in terms of both 304 measurement point and time. Given the vector V as an example, the 305 element dT1 is distinct from the rest by measured at receiver 1 at 306 time T1. Additional to a singleton, Vector gives information over a 307 space dimension. 309 2.8. Matrix 311 Several vectors can form up a Matrix, which contains results observed 312 in a sampling interval at different place of a network at different 313 time. For instance, given One-way delay vectors V1={dT11, dT12,..., 314 dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for 315 Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, 316 V2,...,Vm}. Additional to the information given by a Vector, a 317 Matrix is more powerful to present network performance in both space 318 and time dimensions. It normally corresponds to a sample. 320 The relation among Singleton, Vector and Matrix can be shown in the 321 following Figure 3. 323 Point of Singleton 324 interest / Samples 325 ,----. ^ / 326 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 327 / \ | | | 328 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 329 Src | || | | 330 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 331 | || | | 332 : ;| | | 333 \ / | | | 334 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 335 `-----' +-------------------------------------> time 337 Vector Matrix 338 (space) (time) 340 Figure 3: Relation beween Singletons, vectors and matrix 342 3. Motivations 344 All IPPM metrics are defined for end-to-end measurement. These 345 metrics provide very good guides for measurement in the pair 346 communications. However, further efforts should be put to define 347 metrics for multiparty measurements such as one to one trajectory 348 metrics and one to multipoint metrics. 350 3.1. Motivations for spatial metrics 352 Decomposition of instantaneous end-to-end measures is needed: 354 o Decomposing the performance of interdomain path is desirable in 355 interdomain to qualify per AS contribution to the performance. So 356 it is necessary to define standard spatial metrics before going 357 further in the computation of inter domain path with QoS 358 constraint. 360 o Traffic engineering and troubleshooting applications require 361 spatial views of the one-way delay consumption, identification of 362 the location of the lost of packets and the decomposition of the 363 ipdv over the path. 365 o Monitoring the QoS of a multicast tree, of MPLS point-to- 366 multipoint and inter-domain communication require spatial 367 decomposition of the one-way delay, of the packet loss and of the 368 ipdv. 370 o Composition of metrics is a need to scale in the measurement 371 plane. Spatial measure give typically the individual performance 372 of an intra domain segment. It is the elementary piece of 373 information to exchange for measuring interdomain performance 374 based on composition of metrics. 376 o The PSAMP WG defines capabilities to sample packets in a way to to 377 support instantaneous measurement respecful of the IPPM framework 378 [RFC2330]. Consequently it is necessary to define a set of 379 spatial metrics for passive and active techniques. 381 3.2. Motivations for One-to-group metrics 383 While the node-to-node based spatial measures can provide very useful 384 data in the view of each connection, we also need measures to present 385 the performance of a multiparty communication in the view of a group 386 with consideration that it involves a group of people rather than 387 two. As a consequence a simple one-way metric cannot describe the 388 multi-connection situation. We need some new metrics to collect 389 performance of all the connections for further statistics analysis. 390 A group of metrics are proposed in this stage named one-to-group 391 performance metrics based on the unicast metrics defined in IPPM WG. 392 One-to-group metrics are trying to composite one-way metrics from one 393 source to a group of destinations to make up new metrics. The 394 compositions are necessary for judging the network performance of 395 multiparty communications and can also be used to describe the 396 difference of the QoS served among a group of users. 398 One-to-group performance metrics are needed for several reasons: 400 o For designing and engineering multicast trees and MPLS point-to- 401 multipoint LSP; 403 o For evaluating and controlling of the quality of the multicast 404 services; 406 o For controlling the performance of the inter domain multicast 407 services; 409 o For presenting and evaluating the relative QoS requirements for 410 the multiparty communications. 412 To understand the connection situation between one source and any one 413 receiver in the multiparty communication group, we need the 414 collection of instantaneous end-to-end measures. It will give us 415 very detailed insight into each branch of the multicast tree in terms 416 of end-to-end absolute QoS. It can provide clear and helpful 417 information for engineers to identify the connection with problems in 418 a complex multiparty routing tree. 420 The one-to-group metrics described in this memo introduce one-to-many 421 concerns to the IPPM working group to measure the performance of a 422 group of users who receiving data from the same source. The concept 423 extends the "path" in the one-way measurement to "path tree" to cover 424 both one-to-one and one-to-many communications. Nevertheless, 425 applied to one-to-one communications they provide exactly the same 426 results as the corresponding one-to-one metrics. 428 3.3. Discussion on Group-to-one and Group-to-group metrics 430 We note that points of interest can also be selected to define 431 measurements on Group-to-one and Group-to-group topologies. These 432 topologies are currently beyond the scope of this memo, because they 433 would involve multiple packets launched from different sources. 434 However, we can give some clues here on these two cases. 436 The measurements for group-to-one topology can be easily derived from 437 the one-to-group measurement. The measurement point is the reference 438 point that is acting as a receiver while all of clients/receivers 439 defined for one-to-group measurement act as sources in this case. 441 For the group-to-group connection topology, we can hardly define the 442 reference point and, therefore, have difficulty to define the 443 measurement points. However, we can always avoid this confusion by 444 treating the connections as one-to-group or group-to-one in our 445 measurements without consideration on how the real communication will 446 be carried out. For example, if one group of hosts < ha, hb, hc, 447 ..., hn > are acting as sources to send data to another group of 448 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 449 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 450 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 451 ..., Hm >. 453 4. Spatial vectors metrics definitions 455 This section defines vectors for the decomposition of end-to-end 456 singleton metrics over a path. 458 Spatial vectors metrics are based on the decomposition of standard 459 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 460 [RFC3393] and [RFC3432]. 462 Definitions are coupled with the corresponding end-to-end metrics. 463 Methodology specificities are common to all the vectors defined and 464 are consequently discussed in a common section. 466 4.1. A Definition for Spatial One-way Delay Vector 468 This section is coupled with the definition of Type-P-One-way-Delay. 469 When a parameter from section 3 of [RFC2679] is first used in this 470 section, it will be tagged with a trailing asterisk. 472 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 473 statements for end-to-end one-way-delay measurements. They are 474 applicable to each point of interest Hi involved in the measure. 475 Spatial one-way-delay measurement SHOULD be respectful of them, 476 especially those related to methodology, clock, uncertainties and 477 reporting. 479 Following we adapt some of them and introduce points specific to 480 spatial measurement. 482 4.1.1. Metric Name 484 Type-P-Spatial-One-way-Delay-Vector 486 4.1.2. Metric Parameters 488 o Src*, the IP address of the sender. 490 o Dst*, the IP address of the receiver. 492 o i, An integer if the list <1,2,...,n> which ordered the hosts in 493 the path. 495 o Hi, A host* of the path digest. 497 o T*, a time, the sending (or initial observation) time for a 498 measured packet. 500 o dT* a delay, the one-way delay for a measured packet. 502 o a list of delay. 504 o P*, the specification of the packet type. 506 o , hosts path digest. 508 4.1.3. Metric Units 510 A sequence of times. 512 4.1.4. Definition 514 Given a Type-P packet sent by the sender Src at wire-time (first bit) 515 T to the receiver Dst in the path . Given the 516 sequence of values such that dT is the 517 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 518 path, T+dTi is either a real number corresponding to the wire-time 519 the packet passes (last bit received) Hi, or undefined if the packet 520 never passes Hi. 522 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 523 as the sequence of values 524 . 526 4.1.5. Discussion 528 Following are specific issues which may occur: 530 o the delay looks to decrease: dTi > DTi+1. This seem typically du 531 to some clock synchronisation issue. This point is discussed in 532 the section 3.7.1. "Errors or uncertainties related to Clocks" of 533 of [RFC2679]. One consequence of these uncertainties is that 534 times of a measure at different hosts shall not be used to order 535 hosts on the path of a measure; 537 o The location of the point of interest in the device influences the 538 result. If the packet is not observed on the input interface the 539 delay includes buffering time and consequently an uncertainty due 540 to the difference between 'wire time' and 'host time'; 542 4.2. A Definition for Spatial One-way Packet Loss Vector 544 This section is coupled with the definition of Type-P-One-way-Packet- 545 Loss. Then when a parameter from the section 2 of [RFC2680] is first 546 used in this section, it will be tagged with a trailing asterisk. 548 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 549 statements for end-to-end one-way-Packet-Loss measurements. They are 550 applicable to each point of interest Hi involved in the measure. 551 Spatial packet loss measurement SHOULD be respectful of them, 552 especially those related to methodology, clock, uncertainties and 553 reporting. 555 Following we define the spatial metric, then we adapt some of the 556 points above and introduce points specific to spatial measurement. 558 4.2.1. Metric Name 560 Type-P-Spatial-One-way-Packet-Loss-Vector 562 4.2.2. Metric Parameters 564 + Src*, the IP address of the sender. 566 + Dst*, the IP address of the receiver. 568 + i, An integer which ordered the hosts in the path. 570 + Hi, exchange points of the path digest. 572 + T*, a time, the sending (or initial observation) time for 573 a measured packet. 575 + dT1,..., dTn, dT, a list of delay. 577 + P*, the specification of the packet type. 579 + , hosts path digest. 581 + B1, B2, ..., Bi, ..., Bn, a list of Boolean values. 583 4.2.3. Metric Units 585 A sequence of Boolean values. 587 4.2.4. Definition 589 Given a Type-P packet sent by the sender Src at time T to the 590 receiver Dst in the path . Given the sequence of 591 times the packet passes , 594 Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence 595 of values such that for each Hi of the path, a 596 value of Bi of 0 means that dTi is a finite value, and a value of 1 597 means that dTi is undefined. 599 4.2.5. Discussion 601 Following are specific issues which may occur: 603 o the result includes the sequence 1,0. This case means that the 604 packet was seen by a host but not by it successor on the path; 606 The location of the point of interest in the device influences the 607 result: 609 o Even if the packet is received by a host, it may be not observed 610 by the point of interest located after a buffer; 612 4.3. A Definition for Spatial One-way Ipdv Vector 614 This section uses parameters from the definition of Type-P-One-way- 615 ipdv. When a parameter from section 2 of [RFC3393] is first used in 616 this section, it will be tagged with a trailing asterisk. 618 Following we adapt some of them and introduce points specific which 619 are to spatial measurement. 621 4.3.1. Metric Name 623 Type-P-Spatial-One-way-ipdv-Vector 625 4.3.2. Metric Parameters 627 + Src*, the IP address of the sender. 629 + Dst*, the IP address of the receiver. 631 + i, An integer which ordered the hosts in the path. 633 + Hi, exchange points of the path digest. 635 + T1*, the time the first packet was sent. 637 + T2*, the time the second packet was sent. 639 + P, the specification of the packet type. 641 + P1, the first packet sent at time T1. 643 + P2, the second packet sent at time T2. 645 + , host path digest. 647 + , 648 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 649 time T1; 651 + , 652 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 653 time T2; 655 + L*, a packet length in bits. The packets of a Type P 656 packet stream from which the 657 Type-P-Spatial-One-way-Delay-Vector metric is taken MUST 658 all be of the same length. 660 4.3.3. Metric Units 662 A sequence of times. 664 4.3.4. Definition 666 Given the Type-P packet having the size L and sent by the sender Src 667 at wire-time (first bit) T1 to the receiver Dst in the path . 670 Given the Type-P packet having the size L and sent by the sender Src 671 at wire-time (first bit) T2 to the receiver Dst in the same path. 673 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P1. 676 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P2. 679 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 680 of values 681 Such that for each Hi of the path , dT2.i-dT1.i is 682 either a real number if the packets P1 and P2 passes Hi at wire-time 683 (last bit) dT1.i, respectively dT2.i, or undefined if at least one of 684 them never passes Hi. T2-T1 is the inter-packet emission interval 685 and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. 687 4.4. Spatial Methodology 689 Methodology, reporting and uncertainties points specified in section 690 3 of [RFC2679][RFC2679] applies to each point of interest Hi 691 measuring a element of a spatial delay vector. 693 Methodology, reporting and uncertainties points specified in section 694 2 of [RFC2680][RFC2680] applies to each point of interest Hi 695 measuring a element of a spatial packet loss vector. 697 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 698 statements for end-to-end One-way ipdv measurements. They are 699 applicable to each point of interest Hi involved in the measure. 700 Spatial One-way ipdv measurement SHOULD be respectful of methodology, 701 clock, uncertainties and reporting aspects given in this section. 703 Passive and active measurement approaches of the metrology are 704 considered as orthogonal. Active measure differs mainly from passive 705 measure by the knowledge of the time the packet was send by the 706 source and received by the destination, making the RFC2330 framework 707 difficults to apply to passive measurement. On the other hand, 708 spatial metrics rely on passive observation of the packets involved 709 in the measure. 711 In fact each approach compliments the other setting the base of 712 spatial measurement methodology: Active points of interest provide 713 information observed at the source and at the destination while 714 Passive points of interests provide information observed at 715 intermediary hosts of the path. 717 Generally, for a given Type-P of length L, in a given Hi, the 718 methodology for spatial vector metrics would proceed as follows: 720 o At each Hi, points of interest prepare to capture the packet sent 721 a time T, take a timestamp Ti', determine the internal delay 722 correction dTi' (See section 3.7.1. "Errors or uncertainties 723 related to Clocks" of [RFC2679]), 725 o Each Hi extracts the path ordering information from the packet 726 (e.g. time-to-live); 728 o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. 729 This arrival time is undefined (infinite) if the packet is not 730 detected after the 'loss threshold' duration; 732 o Each Hi extracts the timestamp T from the packet, 734 o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; 736 o The reference point gathers the result and time-to-live of each Hi 737 and order them according to the path to build the Type-P-Spatial- 738 One-way-Delay-Vector metric over the path 739 . 741 4.4.1. Loss threshold 743 Loss threshold is the centrality of any methodology because it 744 determines the presence the packet in the measurement process of the 745 point of interest and consequently determines any ground truth metric 746 result. It determines the presence of an effective delay, and bias 747 the measure of ipdv, of packet loss and of the statistics. 749 This is consistent for end-to-end but impacts spatial measure: 750 depending on the consistency of the Loss threshold among the points 751 of interest, a packet may be considered loss a one host but present 752 in another one, or may be observed by the last host (last hop) of the 753 path but considered lost by Dst. The analysis of such results is not 754 deterministic: has the path change? Does the packet arrive at 755 destination or was it lost during the last mile? The same applies, 756 of course, for one-way-delay measures: a delay measured may be 757 infinite at one host but a real value in another one, or may be 758 measured as a real value by the last host of the path but observed as 759 infinite by Dst. The Loss threshold should be set up with the same 760 value in each host of the path and in the destination. The Loss 761 threshold must be systematically reported to permit careful 762 introspection and to avoid the introduction of any contradiction in 763 the statistic computation process. 765 4.4.2. Host Path Digest 767 The methodology given above adds the order of the points of interest 768 over the path to [RFC2679] one's. 770 A perfect Host Path Digest (hum! of cource from the measurement point 771 of view only, that is, corresponding to the real path the test packet 772 experimented) may include several times several hosts: 774 o coresponds to a loop in the path; 776 o coresponds to a loop in the path which 777 may occurs during rerouting phases; 779 These cases MUST be identified before statistics computation to avoid 780 corrupted results' production. This applies especially to the 781 measure of segments which are build from results of a measure of a 782 vector metric. 784 5. Spatial Segments metrics definitions 786 This section defines samples to measure a sequence of delays, a 787 sequence of lost and a sequence of ipdv between 2 hosts of the path, 788 a segment. Singletons are taken from segments of vectors defined 789 above. 791 5.1. A Definition of a sample of One-way Delay of a segment of the path 793 This metric defines a sample of One-way delays between a pair of 794 hosts of a path. 796 5.1.1. Metric Name 798 Type-P-Segment-One-way-Delay-Stream 800 5.1.2. Metric Parameters 802 + Src*, the IP address of the sender. 804 + Dst*, the IP address of the receiver. 806 + P*, the specification of the packet type; 808 + i, An integer which orders exchange points in the path. 810 + k, An integer which orders the packets sent. 812 + Hi, a host of the path digest; 814 + , host path digest. 816 + Ha, a host of the path digest different from Dst and Hb; 818 + Hb, a host of the path digest different from Src and Ha. 819 Hb order in the path must greater that Ha; 821 + , a list of time ordered by k; 823 + dT1,..., dTn a list of delay; 825 5.1.3. Metric Units 827 A sequence of delay 829 5.1.4. Definition 831 Given 2 hosts Ha and Hb of the path , given 832 a flow of packets of Type-P sent from Src to Dst at the times T1, 833 T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- 834 way-Delay-Vector . We define 835 the value of the sample Type-P-segment-One-way-Delay-Stream as the 836 sequence made up of the delays dTk.b - dTk.a. dTk.a is the delay 837 between Src and Ha. dTk.b is the delay between Src and Hb. 'dTk.b - 838 dTk.a' is the one-way delay experienced by the packet sent by Src at 839 the time Tk when going from Ha to Hb. 841 5.1.5. Discussion 843 Following are specific issues which may occur: 845 o When a is Src is the measure of the first hop. 847 o When b is Dst is the measure of the last hop. 849 o the delay looks to decrease: dTi > DTi+1: 851 * This is typically du to clock synchronisation issue. this point 852 is discussed in the section 3.7.1. "Errors or uncertainties 853 related to Clocks" of of [RFC2679]; 855 * This may occurs too when the clock resolution of one probe is 856 bigger than the minimum delay of a path. As an example this 857 happen when measuring the delay of a path which is 500 km long 858 with one probe synchronized using NTP having a clock resolution 859 of 8ms. 861 o The location of the point of interest in the device influences the 862 result. If the packet is not observed on the input interface the 863 delay includes buffering time and consequently an uncertainty due 864 to the difference between 'wire time' and 'host time'; 866 o dTk.b may be observed and not dTk.a. 868 o Tk is unknown if the flow is made of end user packets, that is 869 pure passive measure. In this case Tk may be forced to Tk+dTk.a. 870 This motivate separate metrics names for pure passive measurement 871 or specific reporting information. 873 o Pure passive measure should consider packets of the same size and 874 of the same Type-P. 876 5.2. A Definition of a sample of Packet Loss of a segment of the path 878 This metric defines a sample of Packet lost between a pair of hosts 879 of a path. 881 5.2.1. Metric Name 883 Type-P-segment-Packet-loss-Stream 885 5.2.2. Metric Parameters 887 + Src*, the IP address of the sender. 889 + Dst*, the IP address of the receiver. 891 + P*, the specification of the packet type. 893 + k, An integer which orders the packets sent. 895 + n, An integer which orders the hosts on the path. 897 + , hosts path digest. 899 + Ha, a host of the path digest different from Dst and Hb; 901 + Hb, a host of the path digest different from Src and Ha. 902 Hb order in the path must greater that Ha; 904 + Hi, exchange points of the path digest. 906 + a list of bits. 908 + a list of integers. 910 5.2.3. Metric Units 912 A sequence of integers 914 5.2.4. Definition 916 Given 2 hosts Ha and Hb of the path , given 917 a flow of packets of Type-P sent from Src to Dst at the times T1, 918 T2... Tn. At each of these times, we obtain a Type-P-Spatial- 919 Packet-Lost-Vector . We define the value of 920 the sample Type-P-segment-Packet-Lost-Stream between Ha and Hb as the 921 sequence made up of the integer such that for each 922 Tk: 924 o a value of Lk of 0 means that Bk.a has a value of 0 (observed) and 925 that Bk.b have a value of 0 (observed); 927 o a value of Lk of 1 means that Bk.a has a value of 0 (observed) and 928 that Bk.b have a value of 1 (not observed); 930 o a value of Lk of 2 means that Bk.a has a value of 1 (not observed) 931 and that Bk.b have a value of 0 (observed); 933 o a value of Lk of 3 means that Bk.a has a value of 1 (not observed) 934 and that Bk.b have a value of 1 (not observed). 936 5.2.5. Discussion 938 The semantic of a Type-P-segment-Packet-loss-Stream is similar to the 939 one of Type-P-Packet-loss-Stream: 941 o a value of 0 means that the packet was observed by Ha (similar to 942 'send by Src') and not observed by Hb ( similar to 'not received 943 by Dst'); 945 o a value of 1 means that it was observed by Ha (similar to 'send by 946 Src') and observed by Hb ( similar to 'received by Dst'). 948 This definition of Type-P-segment-Packet-loss-Stream is similar to 949 the Type-P-Packet-loss-Stream defined in [RFC2680] excepted that in a 950 Type-P-segment-Packet-loss-Stream the rules of the point of interests 951 Ha and Hb are symetrical: The asumption that a set of packets are 952 going from Ha to Hb does not apply to Type-P-segment-Packet-loss- 953 Stream because as the host path digest is dynamic each packet has its 954 own host path digest. 956 Making the asumption that the host path digest of a Type-P-spatial- 957 Packet-loss-vector does not change and that the set of (Hk, Hk+1) 958 tuples is mostly stable over time lead to unusable results and to the 959 introduction of mistakes in the metrics aggregation processes. The 960 right approach consists in carefully scrutening the path ordering 961 information to build sample with elements of vectors sharing the same 962 properties in term of Ha and Hb and 'Ha to Hb'. So a measure of 963 Type-P-spatial-Packet-loss-vector differs from a Type-P-Packet-loss 964 one in that it produces different samples of packet loss over time. 966 The semantic of a Type-P-segment-Packet-loss-Stream defines 2 new 967 results: 969 o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering 970 of Ha and Hb over the path coming either from the configuration 971 (asumption on the path) or from the processing of the vectors: bad 972 scrutening of the path ordering information, or some other mistake 973 in the measure or the reporting. It is not in the scope of this 974 document to go in further details which are mostly implementation 975 dependent. This value MUST not be used to compute packet lost 976 statistics. 978 o A value of Lk of 3 (1,1) corresponds to a lost of the packet in 979 upper segment of the path. 981 5.3. A Definition of a sample of One-way Ipdv of a segment of the path 983 This metric defines a sample of ipdv between a pair of hosts of a 984 path. 986 Editor note: work in progress 988 5.3.1. Metric Name 990 Type-P-Segment-Ipdv-Stream 992 5.3.2. Metric Parameters 994 5.3.3. Metric Units 996 5.3.4. Definition 998 5.3.5. Discussion 1000 5.4. Discussion on Passive Segment Metrics 1002 A pure passive spatial measure is the measure of a spatial metric 1003 based on the observation of user traffic instead of packets dedicated 1004 to the measure. 1006 This section discusses the applicability of pure passive measurement 1007 methodology (e.g. without injecting test traffic as described by 1008 PSAMP documents [draft-ietf-psamp-sample-tech-10.txt]) to measure 1009 spatial metrics. 1011 To permit comparison and discussion, we firstly define pure passive 1012 measurement methodology following the spirit of IPPM framework 1013 [RFC2330] and the methodology of [RFC2679]. Then we propose several 1014 passive metrics complying to this framework. 1016 5.4.1. A methodololy for passive segment metrics 1018 The following starts from the point that the time a packet is sent is 1019 not needed to measure the delay from one host Ha of the path to 1020 another host Hb. 1022 Generally, for the packets of Type-P and length L sent a time by the source Src pure passive methodology might proceed 1024 as follows: 1026 o Each point of interest Ha and Hb prepares to capture these 1027 packets; 1029 o Each point of interest Ha and Hb takes a timestamp Ti', determines 1030 the internal delay correction dTi' (See section 3.7.1. "Errors or 1031 uncertainties related to Clocks" of [RFC2679]), 1033 o Each points of interest Ha and Hb extracts the path ordering 1034 information from the packet (e.g. time-to-live) 1036 o Each points of interest Ha and Hb computes the wiretime fSrom Src 1037 to Hi: Ti = Ti' - dTi'. ; 1039 o The reference point gathers individual information for the packets 1040 sent a time from each point of interest Ha and Hb 1041 and proceeds as follow: 1043 * Orders them according to the path ordering information; 1045 * Extracts the timestamps Ti.a and Ti+1.b. This arrival time is 1046 undefined (infinite) if the packet is not detected; 1048 * Computes the one-way-delay from Ha to Hb as (Ti+1.b - Ti.a). 1049 The delay is undefined (infinite) if the packet is not detected 1050 in Ha or Hb; 1052 o The reference point builds the segment sample from Ha to Hb; 1055 5.4.2. Discussion on passive methodololy 1057 Intrinsically passive methodololy does not known (neither in the 1058 points of interest nor in the point of reference) the time each 1059 packet is sent and the time each packet it received. 1061 Section 5.4.1 shows that a passive segment one-way delay measure does 1062 not rely on the time T the packet is sent to compute the delay from a 1063 host Ha to a host Hb. 1065 Intuitively, packets loss measurement does not require any time 1066 information and only expects the packet was sent. Passive packet 1067 loss methodology relies on the detection of the packet by one point 1068 of interest and not by another. This relies on asumptions similar to 1069 spatial methodology: 1071 o The knowledge of the path and the order of the points of interest 1072 over the path; 1074 o The packet is observed by one point of interest and not by 1075 another; 1077 Nevertheless, passive packet loss measure is limited by the fact that 1078 information that neither a packet has be sent nor that the packet was 1079 received is never available: 1081 when the path changes and the packet is not observed it is not 1082 deterministic to state that the packet is lost because the measure 1083 does not known that the packet is received by Dst. 1085 when the measure does not observe any packets it is not possible 1086 to state that all packets are lost because the measure does not 1087 known that any packets were sent. 1089 The drawback is that monitoring finely these events is crucial for 1090 troubleshooting workflow. 1092 IPPM framework relies on the mesure of the behavior of packets of the 1093 same size. Consequently a passive metric sample MUST not mix 1094 information of packets of different sizes. 1096 Segment metrics may be measured using pure passive technics. Passive 1097 segment metrics definitions are very closed to spatial segment 1098 metrics definitions. Therefore below we just name passive segment 1099 metrics to distinguish the methodology used. Having distinct metrics 1100 identifiers for spatial metrics and passive spatial metrics in the 1101 [RFC4148] will avoid interoperability issues especially during 1102 composition of metrics the IPPM WG is currently defining. 1104 5.4.3. Passive Segment metrics 1106 5.4.3.1. Passive Segment One way Delay metric 1108 This metric definition is based on the top of the Type-P-spatial- 1109 segment-One-way-Delay-Stream metric definition. 1111 name: Type-P-Passive-Segment-One-way-Delay-Stream 1113 5.4.3.2. Passive Segment Packet Loss metric 1115 This metric definition is based on the top of the Type-P-spatial- 1116 segment-Packet-Loss-Stream metric definition. 1118 name: Type-P-Passive-Segment-Packet-Loss-Stream 1120 5.4.3.3. Passive Segment One-way Ipdv metric 1122 This metric definition is based on the top of the Type-P-Segment- 1123 Ipdv-Stream metric definition. 1125 name: Type-P-Passive-Segment-One-way-Ipdv-Stream 1127 6. One-to-group metrics definitions 1129 6.1. A Definition for one-to-group One-way Delay 1131 6.1.1. Metric Name 1133 Type-P-one-to-group-One-way-Delay-Vector 1135 6.1.2. Metric Parameters 1137 o Src, the IP address of a host acting as the source. 1139 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1140 receivers. 1142 o T, a time. 1144 o dT1,...,dTn a list of time. 1146 o P, the specification of the packet type. 1148 o Gr, the multicast group address (optional). The parameter Gr is 1149 the multicast group address if the measured packets are 1150 transmitted by multicast. This parameter is to identify the 1151 measured traffic from other unicast and multicast traffic. It is 1152 set to be optional in the metric to avoid losing any generality, 1153 i.e. to make the metric also applicable to unicast measurement 1154 where there is only one receivers. 1156 6.1.3. Metric Units 1158 The value of a Type-P-one-to-group-One-way-Delay-Vector is a set of 1159 singletons metrics Type-P-One-way-Delay [RFC2679]. 1161 6.1.4. Definition 1163 Given a Type P packet sent by the source Src at Time T, given the N 1164 hosts { Recv1,...,RecvN } which receive the packet at the time { 1165 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is 1166 defined as the set of the Type-P-One-way-Delay singleton between Src 1167 and each receiver with value of { dT1, dT2,...,dTn }. 1169 6.2. A Definition for one-to-group One-way Packet Loss 1171 6.2.1. Metric Name 1173 Type-P-one-to-group-One-way-Packet-Loss-Vector 1175 6.2.2. Metric Parameters 1177 o Src, the IP address of a host acting as the source. 1179 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1180 receivers. 1182 o T, a time. 1184 o T1,...,Tn a list of time. 1186 o P, the specification of the packet type. 1188 o Gr, the multicast group address (optional). 1190 6.2.3. Metric Units 1192 The value of a Type-P-one-to-group-One-way-Packet-Loss-Vector is a 1193 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 1195 6.2.4. Definition 1197 Given a Type P packet sent by the source Src at T and the N hosts, 1198 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 1199 Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of 1200 the Type-P-One-way-Packet-Loss singleton between Src and each of the 1201 receivers {,,..., }. 1203 6.3. A Definition for one-to-group One-way Ipdv 1205 6.3.1. Metric Name 1207 Type-P-One-to-group-One-way-ipdv-Vector 1209 6.3.2. Metric Parameters 1211 + Src, the IP address of a host acting as the source. 1213 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 1214 receivers. 1216 + T1, a time. 1218 + T2, a time. 1220 + ddT1,...,ddTn, a list of time. 1222 + P, the specification of the packet type. 1224 + F, a selection function defining unambiguously the two 1225 packets from the stream selected for the metric. 1227 + Gr, the multicast group address (optional) 1229 6.3.3. Metric Units 1231 The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of 1232 singletons metrics Type-P-One-way-ipdv [RFC3393]. 1234 6.3.4. Definition 1236 Given a Type P packet stream, Type-P-one-to-group-One-way-ipdv-Vector 1237 is defined for two packets from the source Src to the N hosts 1238 {Recv1,...,RecvN },which are selected by the selection function F, as 1239 the difference between the value of the Type-P-one-to-group-One-way- 1240 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1241 value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { 1242 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1243 the first bit of the first packet, and T2 is the wire-time at which 1244 Src sent the first bit of the second packet. This metric is derived 1245 from the Type-P-one-to- group-One-way-Delay-Vector metric. 1247 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 1248 group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 1249 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1250 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1251 and the packets were received by { Recv1,...,RecvN } at wire-time 1252 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1253 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1254 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1256 7. One-to-Group Sample Statistics 1258 The defined one-to-group metrics above can all be directly achieved 1259 from the relevant unicast one-way metrics. They managed to collect 1260 all unicast measurement results of one-way metrics together in one 1261 profile and sort them by receivers and packets in a multicast group. 1262 They can provide sufficient information regarding the network 1263 performance in terms of each receiver and guide engineers to identify 1264 potential problem happened on each branch of a multicast routing 1265 tree. However, these metrics can not be directly used to 1266 conveniently present the performance in terms of a group and neither 1267 to identify the relative performance situation. 1269 From the performance point of view, the multiparty communication 1270 services not only require the absolute performance support but also 1271 the relative performance. The relative performance means the 1272 difference between absolute performance of all users. Directly using 1273 the one-way metrics cannot present the relative performance 1274 situation. However, if we use the variations of all users one-way 1275 parameters, we can have new metrics to measure the difference of the 1276 absolute performance and hence provide the threshold value of 1277 relative performance that a multiparty service might demand. A very 1278 good example of the high relative performance requirement is the 1279 online gaming. A very light difference in delay might result in 1280 failure in the game. We have to use multicast specific statistic 1281 metrics to define exactly how small the relative delay the online 1282 gaming requires. There are many other services, e.g. online biding, 1283 online stock market, etc., that require multicast metrics in order to 1284 evaluate the network against their requirements. Therefore, we can 1285 see the importance of new, multicast specific, statistic metrics to 1286 feed this need. 1288 We might also use some one-to-group statistic conceptions to present 1289 and report the group performance and relative performance to save the 1290 report transmission bandwidth. Statistics have been defined for One- 1291 way metrics in corresponding RFCs. They provide the foundation of 1292 definition for performance statistics. For instance, there are 1293 definitions for minimum and maximum One-way delay in [RFC2679]. 1294 However, there is a dramatic difference between the statistics for 1295 one-to-one communications and for one-to-many communications. The 1296 former one only has statistics over the time dimension while the 1297 later one can have statistics over both time and space dimensions. 1298 This space dimension is introduced by the Matrix concept as 1299 illustrated in Figure 9. For a Matrix M each row is a set of One-way 1300 singletons spreading over the time dimension and each column is 1301 another set of One-way singletons spreading over the space dimension. 1303 Receivers 1304 Space 1305 ^ 1306 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1307 | | | 1308 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1309 | | | 1310 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1311 . | | | 1312 . | | | 1313 . | | | 1314 n | \ RndT1 RndT2 RndT3 ... RndTk / 1315 +--------------------------------------------> time 1316 T0 1318 Figure 9: Matrix M (n*m) 1320 In Matrix M, each element is a One-way delay singleton. Each column 1321 is a delay vector contains the One-way delays of the same packet 1322 observed at M points of interest. It implies the geographical factor 1323 of the performance within a group. Each row is a set of One-way 1324 delays observed during a sampling interval at one of the points of 1325 interest. It presents the delay performance at a receiver over the 1326 time dimension. 1328 Therefore, one can either calculate statistics by rows over the space 1329 dimension or by columns over the time dimension. It's up to the 1330 operators or service provides which dimension they are interested in. 1331 For example, a TV broadcast service provider might want to know the 1332 statistical performance of each user in a long term run to make sure 1333 their services are acceptable and stable. While for an online gaming 1334 service provider, he might be more interested to know if all users 1335 are served fairly by calculating the statistics over the space 1336 dimension. This memo does not intend to recommend which of the 1337 statistics are better than the other. 1339 To save the report transmission bandwidth, each point of interest can 1340 send statistics in a pre-defined time interval to the reference point 1341 rather than sending every One-way singleton it observed. As long as 1342 an appropriate time interval is decided, appropriate statistics can 1343 represent the performance in a certain accurate scale. How to decide 1344 the time interval and how to bootstrap all points of interest and the 1345 reference point depend on applications. For instance, applications 1346 with lower transmission rate can have the time interval longer and 1347 ones with higher transmission rate can have the time interval 1348 shorter. However, this is out of the scope of this memo. 1350 Moreover, after knowing the statistics over the time dimension, one 1351 might want to know how this statistics distributed over the space 1352 dimension. For instance, a TV broadcast service provider had the 1353 performance Matrix M and calculated the One-way delay mean over the 1354 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1355 calculated the mean of all the elements in the Vector to see what 1356 level of delay he has served to all N users. This new delay mean 1357 gives information on how good the service has been delivered to a 1358 group of users during a sampling interval in terms of delay. It 1359 needs twice calculation to have this statistic over both time and 1360 space dimensions. We name this kind of statistics 2-level statistics 1361 to distinct with those 1-level statistics calculated over either 1362 space or time dimension. It can be easily prove that no matter over 1363 which dimension a 2-level statistic is calculated first, the results 1364 are the same. I.e. one can calculate the 2-level delay mean using 1365 the Matrix M by having the 1-level delay mean over the time dimension 1366 first and then calculate the mean of the obtained vector to find out 1367 the 2-level delay mean. Or, he can do the 1-level statistic 1368 calculation over the space dimension first and then have the 2-level 1369 delay mean. Both two results will be exactly the same. Therefore, 1370 when define a 2-level statistic, there is no need to specify in which 1371 procedure the calculation should follow. 1373 Comment: The above statement depends on whether the order of 1374 operations has any affect on the outcome. 1376 Many statistics can be defined for the proposed one-to-group metrics 1377 over either the space dimension or the time dimension or both. This 1378 memo treats the case where a stream of packets from the Source 1379 results in a sample at each of the Receivers in the Group, and these 1380 samples are each summarized with the usual statistics employed in 1381 one-to-one communication. New statistic definitions are presented, 1382 which summarize the one-to-one statistics over all the Receivers in 1383 the Group. 1385 7.1. Discussion on the Impact of packet loss on statistics 1387 The packet loss does have effects on one-way metrics and their 1388 statistics. For example, the lost packet can result an infinite one- 1389 way delay. It is easy to handle the problem by simply ignoring the 1390 infinite value in the metrics and in the calculation of the 1391 corresponding statistics. However, the packet loss has so strong 1392 impact on the statistics calculation for the one-to-group metrics 1393 that it can not be solved by the same method used for one-way 1394 metrics. This is due to the complex of building a Matrix, which is 1395 needed for calculation of the statistics proposed in this memo. 1397 The situation is that measurement results obtained by different end 1398 users might have different packet loss pattern. For example, for 1399 User1, packet A was observed lost. And for User2, packet A was 1400 successfully received but packet B was lost. If the method to 1401 overcome the packet loss for one-way metrics is applied, the two 1402 singleton sets reported by User1 and User2 will be different in terms 1403 of the transmitted packets. Moreover, if User1 and User2 have 1404 different number of lost packets, the size of the results will be 1405 different. Therefore, for the centralized calculation, the reference 1406 point will not be able to use these two results to build up the group 1407 Matrix and can not calculate the statistics. In an extreme 1408 situation, no single packet arrives all users in the measurement and 1409 the Matrix will be empty. One of the possible solutions is to 1410 replace the infinite/undefined delay value by the average of the two 1411 adjacent values. For example, if the result reported by user1 is { 1412 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1413 is an undefined value, the reference point can replace it by R1dTK = 1414 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1415 build up the group Matrix with an estimated value R1dTK. There are 1416 other possible solutions such as using the overall mean of the whole 1417 result to replace the infinite/undefined value, and so on. It is out 1418 of the scope of this memo. 1420 For the distributed calculation, the reported statistics might have 1421 different "weight" to present the group performance, which is 1422 especially true for delay and ipdv relevant metrics. For example, 1423 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1424 in Figure. 8 without any packet loss and User2 calculates the R2DM 1425 with N-2 packet loss. The R1DM and R2DM should not be treated with 1426 equal weight because R2DM was calculated only based on 2 delay values 1427 in the whole sample interval. One possible solution is to use a 1428 weight factor to mark every statistic value sent by users and use 1429 this factor for further statistic calculation. 1431 7.2. General Metric Parameters 1433 o Src, the IP address of a host 1435 o G, the Group IP address 1437 o N, the number of Receivers (Recv1, Recv2, ... RecvN) 1439 o T, a time (start of test interval) 1441 o Tf, a time (end of test interval) 1443 o K, the number of packets sent from the source during the test 1444 interval 1446 o J[n], the number of packets received at a particular Receiver, n, 1447 where 1<=n<=N 1449 o lambda, a rate in reciprocal seconds (for Poisson Streams) 1451 o incT, the nominal duration of inter-packet interval, first bit to 1452 first bit (for Periodic Streams) 1454 o T0, a time that MUST be selected at random from the interval [T, 1455 T+I] to start generating packets and taking measurements (for 1456 Periodic Streams) 1458 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1459 Source Measurement Point) 1461 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1462 assigned to packets that arrive within a "reasonable" time 1464 o Tmax, a maximum waiting time for packets at the destination, set 1465 sufficiently long to disambiguate packets with long delays from 1466 packets that are discarded (lost), thus the distribution of delay 1467 is not truncated 1469 o dT, shorthand notation for a one-way delay singleton value 1471 o L, shorthand notation for a one-way loss singleton value, either 1472 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1473 the destination within TstampSrc + Tmax, may be indexed over n 1474 Receivers 1476 o DV, shorthand notation for a one-way delay variation singleton 1477 value 1479 7.3. One-to-Group one-way Delay Statistics 1481 This section defines the overall one-way delay statistics for an 1482 entire Group or receivers. For example, we can define the group mean 1483 delay, as illustrated below. This is a metric designed to summarize 1484 the whole matrix. 1486 Recv /----------- Sample -------------\ Stats Group Stat 1488 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1489 | 1490 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 1491 | 1492 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD 1493 . | 1494 . | 1495 . | 1496 n RndT1 RndT2 RndT3 ... RndTk RnDM / 1498 Figure 10: One-to-GroupGroup Mean Delay 1500 where: 1502 R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at 1503 Receiver 1 for packet 1. 1505 R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 1506 for the sample of packets (1,...K). 1508 GMD is the mean of the sample means over all Receivers (1, ...N). 1510 7.3.1. Definition and Metric Units 1512 Using the parameters above, we obtain the value of Type-P-One-way- 1513 Delay singleton for all packets sent during the test interval at each 1514 Receiver (Destination), as per [RFC2679]. For each packet that 1515 arrives within Tmax of its sending time, TstampSrc, the one-way delay 1516 singleton (dT) will be a finite value in units of seconds. 1517 Otherwise, the value of the singleton is Undefined. 1519 For each packet [i] that has a finite One-way Delay at Receiver n (in 1520 other words, excluding packets which have undefined one-way delay): 1522 Type-P-Finite-One-way-Delay-Receiver-n-[i] = 1524 = TstampRecv[i] - TstampSrc[i] 1526 The units of Finite one-way delay are seconds, with sufficient 1527 resolution to convey 3 significant digits. 1529 7.3.2. Sample Mean Statistic 1531 This section defines the Sample Mean at each of N Receivers. 1533 Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = 1534 J[n] 1535 --- 1536 1 \ 1537 --- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] 1538 J[n] / 1539 --- 1540 i = 1 1542 Figure 11: Type-P-Finite-One-way-Delay-Mean-Receiver-n 1544 where all packets i= 1 through J[n] have finite singleton delays. 1546 7.3.3. One-to-Group Mean Delay Statistic 1548 This section defines the Mean One-way Delay calculated over the 1549 entire Group (or Matrix). 1551 Type-P-One-to-Group-Mean-Delay = GMD = 1552 N 1553 --- 1554 1 \ 1555 - * > RnDM 1556 N / 1557 --- 1558 n = 1 1560 Figure 12: Type-P-One-to-Group-Mean-Delay 1562 Note that the Group Mean Delay can also be calculated by summing the 1563 Finite one-way Delay singletons in the Matrix, and dividing by the 1564 number of Finite One-way Delay singletons. 1566 7.3.4. One-to-Group Range of Mean Delays 1568 This section defines a metric for the range of mean delays over all N 1569 receivers in the Group, (R1DM, R2DM,...RnDM). 1571 Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1573 7.3.5. One-to-Group Maximum of Mean Delays 1575 This section defines a metrics for the maximum of mean delays over 1576 all N receivers in the Group, (R1DM, R2DM,...RnDM). 1578 Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) 1580 7.4. One-to-Group one-way Loss Statistics 1582 This section defines the overall 1-way loss statistics for an entire 1583 Group. For example, we can define the group loss ratio, as 1584 illustrated below. This is a metric designed to summarize the entire 1585 Matrix. 1587 Recv /----------- Sample ----------\ Stats Group Stat 1589 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1590 | 1591 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1592 | 1593 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR 1594 . | 1595 . | 1596 . | 1597 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1599 Figure 13: One-to-Group Loss Ratio 1601 where: 1603 R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 1604 for packet 1. 1606 R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the 1607 sample of packets (1,...K). 1609 GLR is the loss ratio over all Receivers (1, ..., N). 1611 7.4.1. One-to-Group Loss Ratio 1613 The overall Group loss ratio id defined as 1615 Type-P-One-to-Group-Loss-Ratio = 1616 K,N 1617 --- 1618 1 \ 1619 = --- * > L(k,n) 1620 K*N / 1621 --- 1622 k,n = 1 1624 Figure 14 1626 ALL Loss ratios are expressed in units of packets lost to total 1627 packets sent. 1629 7.4.2. One-to-Group Loss Ratio Range 1631 Given a Matrix of loss singletons as illustrated above, determine the 1632 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1633 according to the definitions and method of [RFC2680]. The Type-P- 1634 One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- 1635 way-Loss-Ratio illustrated above are equivalent metrics. In terms of 1636 the parameters used here, these metrics definitions can be expressed 1637 as 1639 Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = 1640 K 1641 --- 1642 1 \ 1643 - * > RnLk 1644 K / 1645 --- 1646 k = 1 1648 Figure 15: Type-P-One-way-Loss-Ratio-Receiver-n 1650 The One-to-Group Loss Ratio Range is defined as 1652 Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) 1654 It is most effective to indicate the range by giving both the max and 1655 minimum loss ratios for the Group, rather than only reporting the 1656 difference between them. 1658 7.4.3. Comparative Loss Ratio 1660 Usually, the number of packets sent is used in the denominator of 1661 packet loss ratio metrics. For the comparative metrics defined here, 1662 the denominator is the maximum number of packets received at any 1663 receiver for the sample and test interval of interest. 1665 The Comparative Loss Ratio is defined as 1667 Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = 1668 K 1669 --- 1670 \ 1671 > Ln(k) 1672 / 1673 --- 1674 k=1 1675 = ----------------------------- 1676 / K \ 1677 | --- | 1678 | \ | 1679 K - Min | > Ln(k) | 1680 | / | 1681 | --- | 1682 \ k=1 / N 1684 Figure 16: Type-P-Comp-Loss-Ratio-Receiver-n 1686 7.5. One-to-Group one-way Delay Variation Statistics 1688 There are two delay variation (DV) statistics that summarize the 1689 performance over the Group: the maximum DV over all receivers and the 1690 minimum DV over all receivers (where DV is a point-to-point metric). 1691 For each receiver, the DV is usually expressed as the 1-10^(-3) 1692 quantile of one-way delay minus the minimum one-way delay. 1694 8. Measurement Methods: Scaleability and Reporting 1696 Virtually all the guidance on measurement processes supplied by the 1697 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1698 scenarios is applicable here in the spatial and multiparty 1699 measurement scenario. The main difference is that the spatial and 1700 multiparty configurations require multiple measurement points where a 1701 stream of singletons will be collected. The amount of information 1702 requiring storage grows with both the number of metrics and the 1703 number of measurement points, so the scale of the measurement 1704 architecture multiplies the number of singleton results that must be 1705 collected and processed. 1707 It is possible that the architecture for results collection involves 1708 a single aggregation point with connectivity to all the measurement 1709 points. In this case, the number of measurement points determines 1710 both storage capacity and packet transfer capacity of the host acting 1711 as the aggregation point. However, both the storage and transfer 1712 capacity can be reduced if the measurement points are capable of 1713 computing the summary statistics that describe each measurement 1714 interval. This is consistent with many operational monitoring 1715 architectures today, where even the individual singletons may not be 1716 stored at each measurement point. 1718 In recognition of the likely need to minimize form of the results for 1719 storage and communication, the Group metrics above have been 1720 constructed to allow some computations on a per-Receiver basis. This 1721 means that each Receiver's statistics would normally have an equal 1722 weight with all other Receivers in the Group (regardless of the 1723 number of packets received). 1725 8.1. Computation methods 1727 The scalability issue can be raised when there are thousands of 1728 points of interest in a group who are trying to send back the 1729 measurement results to the reference point for further processing and 1730 analysis. The points of interest can send either the whole measured 1731 sample or only the calculated statistics. The former one is a 1732 centralized statistic calculation method and the latter one is a 1733 distributed statistic calculation method. The sample should include 1734 all metrics parameters, the values and the corresponding sequence 1735 numbers. The transmission of the whole sample can cost much more 1736 bandwidth than the transmission of the statistics that should include 1737 all statistic parameters specified by policies and the additional 1738 information about the whole sample, such as the size of the sample, 1739 the group address, the address of the point of interest, the ID of 1740 the sample session, and so on. Apparently, the centralized 1741 calculation method can require much more bandwidth than the 1742 distributed calculation method when the sample size is big. This is 1743 especially true when the measurement has huge number of the points of 1744 interest. It can lead to a scalability issue at the reference point 1745 by over load the network resources. The distributed calculation 1746 method can save much more bandwidth and release the pressure of the 1747 scalability issue at the reference point side. However, it can 1748 result in the lack of information because not all measured singletons 1749 are obtained for building up the group matrix. The performance over 1750 time can be hidden from the analysis. For example, the loss pattern 1751 can be missed by simply accepting the loss ratio as well as the delay 1752 pattern. This tradeoff between the bandwidth consuming and the 1753 information acquiring has to be taken into account when design the 1754 measurement campaign to optimize the measurement results delivery. 1755 The possible solution could be to transit the statistic parameters to 1756 the reference point first to obtain the general information of the 1757 group performance. If the detail results are required, the reference 1758 point should send the requests to the points of interest, which could 1759 be particular ones or the whole group. This procedure can happen in 1760 the off peak time and can be well scheduled to avoid delivery of too 1761 many points of interest at the same time. Compression techniques can 1762 also be used to minimize the bandwidth required by the transmission. 1763 This could be a measurement protocol to report the measurement 1764 results. It is out of the scope of this memo. 1766 8.2. Measurement 1768 To prevent any bias in the result, the configuration of a one-to-many 1769 measure must take in consideration that implicitly more packets will 1770 to be routed than send and selects a test packets rate that will not 1771 impact the network performance. 1773 8.3. Effect of Time and Space Aggregation Order on Stats 1775 This section presents the impact of the aggregation order on the 1776 scalability of the reporting and of the computation. It makes the 1777 hypothesis that receivers are managed remotely and not co-located. 1779 multimetrics samples represented a matrix as illustrated below 1781 Point of 1782 interest 1783 1 R1S1 R1S1 R1S1 ... R1Sk \ 1784 | 1785 2 R2S1 R2S2 R2S3 ... R2Sk | 1786 | 1787 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1788 . | 1789 . | 1790 . | 1791 n RnS1 RnS2 RnS3 ... RnSk / 1793 S1M S2M S3M ... SnM Stats over space 1795 \------------- ------------/ 1796 \/ 1797 Stat over space and time 1799 Figure 17: Impact of space aggregation on multimetrics Stat 1801 2 methods are available to compute statistics on the resulting 1802 matrix: 1804 o metric is computed over time and then over space; 1805 o metric is computed over space and then over time. 1807 They differ only by the order of the time and of the space 1808 aggregation. View as a matrix this order is neutral as does not 1809 impact the result, but the impact on a measurement deployment is 1810 critical. 1812 In both cases the volume of data to report is proportional to the 1813 number of probes. But there is a major difference between these 2 1814 methods: 1816 method2: In space and time aggregation mode the volume of data to 1817 collect is proportional to the number of test packets received; 1818 Each received packet RiSi triggers out a block of data that must 1819 be reported to a common place for computing the stat over space; 1821 method1: In time and space aggregation mode the volume of data to 1822 collect is proportional to the period of aggregation, so it does 1823 not depend on the number of packet received; 1825 Method 2 property has severe drawbacks in terms of security and 1826 dimensioning: 1828 The increasing of the rate of the test packets may result in a 1829 sort of DoS toward the computation points; 1831 The dimensioning of a measurement system is quite impossible to 1832 validate. 1834 The time aggregation interval provides the reporting side with a 1835 control of various collecting aspects such as bandwidth and 1836 computation and storage capacities. So this draft defines metrics 1837 based on method 1. 1839 Note: In some specific cases one may need sample of singletons over 1840 space. To address this need it is suggested firstly to limit the 1841 number of test and the number of test packets per seconds. Then 1842 reducing the size of the sample over time to one packet give sample 1843 of singleton over space.. 1845 8.3.1. Impact on group stats 1847 2 methods are available to compute group statistics: 1849 o method1: Figure 10 andFigure 13 illustrate the method chosen: the 1850 one-to-one statistic is computed per interval of time before the 1851 computation of the mean over the group of receivers; 1853 o method2: Figure 17 presents the second one, metric is computed 1854 over space and then over time. 1856 8.3.2. Impact on spatial stats 1858 2 methods are available to compute group statistics: 1860 o method 1: spatial segment metrics and statistics are preferably 1861 computed over time by each points of interest; 1863 o method 2: Vectors metrics are intrinsecally instantaneous space 1864 metrics which must be reported using method2 whenever 1865 instantaneous metrics information is needed. Pure passive 1866 measurement approach has no choice but to use this method because 1867 delay and losses may not be computed in each point of interest. 1869 9. Manageability Considerations 1871 Usually IPPM WG documents defines each metric reporting within its 1872 definition. This document defines the reporting of all the metrics 1873 introduced in a single section to provide consistent information 1874 while avoiding repetitions. the aim is to contribute to the work of 1875 the WG on the reporting and to satisfy IESG recommendation of 1876 gathering manageability considerations in a dedicated section. 1878 Data models of spatial and one-to-group metrics are similar excepted 1879 that points of interests of spatial vectors must be ordered. 1881 The complexity of the reporting relies on the number of points of 1882 interests. 1884 9.1. Reporting spatial metric 1886 The reporting of spatial metrics shares a lot of aspects with 1887 RFC2679-80. New ones are common to all the definitions and are 1888 mostly related to the reporting of the path and of methodology 1889 parameters that may bias raw results analysis. This section presents 1890 these specific parameters and then lists exhaustively the parameters 1891 that shall be reported. 1893 9.1.1. Path 1895 End-to-end metrics can't determine the path of the measure despite 1896 IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]). 1897 Spatial metrics vectors provide this path. The report of a spatial 1898 vector must include the points of interests involved: the sub set of 1899 the hosts of the path participating to the instantaneous measure. 1901 9.1.2. Host order 1903 A spatial vector must order the points of interest according to their 1904 order in the path. It is highly suggested to use the TTL in IPv4, 1905 the Hop Limit in IPv6 or the corresponding information in MPLS. 1907 The report of a spatial vector must include the ordered list of the 1908 hosts involved in the instantaneous measure. 1910 9.1.3. Timestamping bias 1912 The location of the point of interest inside a node influences the 1913 timestamping skew and accuracy. As an example, consider that some 1914 internal machinery delays the timestamping up to 3 milliseconds then 1915 the minimal uncertainty reported be 3 ms if the internal delay is 1916 unknown at the time of the timestamping. 1918 The report of a spatial vector must include the uncertainty of the 1919 timestamping compared to wire time. 1921 9.1.4. Reporting spatial One-way Delay 1923 The reporting includes information to report for one-way-delay as 1924 perthe Section 3.6 of [RFC2679].the same apply for packet loss and 1925 ipdv 1927 9.2. Reporting One-to-group metric 1929 9.3. Metric identification 1931 IANA assigns each metric defined by the IPPM WG with a unique 1932 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1934 To avoid misunderstanding and to address specific reporting 1935 constraints, section Section 5.4.3 of this memo gives distinct names 1936 to passive metrics and Section 13 requests a distinct metric 1937 identifier for each metrics the memo defines. 1939 As it is crucial for composition of metrics to know the methodology 1940 used (e.g. generation method, detection method...), the report of a 1941 metric result used in composition of metrics MUST alway include its 1942 metric identifier. 1944 9.4. Reporting data model 1946 This section presents the elements of the datamodel and the usage of 1947 the information reported for real network performance analysis. It 1948 is out of the scope of this section to define how the information is 1949 reported. 1951 The data model is build with pieces of information introduced and 1952 explained in one-way delay definitions [RFC2679], in packet loss 1953 definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It 1954 includes not only information given by "Reporting the metric" 1955 sections but by sections "Methodology" and "Errors and Uncertainties" 1956 sections. 1958 Following are the elements of the datamodel taken from end-to-end 1959 definitions referred in this memo and from spatial and multicast 1960 metrics it defines: 1962 o Packet_type, The Type-P of test packets (Type-P); 1964 o Packet_length, a packet length in bits (L); 1966 o Src_host, the IP address of the sender; 1968 o Dst_host, the IP address of the receiver; 1970 o Hosts_serie: , a list of points of interest; 1972 o Loss_threshold: The threshold of infinite delay; 1974 o Systematic_error: constant delay between wire time and 1975 timestamping; 1977 o Calibration_error: maximal uncertainty; 1979 o Src_time, the sending time for a measured packet; 1981 o Dst_time, the receiving time for a measured packet; 1983 o Result_status : an indicator of usability of a result 'Resource 1984 exhaustion' 'infinite', 'lost'; 1986 o Delays_serie: a list of delays; 1988 o Losses_serie: , a list of Boolean values 1989 (spatial) or a set of Boolean values (one-to-group); 1991 o Result_status_serie: a list of results status; 1993 o dT: a delay; 1995 o Singleton_number: a number of singletons; 1996 o Observation_duration: An observation duration; 1998 o metric_identifier. 2000 Following is the information of each vector that should be available 2001 to compute samples: 2003 o Packet_type; 2005 o Packet_length; 2007 o Src_host, the sender of the packet; 2009 o Dst_host, the receiver of the packet, apply only for spatial 2010 vectors; 2012 o Hosts_serie: not ordered for one-to-group; 2014 o Src_time, the sending time for the measured packet; 2016 o dT, the end-to-end one-way delay for the measured packet, apply 2017 only for spatial vectors; 2019 o Delays_serie: apply only for delays and ipdv vector, not ordered 2020 for one-to-group; 2022 o Losses_serie: apply only for packets loss vector, not ordered for 2023 one-to-group; 2025 o Result_status_serie; 2027 o Observation_duration: the difference between the time of the last 2028 singleton and the time of the first singleton. 2030 o Following is the context information (measure, points of 2031 interests) that should be available to compute samples : 2033 * Loss threshold; 2035 * Systematic error: constant delay between wire time and 2036 timestamping; 2038 * Calibration error: maximal uncertainty; 2040 A spatial or a one-to-group sample is a collection of singletons 2041 giving the performance from the sender to a single point of interest. 2042 Following is the information that should be available for each sample 2043 to compute statistics: 2045 o Packet_type; 2047 o Packet_length; 2049 o Src_host, the sender of the packet; 2051 o Dst_host, the receiver of the packet; 2053 o Start_time, the sending time of the first packet; 2055 o Delays_serie: apply only for delays and ipdv samples; 2057 o Losses_serie: apply only for packets loss samples; 2059 o Result_status_serie; 2061 o Observation_duration: the difference between the time of the last 2062 singleton of the last sample and the time of the first singleton 2063 of the first sample. 2065 o Following is the context information (measure, points of 2066 interests) that should be available to compute statistics : 2068 * Loss threshold; 2070 * Systematic error: constant delay between wire time and 2071 timestamping; 2073 * Calibration error: maximal uncertainty; 2075 Following is the information of each statistic that should be 2076 reported: 2078 o Result; 2080 o Start_time; 2082 o Duration; 2084 o Result_status; 2086 o Singleton_number, the number of singletons the statistic is 2087 computed on; 2089 10. Open issues 2091 Do we define min, max, avg of for each segment metrics ? 2093 having the maximum loss metric value could be interesting. Say, 2094 the segment between router A and B always contributes loss metric 2095 value of "1" means it could be the potential problem segment. 2097 Uploading dTi of each Hi consume a lot of bandwidth. Computing 2098 statistics (min, max and avg) of dTi locally in each Hi reduce the 2099 bandwidth consumption. 2101 11. Security Considerations 2103 Spatial and one-to-group metrics are defined on the top of end-to-end 2104 metrics. Security considerations discussed in One-way delay metrics 2105 definitions of [RFC2679] , in packet loss metrics definitions 2106 of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 2107 apply to multimetrics. 2109 11.1. Spatial metrics 2111 Malicious generation of packets with spoofing addresses may corrupt 2112 the results without any possibility to detect the spoofing. 2114 Malicious generation of packets which match systematically the hash 2115 function used to detect the packets may lead to a DoS attack toward 2116 the point of reference. 2118 11.2. one-to-group metric 2120 The reporting of measurement results from a huge number of probes may 2121 overload the network the reference point is attach to, the reference 2122 point network interfaces and the reference point computation 2123 capacities. 2125 The configuration of a measure must take in consideration that 2126 implicitly more packets will to be routed than send and selects a 2127 test packets rate accordingly. Collecting statistics from a huge 2128 number of probes may overload any combination of the network where 2129 the measurement controller is attach to, measurement controller 2130 network interfaces and measurement controller computation capacities. 2132 one-to-group metrics measurement should consider using source 2133 authentication protocols, standardized in the MSEC group, to avoid 2134 fraud packet in the sampling interval. The test packet rate could be 2135 negotiated before any measurement session to avoid deny of service 2136 attacks. 2138 12. Acknowledgments 2140 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2141 of Surrey, for his instruction and helpful comments on this work. 2143 13. IANA Considerations 2145 Metrics defined in this memo Metrics defined in this memo are 2146 designed to be registered in the IANA IPPM METRICS REGISTRY as 2147 described in initial version of the registry [RFC4148] : 2149 IANA is asked to register the following metrics in the IANA-IPPM- 2150 METRICS-REGISTRY-MIB : 2152 Spatial-One-way-Delay-Vector OBJECT-IDENTITY 2154 STATUS current 2156 DESCRIPTION 2158 "Type-P-Spatial-One-way-Delay-Vector" 2160 REFERENCE 2162 "Reference "RFCyyyy, section 4.1." 2164 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2165 note 2167 := { ianaIppmMetrics nn } -- IANA assigns nn 2169 Spatial-Packet-Loss-Vector OBJECT-IDENTITY 2171 STATUS current 2173 DESCRIPTION 2175 "Type-P-Spatial-Packet-Loss-Vector" 2177 REFERENCE 2178 "Reference "RFCyyyy, section 4.2." 2180 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2181 note 2183 := { ianaIppmMetrics nn } -- IANA assigns nn 2185 Spatial-One-way-ipdv-Vector OBJECT-IDENTITY 2187 STATUS current 2189 DESCRIPTION 2191 "Type-P-Spatial-One-way-ipdv-Vector" 2193 REFERENCE 2195 "Reference "RFCyyyy, section 4.3." 2197 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2198 note 2200 := { ianaIppmMetrics nn } -- IANA assigns nn 2202 Spatial-Segment-One-way-Delay-Stream OBJECT-IDENTITY 2204 STATUS current 2206 DESCRIPTION 2208 "Type-P-Spatial-Segment-One-way-Delay-Stream" 2210 REFERENCE 2212 "Reference "RFCyyyy, section 5.1." 2214 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2215 note 2217 := { ianaIppmMetrics nn } -- IANA assigns nn 2219 Spatial-Segment-Packet-Loss-Stream OBJECT-IDENTITY 2221 STATUS current 2223 DESCRIPTION 2224 "Type-P-Spatial-Segment-Packet-Loss-Stream" 2226 REFERENCE 2228 "Reference "RFCyyyy, section 5.2." 2230 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2231 note 2233 := { ianaIppmMetrics nn } -- IANA assigns nn 2235 Spatial-Segment-One-way-ipdv-Stream OBJECT-IDENTITY 2237 STATUS current 2239 DESCRIPTION 2241 "Type-P-Spatial-Segment-ipdv-Stream" 2243 REFERENCE 2245 "Reference "RFCyyyy, section 5.3." 2247 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2248 note 2250 := { ianaIppmMetrics nn } -- IANA assigns nn 2252 Passive-Segment-One-way-Delay-Stream OBJECT-IDENTITY 2254 STATUS current 2256 DESCRIPTION 2258 "Type-P-Passive-Segment-One-way-Delay-Stream" 2260 REFERENCE 2262 "Reference "RFCyyyy, section 5.4.1." 2264 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2265 note 2267 := { ianaIppmMetrics nn } -- IANA assigns nn 2269 Passive-Segment-Packet-Loss-Stream OBJECT-IDENTITY 2270 STATUS current 2272 DESCRIPTION 2274 "Type-P-Passive-Segment-Packet-Loss-Stream" 2276 REFERENCE 2278 "Reference "RFCyyyy, section 5.4.2." 2280 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2281 note 2283 := { ianaIppmMetrics nn } -- IANA assigns nn 2285 Passive-Segment-One-way-ipdv-Stream OBJECT-IDENTITY 2287 STATUS current 2289 DESCRIPTION 2291 "Type-P-Passive-Segment-One-way-ipdv-Stream" 2293 REFERENCE 2295 "Reference "RFCyyyy, section 5.4.3." 2297 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2298 note 2300 := { ianaIppmMetrics nn } -- IANA assigns nn 2302 -- One-to-group metrics 2304 one-to-group-One-way-Delay-Vector OBJECT-IDENTITY 2306 STATUS current 2308 DESCRIPTION 2310 "Type-P-one-to-group-One-way-Delay-Vector" 2312 REFERENCE 2314 "Reference "RFCyyyy, section 5.1." 2316 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2317 note 2319 := { ianaIppmMetrics nn } -- IANA assigns nn 2321 one-to-group-One-way-Packet-Loss-Vector OBJECT-IDENTITY 2323 STATUS current 2325 DESCRIPTION 2327 "Type-P-one-to-group-One-way-Packet-Loss-Vector" 2329 REFERENCE 2331 "Reference "RFCyyyy, section 5.2." 2333 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2334 note 2336 := { ianaIppmMetrics nn } -- IANA assigns nn 2338 one-to-group-One-way-ipdv-Vector OBJECT-IDENTITY 2340 STATUS current 2342 DESCRIPTION 2344 "Type-P-one-to-group-One-way-ipdv-Vector" 2346 REFERENCE 2348 "Reference "RFCyyyy, section 5.3." 2350 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2351 note 2353 := { ianaIppmMetrics nn } -- IANA assigns nn 2355 One-to-Group-Mean-Delay OBJECT-IDENTITY 2357 STATUS current 2359 DESCRIPTION 2361 "Type-P-One-to-Group-Mean-Delay" 2363 REFERENCE 2365 "Reference "RFCyyyy, section 6.3.3." 2366 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2367 note 2369 := { ianaIppmMetrics nn } -- IANA assigns nn 2371 One-to-Group-Range-Mean-Delay OBJECT-IDENTITY 2373 STATUS current 2375 DESCRIPTION 2377 "Type-P-One-to-Group-Range-Mean-Delay" 2379 REFERENCE 2381 "Reference "RFCyyyy, section 6.3.4." 2383 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2384 note 2386 := { ianaIppmMetrics nn } -- IANA assigns nn 2388 One-to-Group-Max-Mean-Delay OBJECT-IDENTITY 2390 STATUS current 2392 DESCRIPTION 2394 "Type-P-One-to-Group-Max-Mean-Delay" 2396 REFERENCE 2398 "Reference "RFCyyyy, section 6.3.5." 2400 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2401 note 2403 := { ianaIppmMetrics nn } -- IANA assigns nn 2405 One-to-Group-Loss-Ratio OBJECT-IDENTITY 2407 STATUS current 2409 DESCRIPTION 2411 "Type-P-One-to-Group-Loss-Ratio" 2413 REFERENCE 2415 "Reference "RFCyyyy, section 6.4.1." 2417 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2418 note 2420 := { ianaIppmMetrics nn } -- IANA assigns nn 2422 -- 2424 One-to-Group-Loss-Ratio-Range OBJECT-IDENTITY 2426 STATUS current 2428 DESCRIPTION 2430 "Type-P-One-to-Group-Loss-Ratio-Range" 2432 REFERENCE 2434 "Reference "RFCyyyy, section 6.4.2." 2436 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2437 note 2439 := { ianaIppmMetrics nn } -- IANA assigns nn 2441 -- 2443 14. References 2445 14.1. Normative References 2447 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2448 "Framework for IP Performance Metrics", RFC 2330, 2449 May 1998. 2451 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2452 Delay Metric for IPPM", RFC 2679, September 1999. 2454 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2455 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2457 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2458 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2459 November 2002. 2461 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2462 Registry", BCP 108, RFC 4148, August 2005. 2464 14.2. Informative References 2466 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 2467 Connectivity", RFC 2678, September 1999. 2469 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2470 Delay Metric for IPPM", RFC 2681, September 1999. 2472 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 2473 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 2474 July 2001. 2476 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 2477 Metrics", RFC 3357, August 2002. 2479 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2480 performance measurement with periodic streams", RFC 3432, 2481 November 2002. 2483 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 2484 Measurement Protocol (OWAMP) Requirements", RFC 3763, 2485 April 2004. 2487 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2488 Zekauskas, "A One-way Active Measurement Protocol 2489 (OWAMP)", RFC 4656, September 2006. 2491 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2492 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2493 November 2006. 2495 Authors' Addresses 2497 Stephan Emile 2498 France Telecom Division R&D 2499 2 avenue Pierre Marzin 2500 Lannion, F-22307 2502 Fax: +33 2 96 05 18 52 2503 Email: emile.stephan@orange-ftgroup.com 2504 Lei Liang 2505 CCSR, University of Surrey 2506 Guildford 2507 Surrey, GU2 7XH 2509 Fax: +44 1483 683641 2510 Email: L.Liang@surrey.ac.uk 2512 Al Morton 2513 200 Laurel Ave. South 2514 Middletown, NJ 07748 2515 USA 2517 Phone: +1 732 420 1571 2518 Email: acmorton@att.com 2520 Full Copyright Statement 2522 Copyright (C) The IETF Trust (2007). 2524 This document is subject to the rights, licenses and restrictions 2525 contained in BCP 78, and except as set forth therein, the authors 2526 retain all their rights. 2528 This document and the information contained herein are provided on an 2529 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2530 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2531 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2532 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2533 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2536 Intellectual Property 2538 The IETF takes no position regarding the validity or scope of any 2539 Intellectual Property Rights or other rights that might be claimed to 2540 pertain to the implementation or use of the technology described in 2541 this document or the extent to which any license under such rights 2542 might or might not be available; nor does it represent that it has 2543 made any independent effort to identify any such rights. Information 2544 on the procedures with respect to rights in RFC documents can be 2545 found in BCP 78 and BCP 79. 2547 Copies of IPR disclosures made to the IETF Secretariat and any 2548 assurances of licenses to be made available, or the result of an 2549 attempt made to obtain a general license or permission for the use of 2550 such proprietary rights by implementers or users of this 2551 specification can be obtained from the IETF on-line IPR repository at 2552 http://www.ietf.org/ipr. 2554 The IETF invites any interested party to bring to its attention any 2555 copyrights, patents or patent applications, or other proprietary 2556 rights that may cover technology that may be required to implement 2557 this standard. Please address the information to the IETF at 2558 ietf-ipr@ietf.org. 2560 Acknowledgment 2562 Funding for the RFC Editor function is provided by the IETF 2563 Administrative Support Activity (IASA).