[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                  A.Morton,Editor
Internet Draft                                                AT&T Labs
Document: <draft-morton-ippm-composition-00.txt>
Category: Individual






                          Composition of Metrics


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

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of BCP 78.

   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.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo intends to define metrics that are applicable to both
   complete paths and sub-paths, where a corresponding relationship can
   be specified to compose the complete path metric from the sub-path
   metrics with sufficient accuracy.  The current memo gives some
   background and proposes wording for a Scope and Application section
   to define this new work. The description of an example metric and
   statistic follows.


Morton, et al.       Individual  exp. January 2006              Page 1
Composition of Metrics                                       July 2005


Contents

   Status of this Memo................................................1
   Copyright Notice...................................................1
   Abstract...........................................................1
   Authors/Contributors...............................................2
   1. Conventions used in this document...............................3
   2. Introduction....................................................3
   3. Proposed Scope and Application..................................4
   3.1  Scope of Work.................................................4
   3.2  Application...................................................4
   3.3  Measurement Points............................................5
   4. One-way Delay Composition Metrics and Statistics................5
   4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream......5
   4.1.1 Metric Parameters:...........................................5
   4.1.2 Definition:..................................................5
   4.1.3 Discussion and other details.................................6
   4.1.4 Mean Statistic...............................................6
   4.1.5 Composition Relationship: Sum of Mean Delays.................6
   4.1.6 Statement of Conjecture......................................6
   4.1.7 Justification for the composite relationship.................6
   4.1.8 Sources of Error.............................................6
   4.1.9 Specific cases where the conjecture might fail...............7
   4.1.10 Application of Measurement Methodology......................7
   5. Loss Metrics/Statistics.........................................7
   6. Delay Variation Metrics/Statistics..............................7
   7. Other Metrics/Statistics........................................7
   8. Security Considerations.........................................7
   8.1 Denial of Service Attacks......................................7
   8.2 User data confidentiality......................................8
   8.3 Interference with the metric...................................8
   9. IANA Considerations.............................................8
   10. Normative References...........................................8
   11. Informative References.........................................9
   12. Acknowledgments................................................9
   13. Author's Addresses.............................................9
   Full Copyright Statement..........................................10
   Intellectual Property.............................................10
   Acknowledgement...................................................10

Authors/Contributors

   Thus far, the following people have contributed useful ideas or
   suggestions 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>
   - Emile Stephan <emile.stephan@francetelecom.com>


Morton, et al.       Individual exp. January 2006               Page 2
Composition of Metrics                                       July 2005


1. Conventions used in this document

   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].
   Although RFC 2119 was written with protocols in mind, the key words
   are used in this document for similar reasons.  They are used to
   ensure the results of measurements from two different
   implementations are comparable, and to note instances when an
   implementation could perturb the network.

   In this memo, the characters "<=" should be read as "less than or
   equal to" and ">=" as "greater than or equal to".


2. Introduction

   The IPPM framework RFC 2330 [RFC2330] describes two forms of metric
   composition, spatial and temporal. Spatial composition encompasses
   the definitions of performance metrics that are applicable to the
   complete path, and to various sub-paths. Also, the text suggests
   that the concepts of the analytical framework (or A-frame) would
   help to define useful relationships between the complete path
   metrics and the sub-path metrics. 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:

   +  the specific conjecture applied to the metric,
   +  a justification of the practical utility of the composition in
      terms of making accurate measurements of the metric on the path,
   +  a justification of the usefulness of the composition in terms of
      making analysis of the path using A-frame concepts more
      effective, and
   +  an analysis of how the conjecture could be incorrect.

   RFC 2330 also 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 path without direct measurement, and the performance
   estimate of the complete path is related to the measured results for
   various sub-paths instead.

   Approximate relationships 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

Morton, et al.       Individual exp. January 2006               Page 3
Composition of Metrics                                       July 2005

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


3. Proposed Scope and Application

3.1  Scope of Work

   For the primary IPPM metrics (currently Loss, Delay, and Delay
   Variation), this memo gives a set of complete path metrics that can
   be composed from the same or similar sub-path metrics. This means
   that the complete path metric may be composed from:

   +  the same metric for each sub-path

   +  multiple metrics for each sub-path (possibly one that is the same
      as the complete path metric)

   +  a single sub-path metrics that is different from the complete
      path metric

   Each metric will clearly state:

   -  the definition (and statistic, where appropriate)

   -  the composition relationship

   -  the specific conjecture on which the relationship is based

   -  a justification of practical utility or usefulness for analysis
      using the A-frame concepts

   -  one or more examples of how the conjecture could be incorrect and
      lead to inaccuracy

3.2  Application

   For each metric, the applicable circumstances are defined, in terms
   of whether the composition:

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

   Needs information or access that will only be available within an
   operator's domain, or is applicable to Inter-domain composition.


Morton, et al.       Individual exp. January 2006               Page 4
Composition of Metrics                                       July 2005

   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  Measurement Points

   This section will define the terminology applicable to both complete
   path and sub-path metrics.

4. One-way Delay Composition Metrics and Statistics


4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream


4.1.1 Metric Parameters:

   +  Src, the IP address of a host

   +  Dst, the IP address of a host

   +  T, a time (start of test interval)

   +  Tf, a time (end of test interval)

   +  lambda, a rate in reciprocal seconds (for Poisson Streams)

   +  incT, the nominal duration of inter-packet interval, first bit to
      first bit (for Periodic Streams)

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

   +  TstampSrc, the wire time of the packet as measured at MP(Src)

   +  TstampDst, the wire time of the packet as measured at MP(Dst),
      assigned to packets that arrive within a "reasonable" time.

4.1.2 Definition:

   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, or infinite one-way delay):

   Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] =
                  FiniteDelay[i] = TstampDst - TstampSrc

Morton, et al.       Individual exp. January 2006               Page 5
Composition of Metrics                                       July 2005


4.1.3 Discussion and other details...

4.1.4 Mean Statistic

   +  L,  the total number of packets received at Dst (sent between T0
      and Tf)

   The

   Type-P-Finite-One-way-Delay-Mean =

              MeanDelay = (1/L)Sum(from i=1 to L, FiniteDelay[i])

   where all packets i= 1 through L have finite singleton delays.

4.1.5 Composition Relationship: Sum of Mean Delays

   The Type-P-Finite-One-way-Delay-Mean, or MeanDelay for the complete
   Source to Destination path can be calculated from sum of the Mean
   Delays of all its constituent sub-paths.

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 for the composite relationship

   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 Error

   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

Morton, et al.       Individual exp. January 2006               Page 6
Composition of Metrics                                       July 2005

   the complete path. Therefore, the sub-path measurements may differ
   from the performance experienced by packets on the complete path.
   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

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

   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/Statistics

6. Delay Variation Metrics/Statistics

7. Other Metrics/Statistics

8. 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).



Morton, et al.       Individual exp. January 2006               Page 7
Composition of Metrics                                       July 2005

   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 metric

   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

   Since this metric does not define a protocol or well-known values,
   there are no IANA considerations in this memo.

10. Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.
              Obtain via: http://www.rfc-editor.org/rfc/rfc791.txt

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.
              Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.
              Obtain via: http://www.rfc-editor.org/rfc/rfc2330.txt

Morton, et al.       Individual exp. January 2006               Page 8
Composition of Metrics                                       July 2005


   [RFC2679]  Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way
              delay metric for IPPM", RFC 2679, September 1999.
              Obtain via: http://www.rfc-editor.org/rfc/rfc2679.txt

   [RFC3148]  Mathis, M. and Allman, M., "A Framework for Defining
              Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
              2001.
              Obtain via: http://www.rfc-editor.org/rfc/rfc3148.txt

   [RFC3432]  Raisanen, V., Grotefeld, G., and Morton, A., "Network
              performance measurement with periodic streams", RFC 3432,
              November 2002.


11. Informative References


   [I.356]    ITU-T Recommendation I.356, "B-ISDN ATM layer cell
              transfer performance", March 2000.


   [Pax98]    V.Paxson, "Measurements and Analysis of End-to-End
              Internet Dynamics," Ph.D. dissertation, U.C. Berkeley,
              1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.


   [RFC3393]  Demichelis, C., and Chimento, P., "IP Packet Delay
              Variation Metric for IP Performance Metrics (IPPM)", RFC
              3393, November 2002.

   [Y.1540]   ITU-T Recommendation Y.1540, "Internet protocol data
              communication service - IP packet transfer and
              availability performance parameters", December 2002.




12. Acknowledgments

   The authors would like to acknowledge many helpful discussions with
   . . . (lots of people, eventually).

13. Author's Addresses

   Al Morton
   AT&T Labs
   Room D3 - 3C06
   200 Laurel Ave. South
   Middletown, NJ 07748 USA
   Phone  +1 732 420 1571
   EMail: <acmorton@att.com>

Morton, et al.       Individual exp. January 2006               Page 9
Composition of Metrics                                       July 2005


   Need addresses for:
   - Phil Chimento <vze275m9@verizon.net>
   - Reza Fardid <RFardid@Covad.COM>
   - Roman Krzanowski <roman.krzanowski@verizon.com>
   - Maurizio Molina <maurizio.molina@dante.org.uk>
   - Emile Stephan <emile.stephan@francetelecom.com>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

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

Acknowledgement



Morton, et al.       Individual exp. January 2006              Page 10
Composition of Metrics                                       July 2005

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















































Morton, et al.       Individual exp. January 2006              Page 11