draft-ietf-ippm-spatial-composition-01.txt   draft-ietf-ippm-spatial-composition-02.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Expires: December 26, 2006 E. Stephan Intended status: Standards Track E. Stephan
France Telecom Division R&D Expires: April 25, 2007 France Telecom Division R&D
June 24, 2006 October 22, 2006
Spatial Composition of Metrics Spatial Composition of Metrics
draft-ietf-ippm-spatial-composition-01 draft-ietf-ippm-spatial-composition-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo utilizes IPPM metrics that are applicable to both complete This memo utilizes IPPM metrics that are applicable to both complete
paths and sub-paths, and defines relationships to compose a complete paths and sub-paths, and defines relationships to compose a complete
path metric from the sub-path metrics with some accuracy w.r.t. the path metric from the sub-path metrics with some accuracy w.r.t. the
skipping to change at page 2, line 19 skipping to change at page 2, line 19
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In this memo, the characters "<=" should be read as "less than or In this memo, the characters "<=" should be read as "less than or
equal to" and ">=" as "greater than or equal to". equal to" and ">=" as "greater than or equal to".
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope, Application, and Terminology . . . . . . . . . . . . . 5 3. Scope and Application . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
4. One-way Delay Composed Metrics and Statistics . . . . . . . . 7 4. One-way Delay Composed Metrics and Statistics . . . . . . . . 7
4.1. Name: 4.1. Name:
Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 7 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 7
4.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 7 4.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 7
4.1.2. Definition and Metric Units . . . . . . . . . . . . . 8 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 7
4.1.3. Discussion and other details . . . . . . . . . . . . . 8 4.1.3. Discussion and other details . . . . . . . . . . . . . 8
4.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . . 8
4.1.5. Composition Function: Sum of Means . . . . . . . . . . 9 4.1.5. Composition Function: Sum of Means . . . . . . . . . . 8
4.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 9 4.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 9
4.1.7. Justification of the Composition Function . . . . . . 10 4.1.7. Justification of the Composition Function . . . . . . 9
4.1.8. Sources of Deviation from the Ground Truth . . . . . . 10 4.1.8. Sources of Deviation from the Ground Truth . . . . . . 9
4.1.9. Specific cases where the conjecture might fail . . . . 10 4.1.9. Specific cases where the conjecture might fail . . . . 9
4.1.10. Application of Measurement Methodology . . . . . . . . 10 4.1.10. Application of Measurement Methodology . . . . . . . . 10
5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 11 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 10
5.1. Name: 5.1. Name:
Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream . . . . 11 Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream . . . . 10
5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 11 5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 10
5.1.2. Definition and Metric Units . . . . . . . . . . . . . 11 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 10
5.1.3. Discussion and other details . . . . . . . . . . . . . 11 5.1.3. Discussion and other details . . . . . . . . . . . . . 11
5.1.4. Statistic: 5.1.4. Statistic:
Type-P-One-way-Packet-Loss-Empirical-Probability . . . 11 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 11
5.1.5. Composition Function: Composition of Empirical 5.1.5. Composition Function: Composition of Empirical
Probabilities . . . . . . . . . . . . . . . . . . . . 12 Probabilities . . . . . . . . . . . . . . . . . . . . 11
5.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 12 5.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 11
5.1.7. Justification of the Composition Function . . . . . . 12 5.1.7. Justification of the Composition Function . . . . . . 11
5.1.8. Sources of Deviation from the Ground Truth . . . . . . 12 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 12
5.1.9. Specific cases where the conjecture might fail . . . . 13 5.1.9. Specific cases where the conjecture might fail . . . . 12
5.1.10. Application of Measurement Methodology . . . . . . . . 13 5.1.10. Application of Measurement Methodology . . . . . . . . 12
6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 13 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 13
6.1. Name: 6.1. Name:
Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream . . . . 14
6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 14 Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream . . . . 13
6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 13
6.1.2. Definition and Metric Units . . . . . . . . . . . . . 14 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 14
6.1.3. Discussion and other details . . . . . . . . . . . . . 15 6.1.3. Discussion and other details . . . . . . . . . . . . . 14
6.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 15 6.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 14
6.1.5. Composition Functions: . . . . . . . . . . . . . . . . 16 6.1.5. Composition Functions: . . . . . . . . . . . . . . . . 15
6.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 16 6.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 15
6.1.7. Justification of the Composition Function . . . . . . 16 6.1.7. Justification of the Composition Function . . . . . . 15
6.1.8. Sources of Deviation from the Ground Truth . . . . . . 16 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 15
6.1.9. Specific cases where the conjecture might fail . . . . 16 6.1.9. Specific cases where the conjecture might fail . . . . 15
6.1.10. Application of Measurement Methodology . . . . . . . . 16 6.1.10. Application of Measurement Methodology . . . . . . . . 15
7. Other Metrics and Statistics: One-way Combined Metric . . . . 16 7. Other Metrics and Statistics: One-way Combined Metric . . . . 16
7.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 16 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 16
7.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 16
7.1.3. Discussion and other details . . . . . . . . . . . . . 17 8.3. Interference with the metrics . . . . . . . . . . . . . . 16
7.1.4. Type-P-One-way-Combo-subpathes-stream . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1.5. Type-P-One-way-composition . . . . . . . . . . . . . . 18 10. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 17
7.1.6. Type-P-One-way-composition . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.7. Statement of Conjecture . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.8. Justification of Composite Relationship . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.1.9. Sources of Error . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 19
7.1.10. Specific cases where the conjecture might fail . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.11. Application of Measurement Methodology . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 19
8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 19
8.3. Interference with the metrics . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Contributors 1. Contributors
Thus far, the following people have contributed useful ideas, Thus far, the following people have contributed useful ideas,
suggestions, or the text of sections that have been incorporated into suggestions, or the text of sections that have been incorporated into
this memo: this memo:
- Phil Chimento <vze275m9@verizon.net> - Phil Chimento <vze275m9@verizon.net>
- Reza Fardid <RFardid@Covad.COM> - Reza Fardid <RFardid@Covad.COM>
skipping to change at page 4, line 27 skipping to change at page 4, line 27
- Maurizio Molina <maurizio.molina@dante.org.uk> - Maurizio Molina <maurizio.molina@dante.org.uk>
- Al Morton <acmorton@att.com> - Al Morton <acmorton@att.com>
- Emile Stephan <emile.stephan@francetelecom.com> - Emile Stephan <emile.stephan@francetelecom.com>
- Lei Liang <L.Liang@surrey.ac.uk> - Lei Liang <L.Liang@surrey.ac.uk>
2. Introduction 2. Introduction
The IPPM framework RFC 2330 [RFC2330] describes two forms of metric The IPPM framework [RFC2330] describes two forms of metric
composition, spatial and temporal. The new composition framework composition, spatial and temporal. The new composition framework
[I-D.ietf-ippm-framework-compagg] expands and further qualifies these [I-D.ietf-ippm-framework-compagg] expands and further qualifies these
original forms into three categories. This memo describes Spatial original forms into three categories. This memo describes Spatial
Composition, one of the categories of metrics under the umbrella of Composition, one of the categories of metrics under the umbrella of
the composition framework. the composition framework.
Spatial composition encompasses the definition of performance metrics Spatial composition encompasses the definition of performance metrics
that are applicable to a complete path, based on metrics collected on that are applicable to a complete path, based on metrics collected on
various sub-paths. various sub-paths.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
o the specific conjecture applied to the metric, o the specific conjecture applied to the metric,
o a justification of the practical utility of the composition in o a justification of the practical utility of the composition in
terms of making accurate measurements of the metric on the path, terms of making accurate measurements of the metric on the path,
o a justification of the usefulness of the composition in terms of o a justification of the usefulness of the composition in terms of
making analysis of the path using A-frame concepts more effective, making analysis of the path using A-frame concepts more effective,
and and
o an analysis of how the conjecture could be incorrect. o an analysis of how the conjecture could be incorrect.
RFC 2330 also gives an example where a conjecture that the delay of a Also, [RFC2330] gives an example where a conjecture that the delay of
path is very nearly the sum of the delays of the exchanges and clouds a path is very nearly the sum of the delays of the exchanges and
of the corresponding path digest. This example is particularly clouds of the corresponding path digest. This example is
relevant to those who wish to assess the performance of an Inter- particularly relevant to those who wish to assess the performance of
domain path without direct measurement, and the performance estimate an Inter-domain path without direct measurement, and the performance
of the complete path is related to the measured results for various estimate of the complete path is related to the measured results for
sub-paths instead. various sub-paths instead.
Approximate functions between the sub-path and complete path metrics Approximate functions between the sub-path and complete path metrics
are useful, with knowledge of the circumstances where the are useful, with knowledge of the circumstances where the
relationships are/are not applicable. For example, we would not relationships are/are not applicable. For example, we would not
expect that delay singletons from each sub-path would sum to produce expect that delay singletons from each sub-path would sum to produce
an accurate estimate of a delay singleton for the complete path an accurate estimate of a delay singleton for the complete path
(unless all the delays were essentially constant - very unlikely). (unless all the delays were essentially constant - very unlikely).
However, other delay statistics (based on a reasonable sample size) However, other delay statistics (based on a reasonable sample size)
may have a sufficiently large set of circumstances where they are may have a sufficiently large set of circumstances where they are
applicable. applicable.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
domains that have conflicting policies, measurement tools and domains that have conflicting policies, measurement tools and
methods, and measurement time assignment. The solution then may be methods, and measurement time assignment. The solution then may be
the composition of several sub-path measurements. This means each the composition of several sub-path measurements. This means each
domain performs the One-way measurement on a sub path between two domain performs the One-way measurement on a sub path between two
nodes that are involved in the complete path following its own nodes that are involved in the complete path following its own
policy, using its own measurement tools and methods, and using its policy, using its own measurement tools and methods, and using its
own measurement timing. Under the appropriate conditions, one can own measurement timing. Under the appropriate conditions, one can
combine the sub-path One-way metric results to estimate the complete combine the sub-path One-way metric results to estimate the complete
path One-way measurement metric with some degree of accuracy. path One-way measurement metric with some degree of accuracy.
3. Scope, Application, and Terminology 3. Scope and Application
3.1. Scope of work 3.1. Scope of work
For the primary IPPM metrics of Loss, Delay, and Delay Variation, For the primary IPPM metrics of Loss, Delay, and Delay Variation,
this memo gives a set of complete path metrics that can be composed this memo gives a set of metrics for that can be composed from the
from the same or similar sub-path metrics. This means that the same or similar sub-path metrics. This means that the composition
complete path metric may be composed from: function may utilize:
o the same metric for each sub-path; o the same metric for each sub-path;
o multiple metrics for each sub-path (possibly one that is the same o multiple metrics for each sub-path (possibly one that is the same
as the complete path metric); as the complete path metric);
o a single sub-path metrics that is different from the complete path o a single sub-path metrics that is different from the complete path
metric; metric;
o different measurement techniques like active and passive o different measurement techniques like active and passive
skipping to change at page 6, line 45 skipping to change at page 7, line 5
operator's domain, or is applicable to Inter-domain composition. operator's domain, or is applicable to Inter-domain composition.
Requires synchronized measurement time intervals in all sub-paths, or Requires synchronized measurement time intervals in all sub-paths, or
largely overlapping, or no timing requirements. largely overlapping, or no timing requirements.
Requires assumption of sub-path independence w.r.t. the metric being Requires assumption of sub-path independence w.r.t. the metric being
defined/composed, or other assumptions. defined/composed, or other assumptions.
Has known sources of inaccuracy/error, and identifies the sources. Has known sources of inaccuracy/error, and identifies the sources.
3.3. Terminology
This section defines the terminology applicable to Spatial
Composition metrics.
Measurement Points:
<there must be a suitable definition for this in IPPM's literature>
Complete path:
The complete path is the true path that a packet would follow as it
traverses from the packet's Source to its Destination.
Complete path metric:
The complete path metric is the Source to Destination metric that a
composed metric is estimating. A complete path metric represents the
ground-truth for a composed metric.
Composed Metric:
A composed metric is derived from other metrics principally by
applying a composition function.
Composition Function:
A composition function is a deterministic process applied to Sub-path
metrics to derive another metric (such as a Composed metric).
Sub-path:
A Sub-path is a portion of the complete path where at least the Sub-
path Source and Destination hosts are constituents of the complete
path. We say that this sub-path is "involved" in the complete path.
Sub-path metrics:
A sub-path path metric is an element of the process to derive a
Composite metric, quantifying some aspect of the performance a
particular sub-path from its Source to Destination.
4. One-way Delay Composed Metrics and Statistics 4. One-way Delay Composed Metrics and Statistics
4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream
This metric is a necessary element of Delay Composition metrics, and This metric is a necessary element of Delay Composition metrics, and
its definition does not formally exist elsewhere in IPPM literature. its definition does not formally exist elsewhere in IPPM literature.
4.1.1. Metric Parameters: 4.1.1. Metric Parameters:
o Src, the IP address of a host + Dst, the IP address of a host o Src, the IP address of a host + Dst, the IP address of a host
skipping to change at page 8, line 30 skipping to change at page 7, line 42
assigned to packets that arrive within a "reasonable" time. assigned to packets that arrive within a "reasonable" time.
o Tmax, a maximum waiting time for packets at the destination, set o Tmax, a maximum waiting time for packets at the destination, set
sufficiently long to disambiguate packets with long delays from sufficiently long to disambiguate packets with long delays from
packets that are discarded (lost), thus the distribution of delay packets that are discarded (lost), thus the distribution of delay
is not truncated. is not truncated.
4.1.2. Definition and Metric Units 4.1.2. Definition and Metric Units
Using the parameters above, we obtain the value of Type-P-One-way- Using the parameters above, we obtain the value of Type-P-One-way-
Delay singleton as per RFC 2679 [RFC2679]. Delay singleton as per [RFC2679].
For each packet [i] that has a finite One-way Delay (in other words, For each packet [i] that has a finite One-way Delay (in other words,
excluding packets which have undefined one-way delay): excluding packets which have undefined one-way delay):
Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] =
FiniteDelay[i] = TstampDst - TstampSrc FiniteDelay[i] = TstampDst - TstampSrc
4.1.3. Discussion and other details 4.1.3. Discussion and other details
skipping to change at page 11, line 30 skipping to change at page 10, line 39
5.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 5.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream
5.1.1. Metric Parameters: 5.1.1. Metric Parameters:
Same as section 4.1.1. Same as section 4.1.1.
5.1.2. Definition and Metric Units 5.1.2. Definition and Metric Units
Using the parameters above, we obtain the value of Type-P-One-way- Using the parameters above, we obtain the value of Type-P-One-way-
Packet-Loss singleton and stream as per RFC 2680 [RFC2680]. Packet-Loss singleton and stream as per [RFC2680].
We obtain a sequence of pairs with elements as follows: We obtain a sequence of pairs with elements as follows:
o TstampSrc, as above o TstampSrc, as above
o L, either zero or one, where L=1 indicates loss and L=0 indicates o L, either zero or one, where L=1 indicates loss and L=0 indicates
arrival at the destination within TstampSrc + Tmax. arrival at the destination within TstampSrc + Tmax.
5.1.3. Discussion and other details 5.1.3. Discussion and other details
skipping to change at page 16, line 41 skipping to change at page 16, line 7
6.1.7. Justification of the Composition Function 6.1.7. Justification of the Composition Function
6.1.8. Sources of Deviation from the Ground Truth 6.1.8. Sources of Deviation from the Ground Truth
6.1.9. Specific cases where the conjecture might fail 6.1.9. Specific cases where the conjecture might fail
6.1.10. Application of Measurement Methodology 6.1.10. Application of Measurement Methodology
7. Other Metrics and Statistics: One-way Combined Metric 7. Other Metrics and Statistics: One-way Combined Metric
This definition may be the common part for the definition of "Loss
Metrics/Statistics" and for the definition of "One-way Delay
Composition Metrics and Statistics".
7.1. Metric Name:
Type-P-One-way-Combo-mean
7.1.1. Metric Parameters:
Editorial notes (ES): parameters list to be completed
<P1,T1,dt1>...<Pn,Tn,dtn>:
It is a stream of One-way delay corresponding either to an end to end
measure of a sub-path, or to the spatial measure of the sub-path:
- Type-P-One-way-Delay-Poisson-Stream as per [RFC2679];
- Type-P-One-way-Delay-Periodic-Stream a per RFC 3432 [RFC3432];
- Type-P-One-way-Composition-Stream as defined below;
- Type-P-subpath-One-way-Delay-Stream as per
I-D.stephan-ippm-multimetrics [I-D.stephan-ippm-multimetrics].
7.1.2. Definition and Metric Units
Using the value <P1,T1,dt1>...<Pn,Tn,dtn> of one of the One-way delay
Stream listed above, we define Type-P-One-way-Combo as the couple
(D,L) where D is the mean of the delay of the packets that have a
finite One-way, and where L is the average of lost of packets (which
have undefined, or infinite one-way delay).
D corresponds to the Type-P-Finite-One-way-Delay-Mean defined above.
L corresponds to the Type-P-One-way-Packet-Loss-Empirical-Probability
defined above.
7.1.3. Discussion and other details
7.1.4. Type-P-One-way-Combo-subpathes-stream
Parameters:
+ dT1,..., dTn a list of delay.
+ <Src, H1, H2,..., Hn, Dst>, the equivalent path.
Definition:
Using Type-P-One-way-Combo-mean of each sub-path in the equivalent
path we define a Type-P-One-way-subpathes-stream as the list of
couples (D,L) of the sub-path list;
Results: {<D0,L0>, <D1,L1>, <D2,L2>, ... <Dn,Ln>}
7.1.5. Type-P-One-way-composition
The composition over a path gives D and L which give an estimation of
the end-to-end delay and end-to-end packet lost over this path.
Parameters:
+ <Src, H1, H2,..., Hn, Dst>, the complete path.
+ {<D0,L0>, <D1,L1>, <D2,L2>, ... <Dn,Ln>}, the composition stream of
the sub-paths of a path.
Definition:
Using Type-P-One-way-subpathes-stream we define Type-P-One-way-
composition as the couple <D,L> where D is the mean of the delays Di
and where L is the average of lost of Li.
Results: <D,L>, where D is a delay and L is the lost
7.1.6. Type-P-One-way-composition
The sample of Type-P-One-way-composition is defined to permit the
usage of the results of Type-P-One-way-composition measure in
computation of Type-P-One-way-Combo-mean composition.
Parameters:
+ T1,..., Tn, a list of times;
+ <D,L>, the delay and the lost computed by composition.
Definition:
Using Type-P-One-way-composition we define Type-P-One-way-
composition-stream as the stream of couples <D,L> over time.
Results: <T1,D1,L1>...<Tn,Dn,Ln>
7.1.7. Statement of Conjecture
7.1.8. Justification of Composite Relationship
Combo metric is very easy to measure and to compose.
It gives the delay and the lost, so most of the need.
Combo metric may be performed on com metric too.
7.1.9. Sources of Error
Packets may cross different sub path than the equivalent end-to-end
measure because Type-P differ.
Packets may experiment different behavior than the equivalent end-to-
end measure because of access classification based on packet
addresses.
7.1.10. Specific cases where the conjecture might fail
When
+ Sum of sub-path differ from the equivalent path.
+ Type-P differ.
+ Size differ.
7.1.11. Application of Measurement Methodology
The methodology: Is applicable to Intra and interdomain;
SHOULD report the context of the measure;
8. Security Considerations 8. Security Considerations
8.1. Denial of Service Attacks 8.1. Denial of Service Attacks
This metric requires a stream of packets sent from one host (source) This metric requires a stream of packets sent from one host (source)
to another host (destination) through intervening networks. This to another host (destination) through intervening networks. This
method could be abused for denial of service attacks directed at method could be abused for denial of service attacks directed at
destination and/or the intervening network(s). destination and/or the intervening network(s).
Administrators of source, destination, and the intervening network(s) Administrators of source, destination, and the intervening network(s)
skipping to change at page 20, line 25 skipping to change at page 16, line 50
generate additional packets that appear to be part of the sample generate additional packets that appear to be part of the sample
metric. These additional packets are likely to perturb the results metric. These additional packets are likely to perturb the results
of the sample measurement. of the sample measurement.
To discourage the kind of interference mentioned above, packet To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used. interference checks, such as cryptographic hash, may be used.
9. IANA Considerations 9. IANA Considerations
Metrics defined in this memo will be registered in the IANA IPPM Metrics defined in this memo will be registered in the IANA IPPM
METRICS REGISTRY as described in initial version of the registry RFC METRICS REGISTRY as described in initial version of the registry
4148 [RFC4148]. [RFC4148].
10. Open Issues 10. Issues (Open and Closed)
>>>>>>>>>>>>Open issue: >>>>>>>>>>>>Issue:
What is the relationship between the decomposition and composition What is the relationship between the decomposition and composition
metrics? Should we put both kinds in one draft to make up a metrics? Should we put both kinds in one draft to make up a
framework? The motivation of decomposition is as follows: framework? The motivation of decomposition is as follows:
The One-way measurement can provide result to show what the network The One-way measurement can provide result to show what the network
performance between two end hosts is and whether it meets operator performance between two end hosts is and whether it meets operator
expectations or not. It cannot provide further information to expectations or not. It cannot provide further information to
engineers where and how to improve the performance between the source engineers where and how to improve the performance between the source
and the destination. For instance, if the network performance is not and the destination. For instance, if the network performance is not
skipping to change at page 21, line 4 skipping to change at page 17, line 28
and the destination. For instance, if the network performance is not and the destination. For instance, if the network performance is not
acceptable in terms of the One-way measurement, in which part of the acceptable in terms of the One-way measurement, in which part of the
network the engineers should put their efforts. This question can to network the engineers should put their efforts. This question can to
be answered by decompose the One-way measurement to sub-path be answered by decompose the One-way measurement to sub-path
measurement to investigate the performance of different part of the measurement to investigate the performance of different part of the
network. network.
Editor's Questions for clarification: What additional information Editor's Questions for clarification: What additional information
would be provided to the decomposition process, beyond the would be provided to the decomposition process, beyond the
measurement of the complete path? measurement of the complete path?
Is the decomposition described above intended to estimate a metric Is the decomposition described above intended to estimate a metric
for some/all disjoint sub-paths involved in the complete path? for some/all disjoint sub-paths involved in the complete path?
>>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a seperate memo >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a seperate memo
>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>OPEN Issue >>>>>>>>>>>>>>>>>>>Issue
Section 7 defines a new type of metric, a "combination" of metrics Section 7 defines a new type of metric, a "combination" of metrics
for one-way delay and packet loss. The purpose of this metric is to for one-way delay and packet loss. The purpose of this metric is to
link these two primary metrics in a convenient way. link these two primary metrics in a convenient way.
Readers are asked to comment on the efficiency of the combination Readers are asked to comment on the efficiency of the combination
metric. metric.
>>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as
having "undefined" delay when the packet does not arrive within the having "undefined" delay when the packet does not arrive within the
waiting time Tmax, then this information is sufficient to determine waiting time Tmax, then this information is sufficient to determine
the fraction of lost packets in the sample, and the additional loss the fraction of lost packets in the sample, and the additional loss
indication of this combo is not needed. indication of this combo is not needed.
>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> OPEN Issue >>>>>>>>>>>>>>>>> Issue
How can we introduce multicast metrics here, without causing too much Can we introduce multicast metrics here, without causing too much
confusion? Should the multicast version of this draft wait until the confusion? Should the multicast version of this draft wait until the
Unicast concepts are stable (or maybe appear in a separate draft)? Unicast concepts are stable (or maybe appear in a separate draft)?
>>>>>>>>>>>>>>>>RESOLUTION: Yes and Yes. >>>>>>>>>>>>>>>>RESOLUTION: No and Yes.
11. Acknowledgements 11. Acknowledgements
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-ippm-framework-compagg] [I-D.ietf-ippm-framework-compagg]
Morton, A. and S. Berghe, "Framework for Metric Morton, A. and S. Berghe, "Framework for Metric
Composition", draft-ietf-ippm-framework-compagg-00 (work Composition", draft-ietf-ippm-framework-compagg-01 (work
in progress), February 2006. in progress), June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
skipping to change at page 24, line 5 skipping to change at page 20, line 5
France Telecom Division R&D France Telecom Division R&D
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion, F-22307 Lannion, F-22307
France France
Phone: Phone:
Fax: +33 2 96 05 18 52 Fax: +33 2 96 05 18 52
Email: emile.stephan@francetelecom.com Email: emile.stephan@francetelecom.com
URI: URI:
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 29 skipping to change at page 20, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 35 change blocks. 
271 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/