1. IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt 79th IETF Meeting – November 2010 IPPM Working Group Emile Stephan

2. (2) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG IETF IPPM WG IP Performance metrics 83 metrics – 'Core' metrics Connectivity (5) One-way delay (6) packet lost (3) Round-trip Delay (6) Lost pattern(6) Ipdv (6) – 'Ancillary' metrics periodic streams metric (1) Reordering metrics (12) Duplicate packets metrics (6) – Spatial metrics (7): – one-to-group metrics (12): – Composition metrics(13): IANA metrics registry ( See http://www.iana.org/assignments/ianaippmmetricsregistry-mib) – Identifying each metric defined by the IPPM WG – Each metric has an individual number; point to each individual metric definition instead of to the RFC.

3. (3) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG IANA IPPM metrics registry 83 metrics 1 ietfInstantUnidirConnectivity 2 ietfInstantBidirConnectivity 3 ietfIntervalUnidirConnectivity 4 ietfIntervalBidirConnectivity 5 ietfIntervalTemporalConnectivity 6 ietfOneWayDelay 7 ietfOneWayDelayPoissonStream 8 ietfOneWayDelayPercentile 9 ietfOneWayDelayMedian 10 ietfOneWayDelayMinimum 11 ietfOneWayDelayInversePercentile 12 ietfOneWayPktLoss 13 ietfOneWayPktLossPoissonStream 14 ietfOneWayPktLossAverage 15 ietfRoundTripDelay 16 ietfRoundTripDelayPoissonStream 17 ietfRoundTripDelayPercentile 18 ietfRoundTripDelayMedian 19 ietfRoundTripDelayMinimum 20 ietfRoundTripDelayInvPercentile 21 ietfOneWayLossDistanceStream 22 ietfOneWayLossPeriodStream 23 ietfOneWayLossNoticeableRate 24 ietfOneWayLossPeriodTotal 25 ietfOneWayLossPeriodLengths 26 ietfOneWayInterLossPeriodLengths 27 ietfOneWayIpdv 28 ietfOneWayIpdvPoissonStream 29 ietfOneWayIpdvPercentile 30 ietfOneWayIpdvInversePercentile 31 ietfOneWayIpdvJitter 32 ietfOneWayPeakToPeakIpdv 33 ietfOneWayDelayPeriodicStream 34 ietfReorderedSingleton 35 ietfReorderedPacketRatio 36 ietfReorderingExtent 37 ietfReorderingLateTimeOffset 38 ietfReorderingByteOffset 39 ietfReorderingGap 40 ietfReorderingGapTime 41 ietfReorderingFreeRunx 42 ietfReorderingFreeRunq 43 ietfReorderingFreeRunp 44 ietfReorderingFreeRuna 45 ietfnReordering 46 ietfOneWayPacketArrivalCount 47 ietfOneWayPacketDuplication 48 ietfOneWayPacketDuplicationPoissonStream 49 ietfOneWayPacketDuplicationPeriodicStream 50 ietfOneWayPacketDuplicationFraction 51 ietfOneWayReplicatedPacketRate 52 ietfSpatialOneWayDelayVector 53 ietfSpatialPacketLossVector 54 ietfSpatialOneWayIpdvVector 55 ietfSegmentOneWayDelayStream 56 ietfSegmentPacketLossStream 57 ietfSegmentIpdvPrevStream 58 ietfSegmentIpdvMinStream 59 ietfOneToGroupDelayVector 60 ietfOneToGroupPacketLossVector 61 ietfOneToGroupIpdvVector 62 ietfOnetoGroupReceiverNMeanDelay 63 ietfOneToGroupMeanDelay 64 ietfOneToGroupRangeMeanDelay 65 ietfOneToGroupMaxMeanDelay 66 ietfOneToGroupReceiverNLossRatio 67 ietfOneToGroupReceiverNCompLossRatio 68 ietfOneToGroupLossRatio 69 ietfOneToGroupRangeLossRatio 70 ietfOneToGroupRangeDelayVariation 71 ietfFiniteOneWayDelayStream 72 ietfFiniteOneWayDelayMean 73 ietfCompositeOneWayDelayMean 74 ietfFiniteOneWayDelayMinimum 75 ietfCompositeOneWayDelayMinimum 76 ietfOneWayPktLossEmpiricProb 77 ietfCompositeOneWayPktLossEmpiricProb 78 ietfOneWayPdvRefminStream 79 ietfOneWayPdvRefminMean 80 ietfOneWayPdvRefminVariance 81 ietfOneWayPdvRefminSkewness 82 ietfCompositeOneWayPdvRefminQtil 83 ietfCompositeOneWayPdvRefminNPA

4. (4) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG IANA IPPM metrics registry The IPPM WG is reconsidering its need – Is it used? What is missing? – Is it needed? Why is it needed? Current usage is very limited – Provide only an identifier per metrics – Limited to human (RFP…); – MIB modules;

5. (5) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Inputs received

6. (6) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Inputs from the inside of IETF The registry should be obsoleted or More standardization is needed – NMS needs more than an identifier – Registry language should be understandable by all the NM community (i.e. parsable by XML based NM syst) – Results exported should be simple (1 id, 1 result, 1 unit) – Units should be explicitly specified – Should carry metrics options

7. (7) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Inputs from collaborative projects App or ISP ISP – The projects ETICS and Envision are working on uses cases where application and infrastructure entities require network performance information from optimizing resources consumption and for improving the QoE and the QoS served to customers.

8. (8) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Inputs from collaborative projects – Networks and Applications need to optimize their resources to face the increase of the among of multimedia contents to distribute – They are in relation with numerous other applications and networks. – The exchange of Network performance information is a key aspect. – They don't care on the methodology: active, passive end-to-end and passive on-the-path measures… – They are looking for various statistics of delay, jitter, packet Lost and throughput – An application looking for one statistic (e.g. OneWayDelay minimum) from several ISPs accepts this statistic to be computed by differently in each ISP (direct measure stat, composition, division…)

9. (9) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Analysis of the IPPM metrics In this context

10. (10) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Siblings Metrics Sibling metrics are metrics which use different but very close methods to capture exactly the same dimension. E.g.: – OneWayDelayMinimum ietfOneWayDelayMinimum ietfFiniteOneWayDelayMinimum ietfCompositeOneWayDelayMinimum – OneWayPktLossStream ietfOneWayPktLossPoissonStream ietfSegmentPacketLossStream

11. (11) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Siblings Metrics One-way-delay between 2 points may be given by One way delay singleton, Division of a One way delay, One way delay resulting of a composition of delays These metrics results are interchangeable The extension of the registry should describe the siblings metrics – For simplifying the reporting to end-user – To clarify the set of metrics usable for composition

12. (12) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Metric Flavor Metric flavor concept – Profiling a metric One metric definition may have several flavor – i.e. traffic generation laws, statistics – option parameters – results parameters … – Gathering sibling definitions in one flavor for reporting For composition

13. (13) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Metric Reporting Reporting metrics must be simplified. – They are 4 definitions of One-way-delay singletons Why should those metrics results be perceived as different ? How to describe that they are very close ? Example of a metric flavor which gathers 4 metrics: ietfReportingOneWayDelay identifier84 description"OneWayDelay singleton" originMetricietfOneWayDelay originMetricietfOneWayPeriodicDelay originMetricietfFiniteOneWayDelay originMetricietfSpatialOneWayDelay outputCardinality1 outputUnitmillisecond

14. (14) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG IPPM metrics statistics Statistics definitions are based on 'Stream' metrics Siblings metrics should have the same set of statistics (mean, average, median, peak… ). In fact statistics definitions are missing in several RFCs: – One-Way-Delay Minimum example: not defined in the "spatial and multicast" document (RFC5644) Defined in "Composition of Metrics" RFC to be vey soon … The extension of the registry should provide siblings metrics with the same set of statistics.

15. (15) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Harmonize statistics definitions Statistics are missing in several RFCs. – One-Way-Delay Minimum example: not defined in Segment metrics RFC Defined in Spatial Composition of Metrics RFCtoBe … 'Streams' metrics are always defined. A flavor statistic may be defined on the top of a set of sibling 'Streams'. Example OneWayDelayMinimum identifier85 description"Computed on one of the following stream according to the One-Way Delay Minimum definitions of RFC2679 and the framework of RFC2330" AggregateMetricietfFiniteOneWayDelayStream AggregateMetric ietfSegmentOneWayDelayStream AggregateMetric ietfOneWayDelayPoissonStream AggregateMetric ietfOneWayDelayPeriodicStream outputCardinality1 outputUnitmillisecond

16. (16) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Long-term MRTG-like reporting More standardization (unit & period) for LT metrics (examples): ietfOneWayDelayMean1mn identifier86 originMetricietfFiniteOneWayDelayMean ObservationPeriod 60 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean15mn identifier87 originMetricietfFiniteOneWayDelayMean observationPeriod 900 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean1hour identifier88 originMetricietfFiniteOneWayDelayMean observationPeriod 3600 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean1day identifier89 originMetricietfFiniteOneWayDelayMean observationPeriod 86400 outputCardinality 1 outputUnitmillisecond

17. (17) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Discussion Adding Metric flavors in the registry to – Define clear LT metrics – Define sibling metrics – Harmonize statistics definitions

18. (18) emile.stephan@orange-ftgroup.com 79th IETF – IPPM WG Acknowledgements Emile Stephan is partially supported by the ENVISION project (http://www.envision- project.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 248565). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the ENVISION project or the European Commission.