Internet DRAFT - draft-ionta-new-multiparty-metrics-framework

draft-ionta-new-multiparty-metrics-framework





Network Working Group                                          T. Ionta
Internet-Draft                                      Telecom Italia Labs
Intended status: Standard Track                            June 4, 2013
Expires: December 3, 2013

 New Performance Metrics Composition Framework for Multiparty Services 
              draft-ionta-new-multiparty-metrics-framework-02


Abstract
One of the best chances for a Service Provider to face the complex 
growth of IP Services, and their challenging requirements/SLAs along 
the Core network, is to enrich the current Performance metrics - mainly 
derived from a "Network-Oriented point of view", and therefore a 
general perspective, not focused on specific services - with some more 
Performance factors, so to include a "Service-Oriented point of view", 
more centred on the particular kind of service, with its own 
characteristics in terms of protocol, application, manageability, and 
so on. 
Almost nothing about this new approach has been standardized yet for 
the core network. 
To achieve the above goal, and starting from the one-to-group 
performance metrics outlined in RFC 5644 [RFC5644], a new metrics 
composition/aggregation framework is proposed in this memo, where the 
main focus is on multiparty communications (e.g. video providers, 
online biding, online stock market, etc.).
Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 
framework concepts, and need to widen the current performance metrics 
depending on the application, service etc.  


Copyright Notice 

Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document.  Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document.

This Internet-Draft is submitted in full conformance with the provisions
 of BCP 78 and BCP 79. 

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.



Table of Contents
1. Introduction and Scope ..........................................2
2. Terminology .....................................................3
3. Brief metric description.........................................7 
4. One-to-Group Link Metrics definition ............................8
5. One-to-Group Link and Path Statistics ...........................9
6. One-to-Group Overall Packet Loss Statistics ....................10
7. Extended applications...........................................11
8. Security Considerations ........................................12
9. IANA Considerations.............................................12
10. References ....................................................12
11. Acknowledgments................................................13



1. Introduction and Scope

Current Performance Metrics, especially those applied to the core 
network, derive from a "general perspective" approach, only based on a 
"Network-oriented point of view", therefore unconnected to the kind of 
service offered on the network. 
But, due to the growing need to face the complexity of the new IP 
Services, and their challenging SLAs, this approach has become 
inadequate, especially while trying to detect the impact of a 
performance measurement on a particular service. For instance, if a 
network or a link has a 10-4 average PLR, does this impact on the kind 
of service required to be monitored? And to what degree?
Moreover, this "general perspective" approach is unsuited to perceive 
further various factors to be taken into account, such as:

- the specificity of the service, with its own protocol, application 
(i.e. coding), and management (i.e. QOS, fragmentation management) 
characteristics.

- the kind of network topology over which the particular service is 
implemented (i.e. redundancy, tunneling, etc.).

A trivial but clarifying example of this occurs when the same PLR is 
detected over two different links: one of the link coming out from the 
root (source) of a multicast tree, and the other link ending with a 
leaf (receiver). 
The impact on the service, of course, is dramatically different if the 
two cases are considered separately, since the first kind of link 
conveys the whole set of flows originating from the source, while the 
second one conveys just a subset of the whole set of flows. 
As a consequence of the above consideration, a "Service-oriented point 
of view" - more centred on the particular kind of service, and its own 
specific characteristics - must be taken into account while defining 
Performance metrics. In particular two needs raise: 

- widening the aggregation concepts in RFC 5835 [RFC5835], assign a 
sort of weight, specific, and different for each link, to the PLR 
measured over it, in order to take into account the impact of the PLR 
on the service. 

- starting from the metrics outlined in the RFC 5644 [RFC5644] for 
multiparty 
services, define a new performance metrics composition/aggregation 
framework, so to enrich the current Performance Metrics, mainly derived 
from a "Network-oriented point of view".

The main focus of this memo is to address these two needs for 
multiparty communications (e.g. TV broadcast providers, video 
providers, online biding, online stock market, etc.) in order to better 
evaluate the network against the service requirements. 

Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 
framework concepts, and need to widen the current performance metrics 
depending on the application, service etc.  


1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].


2. Terminology

2.1 Naming of the metrics

The names of the metrics, including capitalized letters, are as close 
as possible of the names of the one-way end-to-end or one-to-group 
metrics they are derived from.


2.2 Terms defined elsewhere

composed metric: section 4 of RFC 5835
composition function: section 4 of RFC 5835
higher-order composition: section 5 of RFC 5835
host: section 5 of RFC 2330
link: path: section 5 of RFC 2330
one-to-group metric: section 2 of RFC 5644
path: section 5 of RFC 2330
router: section 5 of RFC 2330
routers digest: section 2 of RFC 5644
sample: section 11 of RFC 2330
singleton: section 11 of RFC 2330
spatial aggregation: section 5 of RFC 5835
spatial composition: section 5 of RFC 5835
spatial metric: section 2 of RFC 5644
subpath: section 5 of RFC 2330
temporal aggregation: section 5 of RFC 5835
Type-P: see RFC 2330
Type-P-One-way-Packet-Loss-Average: see RFC 2680, and RFC 5644


2.2 One-to-Group metrics defined elsewhere

Type-P-One-to-group-Packet-Loss-Vector: section 7, and 8 of RFC 5644
Type-P-One-to-group-Receiver-n-Loss-Ratio: section 7, and 8 of RFC 5644
Type-P-One-to-group-Loss-Ratio: section 7, and 8 of RFC 5644


2.3 Points of Interest

The points of interest correspond to the hosts (according to the RFC 
2330 definition, "hosts" include routing nodes), - i.e. measurement 
collection points - which are a sub-set of the set of hosts involved in 
the delivery of the packets (in addition to the source itself).
In RFC 5644 two possible scenarios concerning the points of interest 
(the spatial one, and one-to-group) have been considered.
For the purpose of this memo a sort of mixed scenario, among the ones 
shown above, is taken into account. In fact the whole set of the hosts 
composing a multicast tree, including destinations, are points of 
interest.
An example of a very simple multicast tree, and its related points of 
interest is depicted in Fig. 1.
 
                   Dst
             /----(*)1                                            
           (*)----(*)2
           / \----(*)3
          /
         /     /--(*)4
Src --- (*)--(*)--(*)5           
         \
        ...  ...--(*)x
           \  
           (*)----(*)X-1
             \----(*)X

              Note : (*) represent the nodes that are points of interest

               Figure 1: Points of Interest for a multicast tree


2.4 Multicast tree equivalent splitting

A generic single-source multicast tree, like the very simple one 
depicted in Fig.2, is composed by J links, and X receivers.

             Link 1               Link 2             Link 3
 +--------+          +--------+           +--------+         +--------+
 |   H1   <>--------<>   H2   <>---------<>   H3  <>--------<>   H4   |
 +--------+          +---<>---+           +--------+        +--------+
                         |
                         |
                         |         Link 4                    +--------+
                         +----------------------------------<>   H5   |  
                                                             +--------+
    <>   Interface
   ----  Link

          Figure 2: Example of a whole (or part of) multicast tree

To accomplish the task of this memo, an equivalent representation of 
the generic single-source multicast tree is proposed, which is obtained 
by splitting it in X different Multicast Equivalent Paths (called "ME-
Paths", from now on), each of them corresponding to one of the X 
different paths - as better explained below - starting from the source, 
and ending up into one of the X receivers. 
The generic ME-Path x is composed by the sequence of hosts, and 
corresponding links between the source, and the receiver x. 
As a result, the ME-Paths are different from each other because even if 
they can partially overlap, they never do it completely. This happens 
because each ME-Path is different from all the other ones regarding at 
least one link, the one ending on the receiver, belonging just to one 
ME-Path.  
To clarify this concept, let's apply the splitting method to the very 
simple tree in Fig. 2. 
It has only two leaves (receivers), therefore, only two different ME-
Paths can be derived, as shown below (Fig. 3).

                    Link 1           Link 2           Link 3
          +------+          +------+         +------+         +-------+
ME-PATH 1 |  H1  <>--------<> H2  <>--------<> H3  <>--------<>  H4   |
          +------+          +------+         +------+         +-------+


                    Link 1                   Link 4
          +------+         +-------+                          +-------+
ME-PATH 2 |  H1  <>-------<> H2    <>-------------------------<>  H5  |  
          +------+         +-------+                          +-------+

    <>   Interface
   ----  Link

          Figure 3: single-source multicast tree equivalent splitting.

The ME-Path definition shown above allows possible partial overlappings 
among some ME-Paths (e.g. ME-Path 1, and ME-Path 2 in Fig. 3). This is 
a specific choice, as detailed hereafter in section 5.3.1.  

The numbering of the links composing the multiparty tree is free, 
provided that: 

- the link numbering remains univocal with respect to the multicast 
tree.

- even if belonging to many ME-Paths, the same link between the same 
two hosts, keeps the same name (e.g. Link 1 in both ME-Path 1, and ME-
Path 2 in Fig. 3)


2.5 Vector

In accordance with the definition of RFC 5644 stated in section 2, a 
vector is a set of singletons (single atomic results) comprised of 
observations corresponding to a packet sent from one point to another. 
In this memo the packet is sent from one side to the other one of each 
of the J links composing the multicast tree. For instance, if the one-
way loss singletons observed over J links are LL1,LL2,...,LLJ (where 
"LL" stands for Link Loss) then a generic one-way loss vector V with J 
elements can be organized as {LL1, LL2,..., LLJ}. The complete vector 
gives information over the dimension of space, a set of J links in this 
memo.
Different vectors for common measurement points of interest are 
distinguished by the packet sending time.


2.6 Matrix

As stated in RFC 5644, several vectors form a matrix, which contains 
results observed over a sampling interval (from T0 to TK) at different 
places in a network at different times. 
For instance, a one-way loss Matrix {V1,V2,...,Vk,...,VK} is formed by 
the one-way loss vectors V1={LL11,LL21,...,LLj1, ...,LLJ1}, 
V2={LL12,LL22,...,LLj2, ...,LLJ2},..., Vk={LL1k,LL2k,...,LLjk, 
...,LLJk},...,VK={LL1K,LL2K,...,LLjK, ...,LLJK} for a sample of packets 
P1, P2,...,Pk,...PK. 
The matrix organizes the vectors information to present network 
performance in both space and time.
Each row is a set of oneway singletons spreading over the time 
dimension, and each column is another set of One-way singletons 
spreading over the space dimension.
A one-dimensional matrix (row) corresponds to a sample in simple point-
to-point (a link in this memo) measurement.
The relationship among sample, vector, and matrix is illustrated in 
Figure 4.

     Space
       ^
Link   |   /----------- Samples ------------------\ 
       |
 1     |    LL11  LL12  LL13  ...  LL1k  ...  LL1K
       |
 2     |    LL21  LL22  LL23  ...  LL2k  ...  LL2K
       |
 3     |    LL31  LL32  LL33  ...  LL3k  ...  LL3K 
 .     |     .     .     .    ...    .         .
 .     |     .     .     .    ...    .         .
 j     |    LLj1  LLj2  LLj3  ...  LLjk  ...  LLjK
 .     |     .     .     .    ...     .        .
 .     |     .     .     .    ...     .        .
 J     |    LLJ1  LLJ2  LLJ3  ...  LLJk  ...  LLJK
       |  
       +-----+-----+-----+---...-----+----...---+----> time  
      T0     T1    T2    T3         Tk         TK  
                   ^                 ^
                   |                 |
                Vector V2         Vector Vk

Figure 4: Relationship among Samples,Vectors, and Matrix.


3. Brief metric description

The metrics, and KPI defined in this memo are based on the source-to-
destination or end-to-end or one-to-group metrics defined by IETF in 
[RFC2679], [RFC2680], [RFC3393], [RFC3432], and [RFC5644]. 
The [RFC2330], and [RFC5644] framework of parameters, unit of 
measurement, and measurement methodologies are also adopted.

In RFC5644 two different approaches have been considered: the spatial 
metric approach - intended to measure the performance of each segment 
along a path - and the multiparty one, aimed at measuring the end-to-
end performance between one sorce and a group of receivers.
To achieve the goals of this memo - enriching the current one-to-group 
Performance metrics, and statistics also with a "Service-oriented point 
of view" - a "mixed" approach is taken into account in this memo, and a 
new set of multiparty metrics is stated.

This memo defines two new metrics:

- Type-P-One-to-Group-Link-Packet-Loss-Vector which collects the set of
Type-P-One-way-Packet-Loss singletons between one side and the other 
one of each of the links composing a multicast tree;
 
- Type-P-One-to-Group-Link-Packet-Loss-Matrix which organizes the 
above vectors information to present network performance in both space 
and time.

Based on the above mentioned new metrics, new link, and path statistics 
are defined: 

- Type-P-One-to-Group-Link-j-Loss-Ratio captures the overall
packet loss ratio for link j;

- Type-P-One-to-Group-Link-Loss-Ratio-Vector which collects the set of
Type-P-One-to-Group-Link-j-Loss-Ratios of each of the links composing 
a multicast tree;

- Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio captures the overall
Weighed packet loss ratio for link j;

- Type-P-One-to-Group-Link-Weighted-Loss-Vector which collects the set 
of Type-P-One-to-Group-Link-j-Weighted-Loss-Ratios of each of the links 
composing a multicast tree. Since this is a very important vector, in 
this memo it is also referred to as the "reference vector"; 

- Type-P-One-to-Group-MEPath-x-Loss-Vector which collects a subset of
Type-P-One-to-Group-Link-Weighted-Loss-Vector elements, which are 
only those corresponding to the links belonging to the generic MEpath 
x.

Finally, based on the statistics shown above, a new overall performance 
metrics composition/aggregation framework is defined:

- Type-P-One-to-Group-MEPath-x-Loss-Ratio is a user definable metric 
composition/aggregation function applied to the set of Type-P-One-to-
group-Link-j-Loss-Ratios associated to the links belonging to the 
generic ME-Path x;

- Type-P-One-to-Group-KPI-Loss-Ratio is a user definable metric 
composition/aggregation function applied to all Type-P-One-to-group-
Path-x-Loss-Ratios of the ME-Paths composing the multiparty tree.



4. One-to-Group Link Metrics definition

This section defines vectors, and matrix for a one-to-group topology 
using loss singleton over the J links composing the multicast tree.


4.1. Type-P-One-to-Group-Link-Packet-Loss-Vector

Each element of the vector defined in section 2 of this memo represents 
a loss singleton over one of the J links composing the multicast tree.  
Thus the number of elements composing the whole vector equals the 
number of links (that is J) composing the whole multiparty tree. 
The generic Type-P-One-to-Group-Link-Packet-Loss-Vector for a packet 
sent at time Tk can be represented as:

Vk = <Tk, LL1, LL2,..., LLj, ..., LLJ >

where j=1,2,...,J , and LLj is the loss singleton over link j.


4.2. Type-P-One-to-Group-Link-Packet-Loss-Matrix

Composing the J vectors shown above, as described in section 2, a Type-
P-One-to-Group-Link-Packet-Loss-Matrix can be built:

   space
     ^
Link |  /----------- Samples ----------\    Stats 
     |
 1   |  LL11  LL12  ...  LL1k ...  LL1K     LL1LR
     |
 2   |  LL21  LL22  ...  LL2k ...  LL2K     LL2LR 
     |
 3   |  LL31  LL32  ...  LL3k ...  LL3K     LL3LR 
 .   |   .     .    ...    .         .         .
 .   |   .     .    ...    .         .         .
 j   |  LLj1  LLj2  ...  LLjk ...  LLjK     LLjLR <-- Link-j Loss Ratio
 .   |   .     .    ...    .         .         .
 .   |   .     .    ...    .         .         .
 J   |  LLJ1  LLJ2  ...  LLJk ...  LLJK     LLJLR
     |  
     +---+-----+----...----+----...--+-->time  ^  
    T0   T1    T2          Tk        TK        |  
                           ^                   |
                           |                   |
                        Vector Vk        Link Loss Ratio Vector

Figure 3: Type-P-One-to-Group-Link-Packet-Loss-Matrix J*K  


From the considerations stated above it can be derived that the number 
of rows composing the matrix equals the number of links (that is J) 
composing the whole multicast tree. 

All loss ratios are expressed in units of packets lost to total packets 
sent. Statistics are computed on the sample of Type-P-One-way-Packet-
Loss[RFC2680] of the above matrix.

Based on the one-to-group vector metrics listed above, statistics are 
defined below, so to capture single link performance, ME-Path 
performance, and group performance, and the relative performance for a 
multiparty communication.


5. One-to-Group Link and Path Statistics

Starting from the above metrics definition, this section defines link, 
and path statistics for a one-to-group topology.


5.1. Type-P-One-to-Group-Link-j-Loss-Ratio

Given the Type-P-One-to-Group-Link-Packet-Loss-Matrix depicted in Fig. 
3, and according to the definitions, and method of [RFC2680], a Type-P-
One-way-Packet-Loss-Average for the sample at each of the J links can 
be determined, and named Type-P-One-to-group-Link-j-Loss-Ratio, also 
called LLjLR. 
It can be expressed as

                   K
                ------
            1   \
    LLjLR = - *  > LLjk
            K   /
                ------
                 k = 1

Figure 4: Type-P-One-to-group-Link-j-Loss-Ratio for Link j.


5.2. Type-P-One-to-Group-Link-Loss-Ratio-Vector

The Type-P-One-to-Group-Link-Loss-Vector collects all the Type-P-One-
to-group-Link-j-Loss-Ratios computed on the J links composing the 
multicast tree.  
An example of Type-P-One-to-Group-Link-Loss-Vector is depicted in Fig. 
3.


5.3. Discussion about the "weighing factor"

The purpose of this memo is to enrich the current Performance metrics - 
mainly derived from a "Network-oriented point of view", and therefore a 
general perspective, which is not focused on specific services - with 
some more Performance factors, so to include a "Service-oriented point 
of view" as well, more centred on:  

- the specificity of the service or services to be monitored, with 
their own protocols, applications (i.e. coding), and management (i.e. 
QOS, fragmentation management) characteristics.

- the kind of network topology over which the service or services to be 
monitored are implemented (i.e. redundancy, tunneling, etc.).

To accomplish this task a weighing factor Wj, related to the 
corresponding Link j, is introduced. Thus each Type-P-One-to-group-
Link-j-Loss-Ratio is weighed through its own specific Wj. 
Since this memo introduces a framework for performance metrics, the 
characterization of Wj is user definable, and up to the service 
provider, depending on many factors he has to manage. 
Some, but not all, of the possible network, and/or service factors that 
can be taken into account while characterizing Wj are: number of 
multicast flows over link j, capacity (any possible type: total, 
available, etc.) of link j, its redundancy, traffic flowing through 
link j, type of service to be monitored over the link, location of the 
link with respect to the whole topology, and so on.


5.3.1 Discussion about the "Overlapping Factor"

While characterizing each Wj - the so called "Overlapping Factor" - is 
worthy of a special remark.
As discussed in section 2, ME-Paths can partially overlap, thus sharing 
one or more links (e.g. Link 1 in Fig. 2). As a result, a generic Link 
j can belong to more than one ME-Path. A consequence of this fact is 
that the more the ME-Paths the generic Link j belongs to, the more a 
packet loss over that link impacts the service it conveys. 
For instance, even if the same packet loss is detected both over a link 
coming out from the root (source) of a multicast tree, and over a link 
ending on a receiver, the impact on the service is dramatically 
different in the two cases. 
As a consequence, the "Overlapping Factor" MUST be taken into account 
while characterizing each Wj.
Considering this, a question arises: how to expressly include it in the 
Wj characterization, since the ME-Paths overlappings are dynamically 
varying, following the dynamic topology changes of the multicast tree. 
A possible way to solve this problem is to take the "Overlapping 
Factor" into account just implicitly, while calculating the final Type-
P-One-to-Group-KPI-Loss-Ratio, as hereafter deepened.


5.4. Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio

Based on the above discussion, a new entity is introduced: the Type-P-
One-to-group-Link-j-Weighted-Loss-Ratio (LLjWLR), defined as:

      LLjWLR = LLjLR * Wj

Note that if Wj is set to 1, thus the weighing factor is not taken into 
consideration for link j.


5.5. Type-P-One-to-Group-Link-Weighted-Loss-Vector

A new kind of loss vector is introduced, the Type-P-One-to-Group-Link-
Weighted-Loss-Vector (Fig. 5).
It collects all the Type-P-One-to-group-Link-j-Weighted-Loss-Ratios of 
each of the links composing a multicast tree.

/ LL1LR * W1 \           / LL1WLR \
| LL2LR * W2 |           | LL2WLR |
| LL3LR * W3 |           | LL3WLR |
| LL4LR * W4 |   --->    | LL4WLR |
|   .        |           |   .    |
|   .        |           |   .    |
| LLjLR * Wj |           |  LLjWLR|
|   .        |           |   .    |
|   .        |           |   .    |
\ LLJLR * WJ /           \ LLJWLR /

Fig. 5. Type-P-One-to-Group-Link-Weighted-Loss-Vector


Type-P-One-to-Group-Link-Weighted-Loss-Vector is hereafter considered 
the "Reference Vector" for the definition of the next statistics, and 
KPI definitions. 


5.6. Type-P-One-to-Group-MEPath-x-Loss-Vector

This section defines the overall one-way loss statistics for an ME-Path 
(as defined above).
Starting from the "Reference Vector" (the above Type-P-One-to-Group-
Link-Weighted-Loss-Vector), and given the X possible ME-Paths 
generated after the multicast tree splitting described in section 2, X 
different Type-P-One-to-Group-MEPath-x-Loss-Vectors are created, each 
of them composed by a subset of the whole set of the "Reference Vector" 
elements (LLjWLR), in other words, only by those elements LLjWLR 
associated to the links composing ME-Path x.
A clarifying example can be given applying the concepts shown above to 
ME-Path 1, and 2 in Fig. 3.
For ME-Path 1:
                                            /LL1WLR \
Type-P-One-to-Group-MEPath-1-Loss-Vector = | LL2WLR |
                                            \LL3WLR /

while for ME-Path 2: 
                                            /LL1WLR \
Type-P-One-to-Group-MEPath-2-Loss-Vector =  \LL4WLR /
     
The number of elements composing the generic Type-P-One-to-Group-
MEPath-x-Loss-Vector equals the number of links composing the ME-
Path x it derives from.
Note that since all ME-Paths are different from each other - at least 
for one link - as a result of this, all Type-P-One-to-Group-MEPath-x-
Loss-Vectors are different from each other as well.


6. One-to-Group Overall Packet Loss Statistics

Starting from the link, and path statistics definition stated above, 
this section defines the overall statistics for a one-to-group 
topology.


6.1. Type-P-One-to-Group-MEPath-x-Loss-Ratio

The current "network-oriented" point of view states that the 
calculation of the Packet Loss Ratio over a path is based on the Packet 
Loss Ratio detected over each of the links belonging to the path, 
applying the usual spatial composition formula:

   Path Packet Loss Ratio = 1 - [(1-L1LR) * (1-L2LR) * ... *(1-LnLR)]

   where LnLR represents the Packet Loss Ratio detected over the generic 
         link n belonging to the path.

However, due to the growing interest in enriching the current 
performance metrics with a "service-oriented" point of view as well, 
the purpose of this memo is to propose a new framework for performance 
metric composition/aggregation.
Thus a new definition of an equivalent PLR over a generic ME-Path x is 
given:
                                              
   Type-P-One-to-Group-Path-x-Loss-Ratio= Fa (Type-P-One-to-Group-
MEPath-x-Loss-Vector) 
                                             
   where  Fa is a user definable metric composition/aggregation function 
          applied to the set of Type-P-One-to-group-Link-j-Loss-Ratios 
          associated to the links belonging to the generic ME-Path x.

A very common example of Fa is the usual spatial composition formula 
mentioned above.


6.2 Type-P-One-to-Group-KPI-Loss-Ratio

This section defines the overall one-way network-service KPI (Key 
Performance Indicator) for a multicast tree loss statistics.

   Type-P-One-to-Group-KPI-Loss-Ratio = Fb (Type-P-One-to-Group-Path-
   1-Loss-Ratio, Type-P-One-to-Group-Path-2-Loss-Ratio, ..., Type-P-One-
   to-Group-Path-X-Loss-Ratio) 

     where Fb is a user definable metric composition/aggregation 
          function applied to all Type-P-One-to-group-Path-x-Loss-Ratios
          of the ME-Paths composing the multiparty tree.

Each service provider defines his own Fb, based on the topology of his 
network, on the way the monitored service is implemented, on the 
specific SLAs associated with the monitored service, and so on.
A very common example of Fb is the average function among all the 
Type-P-One-to-group-Path-x-Loss-Ratios. Other possibilities are the 
maximum value, the minimum value, the range, and so on.
Please point out that the "Overlapping Factor" described in section 
5.3.1 is here taken into account, even if implicitly. In fact all the 
paths are now considered, regardless of the presence of overlapping 
links in the paths.


7. Extended applications


7.1. Extended applications to multi-source one-to-group topology

All the above discussion is applicable both to a single-source one-to-
group topology, and to a multi-source one-to-group topology. In fact, 
given one single group flowing from several sources - thus different 
from several groups flowing from several sources, that is a group-to 
group topology - each host chooses just one, and only one source at a 
time from which the flow is accepted, thus leading us back to the 
single-source one-to-group situation already dealt with in this memo.

 
7.2. Extended applications to One-way Delay and Delay Variation

The framework proposed in this memo is wide enough to be applicable not 
only to the Packet Loss analysis, but also to the One-way Delay, and 
Delay Variation ones. 
This goal is achievable by adequately defining Fa, Fb, and Wj.
Anyway, this is out of the scope of this memo, and it will be deepened 
in another memo.


8. Security Considerations

Spatial, and one-to-group metrics are defined on the top of end-to-end
metrics. Security considerations discussed in the one-way delay
metrics definitions of [RFC2679], in packet loss metrics definitions
of [RFC2680], and in IPDV metrics definitions of [RFC3393], and
[RFC3432] apply to metrics defined in this memo.
Someone may spoof the identity of a point of interest identity, and
intentionally send corrupt results in order to remotely orient the
traffic engineering decisions.
A point of interest could intentionally corrupt its results in order
to remotely orient the traffic engineering decisions.


8.1. One-to-Group Metrics

Reporting of measurement results from a huge number of probes may
overload reference point resources (network, network interfaces,
computation capacities, etc.).
The configuration of a measurement must take into consideration that
implicitly more packets will be routed than sent and select a test
packet rate accordingly. Collecting statistics from a huge number of
probes may overload any combination of the network to which the
measurement controller is attached, measurement controller network
interfaces, and measurement controller computation capacities.
One-to-group metric measurements should consider using source
authentication protocols, standardized in the MSEC group, to avoid
fraud packet in the sampling interval. The test packet rate could be
negotiated before any measurement session to avoid denial-of-service
attacks.
A point of interest could intentionally degrade its results in order
to remotely increase the quality of the network on the branches of
the multicast tree to which it is connected.


9. IANA Considerations

This document has no actions for IANA. 

 
10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.

[RFC3393] Demichelis, C., and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.

[RFC5644] Stephan, E., Liang L., Morton A., "IP Performance Metrics 
(IPPM): Spatial and Multicast", RFC5644, October 2009.

[RFC6390] Clark, A., "Guidelines for Considering New Performance Metric 
Development", BCP170, RFC6390, October 2011.


10.2. Informative References

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 
"Framework for IP Performance Metrics", RFC 2330,
May 1998.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
November 2002.

[RFC5835] Morton, A., Van den Berghe, S., "Framework for metric 
composition", RFC5835, April 2010.



11. Acknowledgments

The author would like to thank his workmates A. Barbetti and A. 
Cappadona for their helpful support while designing the main ideas 
behind this memo.
I am grateful to my boss S. Mariani for trusting in the usefulness of 
this activity.
I also acknowledge the precious comments and suggestions from A. Botta 
and A. Pescape', University "Federico II", Naple, Italy.
A special thank to Daniela Labarbuta for her unselfish help while 
translating this memo.


Author's Address

Tiziano Ionta (editor)
Telecom Italia Labs
Via Valcannuta 250
00167 Rome
Italy

Phone: +39 06 3688 5600
Email: tiziano.ionta@telecomitalia.it