idnits 2.17.1 draft-ietf-ippm-multimetrics-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2417. 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 490: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 566: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 672: '...-way-Delay-Vector metric is taken MUST...' RFC 2119 keyword, line 715: '...ipdv measurement SHOULD be respectful ...' RFC 2119 keyword, line 779: '... These cases MUST be identified befo...' (5 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. -- 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 (November 18, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4601' is mentioned on line 1807, but not defined ** Obsolete undefined reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-05 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet-Draft France Telecom 4 Intended status: Informational L. Liang 5 Expires: May 21, 2008 University of Surrey 6 A. Morton 7 AT&T Labs 8 November 18, 2007 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The IETF IP Performance Metrics (IPPM) working group has standardized 45 metrics for measuring end-to-end performance between two points. 46 This memo defines two new categories of metrics that extend the 47 coverage to multiple measurement points. It defines spatial metrics 48 for measuring the performance of segments of a source to destination 49 path, and metrics for measuring the performance between a source and 50 many destinations in multiparty communications (e.g., a multicast 51 tree). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6 61 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6 62 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 63 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 67 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 68 3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 69 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 70 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 71 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 72 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15 73 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17 74 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19 75 5.1. A Definition of a sample of One-way Delay of a segment 76 of the path . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.2. A Definition of a sample of Packet Loss of a segment 78 of the path . . . . . . . . . . . . . . . . . . . . . . . 20 79 5.3. A Definition of a sample of One-way Ipdv of a segment 80 of the path . . . . . . . . . . . . . . . . . . . . . . . 23 81 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 82 6.1. A Definition for one-to-group One-way Delay . . . . . . . 23 83 6.2. A Definition for one-to-group One-way Packet Loss . . . . 24 84 6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 25 85 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26 86 7.1. Discussion on the Impact of packet loss on statistics . . 29 87 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 30 88 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 31 89 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 33 90 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 35 91 8. Measurement Methods: Scaleability and Reporting . . . . . . . 35 92 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36 93 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37 94 8.3. Effect of Time and Space Aggregation Order on Stats . . . 37 95 9. Manageability Considerations . . . . . . . . . . . . . . . . . 39 96 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39 97 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40 98 9.3. Metric identification . . . . . . . . . . . . . . . . . . 41 99 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 41 100 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 44 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 102 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 45 103 11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 45 104 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 106 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 107 14.1. Normative References . . . . . . . . . . . . . . . . . . . 51 108 14.2. Informative References . . . . . . . . . . . . . . . . . . 51 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 110 Intellectual Property and Copyright Statements . . . . . . . . . . 54 112 1. Introduction 114 The IP Performance Metrics (IPPM) WG has defined a framework for 115 metric definitions and end-to-end, or source to destination 116 measurements: 118 o A general framework for defining performance metrics, described in 119 the Framework for IP Performance Metrics [RFC2330]; 121 The Working Group has specified a set of end-to-end metrics using the 122 framework, and a registry for the metrics: 124 o The IPPM Metrics for Measuring Connectivity [RFC2678]; 126 o The One-way Delay Metric for IPPM [RFC2679]; 128 o The One-way Packet Loss Metric for IPPM [RFC2680]; 130 o The Round-trip Delay Metric for IPPM [RFC2681]; 132 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 133 [RFC3148]; 135 o One-way Loss Pattern Sample Metrics [RFC3357]; 137 o IP Packet Delay Variation Metric for IPPM [RFC3393]; 139 o Network performance measurement for periodic streams [RFC3432]; 141 o Packet Reordering Metrics [RFC4737]; 143 o An IP Performance Metrics Registry [RFC4148]; 145 IPPM has also developed a protocol for one-way source to destination 146 measurements 148 o A One-way Active Measurement Protocol Requirements [RFC3763]; 150 o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; 152 This memo defines two new categories of metrics that extend the 153 coverage to multiple measurement points. It first defines spatial 154 metrics for measuring the performance of segments of a source to 155 destination path: 157 o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be 158 introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679] 159 into a spatial sequence of one-way delay metrics. 161 o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 162 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 163 [RFC2680] in a spatial sequence of packet loss metrics. 165 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector', 166 called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to 167 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of 168 ipdv metrics. 170 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 171 called Type-P-Segment-One-way-Delay-Stream, will be introduced to 172 collect a nested set of one-way delay metrics between the source, 173 intermediate points of interest, and the destination; 175 o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', 176 called Type-P-Segment-Packet-Loss-Stream, will be introduced to 177 collect a nested set of packet loss metrics between the source, 178 intermediate points of interest, and the destination; 180 o Using the Type-P-Spatial-ipdv-Vector metric, a 'sample', called 181 Type-P-Segment-ipdv-Stream, will be introduced to collect a nested 182 set of ipdv metrics between the source, intermediate points of 183 interest, and the destination; 185 Note that all these metrics are based on observations of packets 186 dedicated to testing, a process which is called Active measurement. 187 Purely passive spatial measurement (for example, a spatial metric 188 based on the observation of user traffic) is beyond the scope of this 189 document and the current IPPM charter. 191 Next, this memo defines one-to-group metrics. 193 o Using one test packet sent from one sender to a group of 194 receivers, a metric called Type-P-one-to-group-One-way-Delay- 195 Vector will be introduced to collect the set of Type-P-one-way- 196 delay [RFC2679] singletons between this sender and the group of 197 receivers. 199 o Using one test packet sent from one sender to a group of 200 receivers, a metric called Type-P-one-to-group-One-way-Packet- 201 Loss-Vector, will be introduced to collect the set of Type-P-One- 202 way-Packet-Loss [RFC2680] singletons between this sender and the 203 group of receivers 205 o Using one test packet sent from one sender to a group of 206 receivers, a metric called Type-P-one-to-group-One-way-ipdv- 207 Vector, will be introduced to collect the set of Type-P-One-way- 208 ipdv singletons between this sender and the group of receivers 210 o A discussion section presents the set of statistics that may be 211 computed using these metrics to present the network performance in 212 the view of a group of users. The statistics may be the basis for 213 requirements (e.g. fairness) on multiparty communications. . 215 Metric Reporting is defined in the "Manageability Considerations" 216 section. 218 2. Terminology 220 2.1. Path Digest Hosts 222 The list of the hosts on a path from the source to the destination. 224 2.2. Multiparty metric 226 A metric is said to be multiparty if the topology involves more than 227 one measurement collection point. All multiparty metrics define a 228 set of hosts called "points of interest", where one host is the 229 source and other hosts are the measurement collection points. For 230 example, if the set of points of interest is < ha, hb, hc, ..., hn >, 231 where ha is the source and < hb, hc, ..., hn > are the destinations, 232 then measurements may be conducted between < ha, hb>, < ha, hc>, ..., 233 . 235 For the purposes of this memo (reflecting the scope of a single 236 source), the only multiparty metrics are one-to-group metrics. 238 2.3. Spatial metric 240 A metric is said to be spatial if one of the hosts (measurement 241 collection points) involved is neither the source nor the destination 242 of the measured packet. 244 2.4. One-to-group metric 246 A metric is said to be one-to-group if the measured packet is sent by 247 one source and (potentially) received by several destinations. Thus, 248 the topology of the communication group can be viewed as a centre- 249 distributed or server-client topology with the source as the centre/ 250 server in the topology. 252 2.5. Points of interest 254 Points of interest are the hosts* (as per RFC2330 definition, that 255 includes routing nodes) that are measurement collection points, a 256 sub-set of the set of hosts involved in the delivery of the packets 257 (in addition to the source itself). Note that the points of interest 258 are a possibly arbitrary sub-set of all the hosts involved in the 259 path. 261 Points of interest of One-to-group metrics are the intended 262 destination hosts for packets from the source (in addition to the 263 source itself). 265 Src Recv 266 `. ,-. 267 `. ,' `...... 1 268 `. ; : 269 `. ; : 270 ; :... 2 271 | | 272 : ; 273 : ;.... 3 274 : ; 275 `. ,' 276 `-'....... N 278 Figure 1: One-to-group points of interest 280 A candidate point of interest for spatial metrics is a host from the 281 set of hosts involved in the delivery of the packets from the source. 283 Src ------. Hosts 284 \ 285 `---X ... 1 286 \ 287 x 288 / 289 .---------X .... 2 290 / 291 x 292 \ 293 `---X .... 3 294 \ 295 \ 296 \ 297 X .... N 298 \ 299 \ 300 \ 301 `---- Dst 303 Note: 'x' are nodes which are not points of interest 305 Figure 2: Spatial points of interest 307 2.6. Reference point 309 A reference point is defined as the server where the statistical 310 calculations will be carried out. A centre/server in the 311 multimetrics measurement that is controlled by a network operator is 312 a good example of a reference point, where measurement data can be 313 collected for further processing. However, the actual measurements 314 have to be carried out at all points of interest. 316 2.7. Vector 318 A Vector is a set of singletons, which are a set of results of the 319 observation of the behaviour of the same packet at different places 320 of a network at different times. For instance, if One-way delay 321 singletons observed at N receivers for Packet P sent by the source 322 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 323 elements can be organized as {dT1, dT2,..., dTN}. The elements in 324 one vector are singletons distinct with each other in terms of both 325 measurement point and sending time. Given the vector V as an 326 example, the element dT1 is distinct from all others as the singleton 327 at receiver 1 in response to a packet sent from the source at time 328 T1. The complete Vector gives information over the dimension of 329 space. 331 2.8. Matrix 333 Several vectors form a Matrix, which contains results observed in a 334 sampling interval at different places in a network at different time. 335 For instance, given One-way delay vectors V1={dT11, dT12,..., dT1N}, 336 V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for Packet 337 P1, P2,...,Pm, we can have a One-way delay Matrix {V1, V2,...,Vm}. 338 Additional to the information given by a Vector, a Matrix is more 339 powerful to present network performance in both space and time 340 dimensions. It normally corresponds to a sample in simple point-to- 341 point measurement. 343 The relation among Singleton, Vector and Matrix can be shown in the 344 following Figure 3. 346 Point of Singleton 347 interest / Samples 348 ,----. ^ / 349 / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ 350 / \ | | | 351 ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | 352 Src | || | | 353 | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | 354 | || | | 355 : ;| | | 356 \ / | | | 357 \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / 358 `-----' +-------------------------------------> time 360 Vector Matrix 361 (space) (time) 363 Figure 3: Relation beween Singletons, vectors and matrix 365 3. Motivations 367 All IPPM metrics are defined for end-to-end (source to destination) 368 measurement of point-to-point paths. It is a logical extension to 369 define metrics for multiparty measurements such as one to one 370 trajectory metrics and one to multipoint metrics. 372 3.1. Motivations for spatial metrics 374 Decomposition of instantaneous end-to-end measures is needed: 376 o Decomposing the performance of interdomain path is desirable to 377 quantify the per-AS contribution to the performance. It is 378 valuable to define standard spatial metrics before pursuing inter- 379 domain path performance specifications. 381 o Traffic engineering and troubleshooting applications benefit from 382 spatial views of one-way delay and ipdv consumption, and 383 identification of the location of the lost of packets. 385 o Monitoring the performance of a multicast tree composed of MPLS 386 point-to-multipoint and inter-domain communication require spatial 387 decomposition of the one-way delay, ipdv, and packet loss. 389 o Composition of metrics [I-D.ietf-ippm-spatial-composition] is 390 needed to help measurement systems reach large scale coverage. 391 Spatial measure typically give the individual performance of an 392 intra domain segment and provide an elementary piece of 393 information needed to estimate interdomain performance based on 394 composition of metrics. 396 3.2. Motivations for One-to-group metrics 398 While the node-to-node based spatial measures can provide very useful 399 data in the view of each connection, we also need measures to present 400 the performance of a multiparty communication topology. A simple 401 one-way metric cannot completely describe the multiparty situation. 402 New one-to-group metrics assess performance of all the paths for 403 further statistical analysis. The new metrics proposed in this stage 404 are named one-to-group performance metrics, and they are based on the 405 unicast metrics defined in IPPM WG. One-to-group metrics are one-way 406 metrics from one source to a group of destinations. The metrics are 407 helpful for judging the network performance of multiparty 408 communications and can also be used to describe the variation of 409 performance delivered to a group of destination hosts and their 410 users. 412 One-to-group performance metrics are needed for several reasons: 414 o For designing and engineering multicast trees and MPLS point-to- 415 multipoint LSP; 417 o For evaluating and controlling of the quality of the multicast 418 services; 420 o For controlling the performance of the inter domain multicast 421 services; 423 o For presenting and evaluating the performance requirements for 424 multiparty communications. 426 To understand the packet transfer performance between one source and 427 any one receiver in the multiparty communication group, we need to 428 collect instantaneous end-to-end metrics, or singletons. It will 429 give a very detailed insight into each branch of the multicast tree 430 in terms of end-to-end absolute performance. This detail can provide 431 clear and helpful information for engineers to identify the sub-path 432 with problems in a complex multiparty routing tree. 434 The one-to-group metrics described in this memo introduce the 435 multiparty topology to the IPPM working group; the goal is to measure 436 the performance delivered to a group of users who are receiving 437 packets from the same source. The concept extends the "path" in the 438 one-way measurement to "path tree" to cover both one-to-one and one- 439 to-many communications. If applied to one-to-one communications, the 440 one-to-group metrics provide exactly the same results as the 441 corresponding one-to-one metrics. 443 3.3. Discussion on Group-to-one and Group-to-group metrics 445 We note that points of interest can also be selected to define 446 measurements on Group-to-one and Group-to-group topologies. These 447 topologies are currently beyond the scope of this memo, because they 448 would involve multiple packets launched from different sources. 449 However, we can give some clues here on these two cases. 451 The measurements for group-to-one topology can be easily derived from 452 the one-to-group measurement. The measurement point is the reference 453 point that is acting as a receiver while all of clients/receivers 454 defined for one-to-group measurement act as sources in this case. 456 For the group-to-group connection topology, it is difficult to define 457 the reference point and therefore it is difficult to define the 458 measurement points. However, we can always avoid this confusion by 459 treating the connections as one-to-group or group-to-one in our 460 measurements without consideration on how the real communication will 461 be carried out. For example, if one group of hosts < ha, hb, hc, 462 ..., hn > are acting as sources to send data to another group of 463 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 464 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 465 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 466 ..., Hm >. 468 4. Spatial vectors metrics definitions 470 This section defines vectors for the decomposition of end-to-end 471 singleton metrics over a path. 473 Spatial vectors metrics are based on the decomposition of standard 474 end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], 475 [RFC3393] and [RFC3432]. 477 Definitions are coupled with the corresponding end-to-end metrics. 478 Methodology specificities are common to all the vectors defined and 479 are consequently discussed in a common section. 481 4.1. A Definition for Spatial One-way Delay Vector 483 This section is coupled with the definition of Type-P-One-way-Delay. 484 When a parameter from section 3 of [RFC2679] is first used in this 485 section, it will be tagged with a trailing asterisk. 487 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 488 statements for end-to-end one-way-delay measurements. They are 489 applicable to each point of interest Hi involved in the measure. 490 Spatial one-way-delay measurement SHOULD be respectful of them, 491 especially those related to methodology, clock, uncertainties and 492 reporting. 494 Following we adapt some of them and introduce points specific to 495 spatial measurement. 497 4.1.1. Metric Name 499 Type-P-Spatial-One-way-Delay-Vector 501 4.1.2. Metric Parameters 503 o Src*, the IP address of the sender. 505 o Dst*, the IP address of the receiver. 507 o i, An integer if the list <1,2,...,n> which ordered the hosts in 508 the path. 510 o Hi, A host* of the path digest. 512 o T*, a time, the sending (or initial observation) time for a 513 measured packet. 515 o dT* a delay, the one-way delay for a measured packet. 517 o a list of delay. 519 o P*, the specification of the packet type. 521 o , hosts path digest. 523 4.1.3. Metric Units 525 A sequence of times. 527 4.1.4. Definition 529 Given a Type-P packet sent by the sender Src at wire-time (first bit) 530 T to the receiver Dst in the path . Given the 531 sequence of values such that dT is the 532 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 533 path, T+dTi is either a real number corresponding to the wire-time 534 the packet passes (last bit received) Hi, or undefined if the packet 535 never passes Hi. 537 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 538 as the sequence of values 539 . 541 4.1.5. Discussion 543 Following are specific issues which may occur: 545 o the delay looks to decrease: dTi > DTi+1. This seem typically du 546 to some clock synchronisation issue. This point is discussed in 547 the section 3.7.1. "Errors or uncertainties related to Clocks" of 548 of [RFC2679]. One consequence of these uncertainties is that 549 times of a measure at different hosts shall not be used to order 550 hosts on the path of a measure; 552 o The location of the point of interest in the device influences the 553 result. If the packet is not observed on the input interface the 554 delay includes buffering time and consequently an uncertainty due 555 to the difference between 'wire time' and 'host time'; 557 4.2. A Definition for Spatial One-way Packet Loss Vector 559 This section is coupled with the definition of Type-P-One-way-Packet- 560 Loss. Then when a parameter from the section 2 of [RFC2680] is first 561 used in this section, it will be tagged with a trailing asterisk. 563 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 564 statements for end-to-end one-way-Packet-Loss measurements. They are 565 applicable to each point of interest Hi involved in the measure. 566 Spatial packet loss measurement SHOULD be respectful of them, 567 especially those related to methodology, clock, uncertainties and 568 reporting. 570 Following we define the spatial metric, then we adapt some of the 571 points above and introduce points specific to spatial measurement. 573 4.2.1. Metric Name 575 Type-P-Spatial-One-way-Packet-Loss-Vector 577 4.2.2. Metric Parameters 579 + Src*, the IP address of the sender. 581 + Dst*, the IP address of the receiver. 583 + i, An integer which ordered the hosts in the path. 585 + Hi, exchange points of the path digest. 587 + T*, a time, the sending (or initial observation) time for 588 a measured packet. 590 + dT1,..., dTn, dT, a list of delay. 592 + P*, the specification of the packet type. 594 + , hosts path digest. 596 + B1, B2, ..., Bi, ..., Bn, a list of Boolean values. 598 4.2.3. Metric Units 600 A sequence of Boolean values. 602 4.2.4. Definition 604 Given a Type-P packet sent by the sender Src at time T to the 605 receiver Dst in the path . Given the sequence of 606 times the packet passes , 609 Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence 610 of values such that for each Hi of the path, a 611 value of Bi of 0 means that dTi is a finite value, and a value of 1 612 means that dTi is undefined. 614 4.2.5. Discussion 616 Following are specific issues which may occur: 618 o the result includes the sequence 1,0. This case means that the 619 packet was seen by a host but not by it successor on the path; 621 The location of the point of interest in the device influences the 622 result: 624 o Even if the packet is received by a host, it may be not observed 625 by the point of interest located after a buffer; 627 4.3. A Definition for Spatial One-way Ipdv Vector 629 This section uses parameters from the definition of Type-P-One-way- 630 ipdv. When a parameter from section 2 of [RFC3393] is first used in 631 this section, it will be tagged with a trailing asterisk. 633 Following we adapt some of them and introduce points specific which 634 are to spatial measurement. 636 4.3.1. Metric Name 638 Type-P-Spatial-One-way-ipdv-Vector 640 4.3.2. Metric Parameters 642 + Src*, the IP address of the sender. 644 + Dst*, the IP address of the receiver. 646 + i, An integer which ordered the hosts in the path. 648 + Hi, exchange points of the path digest. 650 + T1*, the time the first packet was sent. 652 + T2*, the time the second packet was sent. 654 + P, the specification of the packet type. 656 + P1, the first packet sent at time T1. 658 + P2, the second packet sent at time T2. 660 + , host path digest. 662 + , 663 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 664 time T1; 666 + , 667 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 668 time T2; 670 + L*, a packet length in bits. The packets of a Type P 671 packet stream from which the 672 Type-P-Spatial-One-way-Delay-Vector metric is taken MUST 673 all be of the same length. 675 4.3.3. Metric Units 677 A sequence of times. 679 4.3.4. Definition 681 Given the Type-P packet having the size L and sent by the sender Src 682 at wire-time (first bit) T1 to the receiver Dst in the path . 685 Given the Type-P packet having the size L and sent by the sender Src 686 at wire-time (first bit) T2 to the receiver Dst in the same path. 688 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P1. 691 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P2. 694 Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence 695 of values 696 Such that for each Hi of the path , dT2.i-dT1.i is 697 either a real number if the packets P1 and P2 passes Hi at wire-time 698 (last bit) dT1.i, respectively dT2.i, or undefined if at least one of 699 them never passes Hi. T2-T1 is the inter-packet emission interval 700 and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. 702 4.4. Spatial Methodology 704 Methodology, reporting and uncertainties points specified in section 705 3 of [RFC2679][RFC2679] applies to each point of interest Hi 706 measuring a element of a spatial delay vector. 708 Methodology, reporting and uncertainties points specified in section 709 2 of [RFC2680][RFC2680] applies to each point of interest Hi 710 measuring a element of a spatial packet loss vector. 712 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 713 statements for end-to-end One-way ipdv measurements. They are 714 applicable to each point of interest Hi involved in the measure. 715 Spatial One-way ipdv measurement SHOULD be respectful of methodology, 716 clock, uncertainties and reporting aspects given in this section. 718 Generally, for a given Type-P of length L, in a given Hi, the 719 methodology for spatial vector metrics would proceed as follows: 721 o At each Hi, points of interest prepare to capture the packet sent 722 a time T, take a timestamp Ti', determine the internal delay 723 correction dTi' (See section 3.7.1. "Errors or uncertainties 724 related to Clocks" of [RFC2679]), 726 o Each Hi extracts the path ordering information from the packet 727 (e.g. time-to-live); 729 o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. 730 This arrival time is undefined (infinite) if the packet is not 731 detected after the 'loss threshold' duration; 733 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 5.2. A Definition of a sample of Packet Loss of a segment of the path 870 This metric defines a sample of Packet lost between a pair of hosts 871 of a path. 873 5.2.1. Metric Name 875 Type-P-segment-Packet-loss-Stream 877 5.2.2. Metric Parameters 879 + Src*, the IP address of the sender. 881 + Dst*, the IP address of the receiver. 883 + P*, the specification of the packet type. 885 + k, An integer which orders the packets sent. 887 + n, An integer which orders the hosts on the path. 889 + , hosts path digest. 891 + Ha, a host of the path digest different from Dst and Hb; 893 + Hb, a host of the path digest different from Src and Ha. 894 Hb order in the path must greater that Ha; 896 + Hi, exchange points of the path digest. 898 + a list of bits. 900 + a list of integers. 902 5.2.3. Metric Units 904 A sequence of integers 906 5.2.4. Definition 908 Given 2 hosts Ha and Hb of the path , given 909 a flow of packets of Type-P sent from Src to Dst at the times T1, 910 T2... Tn. At each of these times, we obtain a Type-P-Spatial- 911 Packet-Lost-Vector . We define the value of 912 the sample Type-P-segment-Packet-Lost-Stream between Ha and Hb as the 913 sequence made up of the integer such that for each 914 Tk: 916 o a value of Lk of 0 means that Bk.a has a value of 0 (observed) and 917 that Bk.b have a value of 0 (observed); 919 o a value of Lk of 1 means that Bk.a has a value of 0 (observed) and 920 that Bk.b have a value of 1 (not observed); 922 o a value of Lk of 2 means that Bk.a has a value of 1 (not observed) 923 and that Bk.b have a value of 0 (observed); 925 o a value of Lk of 3 means that Bk.a has a value of 1 (not observed) 926 and that Bk.b have a value of 1 (not observed). 928 5.2.5. Discussion 930 The semantic of a Type-P-segment-Packet-loss-Stream is similar to the 931 one of Type-P-Packet-loss-Stream: 933 o a value of 0 means that the packet was observed by Ha (similar to 934 'send by Src') and not observed by Hb ( similar to 'not received 935 by Dst'); 937 o a value of 1 means that it was observed by Ha (similar to 'send by 938 Src') and observed by Hb ( similar to 'received by Dst'). 940 This definition of Type-P-segment-Packet-loss-Stream is similar to 941 the Type-P-Packet-loss-Stream defined in [RFC2680] excepted that in a 942 Type-P-segment-Packet-loss-Stream the rules of the point of interests 943 Ha and Hb are symetrical: The asumption that a set of packets are 944 going from Ha to Hb does not apply to Type-P-segment-Packet-loss- 945 Stream because as the host path digest is dynamic each packet has its 946 own host path digest. 948 Making the asumption that the host path digest of a Type-P-spatial- 949 Packet-loss-vector does not change and that the set of (Hk, Hk+1) 950 tuples is mostly stable over time lead to unusable results and to the 951 introduction of mistakes in the metrics aggregation processes. The 952 right approach consists in carefully scrutening the path ordering 953 information to build sample with elements of vectors sharing the same 954 properties in term of Ha and Hb and 'Ha to Hb'. So a measure of 955 Type-P-spatial-Packet-loss-vector differs from a Type-P-Packet-loss 956 one in that it produces different samples of packet loss over time. 958 The semantic of a Type-P-segment-Packet-loss-Stream defines 2 new 959 results: 961 o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering 962 of Ha and Hb over the path coming either from the configuration 963 (asumption on the path) or from the processing of the vectors: bad 964 scrutening of the path ordering information, or some other mistake 965 in the measure or the reporting. It is not in the scope of this 966 document to go in further details which are mostly implementation 967 dependent. This value MUST not be used to compute packet lost 968 statistics. 970 o A value of Lk of 3 (1,1) corresponds to a lost of the packet in 971 upper segment of the path. 973 5.3. A Definition of a sample of One-way Ipdv of a segment of the path 975 This metric defines a sample of ipdv between a pair of hosts of a 976 path. 978 Editor note: work in progress 980 5.3.1. Metric Name 982 Type-P-Segment-Ipdv-Stream 984 5.3.2. Metric Parameters 986 5.3.3. Metric Units 988 5.3.4. Definition 990 5.3.5. Discussion 992 6. One-to-group metrics definitions 994 6.1. A Definition for one-to-group One-way Delay 996 6.1.1. Metric Name 998 Type-P-one-to-group-One-way-Delay-Vector 1000 6.1.2. Metric Parameters 1002 o Src, the IP address of a host acting as the source. 1004 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1005 receivers. 1007 o T, a time. 1009 o dT1,...,dTn a list of time. 1011 o P, the specification of the packet type. 1013 o Gr, the multicast group address (optional). The parameter Gr is 1014 the multicast group address if the measured packets are 1015 transmitted by multicast. This parameter is to identify the 1016 measured traffic from other unicast and multicast traffic. It is 1017 set to be optional in the metric to avoid losing any generality, 1018 i.e. to make the metric also applicable to unicast measurement 1019 where there is only one receivers. 1021 6.1.3. Metric Units 1023 The value of a Type-P-one-to-group-One-way-Delay-Vector is a set of 1024 singletons metrics Type-P-One-way-Delay [RFC2679]. 1026 6.1.4. Definition 1028 Given a Type P packet sent by the source Src at Time T, given the N 1029 hosts { Recv1,...,RecvN } which receive the packet at the time { 1030 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is 1031 defined as the set of the Type-P-One-way-Delay singleton between Src 1032 and each receiver with value of { dT1, dT2,...,dTn }. 1034 6.2. A Definition for one-to-group One-way Packet Loss 1036 6.2.1. Metric Name 1038 Type-P-one-to-group-One-way-Packet-Loss-Vector 1040 6.2.2. Metric Parameters 1042 o Src, the IP address of a host acting as the source. 1044 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 1045 receivers. 1047 o T, a time. 1049 o T1,...,Tn a list of time. 1051 o P, the specification of the packet type. 1053 o Gr, the multicast group address (optional). 1055 6.2.3. Metric Units 1057 The value of a Type-P-one-to-group-One-way-Packet-Loss-Vector is a 1058 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 1060 6.2.4. Definition 1062 Given a Type P packet sent by the source Src at T and the N hosts, 1063 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 1064 Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of 1065 the Type-P-One-way-Packet-Loss singleton between Src and each of the 1066 receivers {,,..., }. 1068 6.3. A Definition for one-to-group One-way Ipdv 1070 6.3.1. Metric Name 1072 Type-P-One-to-group-One-way-ipdv-Vector 1074 6.3.2. Metric Parameters 1076 + Src, the IP address of a host acting as the source. 1078 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 1079 receivers. 1081 + T1, a time. 1083 + T2, a time. 1085 + ddT1,...,ddTn, a list of time. 1087 + P, the specification of the packet type. 1089 + F, a selection function defining unambiguously the two 1090 packets from the stream selected for the metric. 1092 + Gr, the multicast group address (optional) 1094 6.3.3. Metric Units 1096 The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of 1097 singletons metrics Type-P-One-way-ipdv [RFC3393]. 1099 6.3.4. Definition 1101 Given a Type P packet stream, Type-P-one-to-group-One-way-ipdv-Vector 1102 is defined for two packets from the source Src to the N hosts 1103 {Recv1,...,RecvN },which are selected by the selection function F, as 1104 the difference between the value of the Type-P-one-to-group-One-way- 1105 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1106 value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { 1107 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1108 the first bit of the first packet, and T2 is the wire-time at which 1109 Src sent the first bit of the second packet. This metric is derived 1110 from the Type-P-one-to- group-One-way-Delay-Vector metric. 1112 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 1113 group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 1114 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1115 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1116 and the packets were received by { Recv1,...,RecvN } at wire-time 1117 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1118 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1119 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1121 7. One-to-Group Sample Statistics 1123 The defined one-to-group metrics above can all be directly achieved 1124 from the relevant unicast one-way metrics. They managed to collect 1125 all unicast measurement results of one-way metrics together in one 1126 profile and sort them by receivers and packets in a multicast group. 1127 They can provide sufficient information regarding the network 1128 performance in terms of each receiver and guide engineers to identify 1129 potential problem happened on each branch of a multicast routing 1130 tree. However, these metrics can not be directly used to 1131 conveniently present the performance in terms of a group and neither 1132 to identify the relative performance situation. 1134 From the performance point of view, the multiparty communication 1135 services not only require the absolute performance support but also 1136 the relative performance. The relative performance means the 1137 difference between absolute performance of all users. Directly using 1138 the one-way metrics cannot present the relative performance 1139 situation. However, if we use the variations of all users one-way 1140 parameters, we can have new metrics to measure the difference of the 1141 absolute performance and hence provide the threshold value of 1142 relative performance that a multiparty service might demand. A very 1143 good example of the high relative performance requirement is the 1144 online gaming. A very light difference in delay might result in 1145 failure in the game. We have to use multicast specific statistic 1146 metrics to define exactly how small the relative delay the online 1147 gaming requires. There are many other services, e.g. online biding, 1148 online stock market, etc., that require multicast metrics in order to 1149 evaluate the network against their requirements. Therefore, we can 1150 see the importance of new, multicast specific, statistic metrics to 1151 feed this need. 1153 We might also use some one-to-group statistic conceptions to present 1154 and report the group performance and relative performance to save the 1155 report transmission bandwidth. Statistics have been defined for One- 1156 way metrics in corresponding RFCs. They provide the foundation of 1157 definition for performance statistics. For instance, there are 1158 definitions for minimum and maximum One-way delay in [RFC2679]. 1159 However, there is a dramatic difference between the statistics for 1160 one-to-one communications and for one-to-many communications. The 1161 former one only has statistics over the time dimension while the 1162 later one can have statistics over both time and space dimensions. 1163 This space dimension is introduced by the Matrix concept as 1164 illustrated in Figure 9. For a Matrix M each row is a set of One-way 1165 singletons spreading over the time dimension and each column is 1166 another set of One-way singletons spreading over the space dimension. 1168 Receivers 1169 Space 1170 ^ 1171 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1172 | | | 1173 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1174 | | | 1175 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1176 . | | | 1177 . | | | 1178 . | | | 1179 n | \ RndT1 RndT2 RndT3 ... RndTk / 1180 +--------------------------------------------> time 1181 T0 1183 Figure 9: Matrix M (n*m) 1185 In Matrix M, each element is a One-way delay singleton. Each column 1186 is a delay vector contains the One-way delays of the same packet 1187 observed at M points of interest. It implies the geographical factor 1188 of the performance within a group. Each row is a set of One-way 1189 delays observed during a sampling interval at one of the points of 1190 interest. It presents the delay performance at a receiver over the 1191 time dimension. 1193 Therefore, one can either calculate statistics by rows over the space 1194 dimension or by columns over the time dimension. It's up to the 1195 operators or service provides which dimension they are interested in. 1196 For example, a TV broadcast service provider might want to know the 1197 statistical performance of each user in a long term run to make sure 1198 their services are acceptable and stable. While for an online gaming 1199 service provider, he might be more interested to know if all users 1200 are served fairly by calculating the statistics over the space 1201 dimension. This memo does not intend to recommend which of the 1202 statistics are better than the other. 1204 To save the report transmission bandwidth, each point of interest can 1205 send statistics in a pre-defined time interval to the reference point 1206 rather than sending every One-way singleton it observed. As long as 1207 an appropriate time interval is decided, appropriate statistics can 1208 represent the performance in a certain accurate scale. How to decide 1209 the time interval and how to bootstrap all points of interest and the 1210 reference point depend on applications. For instance, applications 1211 with lower transmission rate can have the time interval longer and 1212 ones with higher transmission rate can have the time interval 1213 shorter. However, this is out of the scope of this memo. 1215 Moreover, after knowing the statistics over the time dimension, one 1216 might want to know how this statistics distributed over the space 1217 dimension. For instance, a TV broadcast service provider had the 1218 performance Matrix M and calculated the One-way delay mean over the 1219 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1220 calculated the mean of all the elements in the Vector to see what 1221 level of delay he has served to all N users. This new delay mean 1222 gives information on how good the service has been delivered to a 1223 group of users during a sampling interval in terms of delay. It 1224 needs twice calculation to have this statistic over both time and 1225 space dimensions. We name this kind of statistics 2-level statistics 1226 to distinct with those 1-level statistics calculated over either 1227 space or time dimension. It can be easily prove that no matter over 1228 which dimension a 2-level statistic is calculated first, the results 1229 are the same. I.e. one can calculate the 2-level delay mean using 1230 the Matrix M by having the 1-level delay mean over the time dimension 1231 first and then calculate the mean of the obtained vector to find out 1232 the 2-level delay mean. Or, he can do the 1-level statistic 1233 calculation over the space dimension first and then have the 2-level 1234 delay mean. Both two results will be exactly the same. Therefore, 1235 when define a 2-level statistic, there is no need to specify in which 1236 procedure the calculation should follow. 1238 Comment: The above statement depends on whether the order of 1239 operations has any affect on the outcome. 1241 Many statistics can be defined for the proposed one-to-group metrics 1242 over either the space dimension or the time dimension or both. This 1243 memo treats the case where a stream of packets from the Source 1244 results in a sample at each of the Receivers in the Group, and these 1245 samples are each summarized with the usual statistics employed in 1246 one-to-one communication. New statistic definitions are presented, 1247 which summarize the one-to-one statistics over all the Receivers in 1248 the Group. 1250 7.1. Discussion on the Impact of packet loss on statistics 1252 The packet loss does have effects on one-way metrics and their 1253 statistics. For example, the lost packet can result an infinite one- 1254 way delay. It is easy to handle the problem by simply ignoring the 1255 infinite value in the metrics and in the calculation of the 1256 corresponding statistics. However, the packet loss has so strong 1257 impact on the statistics calculation for the one-to-group metrics 1258 that it can not be solved by the same method used for one-way 1259 metrics. This is due to the complex of building a Matrix, which is 1260 needed for calculation of the statistics proposed in this memo. 1262 The situation is that measurement results obtained by different end 1263 users might have different packet loss pattern. For example, for 1264 User1, packet A was observed lost. And for User2, packet A was 1265 successfully received but packet B was lost. If the method to 1266 overcome the packet loss for one-way metrics is applied, the two 1267 singleton sets reported by User1 and User2 will be different in terms 1268 of the transmitted packets. Moreover, if User1 and User2 have 1269 different number of lost packets, the size of the results will be 1270 different. Therefore, for the centralized calculation, the reference 1271 point will not be able to use these two results to build up the group 1272 Matrix and can not calculate the statistics. In an extreme 1273 situation, no single packet arrives all users in the measurement and 1274 the Matrix will be empty. One of the possible solutions is to 1275 replace the infinite/undefined delay value by the average of the two 1276 adjacent values. For example, if the result reported by user1 is { 1277 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1278 is an undefined value, the reference point can replace it by R1dTK = 1279 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1280 build up the group Matrix with an estimated value R1dTK. There are 1281 other possible solutions such as using the overall mean of the whole 1282 result to replace the infinite/undefined value, and so on. It is out 1283 of the scope of this memo. 1285 For the distributed calculation, the reported statistics might have 1286 different "weight" to present the group performance, which is 1287 especially true for delay and ipdv relevant metrics. For example, 1288 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1289 in Figure. 8 without any packet loss and User2 calculates the R2DM 1290 with N-2 packet loss. The R1DM and R2DM should not be treated with 1291 equal weight because R2DM was calculated only based on 2 delay values 1292 in the whole sample interval. One possible solution is to use a 1293 weight factor to mark every statistic value sent by users and use 1294 this factor for further statistic calculation. 1296 7.2. General Metric Parameters 1298 o Src, the IP address of a host 1300 o G, the Group IP address 1302 o N, the number of Receivers (Recv1, Recv2, ... RecvN) 1304 o T, a time (start of test interval) 1306 o Tf, a time (end of test interval) 1308 o K, the number of packets sent from the source during the test 1309 interval 1311 o J[n], the number of packets received at a particular Receiver, n, 1312 where 1<=n<=N 1314 o lambda, a rate in reciprocal seconds (for Poisson Streams) 1316 o incT, the nominal duration of inter-packet interval, first bit to 1317 first bit (for Periodic Streams) 1319 o T0, a time that MUST be selected at random from the interval [T, 1320 T+I] to start generating packets and taking measurements (for 1321 Periodic Streams) 1323 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1324 Source Measurement Point) 1326 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1327 assigned to packets that arrive within a "reasonable" time 1329 o Tmax, a maximum waiting time for packets at the destination, set 1330 sufficiently long to disambiguate packets with long delays from 1331 packets that are discarded (lost), thus the distribution of delay 1332 is not truncated 1334 o dT, shorthand notation for a one-way delay singleton value 1336 o L, shorthand notation for a one-way loss singleton value, either 1337 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1338 the destination within TstampSrc + Tmax, may be indexed over n 1339 Receivers 1341 o DV, shorthand notation for a one-way delay variation singleton 1342 value 1344 7.3. One-to-Group one-way Delay Statistics 1346 This section defines the overall one-way delay statistics for an 1347 entire Group or receivers. For example, we can define the group mean 1348 delay, as illustrated below. This is a metric designed to summarize 1349 the whole matrix. 1350 Recv /----------- Sample -------------\ Stats Group Stat 1352 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1353 | 1354 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 1355 | 1356 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD 1357 . | 1358 . | 1359 . | 1360 n RndT1 RndT2 RndT3 ... RndTk RnDM / 1362 Figure 10: One-to-GroupGroup Mean Delay 1364 where: 1366 R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at 1367 Receiver 1 for packet 1. 1369 R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 1370 for the sample of packets (1,...K). 1372 GMD is the mean of the sample means over all Receivers (1, ...N). 1374 7.3.1. Definition and Metric Units 1376 Using the parameters above, we obtain the value of Type-P-One-way- 1377 Delay singleton for all packets sent during the test interval at each 1378 Receiver (Destination), as per [RFC2679]. For each packet that 1379 arrives within Tmax of its sending time, TstampSrc, the one-way delay 1380 singleton (dT) will be a finite value in units of seconds. 1381 Otherwise, the value of the singleton is Undefined. 1383 For each packet [i] that has a finite One-way Delay at Receiver n (in 1384 other words, excluding packets which have undefined one-way delay): 1386 Type-P-Finite-One-way-Delay-Receiver-n-[i] = 1388 = TstampRecv[i] - TstampSrc[i] 1390 The units of Finite one-way delay are seconds, with sufficient 1391 resolution to convey 3 significant digits. 1393 7.3.2. Sample Mean Statistic 1395 This section defines the Sample Mean at each of N Receivers. 1397 Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = 1398 J[n] 1399 --- 1400 1 \ 1401 --- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] 1402 J[n] / 1403 --- 1404 i = 1 1406 Figure 11: Type-P-Finite-One-way-Delay-Mean-Receiver-n 1408 where all packets i= 1 through J[n] have finite singleton delays. 1410 7.3.3. One-to-Group Mean Delay Statistic 1412 This section defines the Mean One-way Delay calculated over the 1413 entire Group (or Matrix). 1415 Type-P-One-to-Group-Mean-Delay = GMD = 1416 N 1417 --- 1418 1 \ 1419 - * > RnDM 1420 N / 1421 --- 1422 n = 1 1424 Figure 12: Type-P-One-to-Group-Mean-Delay 1426 Note that the Group Mean Delay can also be calculated by summing the 1427 Finite one-way Delay singletons in the Matrix, and dividing by the 1428 number of Finite One-way Delay singletons. 1430 7.3.4. One-to-Group Range of Mean Delays 1432 This section defines a metric for the range of mean delays over all N 1433 receivers in the Group, (R1DM, R2DM,...RnDM). 1435 Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1437 7.3.5. One-to-Group Maximum of Mean Delays 1439 This section defines a metrics for the maximum of mean delays over 1440 all N receivers in the Group, (R1DM, R2DM,...RnDM). 1442 Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) 1444 7.4. One-to-Group one-way Loss Statistics 1446 This section defines the overall 1-way loss statistics for an entire 1447 Group. For example, we can define the group loss ratio, as 1448 illustrated below. This is a metric designed to summarize the entire 1449 Matrix. 1451 Recv /----------- Sample ----------\ Stats Group Stat 1453 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1454 | 1455 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1456 | 1457 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR 1458 . | 1459 . | 1460 . | 1461 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1463 Figure 13: One-to-Group Loss Ratio 1465 where: 1467 R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 1468 for packet 1. 1470 R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the 1471 sample of packets (1,...K). 1473 GLR is the loss ratio over all Receivers (1, ..., N). 1475 7.4.1. One-to-Group Loss Ratio 1477 The overall Group loss ratio id defined as 1479 Type-P-One-to-Group-Loss-Ratio = 1480 K,N 1481 --- 1482 1 \ 1483 = --- * > L(k,n) 1484 K*N / 1485 --- 1486 k,n = 1 1488 Figure 14 1490 ALL Loss ratios are expressed in units of packets lost to total 1491 packets sent. 1493 7.4.2. One-to-Group Loss Ratio Range 1495 Given a Matrix of loss singletons as illustrated above, determine the 1496 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1497 according to the definitions and method of [RFC2680]. The Type-P- 1498 One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- 1499 way-Loss-Ratio illustrated above are equivalent metrics. In terms of 1500 the parameters used here, these metrics definitions can be expressed 1501 as 1503 Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = 1504 K 1505 --- 1506 1 \ 1507 - * > RnLk 1508 K / 1509 --- 1510 k = 1 1512 Figure 15: Type-P-One-way-Loss-Ratio-Receiver-n 1514 The One-to-Group Loss Ratio Range is defined as 1516 Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) 1518 It is most effective to indicate the range by giving both the max and 1519 minimum loss ratios for the Group, rather than only reporting the 1520 difference between them. 1522 7.4.3. Comparative Loss Ratio 1524 Usually, the number of packets sent is used in the denominator of 1525 packet loss ratio metrics. For the comparative metrics defined here, 1526 the denominator is the maximum number of packets received at any 1527 receiver for the sample and test interval of interest. 1529 The Comparative Loss Ratio is defined as 1531 Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = 1532 K 1533 --- 1534 \ 1535 > Ln(k) 1536 / 1537 --- 1538 k=1 1539 = ----------------------------- 1540 / K \ 1541 | --- | 1542 | \ | 1543 K - Min | > Ln(k) | 1544 | / | 1545 | --- | 1546 \ k=1 / N 1548 Figure 16: Type-P-Comp-Loss-Ratio-Receiver-n 1550 7.5. One-to-Group one-way Delay Variation Statistics 1552 There are two delay variation (DV) statistics that summarize the 1553 performance over the Group: the maximum DV over all receivers and the 1554 minimum DV over all receivers (where DV is a point-to-point metric). 1555 For each receiver, the DV is usually expressed as the 1-10^(-3) 1556 quantile of one-way delay minus the minimum one-way delay. 1558 8. Measurement Methods: Scaleability and Reporting 1560 Virtually all the guidance on measurement processes supplied by the 1561 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1562 scenarios is applicable here in the spatial and multiparty 1563 measurement scenario. The main difference is that the spatial and 1564 multiparty configurations require multiple measurement points where a 1565 stream of singletons will be collected. The amount of information 1566 requiring storage grows with both the number of metrics and the 1567 number of measurement points, so the scale of the measurement 1568 architecture multiplies the number of singleton results that must be 1569 collected and processed. 1571 It is possible that the architecture for results collection involves 1572 a single aggregation point with connectivity to all the measurement 1573 points. In this case, the number of measurement points determines 1574 both storage capacity and packet transfer capacity of the host acting 1575 as the aggregation point. However, both the storage and transfer 1576 capacity can be reduced if the measurement points are capable of 1577 computing the summary statistics that describe each measurement 1578 interval. This is consistent with many operational monitoring 1579 architectures today, where even the individual singletons may not be 1580 stored at each measurement point. 1582 In recognition of the likely need to minimize form of the results for 1583 storage and communication, the Group metrics above have been 1584 constructed to allow some computations on a per-Receiver basis. This 1585 means that each Receiver's statistics would normally have an equal 1586 weight with all other Receivers in the Group (regardless of the 1587 number of packets received). 1589 8.1. Computation methods 1591 The scalability issue can be raised when there are thousands of 1592 points of interest in a group who are trying to send back the 1593 measurement results to the reference point for further processing and 1594 analysis. The points of interest can send either the whole measured 1595 sample or only the calculated statistics. The former one is a 1596 centralized statistic calculation method and the latter one is a 1597 distributed statistic calculation method. The sample should include 1598 all metrics parameters, the values and the corresponding sequence 1599 numbers. The transmission of the whole sample can cost much more 1600 bandwidth than the transmission of the statistics that should include 1601 all statistic parameters specified by policies and the additional 1602 information about the whole sample, such as the size of the sample, 1603 the group address, the address of the point of interest, the ID of 1604 the sample session, and so on. Apparently, the centralized 1605 calculation method can require much more bandwidth than the 1606 distributed calculation method when the sample size is big. This is 1607 especially true when the measurement has huge number of the points of 1608 interest. It can lead to a scalability issue at the reference point 1609 by over load the network resources. The distributed calculation 1610 method can save much more bandwidth and release the pressure of the 1611 scalability issue at the reference point side. However, it can 1612 result in the lack of information because not all measured singletons 1613 are obtained for building up the group matrix. The performance over 1614 time can be hidden from the analysis. For example, the loss pattern 1615 can be missed by simply accepting the loss ratio as well as the delay 1616 pattern. This tradeoff between the bandwidth consuming and the 1617 information acquiring has to be taken into account when design the 1618 measurement campaign to optimize the measurement results delivery. 1619 The possible solution could be to transit the statistic parameters to 1620 the reference point first to obtain the general information of the 1621 group performance. If the detail results are required, the reference 1622 point should send the requests to the points of interest, which could 1623 be particular ones or the whole group. This procedure can happen in 1624 the off peak time and can be well scheduled to avoid delivery of too 1625 many points of interest at the same time. Compression techniques can 1626 also be used to minimize the bandwidth required by the transmission. 1627 This could be a measurement protocol to report the measurement 1628 results. It is out of the scope of this memo. 1630 8.2. Measurement 1632 To prevent any bias in the result, the configuration of a one-to-many 1633 measure must take in consideration that implicitly more packets will 1634 to be routed than send and selects a test packets rate that will not 1635 impact the network performance. 1637 8.3. Effect of Time and Space Aggregation Order on Stats 1639 This section presents the impact of the aggregation order on the 1640 scalability of the reporting and of the computation. It makes the 1641 hypothesis that receivers are managed remotely and not co-located. 1643 multimetrics samples represented a matrix as illustrated below 1645 Point of 1646 interest 1647 1 R1S1 R1S1 R1S1 ... R1Sk \ 1648 | 1649 2 R2S1 R2S2 R2S3 ... R2Sk | 1650 | 1651 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1652 . | 1653 . | 1654 . | 1655 n RnS1 RnS2 RnS3 ... RnSk / 1657 S1M S2M S3M ... SnM Stats over space 1659 \------------- ------------/ 1660 \/ 1661 Stat over space and time 1663 Figure 17: Impact of space aggregation on multimetrics Stat 1665 2 methods are available to compute statistics on the resulting 1666 matrix: 1668 o metric is computed over time and then over space; 1669 o metric is computed over space and then over time. 1671 They differ only by the order of the time and of the space 1672 aggregation. View as a matrix this order is neutral as does not 1673 impact the result, but the impact on a measurement deployment is 1674 critical. 1676 In both cases the volume of data to report is proportional to the 1677 number of probes. But there is a major difference between these 2 1678 methods: 1680 method2: In space and time aggregation mode the volume of data to 1681 collect is proportional to the number of test packets received; 1682 Each received packet RiSi triggers out a block of data that must 1683 be reported to a common place for computing the stat over space; 1685 method1: In time and space aggregation mode the volume of data to 1686 collect is proportional to the period of aggregation, so it does 1687 not depend on the number of packet received; 1689 Method 2 property has severe drawbacks in terms of security and 1690 dimensioning: 1692 The increasing of the rate of the test packets may result in a 1693 sort of DoS toward the computation points; 1695 The dimensioning of a measurement system is quite impossible to 1696 validate. 1698 The time aggregation interval provides the reporting side with a 1699 control of various collecting aspects such as bandwidth and 1700 computation and storage capacities. So this draft defines metrics 1701 based on method 1. 1703 Note: In some specific cases one may need sample of singletons over 1704 space. To address this need it is suggested firstly to limit the 1705 number of test and the number of test packets per seconds. Then 1706 reducing the size of the sample over time to one packet give sample 1707 of singleton over space.. 1709 8.3.1. Impact on group stats 1711 2 methods are available to compute group statistics: 1713 o method1: Figure 10 andFigure 13 illustrate the method chosen: the 1714 one-to-one statistic is computed per interval of time before the 1715 computation of the mean over the group of receivers; 1717 o method2: Figure 17 presents the second one, metric is computed 1718 over space and then over time. 1720 8.3.2. Impact on spatial stats 1722 2 methods are available to compute spatial statistics: 1724 o method 1: spatial segment metrics and statistics are preferably 1725 computed over time by each points of interest; 1727 o method 2: Vectors metrics are intrinsically instantaneous space 1728 metrics which must be reported using method2 whenever 1729 instantaneous metrics information is needed. 1731 9. Manageability Considerations 1733 Usually IPPM WG documents defines each metric reporting within its 1734 definition. This document defines the reporting of all the metrics 1735 introduced in a single section to provide consistent information 1736 while avoiding repetitions. The aim is to contribute to the work of 1737 the WG on the reporting and to satisfy IESG recommendation of 1738 gathering manageability considerations in a dedicated section. 1740 Data models of spatial and one-to-group metrics are similar excepted 1741 that points of interests of spatial vectors must be ordered. 1743 The complexity of the reporting relies on the number of points of 1744 interests. 1746 9.1. Reporting spatial metric 1748 The reporting of spatial metrics shares a lot of aspects with 1749 RFC2679-80. New ones are common to all the definitions and are 1750 mostly related to the reporting of the path and of methodology 1751 parameters that may bias raw results analysis. This section presents 1752 these specific parameters and then lists exhaustively the parameters 1753 that shall be reported. 1755 9.1.1. Path 1757 End-to-end metrics can't determine the path of the measure despite 1758 IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]). 1759 Spatial metrics vectors provide this path. The report of a spatial 1760 vector must include the points of interests involved: the sub set of 1761 the hosts of the path participating to the instantaneous measure. 1763 9.1.2. Host order 1765 A spatial vector must order the points of interest according to their 1766 order in the path. It is highly suggested to use the TTL in IPv4, 1767 the Hop Limit in IPv6 or the corresponding information in MPLS. 1769 The report of a spatial vector must include the ordered list of the 1770 hosts involved in the instantaneous measure. 1772 9.1.3. Timestamping bias 1774 The location of the point of interest inside a node influences the 1775 timestamping skew and accuracy. As an example, consider that some 1776 internal machinery delays the timestamping up to 3 milliseconds then 1777 the minimal uncertainty reported be 3 ms if the internal delay is 1778 unknown at the time of the timestamping. 1780 The report of a spatial vector must include the uncertainty of the 1781 timestamping compared to wire time. 1783 9.1.4. Reporting spatial One-way Delay 1785 The reporting includes information to report for one-way-delay as the 1786 Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. 1788 9.2. Reporting One-to-group metric 1790 All reporting rules described in RFC2679-80 apply to the 1791 corresponding One-to-group metrics RFC2679-80. In addition, several 1792 new parameters are needed to report which are common to all the 1793 metrics and are presented here. 1795 9.2.1. Path 1797 As suggested by the RFC2679-80, the path traversed by the packet 1798 SHOULD be reported, if possible. For One-to-group metrics, there is 1799 a path tree SHOULD be reported rather than A path. This is even more 1800 impractical. If, by anyway, partial information is available to 1801 report, it might not be as valuable as it is in the one-to-one case 1802 because the incomplete path might be difficult to identify its 1803 position in the path tree. For example, how many points of interest 1804 are reached by the packet traveled through this incomplete path? 1805 However, the multicast path tree is normally more stable than 1806 unicast, which is dependant on multicast routing protocols. For 1807 example, the PIM-SM protocol [RFC4601] initializes the multicast 1808 route before any data packets are sent to the receivers. 1810 9.2.2. Group size 1812 The group size should be reported as one of the critical management 1813 parameters. Unlike the spatial metrics, there is no need of order of 1814 points of interests. 1816 9.2.3. Timestamping bias 1818 It is the same as described in section 9.1.3. 1820 9.2.4. Reporting One-to-group One-way Delay 1822 It is the same as described in section 9.1.4. 1824 9.2.5. Measurement method 1826 As explained in section 8, the measurement method will have impact on 1827 the analysis of the measurement result. Therefore, it should be 1828 reported. 1830 9.3. Metric identification 1832 IANA assigns each metric defined by the IPPM WG with a unique 1833 identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. 1835 To avoid misunderstanding and to address specific reporting 1836 constraints, section [passive_metrics] of this memo gives distinct 1837 names to passive metrics and Section 13 requests a distinct metric 1838 identifier for each metrics the memo defines. 1840 As it is crucial for composition of metrics to know the methodology 1841 used (e.g. generation method, detection method...), the report of a 1842 metric result used in composition of metrics MUST always include its 1843 metric identifier. 1845 9.4. Reporting data model 1847 This section presents the elements of the datamodel and the usage of 1848 the information reported for real network performance analysis. It 1849 is out of the scope of this section to define how the information is 1850 reported. 1852 The data model is build with pieces of information introduced and 1853 explained in one-way delay definitions [RFC2679], in packet loss 1854 definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It 1855 includes not only information given by "Reporting the metric" 1856 sections but by sections "Methodology" and "Errors and Uncertainties" 1857 sections. 1859 Following are the elements of the datamodel taken from end-to-end 1860 definitions referred in this memo and from spatial and multicast 1861 metrics it defines: 1863 o Packet_type, The Type-P of test packets (Type-P); 1865 o Packet_length, a packet length in bits (L); 1867 o Src_host, the IP address of the sender; 1869 o Dst_host, the IP address of the receiver; 1871 o Hosts_serie: , a list of points of interest; 1873 o Loss_threshold: The threshold of infinite delay; 1875 o Systematic_error: constant delay between wire time and 1876 timestamping; 1878 o Calibration_error: maximal uncertainty; 1880 o Src_time, the sending time for a measured packet; 1882 o Dst_time, the receiving time for a measured packet; 1884 o Result_status : an indicator of usability of a result 'Resource 1885 exhaustion' 'infinite', 'lost'; 1887 o Delays_serie: a list of delays; 1889 o Losses_serie: , a list of Boolean values 1890 (spatial) or a set of Boolean values (one-to-group); 1892 o Result_status_serie: a list of results status; 1894 o dT: a delay; 1896 o Singleton_number: a number of singletons; 1898 o Observation_duration: An observation duration; 1900 o metric_identifier. 1902 Following is the information of each vector that should be available 1903 to compute samples: 1905 o Packet_type; 1907 o Packet_length; 1909 o Src_host, the sender of the packet; 1911 o Dst_host, the receiver of the packet, apply only for spatial 1912 vectors; 1914 o Hosts_serie: not ordered for one-to-group; 1916 o Src_time, the sending time for the measured packet; 1918 o dT, the end-to-end one-way delay for the measured packet, apply 1919 only for spatial vectors; 1921 o Delays_serie: apply only for delays and ipdv vector, not ordered 1922 for one-to-group; 1924 o Losses_serie: apply only for packets loss vector, not ordered for 1925 one-to-group; 1927 o Result_status_serie; 1929 o Observation_duration: the difference between the time of the last 1930 singleton and the time of the first singleton. 1932 o Following is the context information (measure, points of 1933 interests) that should be available to compute samples : 1935 * Loss threshold; 1937 * Systematic error: constant delay between wire time and 1938 timestamping; 1940 * Calibration error: maximal uncertainty; 1942 A spatial or a one-to-group sample is a collection of singletons 1943 giving the performance from the sender to a single point of interest. 1944 Following is the information that should be available for each sample 1945 to compute statistics: 1947 o Packet_type; 1949 o Packet_length; 1951 o Src_host, the sender of the packet; 1952 o Dst_host, the receiver of the packet; 1954 o Start_time, the sending time of the first packet; 1956 o Delays_serie: apply only for delays and ipdv samples; 1958 o Losses_serie: apply only for packets loss samples; 1960 o Result_status_serie; 1962 o Observation_duration: the difference between the time of the last 1963 singleton of the last sample and the time of the first singleton 1964 of the first sample. 1966 o Following is the context information (measure, points of 1967 interests) that should be available to compute statistics : 1969 * Loss threshold; 1971 * Systematic error: constant delay between wire time and 1972 timestamping; 1974 * Calibration error: maximal uncertainty; 1976 Following is the information of each statistic that should be 1977 reported: 1979 o Result; 1981 o Start_time; 1983 o Duration; 1985 o Result_status; 1987 o Singleton_number, the number of singletons the statistic is 1988 computed on; 1990 10. Open issues 1992 Do we define min, max, avg of for each segment metrics ? 1994 having the maximum loss metric value could be interesting. Say, 1995 the segment between router A and B always contributes loss metric 1996 value of "1" means it could be the potential problem segment. 1998 Uploading dTi of each Hi consume a lot of bandwidth. Computing 1999 statistics (min, max and avg) of dTi locally in each Hi reduce the 2000 bandwidth consumption. 2002 11. Security Considerations 2004 Spatial and one-to-group metrics are defined on the top of end-to-end 2005 metrics. Security considerations discussed in One-way delay metrics 2006 definitions of [RFC2679] , in packet loss metrics definitions 2007 of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] 2008 apply to multimetrics. 2010 11.1. Spatial metrics 2012 Malicious generation of packets with spoofing addresses may corrupt 2013 the results without any possibility to detect the spoofing. 2015 Malicious generation of packets which match systematically the hash 2016 function used to detect the packets may lead to a DoS attack toward 2017 the point of reference. 2019 11.2. one-to-group metric 2021 The reporting of measurement results from a huge number of probes may 2022 overload the network the reference point is attach to, the reference 2023 point network interfaces and the reference point computation 2024 capacities. 2026 The configuration of a measure must take in consideration that 2027 implicitly more packets will to be routed than send and selects a 2028 test packets rate accordingly. Collecting statistics from a huge 2029 number of probes may overload any combination of the network where 2030 the measurement controller is attach to, measurement controller 2031 network interfaces and measurement controller computation capacities. 2033 one-to-group metrics measurement should consider using source 2034 authentication protocols, standardized in the MSEC group, to avoid 2035 fraud packet in the sampling interval. The test packet rate could be 2036 negotiated before any measurement session to avoid deny of service 2037 attacks. 2039 12. Acknowledgments 2041 Lei would like to acknowledge Prof. Zhili Sun from CCSR, University 2042 of Surrey, for his instruction and helpful comments on this work. 2044 13. IANA Considerations 2046 Metrics defined in this memo Metrics defined in this memo are 2047 designed to be registered in the IANA IPPM METRICS REGISTRY as 2048 described in initial version of the registry [RFC4148] : 2050 IANA is asked to register the following metrics in the IANA-IPPM- 2051 METRICS-REGISTRY-MIB : 2053 Spatial-One-way-Delay-Vector OBJECT-IDENTITY 2055 STATUS current 2057 DESCRIPTION 2059 "Type-P-Spatial-One-way-Delay-Vector" 2061 REFERENCE 2063 "Reference "RFCyyyy, section 4.1." 2065 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2066 note 2068 := { ianaIppmMetrics nn } -- IANA assigns nn 2070 Spatial-Packet-Loss-Vector OBJECT-IDENTITY 2072 STATUS current 2074 DESCRIPTION 2076 "Type-P-Spatial-Packet-Loss-Vector" 2078 REFERENCE 2080 "Reference "RFCyyyy, section 4.2." 2082 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2083 note 2085 := { ianaIppmMetrics nn } -- IANA assigns nn 2087 Spatial-One-way-ipdv-Vector OBJECT-IDENTITY 2088 STATUS current 2090 DESCRIPTION 2092 "Type-P-Spatial-One-way-ipdv-Vector" 2094 REFERENCE 2096 "Reference "RFCyyyy, section 4.3." 2098 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2099 note 2101 := { ianaIppmMetrics nn } -- IANA assigns nn 2103 Spatial-Segment-One-way-Delay-Stream OBJECT-IDENTITY 2105 STATUS current 2107 DESCRIPTION 2109 "Type-P-Spatial-Segment-One-way-Delay-Stream" 2111 REFERENCE 2113 "Reference "RFCyyyy, section 5.1." 2115 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2116 note 2118 := { ianaIppmMetrics nn } -- IANA assigns nn 2120 Spatial-Segment-Packet-Loss-Stream OBJECT-IDENTITY 2122 STATUS current 2124 DESCRIPTION 2126 "Type-P-Spatial-Segment-Packet-Loss-Stream" 2128 REFERENCE 2130 "Reference "RFCyyyy, section 5.2." 2132 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2133 note 2135 := { ianaIppmMetrics nn } -- IANA assigns nn 2137 Spatial-Segment-One-way-ipdv-Stream OBJECT-IDENTITY 2139 STATUS current 2141 DESCRIPTION 2143 "Type-P-Spatial-Segment-ipdv-Stream" 2145 REFERENCE 2147 "Reference "RFCyyyy, section 5.3." 2149 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2150 note 2152 := { ianaIppmMetrics nn } -- IANA assigns nn 2154 -- One-to-group metrics 2156 one-to-group-One-way-Delay-Vector OBJECT-IDENTITY 2158 STATUS current 2160 DESCRIPTION 2162 "Type-P-one-to-group-One-way-Delay-Vector" 2164 REFERENCE 2166 "Reference "RFCyyyy, section 5.1." 2168 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2169 note 2171 := { ianaIppmMetrics nn } -- IANA assigns nn 2173 one-to-group-One-way-Packet-Loss-Vector OBJECT-IDENTITY 2175 STATUS current 2177 DESCRIPTION 2179 "Type-P-one-to-group-One-way-Packet-Loss-Vector" 2181 REFERENCE 2183 "Reference "RFCyyyy, section 5.2." 2184 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2185 note 2187 := { ianaIppmMetrics nn } -- IANA assigns nn 2189 one-to-group-One-way-ipdv-Vector OBJECT-IDENTITY 2191 STATUS current 2193 DESCRIPTION 2195 "Type-P-one-to-group-One-way-ipdv-Vector" 2197 REFERENCE 2199 "Reference "RFCyyyy, section 5.3." 2201 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2202 note 2204 := { ianaIppmMetrics nn } -- IANA assigns nn 2206 One-to-Group-Mean-Delay OBJECT-IDENTITY 2208 STATUS current 2210 DESCRIPTION 2212 "Type-P-One-to-Group-Mean-Delay" 2214 REFERENCE 2216 "Reference "RFCyyyy, section 6.3.3." 2218 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2219 note 2221 := { ianaIppmMetrics nn } -- IANA assigns nn 2223 One-to-Group-Range-Mean-Delay OBJECT-IDENTITY 2225 STATUS current 2227 DESCRIPTION 2229 "Type-P-One-to-Group-Range-Mean-Delay" 2231 REFERENCE 2233 "Reference "RFCyyyy, section 6.3.4." 2235 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2236 note 2238 := { ianaIppmMetrics nn } -- IANA assigns nn 2240 One-to-Group-Max-Mean-Delay OBJECT-IDENTITY 2242 STATUS current 2244 DESCRIPTION 2246 "Type-P-One-to-Group-Max-Mean-Delay" 2248 REFERENCE 2250 "Reference "RFCyyyy, section 6.3.5." 2252 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2253 note 2255 := { ianaIppmMetrics nn } -- IANA assigns nn 2257 One-to-Group-Loss-Ratio OBJECT-IDENTITY 2259 STATUS current 2261 DESCRIPTION 2263 "Type-P-One-to-Group-Loss-Ratio" 2265 REFERENCE 2267 "Reference "RFCyyyy, section 6.4.1." 2269 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2270 note 2272 := { ianaIppmMetrics nn } -- IANA assigns nn 2274 -- 2276 One-to-Group-Loss-Ratio-Range OBJECT-IDENTITY 2277 STATUS current 2279 DESCRIPTION 2281 "Type-P-One-to-Group-Loss-Ratio-Range" 2283 REFERENCE 2285 "Reference "RFCyyyy, section 6.4.2." 2287 -- RFC Ed.: replace yyyy with actual RFC number & remove this 2288 note 2290 := { ianaIppmMetrics nn } -- IANA assigns nn 2292 -- 2294 14. References 2296 14.1. Normative References 2298 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2299 "Framework for IP Performance Metrics", RFC 2330, 2300 May 1998. 2302 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2303 Delay Metric for IPPM", RFC 2679, September 1999. 2305 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2306 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2308 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2309 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2310 November 2002. 2312 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2313 Registry", BCP 108, RFC 4148, August 2005. 2315 14.2. Informative References 2317 [I-D.ietf-ippm-spatial-composition] 2318 Morton, A. and E. Stephan, "Spatial Composition of 2319 Metrics", draft-ietf-ippm-spatial-composition-05 (work in 2320 progress), November 2007. 2322 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 2323 Connectivity", RFC 2678, September 1999. 2325 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2326 Delay Metric for IPPM", RFC 2681, September 1999. 2328 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 2329 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 2330 July 2001. 2332 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 2333 Metrics", RFC 3357, August 2002. 2335 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2336 performance measurement with periodic streams", RFC 3432, 2337 November 2002. 2339 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 2340 Measurement Protocol (OWAMP) Requirements", RFC 3763, 2341 April 2004. 2343 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2344 Zekauskas, "A One-way Active Measurement Protocol 2345 (OWAMP)", RFC 4656, September 2006. 2347 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2348 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2349 November 2006. 2351 [passive_metrics] 2352 "", 2005. 2354 Authors' Addresses 2356 Stephan Emile 2357 France Telecom Division R&D 2358 2 avenue Pierre Marzin 2359 Lannion, F-22307 2361 Fax: +33 2 96 05 18 52 2362 Email: emile.stephan@orange-ftgroup.com 2363 Lei Liang 2364 CCSR, University of Surrey 2365 Guildford 2366 Surrey, GU2 7XH 2368 Fax: +44 1483 683641 2369 Email: L.Liang@surrey.ac.uk 2371 Al Morton 2372 200 Laurel Ave. South 2373 Middletown, NJ 07748 2374 USA 2376 Phone: +1 732 420 1571 2377 Email: acmorton@att.com 2379 Full Copyright Statement 2381 Copyright (C) The IETF Trust (2007). 2383 This document is subject to the rights, licenses and restrictions 2384 contained in BCP 78, and except as set forth therein, the authors 2385 retain all their rights. 2387 This document and the information contained herein are provided on an 2388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2395 Intellectual Property 2397 The IETF takes no position regarding the validity or scope of any 2398 Intellectual Property Rights or other rights that might be claimed to 2399 pertain to the implementation or use of the technology described in 2400 this document or the extent to which any license under such rights 2401 might or might not be available; nor does it represent that it has 2402 made any independent effort to identify any such rights. Information 2403 on the procedures with respect to rights in RFC documents can be 2404 found in BCP 78 and BCP 79. 2406 Copies of IPR disclosures made to the IETF Secretariat and any 2407 assurances of licenses to be made available, or the result of an 2408 attempt made to obtain a general license or permission for the use of 2409 such proprietary rights by implementers or users of this 2410 specification can be obtained from the IETF on-line IPR repository at 2411 http://www.ietf.org/ipr. 2413 The IETF invites any interested party to bring to its attention any 2414 copyrights, patents or patent applications, or other proprietary 2415 rights that may cover technology that may be required to implement 2416 this standard. Please address the information to the IETF at 2417 ietf-ipr@ietf.org. 2419 Acknowledgment 2421 Funding for the RFC Editor function is provided by the IETF 2422 Administrative Support Activity (IASA).