idnits 2.17.1 draft-stephan-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1170. ** 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 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 361: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 467: '... [RFC2679] says that the path traversed by the packet SHOULD be...' RFC 2119 keyword, line 490: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 598: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 671: '...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 == Line 642 has weird spacing: '... of values ...' == Line 790 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 (October 22, 2005) is 6732 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) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-01) exists of draft-boschi-export-perpktinfo-00 == Outdated reference: A later version (-01) exists of draft-morton-ippm-composition-00 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Stephan 2 Internet-Draft France Telecom 3 Expires: April 25, 2006 L. Liang 4 University of Surrey 5 A. Morton 6 AT&T Labs 7 October 22, 2005 9 IP Performance Metrics (IPPM) for spatial and multicast 10 draft-stephan-ippm-multimetrics-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The IETF IP Performance Metrics (IPPM) working group has standardized 44 metrics for measuring end-to-end performance between 2 points. This 45 memo defines 2 sets of metrics to extend these end-to-end ones. It 46 defines spatial metrics for measuring the performance of segments 47 along a path and metrics for measuring the performance of a group of 48 users in multiparty communications. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1 Multiparty metric . . . . . . . . . . . . . . . . . . . . 5 55 2.2 Spatial metric . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3 Spatial metric points of interest . . . . . . . . . . . . 5 57 2.4 One-to-group metric . . . . . . . . . . . . . . . . . . . 5 58 2.5 One-to-group metric points of interest . . . . . . . . . . 5 59 2.6 Reference point . . . . . . . . . . . . . . . . . . . . . 5 60 3. Motivations for spatial and one-to-group metrics . . . . . . . 6 61 3.1 spatial metrics . . . . . . . . . . . . . . . . . . . . . 6 62 3.2 one-to-group metrics . . . . . . . . . . . . . . . . . . . 7 63 3.3 Discussion on Group-to-one and Group-to-group metrics . . 7 64 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 8 65 4.1 A Definition for Spatial One-way Delay Stream . . . . . . 8 66 4.2 A Definition of a sample of One-way Delay of a sub path . 11 67 4.3 A Definition for Spatial One-way Packet Loss Stream . . . 14 68 4.4 A Definition for Spatial One-way Jitter Stream . . . . . . 15 69 4.5 Discussion on pure passive measurement of spatial 70 metrics . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 4.6 Discussion on spatial statistics . . . . . . . . . . . . . 18 72 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 18 73 5.1 A Definition for one-to-group One-way Delay Stream . . . . 18 74 5.2 A Definition for one-to-group One-way Packet Loss 75 Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.3 A Definition for one-to-group One-way Jitter Stream . . . 20 77 5.4 Discussion on one-to-group statistics . . . . . . . . . . 21 78 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 9.1 Normative References . . . . . . . . . . . . . . . . . . . 24 83 9.2 Informative References . . . . . . . . . . . . . . . . . . 24 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 85 Intellectual Property and Copyright Statements . . . . . . . . 27 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 WG 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 , RFC 4148 [RFC4148]; 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 o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', 156 called Type-P-subpath-One-way-Delay-Stream, will be introduced to 157 define the one-way-delay between any host of the path. This 158 metrics is designed too for pure passive measurement methodology 159 introduced by PSAMP WG. 161 Then it defines one-to-group metrics. 163 o Using one test packet sent from one sender to a group of 164 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 165 Stream, will be introduced to define the list of Type-P-one-way- 166 delay between this sender and the group of receivers. 168 o Using one test packet sent from one sender to a group of 169 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 170 Loss-Stream, will be introduced to define the list of Type-P-One- 171 way-Packet-Loss between this sender and the group of receivers 173 o Using one test packet sent from one sender to a group of 174 receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- 175 Stream, will be introduced to define the list of Type-P-One-way- 176 ipdv between this sender and the group of receivers 178 o Then a discussion section presents the set of statistics that may 179 be computed on the top of these metrics to present the QoS in a 180 view of a group of users as well as the requirements of relative 181 QoS on multiparty communications. 183 2. Terminology 185 2.1 Multiparty metric 187 A metric is said to be multiparty if the definition involved more 188 than two sources or destinations in the measurements. All multiparty 189 metrics define a set of hosts called "points of interest", where one 190 host is the source and other hosts are the measurement collection 191 points. For example, if the set of points of interest is < ha, hb, 192 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 193 destinations, then measurements may be conducted between < ha, hb>, < 194 ha, hc>, ..., . 196 2.2 Spatial metric 198 A metric is said to be spatial if one of the hosts involved is 199 neither the source nor the destination of the metered packet. 201 2.3 Spatial metric points of interest 203 Points of interest of a spatial metric are the routers or sibling in 204 the path between source and destination (in addition to the source 205 and the destination themself). 207 2.4 One-to-group metric 209 A metric is said to be one-to-group if the measured packet is sent by 210 one source and (potentially) received by several destinations. Thus, 211 the topology of the communication group can be viewed as a centre- 212 distributed or server-client topology with the source as the centre/ 213 server in the topology. 215 2.5 One-to-group metric points of interest 217 Points of interest of One-to-group metrics are the set of host 218 destinations receiving packets from the source (in addition to the 219 source itself). 221 2.6 Reference point 223 The centre/server in the one-to-group measurement that is controlled 224 by network operators can be a very good reference point where 225 measurement data can be collected for further processing although the 226 actual measurements have to be carried out at all points of interest. 227 I.e., the measurement points will be all clients/receivers while the 228 reference point acts as source for the one-to-group metric. Thus, we 229 can define the reference point as the host while the statistic 230 calculation will be carried out. 232 3. Motivations for spatial and one-to-group metrics 234 All IPPM metrics are defined for end-to-end measurement. These 235 metrics provide very good guides for measurement in the pair 236 communications. However, further efforts should be put to define 237 metrics for multiparty measurements such as one to one trajectory 238 metrics and one to multipoint metrics. 240 3.1 spatial metrics 242 Decomposition of instantaneous end-to-end measures is needed: 244 o The PCE WG is extending existing protocols to permit remote path 245 computation and path computation quality, including inter domain. 246 One may say that in intra domain the decomposing the performance 247 of a path is not whished. However such decomposition is desirable 248 in interdomain to qualify each AS computation with the initial 249 request. So it is necessary to define standard spatial metrics 250 before going further in the computation of inter domain path with 251 QoS constraint. 253 o Traffic engineering and troubleshooting applications require 254 spatial views of the one-way delay consumption, identification of 255 the location of the lost of packets and the decomposition of the 256 jitter over the path. 258 o Monitoring the QoS of a multicast tree, of MPLS point-to- 259 multipoint and inter-domain communication require spatial 260 decomposition of the one-way delay, of the packet loss and of the 261 jitter. 263 o Composition of metrics is a need to scale in the measurement 264 plane. The definition of composition metrics is a work in 265 progress [I-D.morton-ippm-composition]; . Spatial measure give 266 typically the individual performance of an intra domain segment. 267 It is the elementary piece of information to exchange for 268 measuring interdomain performance based on composition of metrics. 270 o The PSAMP WG defines capabilities to sample packets in a way to to 271 support measurement. [I-D.boschi-export-perpktinfo]; defines a 272 method to collect packets information to measure the instantaneous 273 spatial performance without injecting test traffic. Consequently 274 it is urgent to define a set of common spatial metrics for passive 275 and active techniques which respect the IPPM framework [RFC2330]. 276 This need is emphases by the fact that end-to-end spatial 277 measurement involves the 2 techniques; 279 3.2 one-to-group metrics 281 To understand the connection situation between one source and any one 282 receiver in the multiparty communication group, we need the 283 decomposition of instantaneous end-to-end measures. It will give us 284 very detailed insight into each branch of the routing tree in terms 285 of node-to-node absolute QoS. It can provide clear and helpful 286 information for engineers to identify the connection with problems in 287 a complex multiparty routing tree. 289 While the node-to-node based spatial measures can provide very useful 290 data in the view of each connection, we also need measures to present 291 the performance of a multiparty communication in the view of a group 292 with consideration that it involves a group of people rather than 293 two. As a consequence a simple one-way metric cannot describe the 294 multi-connection situation. We need some new metrics to collect 295 performance of all the connections for further statistics analysis. 296 A group of metrics are proposed in this stage named one-to-group 297 performance metrics based on the unicast metrics defined in IPPM WG. 298 One-to-group metrics are trying to composite one-way metrics from one 299 source to a group of destinations to make up new metrics. The 300 compositions are necessary for judging the network performance of 301 multiparty communications and can also be used to describe the 302 difference of the QoS served among a group of users. 304 One-to-group performance metrics are needed for several reasons: 306 o For designing and engineering multicast trees and MPLS point-to- 307 multipoint LSP; 309 o For evaluating and controlling of the quality of the multicast 310 services; 312 o For controlling the performance of the inter domain multicast 313 services; 315 o For presenting and evaluating the relative QoS requirements for 316 the multiparty communications. 318 3.3 Discussion on Group-to-one and Group-to-group metrics 320 We note that points of interest can also be selected to define 321 measurements on Group-to-one and Group-to-group topologies. These 322 topologies are currently beyond the scope of this memo, because they 323 would involve multiple packets launched from different sources. 324 However, we can give some clues here on these two cases. 326 The measurements for group-to-one topology can be easily derived from 327 the one-to-group measurement. The measurement point is the reference 328 point that is acting as a receiver while all of clients/receivers 329 defined for one-to-group measurement act as sources in this case. 331 For the group-to-group connection topology, we can hardly define the 332 reference point and, therefore, have difficulty to define the 333 measurement points. However, we can always avoid this confusion by 334 treating the connections as one-to-group or group-to-one in our 335 measurements without consideration on how the real communication will 336 be carried out. For example, if one group of hosts < ha, hb, hc, 337 ..., hn > are acting as sources to send data to another group of 338 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 339 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 340 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 341 ..., Hm >. 343 4. Spatial metrics definitions 345 Spatial decomposition metrics are based on standard end-to-end 346 metrics. 348 The definition of a spatial metric is coupled with the corresponding 349 end-to-end metric. The methodoly is based on the measure of the same 350 test packet and parameters of the corresponding end-to-end metric. 352 4.1 A Definition for Spatial One-way Delay Stream 354 This section is coupled with the definition of Type-P-One-way-Delay. 355 When a parameter from section 3 of [RFC2679] is first used in this 356 section, it will be tagged with a trailing asterisk. 358 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 359 statements for end-to-end one-way-delay measurements. They are 360 applicable to each point of interest Hi involved in the measure. 361 Spatial one-way-delay measurement SHOULD be respectful of them, 362 especially those related to methodology, clock, uncertainities and 363 reporting. 365 Following we adapt some of them and introduce points specific to 366 spatial measurement. 368 4.1.1 Metric Name 370 Type-P-Spatial-One-way-Delay-Stream 372 4.1.2 Metric Parameters 374 + Src*, the IP address of the sender. 376 + Dst*, the IP address of the receiver. 378 + i, An integer which ordered the hosts in the path. 380 + Hi, exchange points of the path digest. 382 + T*, a time, the sending (or initial observation) time for 383 a measured packet. 385 + dT* a delay, the one-way delay for a measured packet. 387 + dT1,..., dTn a list of delay. 389 + P*, the specification of the packet type. 391 + , a path digest. 393 4.1.3 Metric Units 395 A sequence of times. 397 4.1.4 Definition 399 Given a Type-P packet sent by the sender Src at wire-time (first bit) 400 T to the receiver Dst in the path . Given the 401 sequence of values such that dT is the 402 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 403 path, T+dTi is either a real number corresponding to the wire-time 404 the packet passes (last bit received) Hi, or undefined if the packet 405 never passes Hi. 407 Type-P-Spatial-One-way-Delay-Stream metric is defined for the path 408 as the sequence of values 409 . 411 4.1.5 Discussion 413 Following are specific issues which may occur: 415 o the delay looks to decrease: dTi > DTi+1. this seem typically du 416 to some clock synchronisation issue. this point is discussed in 417 the section 3.7.1. "Errors or uncertainties related to Clocks" of 418 of [RFC2679];. 420 o The location of the point of interest in the device influences the 421 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 422 observed on the input interface the delay includes buffering time 423 and consequently an uncertainty due to the difference between 424 'wire time' and 'host time'; 426 4.1.6 Interference with other test packet 428 To avoid packet collision it is preferable to include a sequence 429 number in the packet. 431 4.1.7 loss threshold 433 To determine if a dTi is defined or undefined it is necessary to 434 define a period of time after which a packet is considered loss. 436 4.1.8 Methodologies 438 Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- 439 delay measurements. Most of them apply to each points interest Hi 440 and are relevant to this section. 442 Generally, for a given Type-P, in a given Hi, the methodology would 443 proceed as follows: 445 o At each Hi, prepare to capture the packet sent a time T, take a 446 timestamp Ti', determine the internal delay correction dTi', 447 extract the timestamp T from the packet, then compute the one-way- 448 delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is 449 undefined (infinite) if the packet is not detected after the 'loss 450 threshold' duration; 452 o Gather the set of dTi of each Hi and order them according to the 453 path to build the Type-P-Spatial-One-way-Delay-Stream metric 454 over the path . 456 It is out of the scope of this document to define how each Hi detects 457 the packet. 459 4.1.9 Reporting the metric 461 Section 3.6 of [RFC2679] indicates the items to report. 463 4.1.10 Path 465 It is clear that a end-to-end Type-P-One-way-Delay can't determine 466 the list of hosts the packet passes throught. Section 3.8.4 of 467 [RFC2679] says that the path traversed by the packet SHOULD be 468 reported but is practically impossible to determine. 470 This part of the job is provide by Type-P-Spatial-One-way-Delay- 471 Stream metric because each points of interest Hi which capture the 472 packet is part of the path. 474 4.2 A Definition of a sample of One-way Delay of a sub path 476 This metric is similar to the metric Type-P-One-way-Delay-Poisson- 477 stream defined in [RFC2679] and to the metric Type-P-One-way-Delay- 478 Periodic-Stream defined in [RFC3432] 480 Nevertheless its definition differs because it is based of the 481 decomposition of end-to-end One-way delay using the metric Type-P- 482 Spatial-One-way-Delay-Stream defined above. 484 It aims is to define a sample of One-way-Delay between a pair of 485 hosts of a path usable by active and passive measurements. 487 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 488 statements for end-to-end one-way-delay measurements. They are 489 applicable to each point of interest Hi involved in the measure. 490 Subpath one-way-delay measurement SHOULD be respectful of them, 491 especially those related to methodology, clock, uncertainities and 492 reporting. 494 4.2.1 Metric Name 496 Type-P-subpath-One-way-Delay-Stream 498 4.2.2 Metric Parameters 500 + Src*, the IP address of the sender. 502 + Dst*, the IP address of the receiver. 504 + i, An integer which orders exchange points in the path. 506 + k, An integer which orders the packets sent. 508 + , a path digest. 510 + Ha, a host of the path digest different from Dst and Hb; 512 + Hb, a host of the path digest different from Src and Ha. 513 Hb order in the path must greater that Ha; 515 + Hi, exchange points of the path digest. 517 + dT1,..., dTn a list of delay. 519 + P*, the specification of the packet type. 521 4.2.3 Metric Units 523 A sequence of pairs . 525 T is one of time of the sequence T1...Tn; 527 dT is a delay. 529 4.2.4 Definition 531 Given 2 hosts Ha and Hb of the path , given 532 a flow of packets of Type-P sent from Src to Dst at the times T1, 533 T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- 534 way-Delay-Stream . We define the 535 value of the sample Type-P-subpath-One-way-Delay-Stream as the 536 sequence made up of the couples . dTk.a is the 537 delay between Src and Ha. dTk.b is the delay between Src and Hb. 538 'dTk.b - dTk.a' is the one-way delay experienced by the packet sent 539 at the time Tk by Src when going from Ha to Hb. 541 4.2.5 Discussion 543 Following are specific issues which may occur: 545 o The definition permits the measure of when a is 546 Src. 548 o The definition permits the measure of when b is 549 Dst. 551 o the delay looks to decrease: dTi > DTi+1. this seem typically du 552 to some clock synchronisation issue. this point is discussed in 553 the section 3.7.1. "Errors or uncertainties related to Clocks" of 554 of [RFC2679];. 556 o The location of the point of interest in the device influences the 557 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 558 observed on the input interface the delay includes buffering time 559 and consequently an uncertainty due to the difference between 560 'wire time' and 'host time'; 562 o dTk.b may be observed and not dTk.a. 564 o Tk is unknown if the flow is made of end user packets, that is 565 pure passive measure. In this case Tk may be forced to Tk+dTk.a. 566 This motivate separate metrics names for pure passive measurement 567 or specific reporting information. 569 o Pure passive measure should consider packets of the same size and 570 of the same Type-P. 572 4.2.6 Interference with other packet 574 4.2.7 loss threshold 576 To determine if a dTi is defined or undefined it is necessary to 577 define a period of time after which a packet is considered loss. 579 4.2.8 Methodologies 581 Both active and passive method should discussed. 583 4.2.9 Reporting the metric 585 Section 3.6 of [RFC2679] indicates the items to report. 587 4.2.10 Path 589 4.3 A Definition for Spatial One-way Packet Loss Stream 591 This section is coupled with the definition of Type-P-One-way-Packet- 592 Loss. Then when a parameter from the section 2 of [RFC2680] is first 593 used in this section, it will be tagged with a trailing asterisk. 595 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 596 statements for end-to-end one-way-Packet-Loss measurements. They are 597 applicable to each point of interest Hi involved in the measure. 598 Spatial packet loss measurement SHOULD be respectful of them, 599 especially those related to methodology, clock, uncertainities and 600 reporting. 602 Following we define the spatial metric, then we adapt some of the 603 points above and introduce points specific to spatial measurement. 605 4.3.1 Metric Name 607 Type-P-Spatial-One-way-Packet-Loss-Stream 609 4.3.2 Metric Parameters 611 + Src*, the IP address of the sender. 613 + Dst*, the IP address of the receiver. 615 + i, An integer which ordered the hosts in the path. 617 + Hi, exchange points of the path digest. 619 + T*, a time, the sending (or initial observation) time for 620 a measured packet. 622 + dT1,..., dTn, dT, a list of delay. 624 + P*, the specification of the packet type. 626 + , a path digest. 628 + B1, B2, ..., Bi, ..., Bn, a list of boolean values. 630 4.3.3 Metric Units 632 A sequence of boolean values. 634 4.3.4 Definition 636 Given a Type-P packet sent by the sender Src at time T to the 637 receiver Dst in the path . Given the sequence of 638 times the packet passes , 641 Type-P-One-way-Packet-Lost-Stream metric is defined as the sequence 642 of values such that for each Hi of the path, a 643 value of Bi of 0 means that dTi is a finite value, and a value of 1 644 means that dTi is undefined. 646 4.3.5 Discussion 648 Following are specific issues wich may occur: 650 o the result includes the sequence 1,0. This case means that the 651 packet was seen by a host but not by it successor on the path; 653 4.3.6 Discussion 655 The location of the meter in the device influences the result: 657 o Even if the packet is received by a device, it may be not observed 658 by a meter located after a buffer; 660 4.3.7 Sections in progress 662 4.4 A Definition for Spatial One-way Jitter Stream 664 This section uses parameters from the definition of Type-P-One-way- 665 ipdv. When a parameter from section 2 of [RFC3393] is first used in 666 this section, it will be tagged with a trailing asterisk. 668 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 669 statements for end-to-end one-way-ipdv measurements. They are 670 applicable to each point of interest Hi involved in the measure. 671 Spatial one-way-ipdv measurement SHOULD be respectful of them, 672 especially those related to methodology, clock, uncertainities and 673 reporting. 675 Following we adapt some of them and introduce points specific to 676 spatial measurement. 678 4.4.1 Metric Name 680 Type-P-Spatial-One-way-Jitter-Stream 682 4.4.2 Metric Parameters 684 + Src*, the IP address of the sender. 686 + Dst*, the IP address of the receiver. 688 + i, An integer which ordered the hosts in the path. 690 + Hi, exchange points of the path digest. 692 + T1*, the time the first packet was sent. 694 + T2*, the time the second packet was sent. 696 + P, the specification of the packet type. 698 + P1, the first packet sent at time T1. 700 + P2, the second packet sent at time T2. 702 + , a path digest. 704 + , 705 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 706 time T1; 708 + , 709 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 710 time T2; 712 + L*, a packet length in bits. The packets of a Type P 713 packet stream from which the 714 Type-P-Spatial-One-way-Delay-Stream metric is taken MUST 715 all be of the same length. 717 4.4.3 Metric Units 719 A sequence of times. 721 4.4.4 Definition 723 Given the Type-P packet having the size L and sent by the sender Src 724 at wire-time (first bit) T1 to the receiver Dst in the path . 727 Given the Type-P packet having the size L and sent by the sender Src 728 at wire-time (first bit) T2 to the receiver Dst in the same path. 730 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P1. 733 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P2. 736 Type-P-Spatial-One-way-Jitter-Stream metric is defined as the 737 sequence of values Such that for each Hi of the path , 739 dT2.i-dT1.i is either a real number if the packets P1 and P2 passes 740 Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if 741 at least one of them never passes Hi. T2-T1 is the inter-packet 742 emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at 743 T1,T2*. 745 4.4.5 Sections in progress 747 See sections 3.5 to 3.7 of [RFC3393]. 749 4.5 Discussion on pure passive measurement of spatial metrics 751 Spatial metrics may be measured without injecting test traffic as 752 described in [I-D.boschi-export-perpktinfo] even if such a technique 753 have some limitations. 755 o The packet is not a test packet, so it does not include the time 756 it was sent. Consequently a point of interest Hi ignores the time 757 the packet was send. So It is not possible to measure the first 758 hop delay. The collector ignores the time the packet was 759 received. So it is not possible to measure the last hop delay. 760 One might says that most of the operational issues occur in the 761 last mile and that consequently such measure are not 762 useful.Nevertheless they are usable for network TE and interdomain 763 QoS monitoring. 765 o The collector ignores the time the packet was send. So It is not 766 possible to determine that it is lost. 768 o A point of interest Hi ignores the time the packet is send because 769 the packet does not carry the time it was injected in the network. 770 So a probe Hi can not compute dTi. 772 An alternative to these issues consist in considering that T is the 773 time when H1 (the first passive probe of the path) observed the 774 packet. 776 To avoid misunderstanding and to address specific reporting 777 constraint a proposal consists in defining distinct metrics for pure 778 passive measurement based on the definition above. Having distinct 779 metrics identifiers for spatial metrics and passive spatial metrics 780 in the [RFC4148] will avoid interoperabily issues. They may be named 782 o Type-P-Passive-One-way-delay-Stream 784 o Type-P-Passive-One-way-Packet-Loss-Stream 786 o Type-P-Passive-One-way-jitter-Stream 788 4.6 Discussion on spatial statistics 790 Do we define min, max, avg of spatial metrics ? 792 having the maximum loss metric value could be interesting. Say, 793 the segment between router A and B always contributes loss metric 794 value of "1" means it could be the potential problem segment. 796 Uploading dTi of each Hi consume a lot of bandwidth. Computing 797 statistics (min, max and avg) of dTi locally in each Hi reduce the 798 bandwidth consumption. 800 5. One-to-group metrics definitions 802 5.1 A Definition for one-to-group One-way Delay Stream 804 5.1.1 Metric Name 806 Type-P-one-to-group-One-way-Delay-Stream 808 5.1.2 Metric Parameters 810 + Src, the IP address of a host acting as the source. 812 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 813 receivers. 815 + T, a time. 817 + dT1,...,dTn a list of time. 819 + P, the specification of the packet type. 821 5.1.3 Metric Units 823 The value of a Type-P-one-to-group-One-way-Delay-Stream is a set of 824 singletons metrics Type-P-One-way-Delay [RFC2679]. 826 5.1.4 Definition 828 Given a Type P packet sent by the source Src at Time T, given the N 829 hosts { Recv1,...,RecvN } which receive the packet at the time { 830 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Stream is 831 defined as the set of the Type-P-One-way-Delay singleton between Src 832 and each receiver with value of { dT1, dT2,...,dTn }. 834 5.2 A Definition for one-to-group One-way Packet Loss Stream 836 5.2.1 Metric Name 838 Type-P-one-to-group-One-way-Packet-Loss-Stream 840 5.2.2 Metric Parameters 842 + Src, the IP address of a host acting as the source. 844 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 845 receivers. 847 + T, a time. 849 + T1,...,Tn, a list of time. 851 + P, the specification of the packet type. 853 5.2.3 Metric Units 855 The value of a Type-P-one-to-group-One-way-Packet-Loss-Stream is a 856 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 858 5.2.4 Definition 860 Given a Type P packet sent by the source Src at T and the N hosts, 861 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 862 Type-P-one-to-group-One-way-Packet-Loss-Stream is defined as a set of 863 the Type-P-One-way-Packet-Loss singleton between Src and each of the 864 receivers {,,..., }. 866 5.3 A Definition for one-to-group One-way Jitter Stream 868 5.3.1 Metric Name 870 Type-P-one-to-group-One-way-Jitter-Stream 872 5.3.2 Metric Parameters 874 + Src, the IP address of a host acting as the source. 876 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 877 receivers. 879 + T1, a time. 881 + T2, a time. 883 + ddT1,...,ddTn, a list of time. 885 + P, the specification of the packet type. 887 + F, a selection function defining unambiguously the two 888 packets from the stream selected for the metric. 890 5.3.3 Metric Units 892 The value of a Type-P-one-to-group-One-way-Jitter-Stream is a set of 893 singletons metrics Type-P-One-way-ipdv [RFC3393]. 895 5.3.4 Definition 897 Given a Type P packet stream, Type-P-one-to-group-One-way- Jitter- 898 Stream is defined for two packets from the source Src to the N hosts 899 {Recv1,...,RecvN },which are selected by the selection function F, as 900 the difference between the value of the Type-P-one-to-group-One-way- 901 Delay-Stream from Src to { Recv1,..., RecvN } at time T1 and the 902 value of the Type-P-one-to-group- One-way-Delay-Stream from Src to { 903 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Scr sent 904 the first bit of the first packet, and T2 is the wire-time at which 905 Src sent the first bit of the second packet. This metric is derived 906 from the Type-P-one-to- group-One-way-Delay-Stream metric. 908 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 909 group-One-way-Jitter-Stream from Src to { Recv1,...,RecvN } at T1, T2 910 is {ddT1,...,ddTn} means that Src sent two packets, the first at 911 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 912 and the packets were received by { Recv1,...,RecvN } at wire-time 913 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 914 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 915 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 917 5.4 Discussion on one-to-group statistics 919 The defined one-to-group metrics above can all be directly achieved 920 from the relevant unicast one-way metrics. They managed to collect 921 all unicast measurement results of one-way metrics together in one 922 profile and sort them by receivers and packets in a multicast group. 923 They can provide sufficient information regarding the network 924 performance in terms of each receiver and guide engineers to identify 925 potential problem happened on each branch of a multicast routing 926 tree. However, these metrics can not be directly used to 927 conveniently present the performance in terms of a group and neither 928 to identify the relative QoS situation. 930 One may say that no matter how many people join the communication, 931 the connections can still be treated as a set of one-to-one 932 connection. However, we might not describe a multiparty 933 communication by a set of one-way measurement metrics because of the 934 difficulty for understanding and the lack of convenience. For 935 instance, an engineer might not describe the connections of a 936 multiparty online conference in terms of one-to-group one-way delay 937 for user A and B, B and C, and C and A because people might be 938 confused. If there are more users in the same communication, the 939 description might be very long. And he might use the one-way metrics 940 with worst and the best value to give users an idea of the QoS range 941 of the service they are providing. But it is not clear enough and 942 might not be accurate in a large multiparty communication scenario. 944 From the QoS point of view, the multiparty communication services not 945 only require the absolute QoS support but also the relative QoS. The 946 relative QoS means the difference between absolute QoS of all users. 948 Directly using the one-way metrics cannot present the relative QoS 949 situation. However, if we use the variations of all users one-way 950 parameters, we can have new metrics to measure the difference of the 951 absolute QoS and hence provide the threshold value of relative QoS 952 that a multiparty service might demand. A very good example of the 953 high relative QoS requirement is the online gaming. A very light 954 worse delay will result in failure in the game. We have to use the 955 new statistic metrics to define exactly how small the relative delay 956 the online gaming requires. There are many other services, e.g. 957 online biding, online stock market, etc., need a rule to judge the 958 relative QoS requirement. Therefore, we can see the importance of 959 new statistic metrics to feed this need. 961 We might use some one-to-group statistic conceptions to present the 962 group performance and relative QoS. In this stage, we define one-to- 963 group mean stream and one-to-group variation stream. These 964 statistics are offered mostly to be illustrative of what could be 965 done. 967 One-to-group mean streams are trying to measure the overall QoS for a 968 multicast group associated to one source. It is a reflection of the 969 absolute QoS of a multiparty communication service when we treat all 970 receivers as one customer. It can also present the trend of the 971 absolute QoS of all receivers, i.e., it shows that most of the 972 receivers in the multiparty communication service trend to receive an 973 absolute QoS close to the mean. 975 One-to-group variation streams are trying to measure how the QoS 976 varies among all of the users in a multicast group associated to one 977 source. The word "variation" in this memo is the population standard 978 deviation. It reflects the relative QoS situation in a multiparty 979 communication service, i.e., the level of the difference between the 980 absolute QoS of each receivers. 982 Using the one-to-group mean and one-to-group variation concepts, we 983 can have a much clear understand on the QoS of a multiparty 984 communication service in terms of its trend and range. There can be 985 mean and variation stream definitions for each of the three one-to- 986 group metrics defined above. We only present the definition of Type- 987 P-one-to-group-One-way- Delay-Mean-Stream and Type-P-one-to-group- 988 One-way-Delay-Variation-Stream as examples in this memo. 990 5.4.1 Type-P-one-to-group-One-way-Delay-Mean-Stream 992 Given a Type-P-one-to-group-One-way-Delay-Stream, the mean stream of 993 all { dT1, dT2,...,dTn } for the packet from Src at time T to { 994 Recv1,...,RecvN }. 996 For example, suppose we take a sample and the results are: 998 Delay_Stream = < 999 {T1,...,Tn} 1000 {T'1,...,T'n} 1001 {T''1,...T''n} 1002 > 1004 Then the mean stream would be: 1006 Delay_Mean_Stream = < 1007 DM1 1008 DM2 1009 DM3 1010 > 1011 = < 1012 sum{T1,...,Tn}/n 1013 sum{T'1,...,T'n}/n 1014 sum{T''1,...T''n}/n 1015 > 1017 5.4.2 Type-P-one-to-group-One-way-Delay-Variation-Stream 1019 Given a Type-P-one-to-group-One-way-Delay-Stream, the variation 1020 stream of all { dT1, dT2,...,dTn } for the packet from Src at time T 1021 to { Recv1,...,RecvN }. 1023 We still take the above Delay_Stream as a sample and the variation 1024 stream would be: 1026 Delay_Variation_Stream = < 1027 DV1 1028 DV2 1029 DV3 1030 > 1031 =< 1032 (SUM{(T1-DM1)^2,...,(Tn-DM1)^2)}/n)^(1/2) 1033 (SUM{(T'1-DM2)^2,...,(T'n-DM2)^2)}/n)^(1/2) 1034 (SUM{(T''1-DM3)^2,...,(T''n-DM3)^2)}/n)^(1/2) 1035 > 1037 6. Open issues 1039 7. Security Considerations 1041 Active measumrement: see security section in owd pl, jitter rfcs 1042 (editor notes: add references). 1044 passive measurement: The rate of packet sampling is controled by hash 1045 funcion. The analysis of such a function to generate packets that 1046 match the hash funcion may lead to a DoS attack toward the collector. 1047 The generation of packets with spoofing adresses may corrupt the 1048 results without any possibility to detect the spoofing. 1050 TODO: one-to-group metrics defined here are not intrusive: they rely 1051 on measures of owd... nevertheless they require collection of 1052 singletons which may overload the network the measurement controller 1053 is attach to. 1055 The one-to-group metrics are derived from one-way metrics and 1056 therefore, they have very close relationship. 1058 8. IANA Considerations 1060 Metrics defined in this memo will be registered in the IANA IPPM 1061 METRICS REGISTRY as described in initial version of the registry 1062 [RFC4148]. 1064 9. References 1066 9.1 Normative References 1068 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1069 "Framework for IP Performance Metrics", RFC 2330, 1070 May 1998. 1072 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1073 Delay Metric for IPPM", RFC 2679, September 1999. 1075 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1076 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1078 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1079 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1080 November 2002. 1082 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1083 Registry", BCP 108, RFC 4148, August 2005. 1085 9.2 Informative References 1087 [I-D.boschi-export-perpktinfo] 1088 Boschi, E. and L. Mark, "Use of IPFIX for Export of Per- 1089 Packet Information", draft-boschi-export-perpktinfo-00 1090 (work in progress), June 2005. 1092 [I-D.morton-ippm-composition] 1093 Morton, A., "Composition of Metrics", 1094 draft-morton-ippm-composition-00 (work in progress), 1095 July 2005. 1097 [I-D.quittek-ipfix-middlebox] 1098 Quittek, J., "Guidelines for IPFIX Implementations on 1099 Middleboxes", draft-quittek-ipfix-middlebox-00 (work in 1100 progress), February 2004. 1102 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 1103 Connectivity", RFC 2678, September 1999. 1105 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1106 Delay Metric for IPPM", RFC 2681, September 1999. 1108 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1109 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1110 July 2001. 1112 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 1113 Metrics", RFC 3357, August 2002. 1115 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1116 performance measurement with periodic streams", RFC 3432, 1117 November 2002. 1119 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 1120 Measurement Protocol (OWAMP) Requirements", RFC 3763, 1121 April 2004. 1123 Authors' Addresses 1125 Stephan Emile 1126 France Telecom Division R&D 1127 2 avenue Pierre Marzin 1128 Lannion, F-22307 1130 Fax: +33 2 96 05 18 52 1131 Email: emile.stephan@francetelecom.com 1132 Lei Liang 1133 CCSR, University of Surrey 1134 Guildford 1135 Surrey, GU2 7XH 1137 Fax: +44 1483 683641 1138 Email: L.Liang@surrey.ac.uk 1140 Al Morton 1141 200 Laurel Ave. South 1142 Middletown, NJ 07748 1143 USA 1145 Phone: +1 732 420 1571 1146 Email: acmorton@att.com 1148 Intellectual Property Statement 1150 The IETF takes no position regarding the validity or scope of any 1151 Intellectual Property Rights or other rights that might be claimed to 1152 pertain to the implementation or use of the technology described in 1153 this document or the extent to which any license under such rights 1154 might or might not be available; nor does it represent that it has 1155 made any independent effort to identify any such rights. Information 1156 on the procedures with respect to rights in RFC documents can be 1157 found in BCP 78 and BCP 79. 1159 Copies of IPR disclosures made to the IETF Secretariat and any 1160 assurances of licenses to be made available, or the result of an 1161 attempt made to obtain a general license or permission for the use of 1162 such proprietary rights by implementers or users of this 1163 specification can be obtained from the IETF on-line IPR repository at 1164 http://www.ietf.org/ipr. 1166 The IETF invites any interested party to bring to its attention any 1167 copyrights, patents or patent applications, or other proprietary 1168 rights that may cover technology that may be required to implement 1169 this standard. Please address the information to the IETF at 1170 ietf-ipr@ietf.org. 1172 Disclaimer of Validity 1174 This document and the information contained herein are provided on an 1175 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1176 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1177 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1178 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1179 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1180 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1182 Copyright Statement 1184 Copyright (C) The Internet Society (2005). This document is subject 1185 to the rights, licenses and restrictions contained in BCP 78, and 1186 except as set forth therein, the authors retain all their rights. 1188 Acknowledgment 1190 Funding for the RFC Editor function is currently provided by the 1191 Internet Society.