idnits 2.17.1 draft-ionta-new-multiparty-metrics-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 814 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6390], [RFC5644]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 4, 2013) is 3978 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) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ionta 3 Internet-Draft Telecom Italia Labs 4 Intended status: Standard Track June 4, 2013 5 Expires: December 3, 2013 7 New Performance Metrics Composition Framework for Multiparty Services 8 draft-ionta-new-multiparty-metrics-framework-02 10 Abstract 11 One of the best chances for a Service Provider to face the complex 12 growth of IP Services, and their challenging requirements/SLAs along 13 the Core network, is to enrich the current Performance metrics - mainly 14 derived from a "Network-Oriented point of view", and therefore a 15 general perspective, not focused on specific services - with some more 16 Performance factors, so to include a "Service-Oriented point of view", 17 more centred on the particular kind of service, with its own 18 characteristics in terms of protocol, application, manageability, and 19 so on. 20 Almost nothing about this new approach has been standardized yet for 21 the core network. 22 To achieve the above goal, and starting from the one-to-group 23 performance metrics outlined in RFC 5644 [RFC5644], a new metrics 24 composition/aggregation framework is proposed in this memo, where the 25 main focus is on multiparty communications (e.g. video providers, 26 online biding, online stock market, etc.). 27 Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 28 framework concepts, and need to widen the current performance metrics 29 depending on the application, service etc. 31 Copyright Notice 33 Copyright (c) 2012 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 37 Relating to IETF Documents (http://trustee.ietf.org/license-info) 38 in effect on the date of publication of this document. Please 39 review these documents carefully, as they describe your rights and 40 restrictions with respect to this document. 42 This Internet-Draft is submitted in full conformance with the provisions 43 of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering Task 46 Force (IETF), its areas, and its working groups. Note that other 47 groups may also distribute working documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at 51 any time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/1id-abstracts.html. 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 Table of Contents 61 1. Introduction and Scope ..........................................2 62 2. Terminology .....................................................3 63 3. Brief metric description.........................................7 64 4. One-to-Group Link Metrics definition ............................8 65 5. One-to-Group Link and Path Statistics ...........................9 66 6. One-to-Group Overall Packet Loss Statistics ....................10 67 7. Extended applications...........................................11 68 8. Security Considerations ........................................12 69 9. IANA Considerations.............................................12 70 10. References ....................................................12 71 11. Acknowledgments................................................13 73 1. Introduction and Scope 75 Current Performance Metrics, especially those applied to the core 76 network, derive from a "general perspective" approach, only based on a 77 "Network-oriented point of view", therefore unconnected to the kind of 78 service offered on the network. 79 But, due to the growing need to face the complexity of the new IP 80 Services, and their challenging SLAs, this approach has become 81 inadequate, especially while trying to detect the impact of a 82 performance measurement on a particular service. For instance, if a 83 network or a link has a 10-4 average PLR, does this impact on the kind 84 of service required to be monitored? And to what degree? 85 Moreover, this "general perspective" approach is unsuited to perceive 86 further various factors to be taken into account, such as: 88 - the specificity of the service, with its own protocol, application 89 (i.e. coding), and management (i.e. QOS, fragmentation management) 90 characteristics. 92 - the kind of network topology over which the particular service is 93 implemented (i.e. redundancy, tunneling, etc.). 95 A trivial but clarifying example of this occurs when the same PLR is 96 detected over two different links: one of the link coming out from the 97 root (source) of a multicast tree, and the other link ending with a 98 leaf (receiver). 99 The impact on the service, of course, is dramatically different if the 100 two cases are considered separately, since the first kind of link 101 conveys the whole set of flows originating from the source, while the 102 second one conveys just a subset of the whole set of flows. 103 As a consequence of the above consideration, a "Service-oriented point 104 of view" - more centred on the particular kind of service, and its own 105 specific characteristics - must be taken into account while defining 106 Performance metrics. In particular two needs raise: 108 - widening the aggregation concepts in RFC 5835 [RFC5835], assign a 109 sort of weight, specific, and different for each link, to the PLR 110 measured over it, in order to take into account the impact of the PLR 111 on the service. 113 - starting from the metrics outlined in the RFC 5644 [RFC5644] for 114 multiparty 115 services, define a new performance metrics composition/aggregation 116 framework, so to enrich the current Performance Metrics, mainly derived 117 from a "Network-oriented point of view". 119 The main focus of this memo is to address these two needs for 120 multiparty communications (e.g. TV broadcast providers, video 121 providers, online biding, online stock market, etc.) in order to better 122 evaluate the network against the service requirements. 124 Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 125 framework concepts, and need to widen the current performance metrics 126 depending on the application, service etc. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2. Terminology 136 2.1 Naming of the metrics 138 The names of the metrics, including capitalized letters, are as close 139 as possible of the names of the one-way end-to-end or one-to-group 140 metrics they are derived from. 142 2.2 Terms defined elsewhere 144 composed metric: section 4 of RFC 5835 145 composition function: section 4 of RFC 5835 146 higher-order composition: section 5 of RFC 5835 147 host: section 5 of RFC 2330 148 link: path: section 5 of RFC 2330 149 one-to-group metric: section 2 of RFC 5644 150 path: section 5 of RFC 2330 151 router: section 5 of RFC 2330 152 routers digest: section 2 of RFC 5644 153 sample: section 11 of RFC 2330 154 singleton: section 11 of RFC 2330 155 spatial aggregation: section 5 of RFC 5835 156 spatial composition: section 5 of RFC 5835 157 spatial metric: section 2 of RFC 5644 158 subpath: section 5 of RFC 2330 159 temporal aggregation: section 5 of RFC 5835 160 Type-P: see RFC 2330 161 Type-P-One-way-Packet-Loss-Average: see RFC 2680, and RFC 5644 163 2.2 One-to-Group metrics defined elsewhere 165 Type-P-One-to-group-Packet-Loss-Vector: section 7, and 8 of RFC 5644 166 Type-P-One-to-group-Receiver-n-Loss-Ratio: section 7, and 8 of RFC 5644 167 Type-P-One-to-group-Loss-Ratio: section 7, and 8 of RFC 5644 169 2.3 Points of Interest 171 The points of interest correspond to the hosts (according to the RFC 172 2330 definition, "hosts" include routing nodes), - i.e. measurement 173 collection points - which are a sub-set of the set of hosts involved in 174 the delivery of the packets (in addition to the source itself). 175 In RFC 5644 two possible scenarios concerning the points of interest 176 (the spatial one, and one-to-group) have been considered. 177 For the purpose of this memo a sort of mixed scenario, among the ones 178 shown above, is taken into account. In fact the whole set of the hosts 179 composing a multicast tree, including destinations, are points of 180 interest. 181 An example of a very simple multicast tree, and its related points of 182 interest is depicted in Fig. 1. 184 Dst 185 /----(*)1 186 (*)----(*)2 187 / \----(*)3 188 / 189 / /--(*)4 190 Src --- (*)--(*)--(*)5 191 \ 192 ... ...--(*)x 193 \ 194 (*)----(*)X-1 195 \----(*)X 197 Note : (*) represent the nodes that are points of interest 199 Figure 1: Points of Interest for a multicast tree 201 2.4 Multicast tree equivalent splitting 203 A generic single-source multicast tree, like the very simple one 204 depicted in Fig.2, is composed by J links, and X receivers. 206 Link 1 Link 2 Link 3 207 +--------+ +--------+ +--------+ +--------+ 208 | H1 <>--------<> H2 <>---------<> H3 <>--------<> H4 | 209 +--------+ +---<>---+ +--------+ +--------+ 210 | 211 | 212 | Link 4 +--------+ 213 +----------------------------------<> H5 | 214 +--------+ 215 <> Interface 216 ---- Link 218 Figure 2: Example of a whole (or part of) multicast tree 220 To accomplish the task of this memo, an equivalent representation of 221 the generic single-source multicast tree is proposed, which is obtained 222 by splitting it in X different Multicast Equivalent Paths (called "ME- 223 Paths", from now on), each of them corresponding to one of the X 224 different paths - as better explained below - starting from the source, 225 and ending up into one of the X receivers. 226 The generic ME-Path x is composed by the sequence of hosts, and 227 corresponding links between the source, and the receiver x. 228 As a result, the ME-Paths are different from each other because even if 229 they can partially overlap, they never do it completely. This happens 230 because each ME-Path is different from all the other ones regarding at 231 least one link, the one ending on the receiver, belonging just to one 232 ME-Path. 233 To clarify this concept, let's apply the splitting method to the very 234 simple tree in Fig. 2. 235 It has only two leaves (receivers), therefore, only two different ME- 236 Paths can be derived, as shown below (Fig. 3). 238 Link 1 Link 2 Link 3 239 +------+ +------+ +------+ +-------+ 240 ME-PATH 1 | H1 <>--------<> H2 <>--------<> H3 <>--------<> H4 | 241 +------+ +------+ +------+ +-------+ 243 Link 1 Link 4 244 +------+ +-------+ +-------+ 245 ME-PATH 2 | H1 <>-------<> H2 <>-------------------------<> H5 | 246 +------+ +-------+ +-------+ 248 <> Interface 249 ---- Link 251 Figure 3: single-source multicast tree equivalent splitting. 253 The ME-Path definition shown above allows possible partial overlappings 254 among some ME-Paths (e.g. ME-Path 1, and ME-Path 2 in Fig. 3). This is 255 a specific choice, as detailed hereafter in section 5.3.1. 257 The numbering of the links composing the multiparty tree is free, 258 provided that: 260 - the link numbering remains univocal with respect to the multicast 261 tree. 263 - even if belonging to many ME-Paths, the same link between the same 264 two hosts, keeps the same name (e.g. Link 1 in both ME-Path 1, and ME- 265 Path 2 in Fig. 3) 267 2.5 Vector 269 In accordance with the definition of RFC 5644 stated in section 2, a 270 vector is a set of singletons (single atomic results) comprised of 271 observations corresponding to a packet sent from one point to another. 272 In this memo the packet is sent from one side to the other one of each 273 of the J links composing the multicast tree. For instance, if the one- 274 way loss singletons observed over J links are LL1,LL2,...,LLJ (where 275 "LL" stands for Link Loss) then a generic one-way loss vector V with J 276 elements can be organized as {LL1, LL2,..., LLJ}. The complete vector 277 gives information over the dimension of space, a set of J links in this 278 memo. 279 Different vectors for common measurement points of interest are 280 distinguished by the packet sending time. 282 2.6 Matrix 284 As stated in RFC 5644, several vectors form a matrix, which contains 285 results observed over a sampling interval (from T0 to TK) at different 286 places in a network at different times. 287 For instance, a one-way loss Matrix {V1,V2,...,Vk,...,VK} is formed by 288 the one-way loss vectors V1={LL11,LL21,...,LLj1, ...,LLJ1}, 289 V2={LL12,LL22,...,LLj2, ...,LLJ2},..., Vk={LL1k,LL2k,...,LLjk, 290 ...,LLJk},...,VK={LL1K,LL2K,...,LLjK, ...,LLJK} for a sample of packets 291 P1, P2,...,Pk,...PK. 292 The matrix organizes the vectors information to present network 293 performance in both space and time. 294 Each row is a set of oneway singletons spreading over the time 295 dimension, and each column is another set of One-way singletons 296 spreading over the space dimension. 297 A one-dimensional matrix (row) corresponds to a sample in simple point- 298 to-point (a link in this memo) measurement. 299 The relationship among sample, vector, and matrix is illustrated in 300 Figure 4. 302 Space 303 ^ 304 Link | /----------- Samples ------------------\ 305 | 306 1 | LL11 LL12 LL13 ... LL1k ... LL1K 307 | 308 2 | LL21 LL22 LL23 ... LL2k ... LL2K 309 | 310 3 | LL31 LL32 LL33 ... LL3k ... LL3K 311 . | . . . ... . . 312 . | . . . ... . . 313 j | LLj1 LLj2 LLj3 ... LLjk ... LLjK 314 . | . . . ... . . 315 . | . . . ... . . 316 J | LLJ1 LLJ2 LLJ3 ... LLJk ... LLJK 317 | 318 +-----+-----+-----+---...-----+----...---+----> time 319 T0 T1 T2 T3 Tk TK 320 ^ ^ 321 | | 322 Vector V2 Vector Vk 324 Figure 4: Relationship among Samples,Vectors, and Matrix. 326 3. Brief metric description 328 The metrics, and KPI defined in this memo are based on the source-to- 329 destination or end-to-end or one-to-group metrics defined by IETF in 330 [RFC2679], [RFC2680], [RFC3393], [RFC3432], and [RFC5644]. 331 The [RFC2330], and [RFC5644] framework of parameters, unit of 332 measurement, and measurement methodologies are also adopted. 334 In RFC5644 two different approaches have been considered: the spatial 335 metric approach - intended to measure the performance of each segment 336 along a path - and the multiparty one, aimed at measuring the end-to- 337 end performance between one sorce and a group of receivers. 338 To achieve the goals of this memo - enriching the current one-to-group 339 Performance metrics, and statistics also with a "Service-oriented point 340 of view" - a "mixed" approach is taken into account in this memo, and a 341 new set of multiparty metrics is stated. 343 This memo defines two new metrics: 345 - Type-P-One-to-Group-Link-Packet-Loss-Vector which collects the set of 346 Type-P-One-way-Packet-Loss singletons between one side and the other 347 one of each of the links composing a multicast tree; 349 - Type-P-One-to-Group-Link-Packet-Loss-Matrix which organizes the 350 above vectors information to present network performance in both space 351 and time. 353 Based on the above mentioned new metrics, new link, and path statistics 354 are defined: 356 - Type-P-One-to-Group-Link-j-Loss-Ratio captures the overall 357 packet loss ratio for link j; 359 - Type-P-One-to-Group-Link-Loss-Ratio-Vector which collects the set of 360 Type-P-One-to-Group-Link-j-Loss-Ratios of each of the links composing 361 a multicast tree; 363 - Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio captures the overall 364 Weighed packet loss ratio for link j; 366 - Type-P-One-to-Group-Link-Weighted-Loss-Vector which collects the set 367 of Type-P-One-to-Group-Link-j-Weighted-Loss-Ratios of each of the links 368 composing a multicast tree. Since this is a very important vector, in 369 this memo it is also referred to as the "reference vector"; 371 - Type-P-One-to-Group-MEPath-x-Loss-Vector which collects a subset of 372 Type-P-One-to-Group-Link-Weighted-Loss-Vector elements, which are 373 only those corresponding to the links belonging to the generic MEpath 374 x. 376 Finally, based on the statistics shown above, a new overall performance 377 metrics composition/aggregation framework is defined: 379 - Type-P-One-to-Group-MEPath-x-Loss-Ratio is a user definable metric 380 composition/aggregation function applied to the set of Type-P-One-to- 381 group-Link-j-Loss-Ratios associated to the links belonging to the 382 generic ME-Path x; 384 - Type-P-One-to-Group-KPI-Loss-Ratio is a user definable metric 385 composition/aggregation function applied to all Type-P-One-to-group- 386 Path-x-Loss-Ratios of the ME-Paths composing the multiparty tree. 388 4. One-to-Group Link Metrics definition 390 This section defines vectors, and matrix for a one-to-group topology 391 using loss singleton over the J links composing the multicast tree. 393 4.1. Type-P-One-to-Group-Link-Packet-Loss-Vector 395 Each element of the vector defined in section 2 of this memo represents 396 a loss singleton over one of the J links composing the multicast tree. 397 Thus the number of elements composing the whole vector equals the 398 number of links (that is J) composing the whole multiparty tree. 399 The generic Type-P-One-to-Group-Link-Packet-Loss-Vector for a packet 400 sent at time Tk can be represented as: 402 Vk = 404 where j=1,2,...,J , and LLj is the loss singleton over link j. 406 4.2. Type-P-One-to-Group-Link-Packet-Loss-Matrix 408 Composing the J vectors shown above, as described in section 2, a Type- 409 P-One-to-Group-Link-Packet-Loss-Matrix can be built: 411 space 412 ^ 413 Link | /----------- Samples ----------\ Stats 414 | 415 1 | LL11 LL12 ... LL1k ... LL1K LL1LR 416 | 417 2 | LL21 LL22 ... LL2k ... LL2K LL2LR 418 | 419 3 | LL31 LL32 ... LL3k ... LL3K LL3LR 420 . | . . ... . . . 421 . | . . ... . . . 422 j | LLj1 LLj2 ... LLjk ... LLjK LLjLR <-- Link-j Loss Ratio 423 . | . . ... . . . 424 . | . . ... . . . 425 J | LLJ1 LLJ2 ... LLJk ... LLJK LLJLR 426 | 427 +---+-----+----...----+----...--+-->time ^ 428 T0 T1 T2 Tk TK | 429 ^ | 430 | | 431 Vector Vk Link Loss Ratio Vector 433 Figure 3: Type-P-One-to-Group-Link-Packet-Loss-Matrix J*K 435 From the considerations stated above it can be derived that the number 436 of rows composing the matrix equals the number of links (that is J) 437 composing the whole multicast tree. 439 All loss ratios are expressed in units of packets lost to total packets 440 sent. Statistics are computed on the sample of Type-P-One-way-Packet- 441 Loss[RFC2680] of the above matrix. 443 Based on the one-to-group vector metrics listed above, statistics are 444 defined below, so to capture single link performance, ME-Path 445 performance, and group performance, and the relative performance for a 446 multiparty communication. 448 5. One-to-Group Link and Path Statistics 450 Starting from the above metrics definition, this section defines link, 451 and path statistics for a one-to-group topology. 453 5.1. Type-P-One-to-Group-Link-j-Loss-Ratio 455 Given the Type-P-One-to-Group-Link-Packet-Loss-Matrix depicted in Fig. 456 3, and according to the definitions, and method of [RFC2680], a Type-P- 457 One-way-Packet-Loss-Average for the sample at each of the J links can 458 be determined, and named Type-P-One-to-group-Link-j-Loss-Ratio, also 459 called LLjLR. 460 It can be expressed as 462 K 463 ------ 464 1 \ 465 LLjLR = - * > LLjk 466 K / 467 ------ 468 k = 1 470 Figure 4: Type-P-One-to-group-Link-j-Loss-Ratio for Link j. 472 5.2. Type-P-One-to-Group-Link-Loss-Ratio-Vector 474 The Type-P-One-to-Group-Link-Loss-Vector collects all the Type-P-One- 475 to-group-Link-j-Loss-Ratios computed on the J links composing the 476 multicast tree. 477 An example of Type-P-One-to-Group-Link-Loss-Vector is depicted in Fig. 478 3. 480 5.3. Discussion about the "weighing factor" 482 The purpose of this memo is to enrich the current Performance metrics - 483 mainly derived from a "Network-oriented point of view", and therefore a 484 general perspective, which is not focused on specific services - with 485 some more Performance factors, so to include a "Service-oriented point 486 of view" as well, more centred on: 488 - the specificity of the service or services to be monitored, with 489 their own protocols, applications (i.e. coding), and management (i.e. 490 QOS, fragmentation management) characteristics. 492 - the kind of network topology over which the service or services to be 493 monitored are implemented (i.e. redundancy, tunneling, etc.). 495 To accomplish this task a weighing factor Wj, related to the 496 corresponding Link j, is introduced. Thus each Type-P-One-to-group- 497 Link-j-Loss-Ratio is weighed through its own specific Wj. 498 Since this memo introduces a framework for performance metrics, the 499 characterization of Wj is user definable, and up to the service 500 provider, depending on many factors he has to manage. 501 Some, but not all, of the possible network, and/or service factors that 502 can be taken into account while characterizing Wj are: number of 503 multicast flows over link j, capacity (any possible type: total, 504 available, etc.) of link j, its redundancy, traffic flowing through 505 link j, type of service to be monitored over the link, location of the 506 link with respect to the whole topology, and so on. 508 5.3.1 Discussion about the "Overlapping Factor" 510 While characterizing each Wj - the so called "Overlapping Factor" - is 511 worthy of a special remark. 512 As discussed in section 2, ME-Paths can partially overlap, thus sharing 513 one or more links (e.g. Link 1 in Fig. 2). As a result, a generic Link 514 j can belong to more than one ME-Path. A consequence of this fact is 515 that the more the ME-Paths the generic Link j belongs to, the more a 516 packet loss over that link impacts the service it conveys. 517 For instance, even if the same packet loss is detected both over a link 518 coming out from the root (source) of a multicast tree, and over a link 519 ending on a receiver, the impact on the service is dramatically 520 different in the two cases. 521 As a consequence, the "Overlapping Factor" MUST be taken into account 522 while characterizing each Wj. 523 Considering this, a question arises: how to expressly include it in the 524 Wj characterization, since the ME-Paths overlappings are dynamically 525 varying, following the dynamic topology changes of the multicast tree. 526 A possible way to solve this problem is to take the "Overlapping 527 Factor" into account just implicitly, while calculating the final Type- 528 P-One-to-Group-KPI-Loss-Ratio, as hereafter deepened. 530 5.4. Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio 532 Based on the above discussion, a new entity is introduced: the Type-P- 533 One-to-group-Link-j-Weighted-Loss-Ratio (LLjWLR), defined as: 535 LLjWLR = LLjLR * Wj 537 Note that if Wj is set to 1, thus the weighing factor is not taken into 538 consideration for link j. 540 5.5. Type-P-One-to-Group-Link-Weighted-Loss-Vector 542 A new kind of loss vector is introduced, the Type-P-One-to-Group-Link- 543 Weighted-Loss-Vector (Fig. 5). 544 It collects all the Type-P-One-to-group-Link-j-Weighted-Loss-Ratios of 545 each of the links composing a multicast tree. 547 / LL1LR * W1 \ / LL1WLR \ 548 | LL2LR * W2 | | LL2WLR | 549 | LL3LR * W3 | | LL3WLR | 550 | LL4LR * W4 | ---> | LL4WLR | 551 | . | | . | 552 | . | | . | 553 | LLjLR * Wj | | LLjWLR| 554 | . | | . | 555 | . | | . | 556 \ LLJLR * WJ / \ LLJWLR / 558 Fig. 5. Type-P-One-to-Group-Link-Weighted-Loss-Vector 560 Type-P-One-to-Group-Link-Weighted-Loss-Vector is hereafter considered 561 the "Reference Vector" for the definition of the next statistics, and 562 KPI definitions. 564 5.6. Type-P-One-to-Group-MEPath-x-Loss-Vector 566 This section defines the overall one-way loss statistics for an ME-Path 567 (as defined above). 568 Starting from the "Reference Vector" (the above Type-P-One-to-Group- 569 Link-Weighted-Loss-Vector), and given the X possible ME-Paths 570 generated after the multicast tree splitting described in section 2, X 571 different Type-P-One-to-Group-MEPath-x-Loss-Vectors are created, each 572 of them composed by a subset of the whole set of the "Reference Vector" 573 elements (LLjWLR), in other words, only by those elements LLjWLR 574 associated to the links composing ME-Path x. 575 A clarifying example can be given applying the concepts shown above to 576 ME-Path 1, and 2 in Fig. 3. 577 For ME-Path 1: 578 /LL1WLR \ 579 Type-P-One-to-Group-MEPath-1-Loss-Vector = | LL2WLR | 580 \LL3WLR / 582 while for ME-Path 2: 583 /LL1WLR \ 584 Type-P-One-to-Group-MEPath-2-Loss-Vector = \LL4WLR / 586 The number of elements composing the generic Type-P-One-to-Group- 587 MEPath-x-Loss-Vector equals the number of links composing the ME- 588 Path x it derives from. 589 Note that since all ME-Paths are different from each other - at least 590 for one link - as a result of this, all Type-P-One-to-Group-MEPath-x- 591 Loss-Vectors are different from each other as well. 593 6. One-to-Group Overall Packet Loss Statistics 595 Starting from the link, and path statistics definition stated above, 596 this section defines the overall statistics for a one-to-group 597 topology. 599 6.1. Type-P-One-to-Group-MEPath-x-Loss-Ratio 601 The current "network-oriented" point of view states that the 602 calculation of the Packet Loss Ratio over a path is based on the Packet 603 Loss Ratio detected over each of the links belonging to the path, 604 applying the usual spatial composition formula: 606 Path Packet Loss Ratio = 1 - [(1-L1LR) * (1-L2LR) * ... *(1-LnLR)] 608 where LnLR represents the Packet Loss Ratio detected over the generic 609 link n belonging to the path. 611 However, due to the growing interest in enriching the current 612 performance metrics with a "service-oriented" point of view as well, 613 the purpose of this memo is to propose a new framework for performance 614 metric composition/aggregation. 615 Thus a new definition of an equivalent PLR over a generic ME-Path x is 616 given: 618 Type-P-One-to-Group-Path-x-Loss-Ratio= Fa (Type-P-One-to-Group- 619 MEPath-x-Loss-Vector) 621 where Fa is a user definable metric composition/aggregation function 622 applied to the set of Type-P-One-to-group-Link-j-Loss-Ratios 623 associated to the links belonging to the generic ME-Path x. 625 A very common example of Fa is the usual spatial composition formula 626 mentioned above. 628 6.2 Type-P-One-to-Group-KPI-Loss-Ratio 630 This section defines the overall one-way network-service KPI (Key 631 Performance Indicator) for a multicast tree loss statistics. 633 Type-P-One-to-Group-KPI-Loss-Ratio = Fb (Type-P-One-to-Group-Path- 634 1-Loss-Ratio, Type-P-One-to-Group-Path-2-Loss-Ratio, ..., Type-P-One- 635 to-Group-Path-X-Loss-Ratio) 637 where Fb is a user definable metric composition/aggregation 638 function applied to all Type-P-One-to-group-Path-x-Loss-Ratios 639 of the ME-Paths composing the multiparty tree. 641 Each service provider defines his own Fb, based on the topology of his 642 network, on the way the monitored service is implemented, on the 643 specific SLAs associated with the monitored service, and so on. 644 A very common example of Fb is the average function among all the 645 Type-P-One-to-group-Path-x-Loss-Ratios. Other possibilities are the 646 maximum value, the minimum value, the range, and so on. 647 Please point out that the "Overlapping Factor" described in section 648 5.3.1 is here taken into account, even if implicitly. In fact all the 649 paths are now considered, regardless of the presence of overlapping 650 links in the paths. 652 7. Extended applications 654 7.1. Extended applications to multi-source one-to-group topology 656 All the above discussion is applicable both to a single-source one-to- 657 group topology, and to a multi-source one-to-group topology. In fact, 658 given one single group flowing from several sources - thus different 659 from several groups flowing from several sources, that is a group-to 660 group topology - each host chooses just one, and only one source at a 661 time from which the flow is accepted, thus leading us back to the 662 single-source one-to-group situation already dealt with in this memo. 664 7.2. Extended applications to One-way Delay and Delay Variation 666 The framework proposed in this memo is wide enough to be applicable not 667 only to the Packet Loss analysis, but also to the One-way Delay, and 668 Delay Variation ones. 669 This goal is achievable by adequately defining Fa, Fb, and Wj. 670 Anyway, this is out of the scope of this memo, and it will be deepened 671 in another memo. 673 8. Security Considerations 675 Spatial, and one-to-group metrics are defined on the top of end-to-end 676 metrics. Security considerations discussed in the one-way delay 677 metrics definitions of [RFC2679], in packet loss metrics definitions 678 of [RFC2680], and in IPDV metrics definitions of [RFC3393], and 679 [RFC3432] apply to metrics defined in this memo. 680 Someone may spoof the identity of a point of interest identity, and 681 intentionally send corrupt results in order to remotely orient the 682 traffic engineering decisions. 683 A point of interest could intentionally corrupt its results in order 684 to remotely orient the traffic engineering decisions. 686 8.1. One-to-Group Metrics 688 Reporting of measurement results from a huge number of probes may 689 overload reference point resources (network, network interfaces, 690 computation capacities, etc.). 691 The configuration of a measurement must take into consideration that 692 implicitly more packets will be routed than sent and select a test 693 packet rate accordingly. Collecting statistics from a huge number of 694 probes may overload any combination of the network to which the 695 measurement controller is attached, measurement controller network 696 interfaces, and measurement controller computation capacities. 697 One-to-group metric measurements should consider using source 698 authentication protocols, standardized in the MSEC group, to avoid 699 fraud packet in the sampling interval. The test packet rate could be 700 negotiated before any measurement session to avoid denial-of-service 701 attacks. 702 A point of interest could intentionally degrade its results in order 703 to remotely increase the quality of the network on the branches of 704 the multicast tree to which it is connected. 706 9. IANA Considerations 708 This document has no actions for IANA. 710 10. References 712 10.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 718 Delay Metric for IPPM", RFC 2679, September 1999. 720 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 721 Packet Loss Metric for IPPM", RFC 2680, September 1999. 723 [RFC3393] Demichelis, C., and P. Chimento, "IP Packet Delay Variation 724 Metric for IP Performance Metrics (IPPM)", RFC 3393, 725 November 2002. 727 [RFC5644] Stephan, E., Liang L., Morton A., "IP Performance Metrics 728 (IPPM): Spatial and Multicast", RFC5644, October 2009. 730 [RFC6390] Clark, A., "Guidelines for Considering New Performance Metric 731 Development", BCP170, RFC6390, October 2011. 733 10.2. Informative References 735 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 736 "Framework for IP Performance Metrics", RFC 2330, 737 May 1998. 739 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 740 performance measurement with periodic streams", RFC 3432, 741 November 2002. 743 [RFC5835] Morton, A., Van den Berghe, S., "Framework for metric 744 composition", RFC5835, April 2010. 746 11. Acknowledgments 748 The author would like to thank his workmates A. Barbetti and A. 749 Cappadona for their helpful support while designing the main ideas 750 behind this memo. 751 I am grateful to my boss S. Mariani for trusting in the usefulness of 752 this activity. 753 I also acknowledge the precious comments and suggestions from A. Botta 754 and A. Pescape', University "Federico II", Naple, Italy. 755 A special thank to Daniela Labarbuta for her unselfish help while 756 translating this memo. 758 Author's Address 760 Tiziano Ionta (editor) 761 Telecom Italia Labs 762 Via Valcannuta 250 763 00167 Rome 764 Italy 766 Phone: +39 06 3688 5600 767 Email: tiziano.ionta@telecomitalia.it