draft-ietf-ippm-spatial-composition-12.txt   draft-ietf-ippm-spatial-composition-13.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track E. Stephan Intended status: Standards Track E. Stephan
Expires: December 1, 2010 France Telecom Division R&D Expires: December 27, 2010 France Telecom Division R&D
May 30, 2010 June 25, 2010
Spatial Composition of Metrics Spatial Composition of Metrics
draft-ietf-ippm-spatial-composition-12 draft-ietf-ippm-spatial-composition-13
Abstract Abstract
This memo utilizes IP Performance Metrics that are applicable to both This memo utilizes IP Performance 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 complete path metric from the sub-path metrics with some accuracy
w.r.t. the actual metrics. This is called Spatial Composition in RFC w.r.t. the actual metrics. This is called Spatial Composition in RFC
2330. The memo refers to the Framework for Metric Composition, and 2330. The memo refers to the Framework for Metric Composition, and
provides background and motivation for combining metrics to derive provides background and motivation for combining metrics to derive
others. The descriptions of several composed metrics and statistics others. The descriptions of several composed metrics and statistics
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 1, 2010. This Internet-Draft will expire on December 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 4, line 39 skipping to change at page 4, line 39
7.1.7. Justification of the Composition Function . . . . . . 22 7.1.7. Justification of the Composition Function . . . . . . 22
7.1.8. Sources of Deviation from the Ground Truth . . . . . . 23 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 23
7.1.9. Specific cases where the conjecture might fail . . . . 23 7.1.9. Specific cases where the conjecture might fail . . . . 23
7.1.10. Application of Measurement Methodology . . . . . . . . 23 7.1.10. Application of Measurement Methodology . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23
8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 23 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 23
8.3. Interference with the metrics . . . . . . . . . . . . . . 24 8.3. Interference with the metrics . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 24
11. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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@cariden.com>
- Roman Krzanowski <roman.krzanowski@verizon.com> - Roman Krzanowski <roman.krzanowski@verizon.com>
- Maurizio Molina <maurizio.molina@dante.org.uk> - Maurizio Molina <maurizio.molina@dante.org.uk>
- Lei Liang <L.Liang@surrey.ac.uk> - Lei Liang <L.Liang@surrey.ac.uk>
- Dave Hoeflin <dhoeflin@att.com> - Dave Hoeflin <dhoeflin@att.com>
2. Introduction 2. Introduction
skipping to change at page 24, line 26 skipping to change at page 24, line 26
may distort the measured performance. It may also be possible to may distort the measured performance. It may also be possible to
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 IETF are typically registered in the IANA IPPM
METRICS REGISTRY as described in initial version of the registry METRICS REGISTRY as described in initial version of the registry
[RFC4148]. [RFC4148]. However, areas for improvement of this registry have been
identified, and the registry structure has to be revisited when there
is consensus to do so.
Therefore, the metrics in this draft may be considered for
registration in the future, and no IANA Action is requested at this
time.
10. Acknowlegements 10. Acknowlegements
A long time ago, in a galaxy far, far away (Minneapolis), Will Leland A long time ago, in a galaxy far, far away (Minneapolis), Will Leland
suggested the simple and elegant Type-P-Finite-One-way-Delay concept. suggested the simple and elegant Type-P-Finite-One-way-Delay concept.
Thanks Will. Thanks Will.
Yaakov Stein and Donald McLachlan also provided useful comments along Yaakov Stein and Donald McLachlan also provided useful comments along
the way. the way.
11. Issues (Open and Closed) 11. References
11.1. Normative References
This section to be removed at publication.
>>>>>>>>>>>>Issue:
Is Section 4.1.8.4 really describing a new error case, about
Alternate Routing? Or does Section 4.1.8.1 on sub-path differences
cover it all?
RESOLUTION: The section was re-worded in -10 version to make the
topic, Absence of a real Route between the Src and Dst, more clear.
>>>>>>>>>>>>
>>>>>>>>>>>>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 separate memo
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Issue
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
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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Issue
Can we 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: No and Yes.
12. Acknowledgements
13. References
13.1. Normative References
[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 26, line 45 skipping to change at page 25, line 30
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005. Registry", BCP 108, RFC 4148, August 2005.
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010. Composition", RFC 5835, April 2010.
13.2. Informative References 11.2. Informative References
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644, Metrics (IPPM): Spatial and Multicast", RFC 5644,
October 2009. October 2009.
[Stats] McGraw-Hill NY NY, "Introduction to the Theory of [Stats] McGraw-Hill NY NY, "Introduction to the Theory of
Statistics, 3rd Edition,", 1974. Statistics, 3rd Edition,", 1974.
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data
communication service - IP packet transfer and communication service - IP packet transfer and
 End of changes. 10 change blocks. 
91 lines changed or deleted 25 lines changed or added

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