draft-ietf-ippm-reporting-metrics-03.txt   draft-ietf-ippm-reporting-metrics-04.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft G. Ramachandran Internet-Draft G. Ramachandran
Intended status: Informational G. Maguluri Intended status: Informational G. Maguluri
Expires: December 30, 2010 AT&T Labs Expires: April 28, 2011 AT&T Labs
June 28, 2010 October 25, 2010
Reporting Metrics: Different Points of View Reporting Metrics: Different Points of View
draft-ietf-ippm-reporting-metrics-03 draft-ietf-ippm-reporting-metrics-04
Abstract Abstract
Consumers of IP network performance metrics have many different uses Consumers of IP network performance metrics have many different uses
in mind. The memo provides "long-term" reporting considerations in mind. The memo provides "long-term" reporting considerations
(e.g, days, weeks or months, as opposed to 10 seconds), based on (e.g, days, weeks or months, as opposed to 10 seconds), based on
analysis of the two key audience points-of-view. It describes how analysis of the two key audience points-of-view. It describes how
the audience categories affect the selection of metric parameters and the audience categories affect the selection of metric parameters and
options when seeking info that serves their needs. options when seeking info that serves their needs.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 30, 2010. This Internet-Draft will expire on April 28, 2011.
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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
5.1.4. Reordering . . . . . . . . . . . . . . . . . . . . . . 14 5.1.4. Reordering . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Preferred Statistics . . . . . . . . . . . . . . . . . . . 14 5.2. Preferred Statistics . . . . . . . . . . . . . . . . . . . 14
5.3. Summary for Delay . . . . . . . . . . . . . . . . . . . . 15 5.3. Summary for Delay . . . . . . . . . . . . . . . . . . . . 15
6. Effect of POV on Raw Capacity Metrics . . . . . . . . . . . . 15 6. Effect of POV on Raw Capacity Metrics . . . . . . . . . . . . 15
6.1. Type-P Parameter . . . . . . . . . . . . . . . . . . . . . 15 6.1. Type-P Parameter . . . . . . . . . . . . . . . . . . . . . 15
6.2. a priori Factors . . . . . . . . . . . . . . . . . . . . . 16 6.2. a priori Factors . . . . . . . . . . . . . . . . . . . . . 16
6.3. IP-layer Capacity . . . . . . . . . . . . . . . . . . . . 16 6.3. IP-layer Capacity . . . . . . . . . . . . . . . . . . . . 16
6.4. IP-layer Utilization . . . . . . . . . . . . . . . . . . . 17 6.4. IP-layer Utilization . . . . . . . . . . . . . . . . . . . 17
6.5. IP-layer Available Capacity . . . . . . . . . . . . . . . 17 6.5. IP-layer Available Capacity . . . . . . . . . . . . . . . 17
6.6. Variability in Utilization and Avail. Capacity . . . . . . 18 6.6. Variability in Utilization and Avail. Capacity . . . . . . 18
7. Test Streams and Sample Size . . . . . . . . . . . . . . . . . 18 7. Effect of POV on Restricted Capacity Metrics . . . . . . . . . 18
7.1. Test Stream Characteristics . . . . . . . . . . . . . . . 18 7.1. Type-P Parameter and Type-C Parameter . . . . . . . . . . 19
7.2. Sample Size . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. a priori Factors . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.3. Measurement Interval . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.4. Bulk Transfer Capacity Reporting . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Variability in Bulk Transfer Capacity . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Test Streams and Sample Size . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Test Stream Characteristics . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Sample Size . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
When designing measurements of IP networks and presenting the When designing measurements of IP networks and presenting the
results, knowledge of the audience is a key consideration. To results, knowledge of the audience is a key consideration. To
present a useful and relevant portrait of network conditions, one present a useful and relevant portrait of network conditions, one
must answer the following question: must answer the following question:
"How will the results be used?" "How will the results be used?"
skipping to change at page 4, line 44 skipping to change at page 4, line 44
The IPPM framework [RFC2330] and other RFCs describing IPPM metrics The IPPM framework [RFC2330] and other RFCs describing IPPM metrics
provide a background for this memo. provide a background for this memo.
2. Purpose and Scope 2. Purpose and Scope
The purpose of this memo is to clearly delineate two points-of-view The purpose of this memo is to clearly delineate two points-of-view
(POV) for using measurements, and describe their effects on the test (POV) for using measurements, and describe their effects on the test
design, including the selection of metric parameters and reporting design, including the selection of metric parameters and reporting
the results. the results.
The current scope of this memo primarily covers the design and The scope of this memo primarily covers the design and reporting of
reporting of the loss and delay metrics [RFC2680] [RFC2679]. It will the loss and delay metrics [RFC2680] [RFC2679]. It will also discuss
also discuss the delay variation [RFC3393] and reordering metrics the delay variation [RFC3393] and reordering metrics [RFC4737] where
[RFC4737] where applicable. applicable.
With capacity metrics growing in relevance to the industry, the memo With capacity metrics growing in relevance to the industry, the memo
also covers POV and reporting considerations for metrics resulting also covers POV and reporting considerations for metrics resulting
from the Bulk Transfer Capacity Framework [RFC3148] and Network from the Bulk Transfer Capacity Framework [RFC3148] and Network
Capacity Definitions [RFC5136]. These memos effectively describe two Capacity Definitions [RFC5136]. These memos effectively describe two
different categories of metrics, [RFC3148] with congestion flow- different categories of metrics,
control and the notion of unique data bits delivered, and [RFC5136]
using a definition of raw capacity without the restrictions of data o [RFC3148] with congestion flow-control and the notion of unique
uniqueness or congestion-awareness. It might seem at first glance data bits delivered, and
that each of these metrics has an obvious audience (Raw = Network
Characterization, Restricted = Application Performance), but reality o [RFC5136] using a definition of raw capacity without the
is more complex and consistent with the overall topic of capacity restrictions of data uniqueness or congestion-awareness.
measurement and reporting. For example, TCP is usually used in
Restricted capacity measurement methods, while UDP appears in Raw It might seem at first glance that each of these metrics has an
capacity measurement. The Raw and Restricted capacity metrics will obvious audience (Raw = Network Characterization, Restricted =
be treated in separate sections, although they share one common Application Performance), but reality is more complex and consistent
reporting issue: representing variability in capacity metric results. with the overall topic of capacity measurement and reporting. For
example, TCP is usually used in Restricted capacity measurement
methods, while UDP appears in Raw capacity measurement. The Raw and
Restricted capacity metrics will be treated in separate sections,
although they share one common reporting issue: representing
variability in capacity metric results as part of a long-term report.
Sampling, or the design of the active packet stream that is the basis Sampling, or the design of the active packet stream that is the basis
for the measurements, is also discussed. for the measurements, is also discussed.
3. Reporting Results 3. Reporting Results
This section gives an overview of recommendations, followed by This section gives an overview of recommendations, followed by
additional considerations for reporting results in the "long-term", additional considerations for reporting results in the "long-term",
based on the discussion and conclusions of the major sections that based on the discussion and conclusions of the major sections that
follow. follow.
skipping to change at page 16, line 30 skipping to change at page 16, line 30
ownership, for example), or some of the links in the path but not ownership, for example), or some of the links in the path but not
others, or none of the links. others, or none of the links.
There are cases where the measurement audience only has information There are cases where the measurement audience only has information
on one of the links (the local access link), and wishes to measure on one of the links (the local access link), and wishes to measure
one or more of the raw capacity metrics. This scenario is quite one or more of the raw capacity metrics. This scenario is quite
common, and has spawned a substantial number of experimental common, and has spawned a substantial number of experimental
measurement methods [ref to CAIDA survey page, etc.]. Many of these measurement methods [ref to CAIDA survey page, etc.]. Many of these
methods respect that their users want a result fairly quickly and in methods respect that their users want a result fairly quickly and in
a one-trial. Thus, the measurement interval is kept short (a few a one-trial. Thus, the measurement interval is kept short (a few
seconds to a minute). seconds to a minute). For long-term reporting, a sample of short
term results need to be summarized.
6.3. IP-layer Capacity 6.3. IP-layer Capacity
For links, this metric's theoretical maximum value can be determined For links, this metric's theoretical maximum value can be determined
from the physical layer bit rate and the bit rate reduction due to from the physical layer bit rate and the bit rate reduction due to
the layers between the physical layer and IP. When measured, this the layers between the physical layer and IP. When measured, this
metric takes additional factors into account, such as the ability of metric takes additional factors into account, such as the ability of
the sending device to process and forward traffic under various the sending device to process and forward traffic under various
conditions. For example, the arrival of routing updates may spawn conditions. For example, the arrival of routing updates may spawn
high priority processes that reduce the sending rate temporarily. high priority processes that reduce the sending rate temporarily.
skipping to change at page 18, line 28 skipping to change at page 18, line 28
measurements have come. measurements have come.
Two questions are raised here for further discussion: Two questions are raised here for further discussion:
What ways can Utilization be measured and summarized to describe the What ways can Utilization be measured and summarized to describe the
potential variability in a useful way? potential variability in a useful way?
How can the variability in Available Capacity estimates be reported, How can the variability in Available Capacity estimates be reported,
so that the confidence in the results is also conveyed? so that the confidence in the results is also conveyed?
7. Test Streams and Sample Size 7. Effect of POV on Restricted Capacity Metrics
This section describes the ways that restricted capacity metrics can
be tuned to reflect the preferences of the two audiences, or
different Points-of-View (POV). Raw capacity refers to the metrics
defined in [RFC3148] which include restrictions such as data
uniqueness or flow-control response to congestion.
In primary metric considered is Bulk Transfer Capacity (BTC) for
complete paths. [RFC3148] defines
BTC = data_sent / elapsed_time
for a connection with congestion-aware flow control, where data_sent
is the total of unique payload bits (no headers).
We note that this definition *differs* from the raw capacity
definition in Section 2.3.1 of [RFC5136], where IP-layer Capacity
*includes* all bits in the IP header and payload. This means that
Restricted Capacity BTC is already operating at a disadvantage when
compared to the raw capacity at layers below TCP. Further, there are
cases where "THE IP-layer" is encapsulated in another IP-layer or
other form of tunneling protocol, designating more and more of the
fundamental transport capacity as header bits that are pure overhead
to the BTC measurement.
When thinking about the triad of raw capacity metrics, BTC is most
akin to the "IP-Type-P Available Path Capacity", at least in the eyes
of a network user who seeks to know what transmission performance a
path might support.
7.1. Type-P Parameter and Type-C Parameter
The concept of "packets of type-P" is defined in [RFC2330]. The
considerations for Restricted Capacity are identical to the raw
capacity section on this topic, with the addition that the various
fields and options in the TCP header MUST be included in the
description.
The vast array of TCP flow control options are not well-captured by
Type-P, because they do not exist in the TCP header bits. Therefore,
we introduce a new notion here: TCP Configuration of "Type-C". The
elements of Type-C describe all of the settings for TCP options and
congestion control algorithm variables, including the main form of
congestion control in use.
7.2. a priori Factors
The audience for Network Characterization may have detailed
information about each link that comprises a complete path (due to
ownership, for example), or some of the links in the path but not
others, or none of the links.
There are cases where the measurement audience only has information
on one of the links (the local access link), and wishes to measure
one or more BTC metrics. This scenario is quite common, and has
spawned a substantial number of experimental measurement methods [ref
to CAIDA survey page, etc.]. Many of these methods respect that
their users want a result fairly quickly and in a one-trial. Thus,
the measurement interval is kept short (a few seconds to a minute).
For long-term reporting, a sample of short term results need to be
summarized.
7.3. Measurement Interval
There are limits on a useful measurement interval for BTC. Three
factors that influence the interval duration are listed below:
1. Measurements may choose to include or exclude the 3-way handshake
of TCP connection establishment, which requires at least 1.5 *
RTT and contains both the delay of the path and the host
processing time for responses. However, user experience includes
the 3-way handshake for all new TCP connections.
2. Measurements may choose to include or exclude Slow-Start,
preferring instead to focus on a portion of the transfer that
represents "equilibrium" <<<< which needs a definition for this
purpose >>>>. However, user experience includes the Slow-Start
for all new TCP connections.
3. Measurements may choose to use a fixed block of data to transfer,
where the size of the block has a relationship to the file size
of the application of interest. This approach yields variable
size measurement intervals, where a path faster BTC is measured
for less time than a slower path, an this has implications when
path impairments are time-varying, or transient. Users are
likely to turn their immediate attention elsewhere when a very
large file must be transferred, thus they do not directly
experience such a long transfer -- they see the result (success
or fail) and possibly an objective measurement of the transfer
time (which will likely include the 3-way handshake, Slow-start,
and application file management processing time as well as the
BTC).
Individual measurement intervals may be short or long, but there is a
need to report the results on a long-term basis that captures the BTC
variability experienced between each interval. Consistent BTC is a
valuable commodity along with the value attained.
7.4. Bulk Transfer Capacity Reporting
When BTC of a link or path is estimated through some measurement
technique, the following parameters SHOULD be reported:
o Name and reference to the exact method of measurement
o Maximum Transmission Unit (MTU)
o Maximum BTC that can be assessed in the measurement configuration
o The time and duration of the measurement
o The number of BTC connections used simultaneously
o *All* other parameters specific to the measurement method,
especially the Congestion Control algorithm in use
See also
[http://tools.ietf.org/wg/ippm/draft-ietf-ippm-tcp-throughput-tm/]
Many methods of Bulk Transfer Capacity measurement have a maximum
capacity that they can measure, and this maximum may be less than the
available capacity of the link or path. Therefore, it is important
to specify the measured BTC value beyond which there will be no
measured improvement.
The Application Design audience may have a target capacity value and
simply wish to assess whether there is sufficient BTC. This case
simplifies measurement of link and path capacity to some degree, as
long as the measurable maximum exceeds the target capacity.
7.5. Variability in Bulk Transfer Capacity
As with most metrics and measurements, assessing the consistency or
variability in the results gives a the user an intuitive feel for the
degree (or confidence) that any one value is representative of other
results, or the underlying distribution from which these singleton
measurements have come.
Two questions are raised here for further discussion:
What ways can BTC be measured and summarized to describe the
potential variability in a useful way?
How can the variability in BTC estimates be reported, so that the
confidence in the results is also conveyed?
8. Test Streams and Sample Size
This section discusses two key aspects of measurement that are This section discusses two key aspects of measurement that are
sometimes omitted from the report: the description of the test stream sometimes omitted from the report: the description of the test stream
on which the measurements are based, and the sample size. on which the measurements are based, and the sample size.
7.1. Test Stream Characteristics 8.1. Test Stream Characteristics
Network Characterization has traditionally used Poisson-distributed Network Characterization has traditionally used Poisson-distributed
inter-packet spacing, as this provides an unbiased sample. The inter-packet spacing, as this provides an unbiased sample. The
average inter-packet spacing may be selected to allow observation of average inter-packet spacing may be selected to allow observation of
specific network phenomena. Other test streams are designed to specific network phenomena. Other test streams are designed to
sample some property of the network, such as the presence of sample some property of the network, such as the presence of
congestion, link bandwidth, or packet reordering. congestion, link bandwidth, or packet reordering.
If measuring a network in order to make inferences about applications If measuring a network in order to make inferences about applications
or receiver performance, then there are usually efficiencies derived or receiver performance, then there are usually efficiencies derived
from a test stream that has similar characteristics to the sender. from a test stream that has similar characteristics to the sender.
In some cases, it is essential to synthesize the sender stream, as In some cases, it is essential to synthesize the sender stream, as
with Bulk Transfer Capacity estimates. In other cases, it may be with Bulk Transfer Capacity estimates. In other cases, it may be
sufficient to sample with a "known bias", e.g., a Periodic stream to sufficient to sample with a "known bias", e.g., a Periodic stream to
estimate real-time application performance. estimate real-time application performance.
7.2. Sample Size 8.2. Sample Size
Sample size is directly related to the accuracy of the results, and Sample size is directly related to the accuracy of the results, and
plays a critical role in the report. Even if only the sample size plays a critical role in the report. Even if only the sample size
(in terms of number of packets) is given for each value or summary (in terms of number of packets) is given for each value or summary
statistic, it imparts a notion of the confidence in the result. statistic, it imparts a notion of the confidence in the result.
In practice, the sample size will be selected taking both statistical In practice, the sample size will be selected taking both statistical
and practical factors into account. Among these factors are: and practical factors into account. Among these factors are:
1. The estimated variability of the quantity being measured 1. The estimated variability of the quantity being measured
skipping to change at page 19, line 33 skipping to change at page 22, line 35
4. etc. 4. etc.
A sample size may sometimes be referred to as "large". This is a A sample size may sometimes be referred to as "large". This is a
relative, and qualitative term. It is preferable to describe what relative, and qualitative term. It is preferable to describe what
one is attempting to achieve with their sample. For example, stating one is attempting to achieve with their sample. For example, stating
an implication may be helpful: this sample is large enough such that an implication may be helpful: this sample is large enough such that
a single outlying value at ten times the "typical" sample mean (the a single outlying value at ten times the "typical" sample mean (the
mean without the outlying value) would influence the mean by no more mean without the outlying value) would influence the mean by no more
than X. than X.
8. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
9. Security Considerations 10. Security Considerations
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656]. live networks are relevant here as well. See [RFC4656].
10. Acknowledgements 11. Acknowledgements
The authors thank: Phil Chimento for his suggestion to employ The authors thank: Phil Chimento for his suggestion to employ
conditional distributions for Delay, Steve Konish Jr. for his careful conditional distributions for Delay, Steve Konish Jr. for his careful
review and suggestions, Dave Mcdysan and Don McLachlan for useful review and suggestions, Dave Mcdysan and Don McLachlan for useful
comments based on their long experience with measurement and comments based on their long experience with measurement and
reporting. reporting, and Matt Zekauskas for suggestions on organizing the memo
for easier consumption.
11. References 12. References
11.1. Normative References 12.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.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999. Connectivity", RFC 2678, September 1999.
skipping to change at page 21, line 5 skipping to change at page 24, line 9
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, February 2008. RFC 5136, February 2008.
11.2. Informative References 12.2. Informative References
[Casner] "A Fine-Grained View of High Performance Networking, NANOG [Casner] "A Fine-Grained View of High Performance Networking, NANOG
22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May 22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May
20-22 2001. 20-22 2001.
[Cia03] "Standardized Active Measurements on a Tier 1 IP Backbone, [Cia03] "Standardized Active Measurements on a Tier 1 IP Backbone,
IEEE Communications Mag., pp 90-97.", June 2003. IEEE Communications Mag., pp 90-97.", June 2003.
[I-D.ietf-ippm-reporting] [I-D.ietf-ippm-reporting]
Shalunov, S. and M. Swany, "Reporting IP Performance Shalunov, S. and M. Swany, "Reporting IP Performance
Metrics to Users", draft-ietf-ippm-reporting-04 (work in Metrics to Users", draft-ietf-ippm-reporting-05 (work in
progress), July 2009. progress), July 2010.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009. Applicability Statement", RFC 5481, 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.
[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
availability performance parameters", December 2002. availability performance parameters", December 2002.
 End of changes. 18 change blocks. 
43 lines changed or deleted 202 lines changed or added

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