Network Working Group E. Stephan Internet Draft France Telecom R&D Document: draft-stephan-ippm-spatial-metrics-01.txt June, 2003 Category: Informational Spatial metrics for IPPM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1] except that the right to produce derivative works is not granted. 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. Abstract The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance. This memo defines spatial metrics both for measuring end-to-end network performance using aggregation of sequence of network measures and for measuring the performance of segments of an IP path trajectory. It distinguishes clearly the decomposition of one end-to-end measure result in a sequence of per hop results from the aggregation of a sequence of per hop measure results in an end-to-end result. Table of Contents 1. Introduction................................................2 2. Terminology.................................................4 2.1. Spatial metric..............................................4 2.2. Asynchronous spatial metrics................................4 2.3. Trajectory..................................................4 3. Motivation..................................................4 3.1. Instantaneous end to end measure decomposition..............4 Stephan Informational - Expires December 2003 [Page 1] Internet Draft Spatial metrics for IPPM June 2003 4. End-to-end measures aggregation.............................4 5. Metrics for decomposition of end-to-end one way delay.......5 5.1. Spatial one way delay.......................................5 5.2. One way delay Trajectory metric.............................6 5.3. Aggregated One way delay metric.............................6 6. Metrics for aggregation of end-to-end one way delay.........7 6.1. Asynchronous One way delay Trajectory metric................7 6.2. Asynchronous Aggregated One way delay metric................8 7. Spatial metrics for One-way Packet Loss.....................8 7.1. Spatial one way packet loss.................................8 7.2. Samples for Spatial One-way Packet Loss.....................9 7.3. Statistics for Spatial One-way Packet Loss.................10 8. Applicability statements...................................11 9. Security Considerations....................................11 9.1. Privacy....................................................11 10. Change since 00............................................12 11. Acknowledgments............................................12 12. Author Addresses...........................................12 1. Introduction The metrics specified in this memo are built on notions introduced and discussed in the IPPM Framework document, RFC 2330 [2]. The reader should be familiar with these documents. This memo makes use of definitions of end-to-end One-way Delay Metrics defined in the RFC 2679 [4] to define metrics for aggregation and decomposition of end-to-end one-way delays measure. This memo makes use of definitions of end-to-end One-way Packet loss Metrics defined in the RFC 2680 [5] to define metrics for aggregation and decomposition of end-to-end one-way packet loss measure. The IPPM Framework consists in 4 major components: + A general framework for defining performance metrics, described in the Framework for IP Performance Metrics, RFC 2330; + A set of standardized metrics, which conform to this framework: - The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]; - The One-way Delay Metric for IPPM, RFC 2679 [4]; - The One-way Packet Loss Metric for IPPM, RFC 2680 [5]; - The Round-trip Delay Metric for IPPM, RFC 2681 [6]; - A Framework for Defining Empirical Bulk Transfer Capacity Metrics RFC 3148 [7]; - One-way Loss Pattern Sample Metrics, RFC 3357, [8]; - IP Packet Delay Variation Metric for IPPM, RFC 3393, [9]; Stephan Informational - Expires December 2003 [Page 2] Internet Draft Spatial metrics for IPPM June 2003 - Network performance measurement for periodic streams, RFC 3432, [10]. + Emerging metrics which are being specified in respect of this framework; + A One-way Active Measurement Protocol; + A registry and a Reporting MIB to exchange the results of the measures. The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-spatial-one-way- delay, will be introduced to measure the one-way delay between 2 consecutive hosts of an IP path. + Using this singleton metric, a 'sample', called Type-P-one-way- delay-trajectory, will be introduced to measure the sequence of Type- P-spatial-one-way-delay of the successive pair of hosts of the path. + Using this sample the end to end metric, called Type-P- aggregated-one-way-delay, is defined to measure the end to end delay. + Using the Type-P-one-way-delay metric, the Type-P-spatial-one- way-delay metric, the Type-P-aggregated-one-way-delay metric and the Type-P-asynchronous-aggregated-one-way-delay metric, a 'sample', called Type-P-asynchronous-one-way-delay-trajectory, will be introduced to measure the sequence of delays of a sequence of clouds of an IP path. + Using this sample the end to end metric, called Type-P- asynchronous-aggregated-one-way-delay, is defined to measure the end to end delay. + A 'singleton' analytic metric, called Type-P-spatial-packet- loss, will be introduced to measure the one-way packet loss between 2 consecutive hosts of an IP path. + Using this singleton metric, a 'sample', called Type-P-Spatial- packet-loss-stream, will be introduced to measure the sequence of Type-P-Spatial-packet-loss observed between 2 consecutive hosts of an IP path. Stephan Informational - Expires December 2003 [Page 3] Internet Draft Spatial metrics for IPPM June 2003 + Using this sample, a Type-P-Spatial-packet-loss-average, will be introduced to measure the average of loss of a Type-P-Spatial-packet- loss-stream. 2. Terminology 2.1. Spatial metric A metric is spatial if one of the hosts involved is neither the sender nor the destination of the measurement packet. 2.2. Asynchronous spatial metrics A spatial metric is named asynchronous if its definition involves different measurement packets. 2.3. Trajectory A trajectory is a sequence of hosts of an IP path. Each hop of the path may not be present in the sequence. 3. Motivation 3.1. Instantaneous end to end measure decomposition Decomposition of standard end-to-end measures is needed: + For locating delay consumption in a IP path; + For locating the loss of packets on an IP path; + For trajectory discovery; + For troubleshooting the network; + For designing and engineering the network; + For measuring the performance of a multicast network; + For controlling the performance of the inter domain services. These metrics have to be standardized not only to permit their results to be collected in the IPPM REPORTING MIB, but to provide passive measurement techniques with standard metric definitions and to permit integration of active and passive measurement techniques. 4. End-to-end measures aggregation The IPPM WG has designed metrics for measuring end-to-end performance. Today, there does not exit standardized IP measurement Stephan Informational - Expires December 2003 [Page 4] Internet Draft Spatial metrics for IPPM June 2003 packets to perform inter domain end-to-end measures. They may only be performed using aggregation of sequence of intra domain measure results. To permit interdomain end-to-end measure results aggregations there is a need to standardize spatial metrics + For delay aggregation; + For packet loss aggregation; + For jitter aggregation. These metrics have to be standardized to permit their results being collected in the IPPM REPORTING MIB. 5. Metrics for decomposition of end-to-end one way delay 5.1. Spatial one way delay 5.1.1. Metric Name Type-P-spatial-one-way-delay 5.1.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T0, a time. + T1,..., Tn a list of time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a path digest. 5.1.3. Metric Units The unit is the same as the singleton Type-P-One-way-Delay defined in [4]. The value of a Type-P-spatial-One-way-Delay is either a real number, or an undefined (informally, infinite) number of seconds. 5.1.4. Definition Stephan Informational - Expires December 2003 [Page 5] Internet Draft Spatial metrics for IPPM June 2003 Given a Type P packet sent by the source H0 at T0 to Hn in the path , given the sequence of time of arrival of the packets in , a Type-P-spatial-one-way-delay metric is defined for a hop of the path as following: For a real number dTi, the Type-P-spatial-one-way-delay from Hi to Hi+1 at Ti is dTi means that Hi saw the first bit of a Type-P packet to Hi+1 at wire-time Ti and that Hi+1 saw the last bit of that packet at wire-time Ti+dTi. 5.2. One way delay Trajectory metric 5.2.1. Metric Name Type-P-one-way-delay-trajectory 5.2.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T0, a time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a path digest. 5.2.3. Metric Units A sequence of time. 5.2.4. Definition Given a Type-P packet sent by the source H0 at T0 to Hn in the path , given the sequence of time of arrival of the packet in , a Type-P-one-way-delay-trajectory metric is defined as the sequence of the Type-P-spatial-one-way-delay values 5.3. Aggregated One way delay metric Stephan Informational - Expires December 2003 [Page 6] Internet Draft Spatial metrics for IPPM June 2003 5.3.1. Metric Name Type-P-aggregated-one-way-delay 5.3.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + T0, a time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a trajectory. 5.3.3. Metric Units A time. 5.3.4. Definition Given a Type-P-one-way-delay-trajectory metric value of the trajectory performed using a single measurement packet of type P sent at the time T0 by H0, a Type-P-aggregated-one- way-delay metric is defined as the sum of each term of the Type-P- one-way-delay-trajectory. 5.3.5. Discussion Consider a Type-P-aggregated-one-way-delay measure performed conjointly with a Type-P-one-way-delay measure. As these measures monitor the behavior of the same test packet their results should be identical. Practically these results will differ. 6. Metrics for aggregation of end-to-end one way delay 6.1. Asynchronous One way delay Trajectory metric 6.1.1. Metric Name Type-P-asynchronous-one-way-delay-trajectory 6.1.2. Metric Parameters + H0...Hn, the addresses of the hosts Stephan Informational - Expires December 2003 [Page 7] Internet Draft Spatial metrics for IPPM June 2003 + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + P, the specification of the packet type. 6.1.3. Metric Units A sequence of time. 6.1.4. Definition Given the hops , ... , given the Type-P-one- way-delay Ti from Hi to Hi+1 or the Type-P-spatial-one-way-delay Ti from Hi to Hi+1 or the Type-P-aggregated-one-way-delay Ti from Hi to Hi+1 or the Type-P-asynchronous-aggregated-one-way-delay Ti from Hi to Hi+1, a Type-P-asynchronous-one-way-delay-trajectory metric is defined as the sequence of the values . 6.2. Asynchronous Aggregated One way delay metric 6.2.1. Metric Name Type-P-asynchronous-aggregated-one-way-delay 6.2.2. Metric Parameters + T1,..., Tn a list of time. 6.2.3. Metric Units A time. 6.2.4. Definition Given a Type-P-asynchronous-one-way-delay-trajectory metric value, a Type-P-asynchronous-aggregated-one-way-delay metric is defined as the sum of each term of the Type-P-asynchronous- one-way-delay-trajectory. 7. Spatial metrics for One-way Packet Loss 7.1. Spatial one way packet loss 7.1.1. Metric Name Type-P-Spatial-packet-loss Stephan Informational - Expires December 2003 [Page 8] Internet Draft Spatial metrics for IPPM June 2003 7.1.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + i, An integer which ordered the hosts in the path. + Hi, exchange points of the path. + P, the specification of the packet type. + the path digest. 7.1.3. Metric Units The unit of Type-P-Spatial-packet-loss differs from the unit of Type- P-One-way-packet-loss defined in RFC 2680 [5]. The value of a Type-P-One-way-packet-loss is either zero (meaning that all the bits of the packet crossed Hi), or one (signifying the packet never crossed Hi). 7.1.4. Definition The Type-P-Spatial-packet-loss metric of a Type-P packet sent by H0 to Hn in the path is defined at the hop i as: A Type-P-Spatial-packet-loss value of zero at Hi indicates that all the bits of the packet crossed Hi+1. The Type-P-spatial-packet-loss value at Hi is one means the packet did not cross Hi+1. 7.1.5. Discussion Several issues may appear during the measure: + As by essence, the Internet does not guaranty that the path will not change during the measure, a packet may arrive to destination while not being metered by each host of the path. That occurs if the path changes after the configuration of the measure; + Duplicated packets may cross 2 or more times the same host; + Due to a lack of resources in a host, the packet may not be metered. 7.2. Samples for Spatial One-way Packet Loss Stephan Informational - Expires December 2003 [Page 9] Internet Draft Spatial metrics for IPPM June 2003 The definition does not make any assumption on the way the times of the measure were generated for the following reasons: + Using active measurement test packets are either sent using a pseudo-random Poisson time generator, either sent periodically, either sent in bursts. + Passive measurement captures packets sent by applications at arbitrary instants. 7.2.1. Metric Name Type-P-Spatial-packet-loss-stream 7.2.2. Metric Parameters + P, the specification of the packet type. + the path digest. + i, An integer which ordered the hosts in the path. + Hi, An host of the path. + Hi,Hi+1, Addresses of 2 consecutives hosts of the path. + T0, a time + Tf, a time + a list of time + T, an observation duration 7.2.3. Metric Units A sequence of couples where T is a time and L a Boolean. 7.2.4. Definition Given 2 consecutives hosts Hi and Hi+1, given a Type-P-Spatial- packet-loss performed from Hi to Hi+1 at instants during the duration T, we obtain a sequence of pairs of time, singleton of Type-P-Spatial-packet-loss. Type-P-Spatial-packet-loss-stream is defined as the resulting pairs. 7.3. Statistics for Spatial One-way Packet Loss 7.3.1. Type-P-Spatial-packet-loss-Average Stephan Informational - Expires December 2003 [Page 10] Internet Draft Spatial metrics for IPPM June 2003 Given the sample metric Type-P-Sample-packet-loss-Poisson-Stream, a Type-P-Spatial-packet-loss-Average is defined as the average of all the L values in the stream. 8. Applicability statements Spatial metric may be performed using either using active measurements techniques, either using passive measurements techniques or a combination of both. 9. Security Considerations Since this draft proposes sample metrics based on the One-way Delay singleton metric defined in RFC2679 and RFC2680 it inherits the security considerations mentioned in this RFC. 9.1. Privacy The privacy concerns in network measurement are intrinsically limited by the active measurements. Unlike passive measurements, there can be no release of existing user data. Measurement aspects Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it directly affects neither the security of the Internet nor the security of the applications running on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns. There are two types of security concerns: potential dysfunction caused by the measurements, and potential alteration of the measurements. The measurements could cause dysfunction because they are active, and inject packets into the network. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service. The measurements themselves could be altered by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement Stephan Informational - Expires December 2003 [Page 11] Internet Draft Spatial metrics for IPPM June 2003 methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. 10. Change since 00 Spatial packet loss metrics definitions added. 11. Acknowledgments 12. Author Addresses Emile STEPHAN France Telecom R & D 2 avenue Pierre Marzin F-22307 Lannion cedex Phone: (+ 33) 2 96 05 11 11 Email: emile.stephan@francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Stephan Informational - Expires December 2003 [Page 12] Internet Draft Spatial metrics for IPPM June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [6] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM.", RFC 2681, September 1999. [7] Mathis, G. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics.", RFC3148, July 2001. [8] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002. [9] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IPPM", RFC 3393, November 2002. [ [10]Raisanen,]] V., Grotefeld, G. and A. Morton, "Network performance measurement for periodic streams", RFC 3432, November 2002 Stephan Informational - Expires December 2003 [Page 13]