idnits 2.17.1 draft-ietf-ippm-multimetrics-02.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 on line 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1371. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 416: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 522: '... [RFC2679] says that the path traversed by the packet SHOULD be...' RFC 2119 keyword, line 545: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 658: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 733: '...ipdv measurement SHOULD be respectful ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 22, 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-01 Summary: 7 errors (**), 0 flaws (~~), 2 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: April 25, 2007 University of Surrey 6 A. Morton 7 AT&T Labs 8 October 22, 2006 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-02 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 April 25, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The IETF IP Performance Metrics (IPPM) working group has standardized 45 metrics for measuring end-to-end performance between 2 points. This 46 memo defines 2 sets of metrics to extend these end-to-end ones. It 47 defines spatial metrics for measuring the performance of segments 48 along a path and metrics for measuring the performance of a group of 49 users in multiparty communications. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Spatial metric points of interest . . . . . . . . . . . . 5 58 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 5 59 2.5. One-to-group metric points of interest . . . . . . . . . . 5 60 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 5 61 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Motivations for spatial and one-to-group metrics . . . . . . . 7 64 3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 8 66 3.3. Discussion on Group-to-one and Group-to-group metrics . . 9 67 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 9 68 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 10 69 4.2. A Definition of a sample of One-way Delay of a sub path . 12 70 4.3. A Definition for Spatial One-way Packet Loss Vector . . . 15 71 4.4. A Definition for Spatial One-way Jitter Vector . . . . . . 16 72 4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 18 73 4.6. Discussion on spatial statistics . . . . . . . . . . . . . 20 74 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 20 75 5.1. A Definition for one-to-group One-way Delay . . . . . . . 20 76 5.2. A Definition for one-to-group One-way Packet Loss . . . . 21 77 5.3. A Definition for one-to-group One-way Jitter . . . . . . . 21 78 5.4. Discussion on one-to-group statistics . . . . . . . . . . 23 79 6. Extension from one-to-one to one-to-many measurement . . . . . 26 80 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 88 Intellectual Property and Copyright Statements . . . . . . . . . . 30 90 1. Introduction 92 The metrics specified in this memo are built on notions introduced 93 and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. 94 The reader should be familiar with these documents. 96 This memo makes use of definitions of end-to-end One-way Delay 97 Metrics defined in the RFC 2679 [RFC2679] to define metrics for 98 decomposition of end-to-end one-way delays measurements. 100 This memo makes use of definitions of end-to-end One-way Packet loss 101 Metrics defined in the RFC 2680 [RFC2680] to define metrics for 102 decomposition of end-to-end one-way packet loss measurements. 104 The IPPM WG defined a framework for metric definitions and end-to-end 105 measurements: 107 o A general framework for defining performance metrics, described in 108 the Framework for IP Performance Metrics, RFC 2330 [RFC2330]; 110 o A One-way Active Measurement Protocol Requirements, RFC 3763 111 [RFC3763]; 113 o A One-way Active Measurement Protocol (OWAMP) [work in progress]; 115 o An IP Performance Metrics Registry , RFC 4148 [RFC4148]; 117 It specified a set of end-to-end metrics, which conform to this 118 framework: 120 o The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 122 o The One-way Delay Metric for IPPM, RFC 2679 [RFC2679]; 124 o The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680]; 126 o The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681]; 128 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 129 RFC 3148 [RFC3148]; 131 o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 133 o IP Packet Delay Variation Metric for IPPM, RFC 3393 [RFC3393]; 135 o Network performance measurement for periodic streams, RFC 3432 136 [RFC3432]; 138 o Packet Reordering Metric for IPPM [Work in progress]; 140 Based on these works, this memo defines 2 kinds of multi party 141 metrics. 143 Firstly it defines spatial metrics: 145 o A 'sample', called Type-P-Spatial-One-way-Delay-Vector, will be 146 introduced to divide an end-to-end Type-P-One-way-Delay in a 147 spatial sequence of one-way delays. 149 o A 'sample', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 150 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 151 in a spatial sequence of packet loss. 153 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 154 called Type-P-Spatial-One-way-Jitter-Vector, will be introduced to 155 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of 156 jitter. 158 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 159 called Type-P-subpath-One-way-Delay-Stream, will be introduced to 160 define the one-way-delay between a pair of host of the path. This 161 metric is similar to Type-P-One-way-Delay-Stream. 163 o Using Type-P-subpath-One-way-Delay-Stream, a 'sample' Type-P- 164 Passive-One-way-Delay-Stream will be introduced to define passive 165 metrics. These metrics are designed for pure passive measurement 166 methodology as introduced by PSAMP WG. 168 Then it defines one-to-group metrics. 170 o Using one test packet sent from one sender to a group of 171 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 172 Vector, will be introduced to define the list of Type-P-one-way- 173 delay between this sender and the group of receivers. 175 o Using one test packet sent from one sender to a group of 176 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 177 Loss-Vector, will be introduced to define the list of Type-P-One- 178 way-Packet-Loss between this sender and the group of receivers 180 o Using one test packet sent from one sender to a group of 181 receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- 182 Vector, will be introduced to define the list of Type-P-One-way- 183 ipdv between this sender and the group of receivers 185 o Then a discussion section presents the set of statistics that may 186 be computed on the top of these metrics to present the QoS in a 187 view of a group of users as well as the requirements of relative 188 QoS on multiparty communications. 190 2. Terminology 192 2.1. Multiparty metric 194 A metric is said to be multiparty if the definition involved more 195 than two sources or destinations in the measurements. All multiparty 196 metrics define a set of hosts called "points of interest", where one 197 host is the source and other hosts are the measurement collection 198 points. For example, if the set of points of interest is < ha, hb, 199 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 200 destinations, then measurements may be conducted between < ha, hb>, < 201 ha, hc>, ..., . 203 2.2. Spatial metric 205 A metric is said to be spatial if one of the hosts involved is 206 neither the source nor the destination of the metered packet. 208 2.3. Spatial metric points of interest 210 Points of interest of a spatial metric are the routers or sibling in 211 the path between source and destination (in addition to the source 212 and the destination themself). 214 2.4. One-to-group metric 216 A metric is said to be one-to-group if the measured packet is sent by 217 one source and (potentially) received by several destinations. Thus, 218 the topology of the communication group can be viewed as a centre- 219 distributed or server-client topology with the source as the centre/ 220 server in the topology. 222 2.5. One-to-group metric points of interest 224 Points of interest of One-to-group metrics are the set of host 225 destinations receiving packets from the source (in addition to the 226 source itself). 228 2.6. Reference point 230 The centre/server in the one-to-group measurement that is controlled 231 by network operators can be a very good reference point where 232 measurement data can be collected for further processing although the 233 actual measurements have to be carried out at all points of interest. 234 I.e., the measurement points will be all clients/receivers while the 235 reference point acts as source for the one-to-group metric. Thus, we 236 can define the reference point as the host while the statistic 237 calculation will be carried out. 239 2.7. Vector 241 A group of singletons is the set of results of the observation of the 242 behaviour of the same packet at different places of a network. 244 A Vector is a set of singletons, which are a set of results of the 245 observation of the behaviour of the same packet at different places 246 of a network at different time. For instance, if One-way delay 247 singletons abserved at N receivers for Packet P sent by the source 248 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 249 elements can be orgnized as {dT1, dT2,..., dTN}. The elements in one 250 vector are singletons distinct with each other in terms of both 251 measurement point and time. Given the vector V as an example, the 252 element dT1 is distinct from the rest by measured at receiver 1 at 253 time T1. Additional to a singleton, Vector gives information over a 254 space dimension. 256 2.8. Matrix 258 Several vectors can orgnize form up a Matrix, which contains results 259 observed in a sampling interval at different place of a network at 260 different time. For instance, given One-way delay vectors V1={dT11, 261 dT12,..., dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., 262 dTmN} for Packet P1, P2,...,Pm, we can have a One-way delay Matrix 263 {V1, V2,...,Vm}. Additional to the information given by a Vector, a 264 Matrix is more powerful to present network performance in both space 265 and time dimensions. It normally corresponding to a sample. 267 The relation among Singleton, Vector and Matrix can be shown in the 268 following Fig 1. 270 one to group Singleton 271 / Sample 272 Src Rcvr .............................. 273 ..................R1dT1 R1dT2 R1dT3 R1dT4 274 `:=-.._ 275 T `._ ``-..__ 276 `. `- R2dT1 R2dT2 R2dT3 R2dT4 277 `-. 278 `-. 279 `._R3dT1 R3dT2 R3dT3 R3dT4 281 Vector Matrix 282 (space) (time) 284 Figure 1. 286 3. Motivations for spatial and one-to-group metrics 288 All IPPM metrics are defined for end-to-end measurement. These 289 metrics provide very good guides for measurement in the pair 290 communications. However, further efforts should be put to define 291 metrics for multiparty measurements such as one to one trajectory 292 metrics and one to multipoint metrics. 294 3.1. spatial metrics 296 Decomposition of instantaneous end-to-end measures is needed: 298 o The PCE WG is extending existing protocols to permit remote path 299 computation and path computation quality, including inter domain. 300 One may say that in intra domain the decomposing the performance 301 of a path is not whished. However such decomposition is desirable 302 in interdomain to qualify each AS computation with the initial 303 request. So it is necessary to define standard spatial metrics 304 before going further in the computation of inter domain path with 305 QoS constraint. 307 o Traffic engineering and troubleshooting applications require 308 spatial views of the one-way delay consumption, identification of 309 the location of the lost of packets and the decomposition of the 310 jitter over the path. 312 o Monitoring the QoS of a multicast tree, of MPLS point-to- 313 multipoint and inter-domain communication require spatial 314 decomposition of the one-way delay, of the packet loss and of the 315 jitter. 317 o Composition of metrics is a need to scale in the measurement 318 plane. The definition of composition metrics is a work in 319 progress [I-D.ietf-ippm-spatial-composition]; . Spatial measure 320 give typically the individual performance of an intra domain 321 segment. It is the elementary piece of information to exchange 322 for measuring interdomain performance based on composition of 323 metrics. 325 o The PSAMP WG defines capabilities to sample packets in a way to to 326 support measurement. [I-D.boschi-ipfix-reducing-redundancy]; 327 defines a method to collect packets information to measure the 328 instantaneous spatial performance without injecting test traffic. 329 Consequently it is urgent to define a set of common spatial 330 metrics for passive and active techniques which respect the IPPM 331 framework [RFC2330]. This need is emphases by the fact that end- 332 to-end spatial measurement involves the 2 techniques; 334 3.2. One-to-group metrics 336 While the node-to-node based spatial measures can provide very useful 337 data in the view of each connection, we also need measures to present 338 the performance of a multiparty communication in the view of a group 339 with consideration that it involves a group of people rather than 340 two. As a consequence a simple one-way metric cannot describe the 341 multi-connection situation. We need some new metrics to collect 342 performance of all the connections for further statistics analysis. 343 A group of metrics are proposed in this stage named one-to-group 344 performance metrics based on the unicast metrics defined in IPPM WG. 345 One-to-group metrics are trying to composite one-way metrics from one 346 source to a group of destinations to make up new metrics. The 347 compositions are necessary for judging the network performance of 348 multiparty communications and can also be used to describe the 349 difference of the QoS served among a group of users. 351 One-to-group performance metrics are needed for several reasons: 353 o For designing and engineering multicast trees and MPLS point-to- 354 multipoint LSP; 356 o For evaluating and controlling of the quality of the multicast 357 services; 359 o For controlling the performance of the inter domain multicast 360 services; 362 o For presenting and evaluating the relative QoS requirements for 363 the multiparty communications. 365 To understand the connection situation between one source and any one 366 receiver in the multiparty communication group, we need the 367 collection of instantaneous end-to-end measures. It will give us 368 very detailed insight into each branch of the multicast tree in terms 369 of end-to-end absolute QoS. It can provide clear and helpful 370 information for engineers to identify the connection with problems in 371 a complex multiparty routing tree. 373 3.3. Discussion on Group-to-one and Group-to-group metrics 375 We note that points of interest can also be selected to define 376 measurements on Group-to-one and Group-to-group topologies. These 377 topologies are currently beyond the scope of this memo, because they 378 would involve multiple packets launched from different sources. 379 However, we can give some clues here on these two cases. 381 The measurements for group-to-one topology can be easily derived from 382 the one-to-group measurement. The measurement point is the reference 383 point that is acting as a receiver while all of clients/receivers 384 defined for one-to-group measurement act as sources in this case. 386 For the group-to-group connection topology, we can hardly define the 387 reference point and, therefore, have difficulty to define the 388 measurement points. However, we can always avoid this confusion by 389 treating the connections as one-to-group or group-to-one in our 390 measurements without consideration on how the real communication will 391 be carried out. For example, if one group of hosts < ha, hb, hc, 392 ..., hn > are acting as sources to send data to another group of 393 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 394 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 395 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 396 ..., Hm >. 398 4. Spatial metrics definitions 400 Spatial decomposition metrics are based on standard end-to-end 401 metrics. 403 The definition of a spatial metric is coupled with the corresponding 404 end-to-end metric. The methodoly is based on the measure of the same 405 test packet and parameters of the corresponding end-to-end metric. 407 4.1. A Definition for Spatial One-way Delay Vector 409 This section is coupled with the definition of Type-P-One-way-Delay. 410 When a parameter from section 3 of [RFC2679] is first used in this 411 section, it will be tagged with a trailing asterisk. 413 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 414 statements for end-to-end one-way-delay measurements. They are 415 applicable to each point of interest Hi involved in the measure. 416 Spatial one-way-delay measurement SHOULD be respectful of them, 417 especially those related to methodology, clock, uncertainties and 418 reporting. 420 Following we adapt some of them and introduce points specific to 421 spatial measurement. 423 4.1.1. Metric Name 425 Type-P-Spatial-One-way-Delay-Vector 427 4.1.2. Metric Parameters 429 + Src*, the IP address of the sender. 431 + Dst*, the IP address of the receiver. 433 + i, An integer which ordered the hosts in the path. 435 + Hi, exchange points of the path digest. 437 + T*, a time, the sending (or initial observation) time for 438 a measured packet. 440 + dT* a delay, the one-way delay for a measured packet. 442 + dT1,..., dTn a list of delay. 444 + P*, the specification of the packet type. 446 + , a path digest. 448 4.1.3. Metric Units 450 A sequence of times. 452 4.1.4. Definition 454 Given a Type-P packet sent by the sender Src at wire-time (first bit) 455 T to the receiver Dst in the path . Given the 456 sequence of values such that dT is the 457 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 458 path, T+dTi is either a real number corresponding to the wire-time 459 the packet passes (last bit received) Hi, or undefined if the packet 460 never passes Hi. 462 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 463 as the sequence of values 464 . 466 4.1.5. Discussion 468 Following are specific issues which may occur: 470 o the delay looks to decrease: dTi > DTi+1. this seem typically du 471 to some clock synchronisation issue. this point is discussed in 472 the section 3.7.1. "Errors or uncertainties related to Clocks" of 473 of [RFC2679]; 475 o The location of the point of interest in the device influences the 476 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 477 observed on the input interface the delay includes buffering time 478 and consequently an uncertainty due to the difference between 479 'wire time' and 'host time'; 481 4.1.6. Interference with other test packet 483 To avoid packet collision it is preferable to include a sequence 484 number in the packet. 486 4.1.7. loss threshold 488 To determine if a dTi is defined or undefined it is necessary to 489 define a period of time after which a packet is considered loss. 491 4.1.8. Methodologies 493 Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- 494 delay measurements. Most of them apply to each points interest Hi 495 and are relevant to this section. 497 Generally, for a given Type-P, in a given Hi, the methodology would 498 proceed as follows: 500 o At each Hi, prepare to capture the packet sent a time T, take a 501 timestamp Ti', determine the internal delay correction dTi', 502 extract the timestamp T from the packet, then compute the one-way- 503 delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is 504 undefined (infinite) if the packet is not detected after the 'loss 505 threshold' duration; 507 o Gather the set of dTi of each Hi and order them according to the 508 path to build the Type-P-Spatial-One-way-Delay-Vector metric 509 over the path . 511 It is out of the scope of this document to define how each Hi detects 512 the packet. 514 4.1.9. Reporting the metric 516 Section 3.6 of [RFC2679] indicates the items to report. 518 4.1.10. Path 520 It is clear that a end-to-end Type-P-One-way-Delay can't determine 521 the list of hosts the packet passes throught. Section 3.8.4 of 522 [RFC2679] says that the path traversed by the packet SHOULD be 523 reported but is practically impossible to determine. 525 This part of the job is provide by Type-P-Spatial-One-way-Delay- 526 Vector metric because each points of interest Hi which capture the 527 packet is part of the path. 529 4.2. A Definition of a sample of One-way Delay of a sub path 531 This metric is similar to the metric Type-P-One-way-Delay-Poisson- 532 stream defined in [RFC2679] and to the metric Type-P-One-way-Delay- 533 Periodic-Stream defined in [RFC3432]. 535 Nevertheless its definition differs because it is based of the 536 division of end-to-end One-way delay using the metric Type-P-Spatial- 537 One-way-Delay-Vector defined above. 539 It aims is to define a sample of One-way-Delay between a pair of 540 hosts of a path usable by active and passive measurements. 542 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 543 statements for end-to-end one-way-delay measurements. They are 544 applicable to each point of interest Hi involved in the measure. 545 Subpath one-way-delay measurement SHOULD be respectful of them, 546 especially those related to methodology, clock, uncertainties and 547 reporting. 549 4.2.1. Metric Name 551 Type-P-subpath-One-way-Delay-Stream 553 4.2.2. Metric Parameters 555 + Src*, the IP address of the sender. 557 + Dst*, the IP address of the receiver. 559 + i, An integer which orders exchange points in the path. 561 + k, An integer which orders the packets sent. 563 + , a path digest. 565 + Ha, a host of the path digest different from Dst and Hb; 567 + Hb, a host of the path digest different from Src and Ha. 568 Hb order in the path must greater that Ha; 570 + Hi, exchange points of the path digest. 572 + dT1,..., dTn a list of delay. 574 + P*, the specification of the packet type. 576 4.2.3. Metric Units 578 A sequence of pairs . 580 T is one of time of the sequence T1...Tn; 582 dt is a delay. 584 4.2.4. Definition 586 Given 2 hosts Ha and Hb of the path , given 587 a flow of packets of Type-P sent from Src to Dst at the times T1, 588 T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- 589 way-Delay-Vector . We define the 590 value of the sample Type-P-subpath-One-way-Delay-Stream as the 591 sequence made up of the couples . dTk.a is the 592 delay between Src and Ha. dTk.b is the delay between Src and Hb. 593 'dTk.b - dTk.a' is the one-way delay experienced by the packet sent 594 at the time Tk by Src when going from Ha to Hb. 596 4.2.5. Discussion 598 Following are specific issues which may occur: 600 o When a is Src is the measure of the first hop. 602 o When b is Dst is the measure of the last hop. 604 o the delay looks to decrease: dTi > DTi+1: 606 * This is typically du to clock synchronisation issue. this point 607 is discussed in the section 3.7.1. "Errors or uncertainties 608 related to Clocks" of of [RFC2679]; 610 * This may occurs too when the clock resolution of one probe is 611 bigger than the minimun delay of a path. As an example this 612 happen when measuring the delay of a path which is 500 km long 613 with one probe synchronized using NTP having a clock resolution 614 of 8ms. 616 o The location of the point of interest in the device influences the 617 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 618 observed on the input interface the delay includes buffering time 619 and consequently an uncertainty due to the difference between 620 'wire time' and 'host time'; 622 o dTk.b may be observed and not dTk.a. 624 o Tk is unknown if the flow is made of end user packets, that is 625 pure passive measure. In this case Tk may be forced to Tk+dTk.a. 626 This motivate separate metrics names for pure passive measurement 627 or specific reporting information. 629 o Pure passive measure should consider packets of the same size and 630 of the same Type-P. 632 4.2.6. Interference with other packet 634 4.2.7. loss threshold 636 To determine if a dTi is defined or undefined it is necessary to 637 define a period of time after which a packet is considered loss. 639 4.2.8. Methodologies 641 Both active and passive method should discussed. 643 4.2.9. Reporting the metric 645 Section 3.6 of [RFC2679] indicates the items to report. 647 4.2.10. Path 649 4.3. A Definition for Spatial One-way Packet Loss Vector 651 This section is coupled with the definition of Type-P-One-way-Packet- 652 Loss. Then when a parameter from the section 2 of [RFC2680] is first 653 used in this section, it will be tagged with a trailing asterisk. 655 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 656 statements for end-to-end one-way-Packet-Loss measurements. They are 657 applicable to each point of interest Hi involved in the measure. 658 Spatial packet loss measurement SHOULD be respectful of them, 659 especially those related to methodology, clock, uncertainities and 660 reporting. 662 Following we define the spatial metric, then we adapt some of the 663 points above and introduce points specific to spatial measurement. 665 4.3.1. Metric Name 667 Type-P-Spatial-One-way-Packet-Loss-Vector 669 4.3.2. Metric Parameters 671 + Src*, the IP address of the sender. 673 + Dst*, the IP address of the receiver. 675 + i, An integer which ordered the hosts in the path. 677 + Hi, exchange points of the path digest. 679 + T*, a time, the sending (or initial observation) time for 680 a measured packet. 682 + dT1,..., dTn, dT, a list of delay. 684 + P*, the specification of the packet type. 686 + , a path digest. 688 + B1, B2, ..., Bi, ..., Bn, a list of boolean values. 690 4.3.3. Metric Units 692 A sequence of boolean values. 694 4.3.4. Definition 696 Given a Type-P packet sent by the sender Src at time T to the 697 receiver Dst in the path . Given the sequence of 698 times the packet passes , 701 Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence 702 of values such that for each Hi of the path, a 703 value of Bi of 0 means that dTi is a finite value, and a value of 1 704 means that dTi is undefined. 706 4.3.5. Discussion 708 Following are specific issues wich may occur: 710 o the result includes the sequence 1,0. This case means that the 711 packet was seen by a host but not by it successor on the path; 713 o 715 The location of the meter in the device influences the result: 717 o Even if the packet is received by a device, it may be not observed 718 by a meter located after a buffer; 720 4.3.6. Reporting 722 Section in progress. 724 4.4. A Definition for Spatial One-way Jitter Vector 726 This section uses parameters from the definition of Type-P-One-way- 727 ipdv. When a parameter from section 2 of [RFC3393] is first used in 728 this section, it will be tagged with a trailing asterisk. 730 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 731 statements for end-to-end one-way-ipdv measurements. They are 732 applicable to each point of interest Hi involved in the measure. 733 Spatial one-way-ipdv measurement SHOULD be respectful of them, 734 especially those related to methodology, clock, uncertainities and 735 reporting. 737 Following we adapt some of them and introduce points specific to 738 spatial measurement. 740 4.4.1. Metric Name 742 Type-P-Spatial-One-way-Jitter-Vector 744 4.4.2. Metric Parameters 746 + Src*, the IP address of the sender. 748 + Dst*, the IP address of the receiver. 750 + i, An integer which ordered the hosts in the path. 752 + Hi, exchange points of the path digest. 754 + T1*, the time the first packet was sent. 756 + T2*, the time the second packet was sent. 758 + P, the specification of the packet type. 760 + P1, the first packet sent at time T1. 762 + P2, the second packet sent at time T2. 764 + , a path digest. 766 + , 767 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 768 time T1; 770 + , 771 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 772 time T2; 774 + L*, a packet length in bits. The packets of a Type P 775 packet stream from which the 776 Type-P-Spatial-One-way-Delay-Vector metric is taken MUST 777 all be of the same length. 779 4.4.3. Metric Units 781 A sequence of times. 783 4.4.4. Definition 785 Given the Type-P packet having the size L and sent by the sender Src 786 at wire-time (first bit) T1 to the receiver Dst in the path . 789 Given the Type-P packet having the size L and sent by the sender Src 790 at wire-time (first bit) T2 to the receiver Dst in the same path. 792 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P1. 795 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P2. 798 Type-P-Spatial-One-way-Jitter-Vector metric is defined as the 799 sequence of values Such that for each Hi of the path , 801 dT2.i-dT1.i is either a real number if the packets P1 and P2 passes 802 Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if 803 at least one of them never passes Hi. T2-T1 is the inter-packet 804 emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at 805 T1,T2*. 807 4.4.5. Sections in progress 809 See sections 3.5 to 3.7 of [RFC3393]. 811 4.5. Pure Passive Metrics 813 Spatial metrics may be measured without injecting test traffic as 814 described in [I-D.boschi-ipfix-reducing-redundancy] . 816 4.5.1. Discussion on Passive measurement 818 One might says that most of the operational issues occur in the last 819 mile and that consequently such measure are less useful than active 820 measuremeent. Nevertheless they are usable for network TE and 821 interdomain QoS monitoring, and composition of metric. 823 Such a technique have some limitations that are discussed below. 825 4.5.1.1. Passive One way delay 827 As the packet is not a test packet, it does not include the time it 828 was sent. 830 Consequently a point of interest Hi ignores the time the packet was 831 send. So It is not possible to measure the delay between Src and Hi 832 in the same manner it is not possible to measure the delay betwwen Hi 833 and Dst. 835 4.5.1.2. Passive Packet loss 837 The packet is not a test packet, so it does not include a sequence 838 number. 840 Packet lost measurement doe not require time synchronization and 841 require only one point of observation. Nevertheless it requires the 842 point of interest Hi to be expecting the packet. Practically Hi may 843 not detect a lost of packet that occurs between Src and Hi. 845 A point of interest Hi ignores the time the packet is send because 846 the packet does not carry the time it was injected in the network. 847 So a probe Hi can not compute dTi. 849 An alternative to these issues consist in considering sample spatial 850 One-way delay that T is the time when H1 (the first passive probe of 851 the path) observed the packet. 853 4.5.2. Reporting and composition 855 To avoid misunderstanding and to address specific reporting 856 constraint a proposal consists in defining distinct metrics for pure 857 passive measurement based on the definition above. 859 It is crucial to know the methodologie used because of the difference 860 of method of detection (expecting Seq++); because of the difference 861 of source of time (H1 vs Src) and because of the difference of 862 behavior of the source (Poisson/unknown). 864 4.5.3. naming and registry 866 Having distinct metrics identifiers for spatial metrics and passive 867 spatial metrics in the [RFC4148] will avoid interoperabily issues 868 especially during composition of metrics. 870 4.5.4. Passive One way delay metrics 872 4.5.5. Passive One way PacketLoss metrics 874 4.5.6. Passive One way jitter metrics 875 4.6. Discussion on spatial statistics 877 Do we define min, max, avg of spatial metrics ? 879 having the maximum loss metric value could be interesting. Say, 880 the segment between router A and B always contributes loss metric 881 value of "1" means it could be the potential problem segment. 883 Uploading dTi of each Hi consume a lot of bandwidth. Computing 884 statistics (min, max and avg) of dTi locally in each Hi reduce the 885 bandwidth consumption. 887 5. One-to-group metrics definitions 889 5.1. A Definition for one-to-group One-way Delay 891 5.1.1. Metric Name 893 Type-P-one-to-group-One-way-Delay-Vector 895 5.1.2. Metric Parameters 897 o Src, the IP address of a host acting as the source. 899 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 900 receivers. 902 o T, a time. 904 o dT1,...,dTn a list of time. 906 o P, the specification of the packet type. 908 o Gr, the multicast group address (optional). The parameter Gr is 909 the multicast group address if the measured packets are 910 transmitted by multicast. This parameter is to identify the 911 measured traffic from other unicast and multicast traffic. It is 912 set to be optional in the metric to avoid losing any generality, 913 i.e. to make the metric also applicable to unicast measurement 914 where there is only one receivers. 916 5.1.3. Metric Units 918 The value of a Type-P-one-to-group-One-way-Delay-Vector is a set of 919 singletons metrics Type-P-One-way-Delay [RFC2679]. 921 5.1.4. Definition 923 Given a Type P packet sent by the source Src at Time T, given the N 924 hosts { Recv1,...,RecvN } which receive the packet at the time { 925 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is 926 defined as the set of the Type-P-One-way-Delay singleton between Src 927 and each receiver with value of { dT1, dT2,...,dTn }. 929 5.2. A Definition for one-to-group One-way Packet Loss 931 5.2.1. Metric Name 933 Type-P-one-to-group-One-way-Packet-Loss-Vector 935 5.2.2. Metric Parameters 937 o Src, the IP address of a host acting as the source. 939 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 940 receivers. 942 o T, a time. 944 o T1,...,Tn a list of time. 946 o P, the specification of the packet type. 948 o Gr, the multicast group address (optional). 950 5.2.3. Metric Units 952 The value of a Type-P-one-to-group-One-way-Packet-Loss-Vector is a 953 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 955 5.2.4. Definition 957 Given a Type P packet sent by the source Src at T and the N hosts, 958 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 959 Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of 960 the Type-P-One-way-Packet-Loss singleton between Src and each of the 961 receivers {,,..., }. 963 5.3. A Definition for one-to-group One-way Jitter 965 5.3.1. Metric Name 967 Type-P-one-to-group-One-way-Jitter-Vector 969 5.3.2. Metric Parameters 971 + Src, the IP address of a host acting as the source. 973 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 974 receivers. 976 + T1, a time. 978 + T2, a time. 980 + ddT1,...,ddTn, a list of time. 982 + P, the specification of the packet type. 984 + F, a selection function defining unambiguously the two 985 packets from the stream selected for the metric. 987 + Gr, the multicast group address (optional) 989 5.3.3. Metric Units 991 The value of a Type-P-one-to-group-One-way-Jitter-Vector is a set of 992 singletons metrics Type-P-One-way-ipdv [RFC3393]. 994 5.3.4. Definition 996 Given a Type P packet stream, Type-P-one-to-group-One-way-Jitter- 997 Vector is defined for two packets from the source Src to the N hosts 998 {Recv1,...,RecvN },which are selected by the selection function F, as 999 the difference between the value of the Type-P-one-to-group-One-way- 1000 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1001 value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { 1002 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Scr sent 1003 the first bit of the first packet, and T2 is the wire-time at which 1004 Src sent the first bit of the second packet. This metric is derived 1005 from the Type-P-one-to- group-One-way-Delay-Vector metric. 1007 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 1008 group-One-way-Jitter-Vector from Src to { Recv1,...,RecvN } at T1, T2 1009 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1010 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1011 and the packets were received by { Recv1,...,RecvN } at wire-time 1012 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1013 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1014 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1016 5.4. Discussion on one-to-group statistics 1018 The defined one-to-group metrics above can all be directly achieved 1019 from the relevant unicast one-way metrics. They managed to collect 1020 all unicast measurement results of one-way metrics together in one 1021 profile and sort them by receivers and packets in a multicast group. 1022 They can provide sufficient information regarding the network 1023 performance in terms of each receiver and guide engineers to identify 1024 potential problem happened on each branch of a multicast routing 1025 tree. However, these metrics can not be directly used to 1026 conveniently present the performance in terms of a group and neither 1027 to identify the relative performance situation. 1029 One may say that no matter how many people join the communication, 1030 the connections can still be treated as a set of one-to-one 1031 connection. However, we might not describe a multiparty 1032 communication by a set of one-way measurement metrics because of the 1033 difficulty for understanding and the lack of convenience. For 1034 instance, an engineer might not describe the connections of a 1035 multiparty online conference in terms of one-to-group one-way delay 1036 for user A and B, B and C, and C and A because people might be 1037 confused. If there are more users in the same communication, the 1038 description might be very long. And he might use the one-way metrics 1039 with worst and the best value to give users an idea of the 1040 performance range of the service they are providing. But it is not 1041 clear enough and might not be accurate in a large multiparty 1042 communication scenario. 1044 From the performance point of view, the multiparty communication 1045 services not only require the absolute performance support but also 1046 the relative performance. The relative performance means the 1047 difference between absolute performance of all users. Directly using 1048 the one-way metrics cannot present the relative performance 1049 situation. However, if we use the variations of all users one-way 1050 parameters, we can have new metrics to measure the difference of the 1051 absolute performance and hence provide the threshold value of 1052 relative performance that a multiparty service might demand. A very 1053 good example of the high relative performance requirement is the 1054 online gaming. A very light worse delay will result in failure in 1055 the game. We have to use the new statistic metrics to define exactly 1056 how small the relative delay the online gaming requires. There are 1057 many other services, e.g. online biding, online stock market, etc., 1058 need a rule to judge the relative performance requirement. 1059 Therefore, we can see the importance of new statistic metrics to feed 1060 this need. 1062 We might use some one-to-group statistic conceptions to present and 1063 report the group performance and relative performance to save the 1064 report transmission bandwidth. Statistics have been defined for One- 1065 way metrics in corresponding FRCs. They provide the foundation of 1066 definition for performance statistics. For instance, there are 1067 definitions for minimum and maximum One-way delay in [RFC2679] and 1068 One-way delay mean in [I-D.ietf-ippm-spatial-composition]. However, 1069 there is a dramatic difference between the statistics for one-to-one 1070 communications and for one-to-many communications. The former one 1071 only has statistics over the time dimension while the later one can 1072 have statistics over both time dimension and space dimention. This 1073 space dimension is introduced by the Matrix concept. For a Matrix M 1074 shown in the Fig. 2, each row is a set of One-way singletons 1075 spreading over the space dimension and each colume is another set of 1076 One-way singletons spreading over the time dimension. 1078 (preamble) 1079 / \ 1080 | dT11, dT12,..., dT1N | 1081 | dT21, dT22,..., dT2N | 1082 | : | 1083 | : | 1084 | dTm1, dTm2,..., dTmN | 1085 \ / 1087 Fig. 2 Matrix M (m*N) 1089 In Matrix M, each element is a One-way delay singleton. Each row is 1090 a delay vector contains the One-way delays of the same packet 1091 observed at N points of interest. It implies the geographical factor 1092 of the performance within a group. Each colume is a set of One-way 1093 delays observed during a sampling interval at one of the points of 1094 interest. It presents the delay performance at a receiver over the 1095 time dimension. 1097 Therefore, one can either calculate statistics by rows over the space 1098 dimension or by columes over the time dimension. It's up to the 1099 operators or service provides which dimension they are interested in. 1100 For example, a TV broadcast service provider might want to know the 1101 statistical performance of each user in a long term run to make sure 1102 their services are acceptable and stable. While for an online gaming 1103 service provider, he might be more interested to know if all users 1104 are served farely by calculating the statistics over the space 1105 dimension. This memo does not intent to recommend which of the 1106 statistics are better than the other. 1108 To save the report transmission bandwidth, each point of interest can 1109 send statistics in a pre-defined time interval to the reference point 1110 rather than sending every One-way singleton it observed. As long as 1111 an appropriate time interval is decided, appropriate stantistics can 1112 represent the performance in a certain accurate scale. How to decide 1113 the time interval and how to bootstrap all points of interest and the 1114 reference point depend on applications. For instance, applications 1115 with lower transmission rate can have the time interval longer and 1116 ones with higher transmission rate can have the time interval 1117 shorter. However, this is out of the scope of this memo. 1119 Moreover, after knowing the statistics over the time dimension, one 1120 might want to know how this statistics distributed over the space 1121 dimension. For instance, a TV broadcast service provider had the 1122 performance Matrix M and calculated the One-way delay mean over the 1123 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1124 calculated the mean of all the elements in the Vector to see what 1125 level of delay he has served to all N users. This new delay mean 1126 gives information on how good the service has been delivered to a 1127 group of users during a sampling interval in terms of delay. It 1128 needs twice calculation to have this statistic over both time and 1129 space dimensions. We name this kind of statistics 2-level statistics 1130 to distinct with those 1-level statistics calculated over either 1131 space or time dimension. It can be easily prove that no matter over 1132 which dimension a 2-level statistic is calculated first, the results 1133 are the same. I.e. one can calculate the 2-level delay mean using 1134 the Matrix M by having the 1-level delay mean over the time dimension 1135 first and then calculate the mean of the obtained vector to find out 1136 the 2-level delay mean. Or, he can do the 1-level statistic 1137 calculation over the space dimention first and then have the 2-level 1138 delay mean. Both two results will be exactly the same. Therefore, 1139 when define a 2-level statistic, it is no need to specify in which 1140 procedure the calculation should follow. 1142 There are many statistics can be defined for the proposed one-to- 1143 group metrics over either the space dimension or the time dimension 1144 or both. In this memo, we define one-to-group mean and one-to-group 1145 variation over the space dimension. These statistics are offered 1146 mostly to be illustrative of what could be done. 1148 One-to-group mean are trying to measure the overall performance for a 1149 multicast group associated to one source. It is a reflection of the 1150 absolute performance of a multiparty communication service when we 1151 treat all receivers as one customer. It can also present the trend 1152 of the absolute performance of all receivers, i.e., it shows that 1153 most of the receivers in the multiparty communication service trend 1154 to receive an absolute performance close to the mean. 1156 One-to-group variation streams are trying to measure how the 1157 performance varies among all of the users in a multicast group 1158 associated to one source. The word "variation" in this memo is the 1159 population standard deviation. It reflects the relative 1160 performancesituation in a multiparty communication service, i.e., the 1161 level of the difference between the absolute performanceof each 1162 receivers. 1164 Using the one-to-group mean and one-to-group variation concepts, we 1165 can have a much clear understand on the performanceof a multiparty 1166 communication service in terms of its trend and range. There can be 1167 mean and variation stream definitions for each of the three one-to- 1168 group metrics defined above. We only present the definition of Type- 1169 P-one-to-group-One-way-Delay-Space-Mean and Type-P-one-to-group- One- 1170 way-Delay-Space-Variation as examples in this memo. 1172 5.4.1. Type-P-one-to-group-One-way-Delay-Space-Mean 1174 Given a Type-P-one-to-group-One-way-Delay-Vector, the mean { dT1, 1175 dT2,...,dTN } for the packet from Src at time T to { Recv1,...,RecvN 1176 }. 1178 For example, suppose we take a delay vector and the results is: 1180 Delay_Vector = {dT1,...,dTN} 1182 Then the mean over space dimension would be: 1184 Delay_Space_Mean = DsM = sum{dT1,...,dTN}/N 1186 5.4.2. Type-P-one-to-group-One-way-Delay-Variation-Stream 1188 Given a Type-P-one-to-group-One-way-Delay-Vector, the variation { 1189 dT1, dT2,...,dTN } for the packet from Src at time T to { 1190 Recv1,...,RecvN }. 1192 We still take the above Delay_Vector as an sample and the variation 1193 would be: 1195 Delay_Variation_Stream = {SUM[(dT1-DsM)^2,...,(dTN- 1196 DsM)^2)}/N)^(1/2) 1198 6. Extension from one-to-one to one-to-many measurement 1200 The above one-to-group metrics were defined to compose measurement 1201 results of a group of users who receive the same data from one 1202 source. Moreover, this is one of efforts to introducing the one-to- 1203 many concern to the IPPM working group with respect to the fact that 1204 all existing documents in the group are unicast oriented, which talk 1205 about only one-to-one single "path" in measurements. This concept 1206 can be extended from the "path" to "path tree" to cover both one-to- 1207 one and one-to-many communications. Actually, the one-to-one 1208 communications can be viewed as a special case of one-to-many from 1209 the routing point of view. The one-to-many communications build up a 1210 routing tree in the networks and one-to-one can be viewed as a 1211 special simplified tree without branches but only the "trunk". 1213 Therefore, the one-to-group metrics described in this memo can even 1214 be viewed as general metrics to measure the delay, jitter and packet 1215 loss in IP networks. When it applies to one-to-one communications, 1216 the metrics will have N receivers while N equal to 1. And the 1217 statistic metrics for one-to-one communications are exactly the one- 1218 to-group metrics themselves when calculated using the methods given. 1220 7. Open issues 1222 8. Security Considerations 1224 Active measumrement: see security section in owd pl, jitter rfcs 1225 (editor notes: add references). 1227 passive measurement: 1229 The generation of packets which match systematically the hash 1230 function may lead to a DoS attack toward the collector. 1232 The generation of packets with spoofing adresses may corrupt the 1233 results without any possibility to detect the spoofing. 1235 one-to-group metrics require collection of singletons which may 1236 overload the network the measurement controller is attach to. 1238 9. Acknowledgments 1240 Lei would like to acknowledge Zhili Sun from CCSR, University of 1241 Surrey, for his instruction and helpful comments on this work. 1243 10. IANA Considerations 1245 Metrics defined in this memo will be registered in the IANA IPPM 1246 METRICS REGISTRY as described in initial version of the registry 1247 [RFC4148]. 1249 11. References 1250 11.1. Normative References 1252 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1253 "Framework for IP Performance Metrics", RFC 2330, 1254 May 1998. 1256 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1257 Delay Metric for IPPM", RFC 2679, September 1999. 1259 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1260 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1262 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1263 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1264 November 2002. 1266 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1267 Registry", BCP 108, RFC 4148, August 2005. 1269 11.2. Informative References 1271 [I-D.boschi-ipfix-reducing-redundancy] 1272 Boschi, E., "Reducing redundancy in IPFIX and PSAMP 1273 reports", draft-boschi-ipfix-reducing-redundancy-02 (work 1274 in progress), June 2006. 1276 [I-D.ietf-ippm-spatial-composition] 1277 Morton, A. and E. Stephan, "Spatial Composition of 1278 Metrics", draft-ietf-ippm-spatial-composition-01 (work in 1279 progress), June 2006. 1281 [I-D.quittek-ipfix-middlebox] 1282 Quittek, J., "Guidelines for IPFIX Implementations on 1283 Middleboxes", draft-quittek-ipfix-middlebox-00 (work in 1284 progress), February 2004. 1286 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 1287 Connectivity", RFC 2678, September 1999. 1289 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1290 Delay Metric for IPPM", RFC 2681, September 1999. 1292 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1293 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1294 July 2001. 1296 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 1297 Metrics", RFC 3357, August 2002. 1299 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1300 performance measurement with periodic streams", RFC 3432, 1301 November 2002. 1303 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 1304 Measurement Protocol (OWAMP) Requirements", RFC 3763, 1305 April 2004. 1307 Authors' Addresses 1309 Stephan Emile 1310 France Telecom Division R&D 1311 2 avenue Pierre Marzin 1312 Lannion, F-22307 1314 Fax: +33 2 96 05 18 52 1315 Email: emile.stephan@orange-ft.com 1317 Lei Liang 1318 CCSR, University of Surrey 1319 Guildford 1320 Surrey, GU2 7XH 1322 Fax: +44 1483 683641 1323 Email: L.Liang@surrey.ac.uk 1325 Al Morton 1326 200 Laurel Ave. South 1327 Middletown, NJ 07748 1328 USA 1330 Phone: +1 732 420 1571 1331 Email: acmorton@att.com 1333 Full Copyright Statement 1335 Copyright (C) The Internet Society (2006). 1337 This document is subject to the rights, licenses and restrictions 1338 contained in BCP 78, and except as set forth therein, the authors 1339 retain all their rights. 1341 This document and the information contained herein are provided on an 1342 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1343 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1344 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1345 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1346 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1347 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1349 Intellectual Property 1351 The IETF takes no position regarding the validity or scope of any 1352 Intellectual Property Rights or other rights that might be claimed to 1353 pertain to the implementation or use of the technology described in 1354 this document or the extent to which any license under such rights 1355 might or might not be available; nor does it represent that it has 1356 made any independent effort to identify any such rights. Information 1357 on the procedures with respect to rights in RFC documents can be 1358 found in BCP 78 and BCP 79. 1360 Copies of IPR disclosures made to the IETF Secretariat and any 1361 assurances of licenses to be made available, or the result of an 1362 attempt made to obtain a general license or permission for the use of 1363 such proprietary rights by implementers or users of this 1364 specification can be obtained from the IETF on-line IPR repository at 1365 http://www.ietf.org/ipr. 1367 The IETF invites any interested party to bring to its attention any 1368 copyrights, patents or patent applications, or other proprietary 1369 rights that may cover technology that may be required to implement 1370 this standard. Please address the information to the IETF at 1371 ietf-ipr@ietf.org. 1373 Acknowledgment 1375 Funding for the RFC Editor function is provided by the IETF 1376 Administrative Support Activity (IASA).