Network Working Group A. Morton Internet-Draft AT&T Labs~~Expires: December 26, 2006~~Intended status: Standards TrackE. StephanExpires: April 25, 2007France Telecom Division R&D~~June 24,~~October 22,2006 Spatial Composition of Metrics~~draft-ietf-ippm-spatial-composition-01~~draft-ietf-ippm-spatial-composition-02Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on~~December 26, 2006.~~April 25, 2007.Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo utilizes IPPM metrics that are applicable to both 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 actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In this memo, the characters "<=" should be read as "less than or equal to" and ">=" as "greater than or equal to". Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.~~Scope, Application, and Terminology . . . . . . . . . . . . . 5 3.1.~~Scope~~of work . .~~and Application. . . . . . . . . . . . . . . . . . . . 5~~3.2. Application .~~3.1. Scope of work. . . . . . . . . . . . . . . . . . . . . . 6~~3.3. Terminology~~3.2. Application. . . . . . . . . . . . . . . . . . . . . . . 6 4. One-way Delay Composed Metrics and Statistics . . . . . . . . 7 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 7 4.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 7 4.1.2. Definition and Metric Units . . . . . . . . . . . . .~~8~~74.1.3. Discussion and other details . . . . . . . . . . . . . 8 4.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . .~~9~~84.1.5. Composition Function: Sum of Means . . . . . . . . . .~~9~~84.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 9 4.1.7. Justification of the Composition Function . . . . . .~~10~~94.1.8. Sources of Deviation from the Ground Truth . . . . . .~~10~~94.1.9. Specific cases where the conjecture might fail . . . .~~10~~94.1.10. Application of Measurement Methodology . . . . . . . . 10 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . .~~11~~105.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream . . . .~~11~~105.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . .~~11~~105.1.2. Definition and Metric Units . . . . . . . . . . . . .~~11~~105.1.3. Discussion and other details . . . . . . . . . . . . . 11 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability . . . 11 5.1.5. Composition Function: Composition of Empirical Probabilities . . . . . . . . . . . . . . . . . . . .~~12~~115.1.6. Statement of Conjecture . . . . . . . . . . . . . . .~~12~~115.1.7. Justification of the Composition Function . . . . . .~~12~~115.1.8. Sources of Deviation from the Ground Truth . . . . . . 12 5.1.9. Specific cases where the conjecture might fail . . . .~~13~~125.1.10. Application of Measurement Methodology . . . . . . . .~~13~~126. Delay Variation Metrics and Statistics . . . . . . . . . . . . 13 6.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream . . . .~~14~~136.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . .~~14~~136.1.2. Definition and Metric Units . . . . . . . . . . . . . 14 6.1.3. Discussion and other details . . . . . . . . . . . . .~~15~~146.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . .~~15~~146.1.5. Composition Functions: . . . . . . . . . . . . . . . .~~16~~156.1.6. Statement of Conjecture . . . . . . . . . . . . . . .~~16~~156.1.7. Justification of the Composition Function . . . . . .~~16~~156.1.8. Sources of Deviation from the Ground Truth . . . . . .~~16~~156.1.9. Specific cases where the conjecture might fail . . . .~~16~~156.1.10. Application of Measurement Methodology . . . . . . . .~~16~~157. Other Metrics and Statistics: One-way Combined Metric . . . . 16~~7.1. Metric Name: . . . .~~8. Security Considerations. . . . . . . . . . . . . . . . . . . 16~~7.1.1. Metric Parameters: . .~~8.1. Denial of Service Attacks. . . . . . . . . . . . . . . . 16~~7.1.2. Definition and Metric Units . . . . . . . . . .~~8.2. User Data Confidentiality. . .~~17 7.1.3. Discussion and other details~~. . . . . . . . . . . . .~~17 7.1.4. Type-P-One-way-Combo-subpathes-stream~~16 8.3. Interference with the metrics. . . . . . . .~~17 7.1.5. Type-P-One-way-composition~~. . . . . .16 9. IANA Considerations. . . . . . . .~~18 7.1.6. Type-P-One-way-composition~~. . . . . . . . . . . . .16 10. Issues (Open and Closed).~~18 7.1.7. Statement of Conjecture~~. . . . . . . . . . . . . . .~~18 7.1.8. Justification of Composite Relationship~~. . .17 11. Acknowledgements. . . .~~18 7.1.9. Sources of Error~~. . . . . . . . . . . . . . . . . . .~~19 7.1.10. Specific cases where the conjecture might fail~~18 12. References. . . .~~19 7.1.11. Application of Measurement Methodology~~. . . . . . . .~~19 8. Security Considerations~~. . . . . . . . . . . . . .18 12.1. Normative References. . . . .~~19 8.1. Denial of Service Attacks~~. . . . . . . . . . . . . .18 12.2. Informative References. .~~19 8.2. User Data Confidentiality~~. . . . . . . . . . . . . . . . 19~~8.3. Interference with the metrics . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . .~~Authors' Addresses. . . . . . . . .~~20 10. Open Issues~~. . . . . . . . . . . . . . .19 Intellectual Property and Copyright Statements. . . . . . . . . . 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 Thus far, the following people have contributed useful ideas, suggestions, or the text of sections that have been incorporated into this memo: - Phil Chimento <vze275m9@verizon.net> - Reza Fardid <RFardid@Covad.COM> - Roman Krzanowski <roman.krzanowski@verizon.com> - Maurizio Molina <maurizio.molina@dante.org.uk> - Al Morton <acmorton@att.com> - Emile Stephan <emile.stephan@francetelecom.com> - Lei Liang <L.Liang@surrey.ac.uk> 2. Introduction The IPPM framework~~RFC 2330~~[RFC2330] describes two forms of metric composition, spatial and temporal. The new composition framework [I-D.ietf-ippm-framework-compagg] expands and further qualifies these original forms into three categories. This memo describes Spatial Composition, one of the categories of metrics under the umbrella of the composition framework. Spatial composition encompasses the definition of performance metrics that are applicable to a complete path, based on metrics collected on various sub-paths. The main purpose of this memo is to define the deterministic functions that yield the complete path metrics using metrics of the sub-paths. The effectiveness of such metrics is dependent on their usefulness in analysis and applicability with practical measurement methods. The relationships may involve conjecture, and [RFC2330] lists four points that the metric definitions should include: o the specific conjecture applied to the metric, o a justification of the practical utility of the composition in terms of making accurate measurements of the metric on the path, o a justification of the usefulness of the composition in terms of making analysis of the path using A-frame concepts more effective, and o an analysis of how the conjecture could be incorrect.~~RFC 2330 also~~Also, [RFC2330]gives an example where a conjecture that the delay of a path is very nearly the sum of the delays of the exchanges and clouds of the corresponding path digest. This example is particularly relevant to those who wish to assess the performance of an~~Inter- domain~~Inter-domainpath without direct measurement, and the performance estimate of the complete path is related to the measured results for various sub-paths instead. Approximate functions between the sub-path and complete path metrics are useful, with knowledge of the circumstances where the relationships are/are not applicable. For example, we would not expect that delay singletons from each sub-path would sum to produce an accurate estimate of a delay singleton for the complete path (unless all the delays were essentially constant - very unlikely). However, other delay statistics (based on a reasonable sample size) may have a sufficiently large set of circumstances where they are applicable. 2.1. Motivation One-way metrics defined in other IPPM RFCs all assume that the measurement can be practically carried out between the source and the destination of the interest. Sometimes there are reasons that the measurement can not be executed from the source to the destination. For instance, the measurement path may cross several independent domains that have conflicting policies, measurement tools and methods, and measurement time assignment. The solution then may be the composition of several sub-path measurements. This means each domain performs the One-way measurement on a sub path between two nodes that are involved in the complete path following its own policy, using its own measurement tools and methods, and using its own measurement timing. Under the appropriate conditions, one can combine the sub-path One-way metric results to estimate the complete path One-way measurement metric with some degree of accuracy. 3.~~Scope, Application,~~Scopeand~~Terminology~~Application3.1. Scope of work For the primary IPPM metrics of Loss, Delay, and Delay Variation, this memo gives a set of~~complete path~~metricsforthat can be composed from the same or similar sub-path metrics. This means that the~~complete path metric~~composition functionmay~~be composed from:~~utilize:o the same metric for each sub-path; o multiple metrics for each sub-path (possibly one that is the same as the complete path metric); o a single sub-path metrics that is different from the complete path metric; o different measurement techniques like active and passive (recognizing that PSAMP WG will define capabilities to sample packets to support measurement). 3.2. Application The new composition framework [I-D.ietf-ippm-framework-compagg] requires the specification of the applicable circumstances for each metric. In particular, the application of Spatial Composition metrics are addressed as to whether the metric: Requires the same test packets to traverse all sub-paths, or may use similar packets sent and collected separately in each sub-path. Requires homogeneity of measurement methodologies, or can allow a degree of flexibility (e.g., active or passive methods produce the "same" metric). Also, the applicable sending streams will be specified, such as Poisson, Periodic, or both. Needs information or access that will only be available within an operator's domain, or is applicable to Inter-domain composition. Requires synchronized measurement time intervals in all sub-paths, or largely overlapping, or no timing requirements. Requires assumption of sub-path independence w.r.t. the metric being defined/composed, or other assumptions. Has known sources of inaccuracy/error, and identifies the sources.~~3.3. Terminology~~4. One-way Delay Composed Metrics and Statistics 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-StreamThis~~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~~metricis~~the true path that~~a~~packet would follow as it traverses from the packet's Source to~~necessary element of Delay Composition metrics, andits~~Destination. Complete path metric: The complete path metric is~~definition does not formally exist elsewhere in IPPM literature. 4.1.1. Metric Parameters: o Src,the~~Source to Destination metric that~~IP address ofa~~composed metric is estimating. A complete path metric represents~~host + Dst,the~~ground-truth for~~IP address ofa~~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.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream This metric is a necessary element of Delay Composition metrics, and its definition does not formally exist elsewhere in IPPM literature. 4.1.1. Metric Parameters: o Src, the IP address of a host + Dst, the IP address of a host o T,~~host o T,a time (start of test interval) o Tf, a time (end of test interval) o lambda, a rate in reciprocal seconds (for Poisson Streams) o incT, the nominal duration of inter-packet interval, first bit to first bit (for Periodic Streams) o T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements (for Periodic Streams) o TstampSrc, the wire time of the packet as measured at MP(Src) o TstampDst, the wire time of the packet as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time. o Tmax, a maximum waiting time for packets at the destination, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost), thus the distribution of delay is not truncated. 4.1.2. Definition and Metric Units Using the parameters above, we obtain the value of Type-P-One-way- Delay singleton as per~~RFC 2679~~[RFC2679]. For each packet [i] that has a finite One-way Delay (in other words, excluding packets which have undefined one-way delay): Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = FiniteDelay[i] = TstampDst - TstampSrc 4.1.3. Discussion and other details The "Type-P-Finite-One-way-Delay" metric permits calculation of the sample mean statistic. This resolves the problem of including lost packets in the sample (whose delay is undefined), and the issue with the informal assignment of infinite delay to lost packets (practical systems can only assign some very large value). The Finite-One-way-Delay approach handles the problem of lost packets by reducing the event space. We consider conditional statistics, and estimate the mean one-way delay conditioned on the event that all packets in the sample arrive at the destination (within the specified waiting time, Tmax). This offers a way to make some valid statements about one-way delay, and at the same time avoiding events with undefined outcomes. This approach is derived from the treatment of lost packets in [RFC3393], and is similar~~to[Y.1540]~~to [Y.1540]. 4.1.4. Mean Statistic We add the following parameter: o N, the total number of packets received at Dst (sent between T0 and Tf) and define Type-P-Finite-One-way-Delay-Mean = N --- 1 \ - * > (FiniteDelay [i]) N / --- i = 1 where all packets i= 1 through N have finite singleton delays. 4.1.5. Composition Function: Sum of Means The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay for the complete Source to Destination path can be calculated from sum of the Mean Delays of all its S constituent sub-paths. o S, the number of sub-paths involved in the complete Src-Dst path. Then the Type-P-Finite-Composite-One-way-Delay-Mean = CompMeanDelay = (1/S)Sum(from i=1 to S, MeanDelay[i]) 4.1.6. Statement of Conjecture The mean of a sufficiently large stream of packets measured on each sub-path during the interval [T, Tf] will be representative of the true mean of the delay distribution (and the distributions themselves are sufficiently independent), such that the means may be added to produce an estimate of the complete path mean delay. 4.1.7. Justification of the Composition Function It is sometimes impractical to conduct active measurements between every Src-Dst pair. For example, it may not be possible to collect the desired sample size in each test interval when access link speed is limited, because of the potential for measurement traffic to degrade the user traffic performance. The conditions on a low-speed access link may be understood well-enough to permit use of a small sample size/rate, while a larger sample size/rate may be used on other sub-paths. Also, since measurement operations have a real monetary cost, there is value in re-using measurements where they are applicable, rather than launching new measurements for every possible source-destination pair. 4.1.8. Sources of Deviation from the Ground Truth The measurement packets, each having source and destination addresses intended for collection at edges of the sub-path, may take a different specific path through the network equipment and parallel exchanges than packets with the source and destination addresses of the complete path. Therefore, the sub-path measurements may differ from the performance experienced by packets on the complete path. Multiple measurements employing sufficient sub-path address pairs might produce bounds on the extent of this error. others... 4.1.9. Specific cases where the conjecture might fail If any of the sub-path distributions are bimodal, then the measured means may not be stable, and in this case the mean will not be a particularly useful statistic when describing the delay distribution of the complete path. The mean may not be sufficiently robust statistic to produce a reliable estimate, or to be useful even if it can be measured. others... 4.1.10. Application of Measurement Methodology The methodology: SHOULD use similar packets sent and collected separately in each sub- path. Allows a degree of flexibility (e.g., active or passive methods can produce the "same" metric, but timing and correlation of passive measurements is much more challenging). Poisson and/or Periodic streams are RECOMMENDED. Applicable to both Inter-domain and Intra-domain composition. SHOULD have synchronized measurement time intervals in all sub-paths, but largely overlapping intervals MAY suffice. REQUIRES assumption of sub-path independence w.r.t. the metric being defined/composed. 5. Loss Metrics and Statistics 5.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 5.1.1. Metric Parameters: Same as section 4.1.1. 5.1.2. Definition and Metric Units Using the parameters above, we obtain the value of Type-P-One-way- Packet-Loss singleton and stream as per~~RFC 2680~~[RFC2680]. We obtain a sequence of pairs with elements as follows: o TstampSrc, as above o L, either zero or one, where L=1 indicates loss and L=0 indicates arrival at the destination within TstampSrc + Tmax. 5.1.3. Discussion and other details 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability Given the following stream parameter o M, the total number of packets sent between T0 and Tf We can define the Empirical Probability of Loss Statistic (Ep), consistent with Average Loss in [RFC2680], as follows: Type-P-One-way-Packet-Loss-Empirical-Probability = Ep = (1/M)Sum(from i=1 to M, L[i]) where all packets i= 1 through M have a value for L. 5.1.5. Composition Function: Composition of Empirical Probabilities The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or CompEp for the complete Source to Destination path can be calculated by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... Epn) as Type-P-One-way-Composite-Packet-Loss-Empirical-Probability = CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 5.1.6. Statement of Conjecture The empirical probability of loss calculated on a sufficiently large stream of packets measured on each sub-path during the interval [T, Tf] will be representative of the true loss probability (and the probabilities themselves are sufficiently independent), such that the sub-path probabilities may be combined to produce an estimate of the complete path loss probability. 5.1.7. Justification of the Composition Function It is sometimes impractical to conduct active measurements between every Src-Dst pair. For example, it may not be possible to collect the desired sample size in each test interval when access link speed is limited, because of the potential for measurement traffic to degrade the user traffic performance. The conditions on a low-speed access link may be understood well-enough to permit use of a small sample size/rate, while a larger sample size/rate may be used on other sub-paths. Also, since measurement operations have a real monetary cost, there is value in re-using measurements where they are applicable, rather than launching new measurements for every possible source-destination pair. 5.1.8. Sources of Deviation from the Ground Truth The measurement packets, each having source and destination addresses intended for collection at edges of the sub-path, may take a different specific path through the network equipment and parallel exchanges than packets with the source and destination addresses of the complete path. Therefore, the sub-path measurements may differ from the performance experienced by packets on the complete path. Multiple measurements employing sufficient sub-path address pairs might produce bounds on the extent of this error. others... 5.1.9. Specific cases where the conjecture might fail A concern for loss measurements combined in this way is that root causes may be correlated to some degree. For example, if the links of different networks follow the same physical route, then a single event like a tunnel fire could cause an outage or congestion on remaining paths in multiple networks. Here it is important to ensure that measurements before the event and after the event are not combined to estimate the composite performance. Or, when traffic volumes rise due to the rapid spread of an email- born worm, loss due to queue overflow in one network may help another network to carry its traffic without loss. others... 5.1.10. Application of Measurement Methodology The methodology: SHOULD use similar packets sent and collected separately in each sub- path. Allows a degree of flexibility (e.g., active or passive methods can produce the "same" metric, but timing and correlation of passive measurements is much more challenging). Poisson and/or Periodic streams are RECOMMENDED. Applicable to both Inter-domain and Intra-domain composition. SHOULD have synchronized measurement time intervals in all sub-paths, but largely overlapping intervals MAY suffice. REQUIRES assumption of sub-path independence w.r.t. the metric being defined/composed. 6. Delay Variation Metrics and Statistics 6.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream This metric is a necessary element of Composed Delay Variation metrics, and its definition does not formally exist elsewhere in IPPM literature. 6.1.1. Metric Parameters: In addition to the parameters of section 4.1.1: o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time. o B, a packet length in bits o F, a selection function unambiguously defining the packets from the stream that are selected for the packet-pair computation of this metric. F(first packet), the first packet of the pair, MUST have a valid Type-P-Finite-One-way-Delay less than Tmax (in other words, excluding packets which have undefined, or infinite one-way delay) and MUST have been transmitted during the interval T, Tf. The second packet in the pair MUST be the packet with the minimum valid value of Type-P-Finite-One-way-Delay for the stream, in addition to the criteria for F(first packet). If multiple packets have equal minimum Type-P-Finite-One-way-Delay values, then the value for the earliest arriving packet SHOULD be used. o MinDelay, the Type-P-Finite-One-way-Delay value for F(second packet) given above. o N, the number of packets received at the Destination meeting the F(first packet) criteria. 6.1.2. Definition and Metric Units Using the definition above in section 4.1.2, we obtain the value of Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton for each packet[i] in the stream (a.k.a. FiniteDelay[i]). For each packet[i] that meets the F(first packet) criteria given above: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream[i] = IPDVRefMin[i] = FiniteDelay[i] - MinDelay where IPDVRefMin[i] is in units of time (seconds, milliseconds). 6.1.3. Discussion and other details This metric produces a sample of delay variation normalized to the minimum delay of the sample. The resulting delay variation distribution is independent of the sending sequence (although specific FiniteDelay values within the distribution may be correlated, depending on various stream parameters such as packet spacing). This metric is equivalent to the IP Packet Delay Variation parameter defined in [Y.1540]. 6.1.4. Statistics: Mean, Variance, Skewness, Quanitle We define the mean IPDVRefMin as follows (where all packets i= 1 through N have a value for IPDVRefMin): Type-P-One-way-ipdv-refmin-Mean = MeanIPDVRefMin = N --- 1 \ - * > (IPDVRefMin [i]) N / --- i = 1 We define the variance of IPDVRefMin as follows: Type-P-One-way-ipdv-refmin-Variance = VarIPDVRefMin = N --- 1 \ 2 ------- > (IPDVRefMin [i] - MeanIPDVRefMin) (N - 1) / --- i = 1 We define the skewness of IPDVRefMin as follows: Type-P-One-way-ipdv-refmin-Skewness = SkewIPDVRefMin = N --- 3 \ / \ > | IPDVRefMin[i]- MeanIPDVRefMin | / \ / --- i = 1 ------------------------------------------- / \ | ( 3/2 ) | \ (N - 1) * VarIPDVRefMin / We define the Quantile of the IPDVRefMin sample as the value where the specified fraction of points is less than the given value. 6.1.5. Composition Functions: The Type-P-One-way-Composite-ipdv-refmin-<something> for the complete Source to Destination path can be calculated by combining statistics of all the constituent sub-paths in the following process: < see [Y.1541] > 6.1.6. Statement of Conjecture 6.1.7. Justification of the Composition Function 6.1.8. Sources of Deviation from~~the Ground Truth 6.1.9. Specific cases where the conjecture might fail 6.1.10. Application of Measurement Methodology 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.~~the Ground Truth 6.1.9.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.~~6.1.10.Application of Measurement Methodology~~The methodology: Is applicable to Intra~~7. Other Metricsand~~interdomain; SHOULD report the context of the measure;~~Statistics: One-way Combined Metric8. Security Considerations 8.1. Denial of Service Attacks This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks. This method could be abused for denial of service attacks directed at destination and/or the intervening network(s). Administrators of source, destination, and the intervening network(s) should establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants may be cause for immediate rejection or discard of packets or other escalation procedures defined between the affected parties. 8.2. User Data Confidentiality Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons. 8.3. Interference with the metrics It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g. increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement. To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, may be used. 9. IANA Considerations Metrics defined in this memo will be registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry~~RFC 4148~~[RFC4148]. 10.~~Open~~Issues~~>>>>>>>>>>>>Open issue:~~(Open and Closed) >>>>>>>>>>>>Issue:What is the relationship between the decomposition and composition metrics? Should we put both kinds in one draft to make up a framework? The motivation of decomposition is as follows: The One-way measurement can provide result to show what the network performance between two end hosts is and whether it meets operator expectations or not. It cannot provide further information to engineers where and how to improve the performance between the source and the destination. For instance, if the network performance is not acceptable in terms of the One-way measurement, in which part of the network the engineers should put their efforts. This question can to be answered by decompose the One-way measurement to sub-path measurement to investigate the performance of different part of the network. Editor's Questions for clarification: What additional information would be provided to the decomposition process, beyond the measurement of the complete path? Is the decomposition described above intended to estimate a metric for some/all disjoint sub-paths involved in the complete path? >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a seperate memo >>>>>>>>>>>>>>>>>>>~~>>>>>>>>>>>>>>>>>>>OPEN Issue~~>>>>>>>>>>>>>>>>>>>IssueSection 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 link these two primary metrics in a convenient way. Readers are asked to comment on the efficiency of the combination metric. >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as having "undefined" delay when the packet does not arrive within the waiting time Tmax, then this information is sufficient to determine the fraction of lost packets in the sample, and the additional loss indication of this combo is not needed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>~~OPEN~~Issue~~How can~~Canwe introduce multicast metrics here, without causing too much confusion? Should the multicast version of this draft wait until the Unicast concepts are stable (or maybe appear in a separate draft)? >>>>>>>>>>>>>>>>RESOLUTION:~~Yes~~Noand Yes. 11. Acknowledgements 12. References 12.1. Normative References [I-D.ietf-ippm-framework-compagg] Morton, A. and S. Berghe, "Framework for Metric Composition",~~draft-ietf-ippm-framework-compagg-00~~draft-ietf-ippm-framework-compagg-01(work in progress),~~February~~June2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. 12.2. Informative References [I-D.stephan-ippm-multimetrics] Stephan, E., "IP Performance Metrics (IPPM) for spatial and multicast", draft-stephan-ippm-multimetrics-02 (work in progress), October 2005. [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2002. [Y.1541] ITU-T Recommendation Y.1540, "Network Performance Objectives for IP-based Services", February 2006. Authors' Addresses Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Emile Stephan France Telecom Division R&D 2 avenue Pierre Marzin Lannion, F-22307 France Phone: Fax: +33 2 96 05 18 52 Email: emile.stephan@francetelecom.com URI: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~~Statement~~The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at 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 Funding for the RFC Editor function is~~currently~~provided by the~~Internet Society.~~IETF Administrative Support Activity (IASA).