idnits 2.17.1 draft-stephan-ippm-multimetrics-01.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 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1034. ** 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 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages 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 349: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 455: '... [RFC2679] says that the path traversed by the packet SHOULD be...' RFC 2119 keyword, line 471: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 543: '...ipdv measurement SHOULD be respectful ...' RFC 2119 keyword, line 586: '...-way-Delay-Stream metric is taken MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 514 has weird spacing: '... of values ...' == Line 663 has weird spacing: '... define min, ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2005) is 6867 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 7 errors (**), 0 flaws (~~), 5 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 Expires: January 8, 2006 L. Liang 5 University of Surrey 6 A. Morton 7 AT&T Labs 8 July 7, 2005 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-stephan-ippm-multimetrics-01.txt 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 January 8, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Multiparty metric . . . . . . . . . . . . . . . . . . . . 4 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 3. Motivations for spatial and one-to-group metrics . . . . . . . 5 62 3.1 spatial metrics . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 one-to-group metrics . . . . . . . . . . . . . . . . . . . 6 64 3.3 Discussion on Group-to-one and Group-to-group metrics . . 7 65 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 8 66 4.1 A Definition for Spatial One-way Delay Stream . . . . . . 8 67 4.2 A Definition for Spatial One-way Packet Loss Stream . . . 11 68 4.3 A Definition for Spatial One-way Jitter Stream . . . . . . 12 69 4.4 Discussion on pure passive measurement of spatial 70 metrics . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5 Discussion on spatial statistics . . . . . . . . . . . . . 15 72 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 15 73 5.1 A Definition for one-to-group One-way Delay Stream . . . . 15 74 5.2 A Definition for one-to-group One-way Packet Loss 75 Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 5.3 A Definition for one-to-group One-way Jitter Stream . . . 17 77 5.4 Discussion on one-to-group statistics . . . . . . . . . . 18 78 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 83 9.2 Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . . 24 87 1. Introduction 89 The metrics specified in this memo are built on notions introduced 90 and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. 91 The reader should be familiar with these documents. 93 This memo makes use of definitions of end-to-end One-way Delay 94 Metrics defined in the RFC 2679 [RFC2679] to define metrics for 95 decomposition of end-to-end one-way delays measurements. 97 This memo makes use of definitions of end-to-end One-way Packet loss 98 Metrics defined in the RFC 2680 [RFC2680] to define metrics for 99 decomposition of end-to-end one-way packet loss measurements. 101 The IPPM defined a framework for metric definitions and end-to-end 102 measurements: 104 o A general framework for defining performance metrics, described in 105 the Framework for IP Performance Metrics, RFC 2330 [RFC2330]; 107 o A One-way Active Measurement Protocol Requirements, RFC 3763 108 [RFC3763]; 110 o A One-way Active Measurement Protocol (OWAMP) [work in progress]; 112 o An IP Performance Metrics Registry [work in progress]; 114 It specified a set of end-to-end metrics, which conform to this 115 framework: 117 o The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 119 o The One-way Delay Metric for IPPM, RFC 2679 [RFC2679]; 121 o The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680]; 123 o The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681]; 125 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 126 RFC 3148 [RFC3148]; 128 o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 130 o IP Packet Delay Variation Metric for IPPM, RFC 3393 [RFC3393]; 132 o Network performance measurement for periodic streams, RFC 3432 133 [RFC3432]; 135 o Packet Reordering Metric for IPPM [Work in progress]; 137 Based on these works, this memo defines 2 kinds of multi party 138 metrics. 140 Firstly it defines spatial metrics: 142 o A 'sample', called Type-P-Spatial-One-way-Delay-Stream, will be 143 introduced to decompose an end-to-end Type-P-One-way-Delay in a 144 spatial sequence of one-way delays. 146 o A 'sample', called Type-P-Spatial-One-way-Packet-Loss-Stream, will 147 be introduced to decompose an end-to-end Type-P-One-way-Packet- 148 Loss in a spatial sequence of packet loss. 150 o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', 151 called Type-P-Spatial-One-way-Jitter-Stream, will be introduced to 152 decompose an end-to-end Type-P-One-way-ipdv in a spatial sequence 153 of jitter. 155 Then it defines one-to-group metrics. 157 o Using one test packet sent from one sender to a group of 158 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 159 Stream, will be introduced to define the list of Type-P-one-way- 160 delay between this sender and the group of receivers. 162 o Using one test packet sent from one sender to a group of 163 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 164 Loss-Stream, will be introduced to define the list of Type-P-One- 165 way-Packet-Loss between this sender and the group of receivers 167 o Using one test packet sent from one sender to a group of 168 receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- 169 Stream, will be introduced to define the list of Type-P-One-way- 170 ipdv between this sender and the group of receivers 172 o Then a discussion section presents the set of statistics that may 173 be computed on the top of these metrics to present the QoS in a 174 view of a group of users as well as the requirements of relative 175 QoS on multiparty communications. 177 2. Terminology 179 2.1 Multiparty metric 181 A metric is said to be multiparty if the definition involved more 182 than two sources or destinations in the measurements. All multiparty 183 metrics define a set of hosts called "points of interest", where one 184 host is the source and other hosts are the measurement collection 185 points. For example, if the set of points of interest is < ha, hb, 186 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 187 destinations, then measurements may be conducted between < ha, hb>, < 188 ha, hc>, ..., . 190 2.2 Spatial metric 192 A metric is said to be spatial if one of the hosts involved is 193 neither the source nor the destination of the metered packet. 195 2.3 Spatial metric points of interest 197 Points of interest of a spatial metric are the routers or sibling in 198 the path between source and destination (in addition to the source 199 and the destination themself). 201 2.4 One-to-group metric 203 A metric is said to be one-to-group if the measured packet is sent by 204 one source and (potentially) received by several destinations. Thus, 205 the topology of the communication group can be viewed as a centre- 206 distributed or server-client topology with the source as the centre/ 207 server in the topology. 209 2.5 One-to-group metric points of interest 211 Points of interest of One-to-group metrics are the set of host 212 destinations receiving packets from the source (in addition to the 213 source itself). 215 2.6 Reference point 217 The centre/server in the one-to-group measurement that is controlled 218 by network operators can be a very good reference point where 219 measurement data can be collected for further processing although the 220 actual measurements have to be carried out at all points of interest. 221 I.e., the measurement points will be all clients/receivers while the 222 reference point acts as source for the one-to-group metric. Thus, we 223 can define the reference point as the host while the statistic 224 calculation will be carried out. 226 3. Motivations for spatial and one-to-group metrics 228 All IPPM metrics are defined for end-to-end measurement. These 229 metrics provide very good guides for measurement in the pair 230 communications. However, further efforts should be put to define 231 metrics for multiparty measurements such as one to one trajectory 232 metrics and one to multipoint metrics. 234 3.1 spatial metrics 236 Decomposition of instantaneous end-to-end measures is needed: 238 o The PCE WG is extending existing protocols to permit remote path 239 computation and path computation quality, including inter domain. 240 One may say that in intra domain the decomposing the performance 241 of a path is not whished. However such decomposition is desirable 242 in interdomain to qualify each AS computation with the initial 243 request. So it is necessary to define standard spatial metrics 244 before going further in the computation of inter domain path with 245 QoS constraint. 247 o Traffic engineering and troubleshooting applications require 248 spatial views of the one-way delay consumption, identification of 249 the location of the lost of packets and the decomposition of the 250 jitter over the path. 252 o Monitoring the QoS of a multicast tree, of MPLS point-to- 253 multipoint and inter-domain communication require spatial 254 decomposition of the one-way delay, of the packet loss and of the 255 jitter. 257 o Composition of metrics is a need to scale in the measurement 258 plane. Spatial measures give the individual performance of intra 259 domain segments. Such a item is the elementary piece of 260 information to exchange to measure inter domain performance using 261 composition of metric. 263 o The PSAMP WG defines capabilities to sample packets in a way to to 264 support measurement. [PoMB05]; defines a method to collect 265 packets information to measure the instantaneous spatial 266 performance without injecting test traffic. Consequently it is 267 urgent to define a set of common spatial metrics for passive and 268 active techniques which respect the IPPM framework [RFC2330]. 269 This need is emphases by the fact that measuring end-to-end 270 spatial measuremtent involves these 2 techniques; 272 3.2 one-to-group metrics 274 To understand the connection situation between one source and any one 275 receiver in the multiparty communication group, we need the 276 decomposition of instantaneous end-to-end measures. It will give us 277 very detailed insight into each branch of the routing tree in terms 278 of node-to-node absolute QoS. It can provide clear and helpful 279 information for engineers to identify the connection with problems in 280 a complex multiparty routing tree. 282 While the node-to-node based spatial measures can provide very useful 283 data in the view of each connection, we also need measures to present 284 the performance of a multiparty communication in the view of a group 285 with consideration that it involves a group of people rather than 286 two. As a consequence a simple one-way metric cannot describe the 287 multi-connection situation. We need some new metrics to collect 288 performance of all the connections for further statistics analysis. 289 A group of metrics are proposed in this stage named one-to-group 290 performance metrics based on the unicast metrics defined in IPPM WG. 292 One-to-group performance metrics are needed for several reasons: 294 o For designing and engineering multicast trees and MPLS point-to- 295 multipoint LSP; 297 o For evaluating and controlling of the quality of the multicast 298 services; 300 o For controlling the performance of the inter domain multicast 301 services; 303 o For presenting and evaluating the relative QoS requirements for 304 the multiparty communications. 306 3.3 Discussion on Group-to-one and Group-to-group metrics 308 We note that points of interest can also be selected to define 309 measurements on Group-to-one and Group-to-group topologies. These 310 topologies are currently beyond the scope of this memo, because they 311 would involve multiple packets launched from different sources. 312 However, we can give some clues here on these two cases. 314 The measurements for group-to-one topology can be easily derived from 315 the one-to-group measurement. The measurement point is the reference 316 point that is acting as a receiver while all of clients/receivers 317 defined for one-to-group measurement act as sources in this case. 319 For the group-to-group connection topology, we can hardly define the 320 reference point and, therefore, have difficulty to define the 321 measurement points. However, we can always avoid this confusion by 322 treating the connections as one-to-group or group-to-one in our 323 measurements without consideration on how the real communication will 324 be carried out. For example, if one group of hosts < ha, hb, hc, 325 ..., hn > are acting as sources to send data to another group of 326 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 327 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 328 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 329 ..., Hm >. 331 4. Spatial metrics definitions 333 Spatial decomposition metrics are based on standard end-to-end 334 metrics. 336 The definition of a spatial metric is coupled with the corresponding 337 end-to-end metric. The methodoly is based on the measure of the same 338 test packet and parameters of the corresponding end-to-end metric. 340 4.1 A Definition for Spatial One-way Delay Stream 342 This section is coupled with the definition of Type-P-One-way-Delay. 343 When a parameter from section 3 of [RFC2679] is first used in this 344 section, it will be tagged with a trailing asterisk. 346 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 347 statements for end-to-end one-way-delay measurements. They are 348 applicable to each point of interest Hi involved in the measure. 349 Spatial one-way-delay measurement SHOULD be respectful of them, 350 especially those related to methodology, clock, uncertainities and 351 reporting. 353 Following we adapt some of them and introduce points specific to 354 spatial measurement. 356 4.1.1 Metric Name 358 Type-P-Spatial-One-way-Delay-Stream 360 4.1.2 Metric Parameters 362 + Src*, the IP address of the sender. 364 + Dst*, the IP address of the receiver. 366 + i, An integer which ordered the hosts in the path. 368 + Hi, exchange points of the path digest. 370 + T*, a time. 372 + dT* a delay, 374 + dT1,..., dTn a list of delay. 376 + P*, the specification of the packet type. 378 + , a path digest. 380 4.1.3 Metric Units 382 A sequence of times. 384 4.1.4 Definition 386 Given a Type-P packet sent by the sender Src at wire-time (first bit) 387 T to the receiver Dst in the path . Given the 388 sequence of values such that dT is the 389 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 390 path, T+dTi is either a real number corresponding to the wire-time 391 the packet passes (last bit received) Hi, or undefined if the packet 392 never passes Hi. 394 Type-P-Spatial-One-way-Delay-Stream metric is defined for the path 395 as the sequence of values 396 . 398 4.1.5 Discussion 400 Following are specific issues which may occur: 402 o the delay looks to decrease: dTi > DTi+1. this seem typically du 403 to some clock synchronisation issue. this point is discussed in 404 the section 3.7.1. "Errors or uncertainties related to Clocks" of 405 of [RFC2679];. 407 o The location of the point of interest in the device influences the 408 result (see [QuS04]). If the packet is not observed on the input 409 interface the delay includes buffering time and consequently an 410 uncertainty due to the difference between 'wire time' and 'host 411 time'; 413 4.1.6 Interference with other test packet 415 To avoid packet collision it is preferable to include a sequence 416 number in the packet. 418 4.1.7 loss threshold 420 To determine if a dTi is defined or undefined it is necessary to 421 define a period of time after which a packet is considered loss. 423 4.1.8 Methodologies 425 Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- 426 delay measurements. Most of them apply to each points interest Hi 427 and are relevant to this section. 429 Generally, for a given Type-P, in a given Hi, the methodology would 430 proceed as follows: 432 o At each Hi, prepare to capture the packet sent a time T, take a 433 timestamp Ti', determine the internal delay correction dTi', 434 extract the timestamp T from the packet, then compute the one-way- 435 delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is 436 undefined (infinite) if the packet is not detected after the 'loss 437 threshold' duration; 439 o Gather the set of dTi of each Hi and order them according to the 440 path to build the Type-P-Spatial-One-way-Delay-Stream metric 441 over the path . 443 It is out of the scope of this document to define how each Hi detects 444 the packet. 446 4.1.9 Reporting the metric 448 Section 3.6 of [RFC2679] indicates the items to report. 450 4.1.10 Path 452 It is clear that a end-to-end Type-P-One-way-Delay can't determine 453 the list of hosts the packet passes throught. Section 3.8.4 of 455 [RFC2679] says that the path traversed by the packet SHOULD be 456 reported but is practically impossible to determine. 458 This part of the job is provide by Type-P-Spatial-One-way-Delay- 459 Stream metric because each points of interest Hi which capture the 460 packet is part of the path. 462 4.2 A Definition for Spatial One-way Packet Loss Stream 464 This section is coupled with the definition of Type-P-One-way-Packet- 465 Loss. Then when a parameter from the section 2 of [RFC2680] is first 466 used in this section, it will be tagged with a trailing asterisk. 468 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 469 statements for end-to-end one-way-Packet-Loss measurements. They are 470 applicable to each point of interest Hi involved in the measure. 471 Spatial packet loss measurement SHOULD be respectful of them, 472 especially those related to methodology, clock, uncertainities and 473 reporting. 475 Following we define the spatial metric, then we adapt some of the 476 points above and introduce points specific to spatial measurement. 478 4.2.1 Metric Name 480 Type-P-Spatial-One-way-Packet-Loss-Stream 482 4.2.2 Metric Parameters 484 + Src*, the IP address of the sender. 486 + Dst*, the IP address of the receiver. 488 + i, An integer which ordered the hosts in the path. 490 + Hi, exchange points of the path digest. 492 + T*, a time. 494 + dT1,..., dTn, dT, a list of delay. 496 + P*, the specification of the packet type. 498 + , a path digest. 500 + B1, B2, ..., Bi, ..., Bn, a list of boolean values. 502 4.2.3 Metric Units 504 A sequence of boolean values. 506 4.2.4 Definition 508 Given a Type-P packet sent by the sender Src at time T to the 509 receiver Dst in the path . Given the sequence of 510 times the packet passes , 513 Type-P-One-way-Packet-Lost-Stream metric is defined as the sequence 514 of values such that for each Hi of the path, a 515 value of Bi of 0 means that dTi is a finite value, and a value of 1 516 means that dTi is undefined. 518 4.2.5 Discussion 520 Following are specific issues wich may occur: 522 o the result includes the sequence 1,0. This case means that the 523 packet was seen by a host but not by it successor on the path; 525 4.2.6 Discussion 527 The location of the meter in the device influences the result: 529 o Even if the packet is received by a device, it may be not observed 530 by a meter located after a buffer; 532 4.2.7 Sections in progress 534 4.3 A Definition for Spatial One-way Jitter Stream 536 This section uses parameters from the definition of Type-P-One-way- 537 ipdv. When a parameter from section 2 of [RFC3393] is first used in 538 this section, it will be tagged with a trailing asterisk. 540 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 541 statements for end-to-end one-way-ipdv measurements. They are 542 applicable to each point of interest Hi involved in the measure. 543 Spatial one-way-ipdv measurement SHOULD be respectful of them, 544 especially those related to methodology, clock, uncertainities and 545 reporting. 547 Following we adapt some of them and introduce points specific to 548 spatial measurement. 550 4.3.1 Metric Name 552 Type-P-Spatial-One-way-Jitter-Stream 554 4.3.2 Metric Parameters 556 + Src*, the IP address of the sender. 558 + Dst*, the IP address of the receiver. 560 + i, An integer which ordered the hosts in the path. 562 + Hi, exchange points of the path digest. 564 + T1*, the time the first packet was sent. 566 + T2*, the time the second packet was sent. 568 + P, the specification of the packet type. 570 + P1, the first packet sent at time T1. 572 + P2, the second packet sent at time T2. 574 + , a path digest. 576 + , 577 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 578 time T1; 580 + , 581 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 582 time T2; 584 + L*, a packet length in bits. The packets of a Type P 585 packet stream from which the 586 Type-P-Spatial-One-way-Delay-Stream metric is taken MUST 587 all be of the same length. 589 4.3.3 Metric Units 591 A sequence of times. 593 4.3.4 Definition 595 Given the Type-P packet having the size L and sent by the sender Src 596 at wire-time (first bit) T1 to the receiver Dst in the path . 599 Given the Type-P packet having the size L and sent by the sender Src 600 at wire-time (first bit) T2 to the receiver Dst in the same path. 602 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P1. 605 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P2. 608 Type-P-Spatial-One-way-Jitter-Stream metric is defined as the 609 sequence of values Such that for each Hi of the path , 611 dT2.i-dT1.i is either a real number if the packets P1 and P2 passes 612 Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if 613 at least one of them never passes Hi. T2-T1 is the inter-packet 614 emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at 615 T1,T2*. 617 4.3.5 Sections in progress 619 See sections 3.5 to 3.7 of [RFC3393]. 621 4.4 Discussion on pure passive measurement of spatial metrics 623 Spatial metrics may be measured without injecting test traffic as 624 described in [PoMB05] even if such a technique have some limitations. 626 o The packet is not a test packet, so it does not include the time 627 it was sent. Consequently a point of interest Hi ignores the time 628 the packet was send. So It is not possible to measure the first 629 hop delay. The collector ignores the time the packet was 630 received. So it is not possible to measure the last hop delay. 631 One might says that most of the operational issues occur in the 632 last mile and that consequently such measure are not 633 useful.Nevertheless they are usable for network TE and interdomain 634 QoS monitoring. 636 o The collector ignores the time the packet was send. So It is not 637 possible to determine that it is lost. 639 o A point of interest Hi ignores the time the packet is send because 640 the packet does not carry the time it was injected in the network. 642 So a probe Hi can not compute dTi. 644 An alternative to these issues consist in considering that T is the 645 time when H1 (the first passive probe of the path) observed the 646 packet. 648 To avoid misunderstanding and to address specific reporting 649 constraint a proposal consists in defining distinct metrics for pure 650 passive measurement based on the definition above. Having distinct 651 metrics identifiers for spatial metrics and passive spatial metrics 652 in the [IANA_IPPM_REGISTRY] will avoid interoperabily issues. They 653 may be named 655 o Type-P-Passive-One-way-delay-Stream 657 o Type-P-Passive-One-way-Packet-Loss-Stream 659 o Type-P-Passive-One-way-jitter-Stream 661 4.5 Discussion on spatial statistics 663 Do we define min, max, avg of spatial metrics ? 665 having the maximum loss metric value could be interesting. Say, 666 the segment between router A and B always contributes loss metric 667 value of "1" means it could be the potential problem segment. 669 Uploading dTi of each Hi consume a lot of bandwidth. Computing 670 statistics (min, max and avg) of dTi locally in each Hi reduce the 671 bandwidth consumption. 673 5. One-to-group metrics definitions 675 5.1 A Definition for one-to-group One-way Delay Stream 677 5.1.1 Metric Name 679 Type-P-one-to-group-One-way-Delay-Stream 681 5.1.2 Metric Parameters 683 + Src, the IP address of a host acting as the source. 685 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 686 receivers. 688 + T, a time. 690 + dT1,...,dTn a list of time. 692 + P, the specification of the packet type. 694 5.1.3 Metric Units 696 The value of a Type-P-one-to-group-One-way-Delay-Stream is a set of 697 singletons metrics Type-P-One-way-Delay [RFC2679]. 699 5.1.4 Definition 701 Given a Type P packet sent by the source Src at Time T, given the N 702 hosts { Recv1,...,RecvN } which receive the packet at the time { 703 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Stream is 704 defined as the set of the Type-P-One-way-Delay singleton between Src 705 and each receiver with value of { dT1, dT2,...,dTn }. 707 5.2 A Definition for one-to-group One-way Packet Loss Stream 709 5.2.1 Metric Name 711 Type-P-one-to-group-One-way-Packet-Loss-Stream 713 5.2.2 Metric Parameters 715 + Src, the IP address of a host acting as the source. 717 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 718 receivers. 720 + T, a time. 722 + T1,...,Tn, a list of time. 724 + P, the specification of the packet type. 726 5.2.3 Metric Units 728 The value of a Type-P-one-to-group-One-way-Packet-Loss-Stream is a 729 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 731 5.2.4 Definition 733 Given a Type P packet sent by the source Src at T and the N hosts, 734 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 735 Type-P-one-to-group-One-way-Packet-Loss-Stream is defined as a set of 736 the Type-P-One-way-Packet-Loss singleton between Src and each of the 737 receivers {,,..., }. 739 5.3 A Definition for one-to-group One-way Jitter Stream 741 5.3.1 Metric Name 743 Type-P-one-to-group-One-way-Jitter-Stream 745 5.3.2 Metric Parameters 747 + Src, the IP address of a host acting as the source. 749 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 750 receivers. 752 + T1, a time. 754 + T2, a time. 756 + ddT1,...,ddTn, a list of time. 758 + P, the specification of the packet type. 760 + F, a selection function defining unambiguously the two 761 packets from the stream selected for the metric. 763 5.3.3 Metric Units 765 The value of a Type-P-one-to-group-One-way-Jitter-Stream is a set of 766 singletons metrics Type-P-One-way-ipdv [RFC3393]. 768 5.3.4 Definition 770 Given a Type P packet stream, Type-P-one-to-group-One-way- Jitter- 771 Stream is defined for two packets from the source Src to the N hosts 772 {Recv1,...,RecvN },which are selected by the selection function F, as 773 the difference between the value of the Type-P-one-to-group-One-way- 774 Delay-Stream from Src to { Recv1,..., RecvN } at time T1 and the 775 value of the Type-P-one-to-group- One-way-Delay-Stream from Src to { 776 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Scr sent 777 the first bit of the first packet, and T2 is the wire-time at which 778 Src sent the first bit of the second packet. This metric is derived 779 from the Type-P-one-to- group-One-way-Delay-Stream metric. 781 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 782 group-One-way-Jitter-Stream from Src to { Recv1,...,RecvN } at T1, T2 783 is {ddT1,...,ddTn} means that Src sent two packets, the first at 784 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 785 and the packets were received by { Recv1,...,RecvN } at wire-time 786 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 787 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 788 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 790 5.4 Discussion on one-to-group statistics 792 The defined one-to-group metrics above can all be directly achieved 793 from the relevant unicast one-way metrics. They managed to collect 794 all unicast measurement results of one-way metrics together in one 795 profile and sort them by receivers and packets in a multicast group. 796 They can provide sufficient information regarding the network 797 performance in terms of each receiver and guide engineers to identify 798 potential problem happened on each branch of a multicast routing 799 tree. However, these metrics can not be directly used to 800 conveniently present the performance in terms of a group and neither 801 to identify the relative QoS situation. 803 One may say that no matter how many people join the communication, 804 the connections can still be treated as a set of one-to-one 805 connection. However, we might not describe a multiparty 806 communication by a set of one-way measurement metrics because of the 807 difficulty for understanding and the lack of convenience. For 808 instance, an engineer might not describe the connections of a 809 multiparty online conference in terms of one-to-group one-way delay 810 for user A and B, B and C, and C and A because people might be 811 confused. If there are more users in the same communication, the 812 description might be very long. And he might use the one-way metrics 813 with worst and the best value to give users an idea of the QoS range 814 of the service they are providing. But it is not clear enough and 815 might not be accurate in a large multiparty communication scenario. 817 From the QoS point of view, the multiparty communication services not 818 only require the absolute QoS support but also the relative QoS. The 819 relative QoS means the difference between absolute QoS of all users. 821 Directly using the one-way metrics cannot present the relative QoS 822 situation. However, if we use the variations of all users one-way 823 parameters, we can have new metrics to measure the difference of the 824 absolute QoS and hence provide the threshold value of relative QoS 825 that a multiparty service might demand. A very good example of the 826 high relative QoS requirement is the online gaming. A very light 827 worse delay will result in failure in the game. We have to use the 828 new statistic metrics to define exactly how small the relative delay 829 the online gaming requires. There are many other services, e.g. 830 online biding, online stock market, etc., need a rule to judge the 831 relative QoS requirement. Therefore, we can see the importance of 832 new statistic metrics to feed this need. 834 We might use some one-to-group statistic conceptions to present the 835 group performance and relative QoS. In this stage, we define one-to- 836 group mean stream and one-to-group variation stream. These 837 statistics are offered mostly to be illustrative of what could be 838 done. 840 One-to-group mean streams are trying to measure the overall QoS for a 841 multicast group associated to one source. It is a reflection of the 842 absolute QoS of a multiparty communication service when we treat all 843 receivers as one customer. It can also present the trend of the 844 absolute QoS of all receivers, i.e., it shows that most of the 845 receivers in the multiparty communication service trend to receive an 846 absolute QoS close to the mean. 848 One-to-group variation streams are trying to measure how the QoS 849 varies among all of the users in a multicast group associated to one 850 source. The word "variation" in this memo is the population standard 851 deviation. It reflects the relative QoS situation in a multiparty 852 communication service, i.e., the level of the difference between the 853 absolute QoS of each receivers. 855 Using the one-to-group mean and one-to-group variation concepts, we 856 can have a much clear understand on the QoS of a multiparty 857 communication service in terms of its trend and range. There can be 858 mean and variation stream definitions for each of the three one-to- 859 group metrics defined above. We only present the definition of Type- 860 P-one-to-group-One-way- Delay-Mean-Stream and Type-P-one-to-group- 861 One-way-Delay-Variation-Stream as examples in this memo. 863 5.4.1 Type-P-one-to-group-One-way-Delay-Mean-Stream 865 Given a Type-P-one-to-group-One-way-Delay-Stream, the mean stream of 866 all { dT1, dT2,...,dTn } for the packet from Src at time T to { 867 Recv1,...,RecvN }. 869 For example, suppose we take a sample and the results are: 871 Delay_Stream = < 872 {T1,...,Tn} 873 {T'1,...,T'n} 874 {T''1,...T''n} 875 > 877 Then the mean stream would be: 879 Delay_Mean_Stream = < 880 DM1 881 DM2 882 DM3 883 > 884 = < 885 sum{T1,...,Tn}/n 886 sum{T'1,...,T'n}/n 887 sum{T''1,...T''n}/n 888 > 890 5.4.2 Type-P-one-to-group-One-way-Delay-Variation-Stream 892 Given a Type-P-one-to-group-One-way-Delay-Stream, the variation 893 stream of all { dT1, dT2,...,dTn } for the packet from Src at time T 894 to { Recv1,...,RecvN }. 896 We still take the above Delay_Stream as a sample and the variation 897 stream would be: 899 Delay_Variation_Stream = < 900 DV1 901 DV2 902 DV3 903 > 904 =< 905 (SUM{(T1-DM1)^2,...,(Tn-DM1)^2)}/n)^(1/2) 906 (SUM{(T'1-DM2)^2,...,(T'n-DM2)^2)}/n)^(1/2) 907 (SUM{(T''1-DM3)^2,...,(T''n-DM3)^2)}/n)^(1/2) 908 > 910 6. Open issues 912 7. Security Considerations 914 TODO: Active measumrement: see owd pl, jitter rfc. 916 TODO: passive measurement: DoS toward the collector. 918 TODO: one-to-group metrics defined here are not intrusive: they rely 919 on measures of owd... nevertheless they require collection of 920 singleton: so DoS collector 922 The one-to-group metrics are derived from one-way metrics and 923 therefore, they have very close relationship. Actually, these 924 metrics are derived for further statistic analysis rather than 925 directly use. 927 8. IANA Considerations 929 Metrics defined in this memo will be registred in the 930 [IANA_IPPM_REGISTRY]. 932 9. References 934 9.1 Normative References 936 [IANA_IPPM_REGISTRY] 937 Emile STEPHAN, "IP Performance Metrics (IPPM) metrics 938 registry, IPPM WG document, 939 draft-ietf-ippm-metrics-registry-08.txt, http:// 940 www.iana.org/assignments/ianaippmmetricsregistry-mib", 941 2004. 943 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 944 "Framework for IP Performance Metrics", RFC 2330, 945 May 1998. 947 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 948 Delay Metric for IPPM", RFC 2679, September 1999. 950 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 951 Packet Loss Metric for IPPM", RFC 2680, September 1999. 953 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 954 Metric for IP Performance Metrics (IPPM)", RFC 3393, 955 November 2002. 957 9.2 Informative References 959 [PoMB05] G. Pohl, L. Mark, E. Boschi, ""Use of IPFIX for Export of 960 Per-Packet Information", internet-drafts 961 draft-pohl-perpktinfo-02.txt", 2005. 963 [QuS04] J. Quittek, "Guidelines for IPFIX Implementations on 964 Middleboxes", 2004. 966 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 967 Connectivity", RFC 2678, September 1999. 969 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 970 Delay Metric for IPPM", RFC 2681, September 1999. 972 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 973 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 974 July 2001. 976 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 977 Metrics", RFC 3357, August 2002. 979 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 980 performance measurement with periodic streams", RFC 3432, 981 November 2002. 983 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 984 Measurement Protocol (OWAMP) Requirements", RFC 3763, 985 April 2004. 987 Authors' Addresses 989 Stephan Emile 990 France Telecom Division R&D 991 2 avenue Pierre Marzin 992 Lannion, F-22307 994 Fax: +33 2 96 05 18 52 995 Email: emile.stephan@francetelecom.com 997 Lei Liang 998 CCSR, University of Surrey 999 Guildford 1000 Surrey, GU2 7XH 1002 Fax: +44 1483 683641 1003 Email: L.Liang@surrey.ac.uk 1004 Al Morton 1005 200 Laurel Ave. South 1006 Middletown, NJ 07748 1007 USA 1009 Phone: +1 732 420 1571 1010 Email: acmorton@att.com 1012 Intellectual Property Statement 1014 The IETF takes no position regarding the validity or scope of any 1015 Intellectual Property Rights or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; nor does it represent that it has 1019 made any independent effort to identify any such rights. Information 1020 on the procedures with respect to rights in RFC documents can be 1021 found in BCP 78 and BCP 79. 1023 Copies of IPR disclosures made to the IETF Secretariat and any 1024 assurances of licenses to be made available, or the result of an 1025 attempt made to obtain a general license or permission for the use of 1026 such proprietary rights by implementers or users of this 1027 specification can be obtained from the IETF on-line IPR repository at 1028 http://www.ietf.org/ipr. 1030 The IETF invites any interested party to bring to its attention any 1031 copyrights, patents or patent applications, or other proprietary 1032 rights that may cover technology that may be required to implement 1033 this standard. Please address the information to the IETF at 1034 ietf-ipr@ietf.org. 1036 Disclaimer of Validity 1038 This document and the information contained herein are provided on an 1039 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1040 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1041 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1042 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1043 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1044 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1046 Copyright Statement 1048 Copyright (C) The Internet Society (2005). This document is subject 1049 to the rights, licenses and restrictions contained in BCP 78, and 1050 except as set forth therein, the authors retain all their rights. 1052 Acknowledgment 1054 Funding for the RFC Editor function is currently provided by the 1055 Internet Society.