79th IETF Meeting – November 2010
1 / 18

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

  • Uploaded on

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)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt' - abril

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

79th IETF Meeting – November 2010IPPM Working Group

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

Emile Stephan

Ietf ippm wg ip performance metrics
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
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
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 from the inside of ietf
Inputs from the inside of IETF

The registry should be obsoleted


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
Inputs from collaborative projects

App or 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.

Inputs from collaborative projects1
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…)

Siblings metrics
Siblings Metrics

Sibling metrics are metrics which use different but very close methods to capture exactly the same dimension. E.g.:








Siblings metrics1
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

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
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:


identifier 84

description "OneWayDelay singleton"

originMetric ietfOneWayDelay

originMetric ietfOneWayPeriodicDelay

originMetric ietfFiniteOneWayDelay

originMetric ietfSpatialOneWayDelay

outputCardinality 1

outputUnit millisecond

Ippm metrics statistics
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
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'.



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

Long term mrtg like reporting
Long-term MRTG-like reporting

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


identifier 86

originMetric ietfFiniteOneWayDelayMean

ObservationPeriod 60

outputCardinality 1

outputUnit millisecond


identifier 87

originMetric ietfFiniteOneWayDelayMean

observationPeriod 900

outputCardinality 1

outputUnit millisecond


identifier 88

originMetric ietfFiniteOneWayDelayMean

observationPeriod 3600

outputCardinality 1

outputUnit millisecond


identifier 89

originMetric ietfFiniteOneWayDelayMean

observationPeriod 86400

outputCardinality 1

outputUnit millisecond


Adding Metric flavors in the registry to

Define clear LT metrics

Define sibling metrics

Harmonize statistics definitions


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.