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

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

79th IETF Meeting – November 2010IPPM Working Group

Emile Stephan

(2)[email protected] 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.


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


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;


Inputs received


Inputs from the inside of IETF

• The registry should be obsoletedor

• 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


Inputs from collaborative projects

App or ISP

ISPISP

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


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…)


Analysis of the IPPM metricsIn this context


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


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


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


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 84description "OneWayDelay singleton"originMetric ietfOneWayDelayoriginMetric ietfOneWayPeriodicDelayoriginMetric ietfFiniteOneWayDelayoriginMetric ietfSpatialOneWayDelayoutputCardinality1outputUnit millisecond


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.


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'.• ExampleOneWayDelayMinimum

identifier 85description "Computed on one of the following stream according to the One-Way Delay Minimum definitions of RFC2679 and the framework of RFC2330"AggregateMetric ietfFiniteOneWayDelayStreamAggregateMetric ietfSegmentOneWayDelayStreamAggregateMetric ietfOneWayDelayPoissonStreamAggregateMetric ietfOneWayDelayPeriodicStreamoutputCardinality 1outputUnit millisecond


Long-term MRTG-like reporting

More standardization (unit & period) for LT metrics (examples):ietfOneWayDelayMean1mn

identifier 86originMetric ietfFiniteOneWayDelayMeanObservationPeriod 60outputCardinality 1outputUnit millisecond

ietfOneWayDelayMean15mnidentifier 87originMetric ietfFiniteOneWayDelayMeanobservationPeriod 900outputCardinality 1outputUnit millisecond

ietfOneWayDelayMean1houridentifier 88originMetric ietfFiniteOneWayDelayMeanobservationPeriod 3600outputCardinality 1outputUnit millisecond

ietfOneWayDelayMean1dayidentifier 89originMetric ietfFiniteOneWayDelayMeanobservationPeriod 86400outputCardinality 1outputUnit millisecond


Discussion

• Adding Metric flavors in the registry to – Define clear LT metrics– Define sibling metrics – Harmonize statistics definitions


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.

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

Documents

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