1 / 18

IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt

79th IETF Meeting – November 2010 IPPM Working Group. IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt. Emile Stephan. IETF IPPM WG IP Performance metrics. 83 metrics 'Core' metrics Connectivity (5) One-way delay (6) packet lost (3) Round-trip Delay (6)

abril
Download Presentation

IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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. 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. 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. Inputs received

  6. 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. Inputs from collaborative projects App or ISP 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. 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. Analysis of the IPPM metrics In this context

  10. 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. 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. 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. 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 identifier 84 description "OneWayDelay singleton" originMetric ietfOneWayDelay originMetric ietfOneWayPeriodicDelay originMetric ietfFiniteOneWayDelay originMetric ietfSpatialOneWayDelay outputCardinality 1 outputUnit millisecond

  14. 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. 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 identifier 85 description "Computed on one of the following stream according to the One-Way Delay Minimum definitions of RFC2679 and the framework of RFC2330" AggregateMetric ietfFiniteOneWayDelayStream AggregateMetric ietfSegmentOneWayDelayStream AggregateMetric ietfOneWayDelayPoissonStream AggregateMetric ietfOneWayDelayPeriodicStream outputCardinality 1 outputUnit millisecond

  16. Long-term MRTG-like reporting More standardization (unit & period) for LT metrics (examples): ietfOneWayDelayMean1mn identifier 86 originMetric ietfFiniteOneWayDelayMean ObservationPeriod 60 outputCardinality 1 outputUnit millisecond ietfOneWayDelayMean15mn identifier 87 originMetric ietfFiniteOneWayDelayMean observationPeriod 900 outputCardinality 1 outputUnit millisecond ietfOneWayDelayMean1hour identifier 88 originMetric ietfFiniteOneWayDelayMean observationPeriod 3600 outputCardinality 1 outputUnit millisecond ietfOneWayDelayMean1day identifier 89 originMetric ietfFiniteOneWayDelayMean observationPeriod 86400 outputCardinality 1 outputUnit millisecond

  17. Discussion Adding Metric flavors in the registry to Define clear LT metrics Define sibling metrics Harmonize statistics definitions

  18. 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.

More Related