draft-ietf-ippm-rate-problem-03.txt   draft-ietf-ippm-rate-problem-04.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational April 24, 2013 Intended status: Informational September 19, 2013
Expires: October 26, 2013 Expires: March 23, 2014
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-03 draft-ietf-ippm-rate-problem-04
Abstract Abstract
This memo presents an access rate-measurement problem statement for This memo presents an access rate-measurement problem statement for
test protocols to measure IP Performance Metrics. The rate test protocols to measure IP Performance Metrics. The rate
measurement scenario has wide-spread attention of Internet access measurement scenario has wide-spread attention of Internet access
subscribers and seemingly all industry players, including regulators. subscribers and seemingly all industry players, including regulators.
Key test protocol aspects require the ability to control packet size Key test protocol aspects require the ability to control packet size
on the tested path and enable asymmetrical packet size testing in a on the tested path and enable asymmetrical packet size testing in a
controller-responder architecture. controller-responder architecture.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 26, 2013. This Internet-Draft will expire on March 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6
4. Measurement Method Categories . . . . . . . . . . . . . . . . 7 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7
5. Test Protocol Control & Generation Requirements . . . . . . . 8 5. Test Protocol Control & Generation Requirements . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
There are many possible rate measurement scenarios. This memo There are many possible rate measurement scenarios. This memo
describes one rate measurement problem and presents a rate- describes one rate measurement problem and presents a rate-
measurement problem statement for test protocols to measure IP measurement problem statement for test protocols to measure IP
Performance Metrics (IPPM). Performance Metrics (IPPM).
When selecting a form of access to the Internet, subscribers are When selecting a form of access to the Internet, subscribers are
interested in the performance characteristics of the various interested in the performance characteristics of the various
skipping to change at page 3, line 33 skipping to change at page 4, line 5
characteristics: characteristics:
o The Access portion of the network is the focus of this problem o The Access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with bi- statement. The user typically subscribes to a service with bi-
directional access partly described by rates in bits per second. directional access partly described by rates in bits per second.
The rates may be expressed as raw capacity or restricted capacity The rates may be expressed as raw capacity or restricted capacity
as described in [RFC6703]. These are the quantities that must be as described in [RFC6703]. These are the quantities that must be
measured according to one or more standard metrics, and for which measured according to one or more standard metrics, and for which
measurement methods must also be agreed as a part of the solution. measurement methods must also be agreed as a part of the solution.
o Referring to the reference path defined in o Referring to the reference path illustrated below and defined in
[I-D.morton-ippm-lmap-path], possible measurement points include a [I-D.ietf-ippm-lmap-path], possible measurement points include a
Subscriber's host, the access service demarcation point, Intra IP Subscriber's host, the access service demarcation point, Intra IP
access where a globally routable address is present, or the access where a globally routable address is present, or the
gateway between the measured access network and other networks. gateway between the measured access network and other networks.
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW
device Net #1 Net #2 Demarc. Access GW GRA GW
GRA = Globally Routable Address, GW = Gateway GRA = Globally Routable Address, GW = Gateway
o Rates at some links near the edge of the provider's network can o Rates at some links near the edge of the provider's network can
often be several orders of magnitude less links in than often be several orders of magnitude less than link rates in the
aggregation and core portions of the network. aggregation and core portions of the network.
o Asymmetrical access rates on ingress and egress are prevalent. o Asymmetrical access rates on ingress and egress are prevalent.
o Extremely large scale of access services requires low complexity o Extremely large scale of access services requires low complexity
devices participating at the user end of the path. devices participating at the user end of the path.
This problem statement assumes that the most-likely bottleneck device This problem statement assumes that the most-likely bottleneck device
or link is adjacent to the remote (user-end) measurement device, or or link is adjacent to the remote (user-end) measurement device, or
is within one or two router/switch hops of the remote measurement is within one or two router/switch hops of the remote measurement
skipping to change at page 4, line 49 skipping to change at page 5, line 15
There are several aspects of Type-P where user traffic may be There are several aspects of Type-P where user traffic may be
examined and selected for special treatment that may affect examined and selected for special treatment that may affect
transmission rates. Without being exhaustive, the possibilities transmission rates. Without being exhaustive, the possibilities
include: include:
o Packet length o Packet length
o IP addresses o IP addresses
o Transport protocol (where TCP packets may be routed differently o Transport protocol (e.g. where TCP packets may be routed
from UDP) differently from UDP)
o Transport Protocol port numbers o Transport Protocol port numbers
This issue requires further discussion when specific solutions/ This issue requires further discussion when specific solutions/
methods of measurement are proposed, but for this problem statement methods of measurement are proposed, but for this problem statement
it is sufficient to identify the problem and indicate that the it is sufficient to identify the problem and indicate that the
solution may require an extremely close emulation of user traffic, in solution may require an extremely close emulation of user traffic, in
terms of one or more factors above. terms of one or more factors above.
Although the user may have multiple instances of network access Although the user may have multiple instances of network access
available to them, the primary problem scope is to measure one form available to them, the primary problem scope is to measure one form
of access at a time. It is plausible that a solution for the single of access at a time. It is plausible that a solution for the single
access problem will be applicable to simultaneous measurement of access problem will be applicable to simultaneous measurement of
skipping to change at page 5, line 48 skipping to change at page 6, line 16
This section lists features of active measurement methods needed to This section lists features of active measurement methods needed to
measure access rates in production networks. measure access rates in production networks.
Coordination between source and destination devices through control Coordination between source and destination devices through control
messages and other basic capabilities described in the methods of messages and other basic capabilities described in the methods of
IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as
[RFC5357] and [RFC4656], are taken as given. [RFC5357] and [RFC4656], are taken as given.
Most forms of active testing intrude on user performance to some Most forms of active testing intrude on user performance to some
degree. One key tenet of IPPM methods is to minimize test traffic degree, especially In-Service testing. One key tenet of IPPM methods
effects on user traffic in the production network. Section 5 of is to minimize test traffic effects on user traffic in the production
[RFC2680] lists the problems with high measurement traffic rates, and network. Section 5 of [RFC2680] lists the problems with high
the most relevant for rate measurement is the tendency for measurement traffic rates, and the most relevant for rate measurement
measurement traffic to skew the results, followed by the possibility is the tendency for measurement traffic to skew the results, followed
of introducing congestion on the access link. In-Service testing by the possibility of introducing congestion on the access link. In-
MUST respect these traffic constraints. Obviously, categories of Service testing MUST respect these traffic constraints. Obviously,
rate measurement methods that use less active test traffic than categories of rate measurement methods that use less active test
others with similar accuracy are preferred for In-Service testing. traffic than others with similar accuracy are preferred for In-
Service testing.
On the other hand, Out-of-Service tests where the test path shares no On the other hand, Out-of-Service tests where the test path shares no
links with In-Service user traffic have none of the congestion or links with In-Service user traffic have none of the congestion or
skew concerns, but these tests must address other practical matters skew concerns, but these tests must address other practical matters
such as conducting measurements within a reasonable time from the such as conducting measurements within a reasonable time from the
tester's point of view. Out-of-Service tests where some part of the tester's point of view. Out-of-Service tests where some part of the
test path is shared with In-Service traffic MUST respect the In- test path is shared with In-Service traffic MUST respect the In-
Service constraints. Service constraints.
The **intended metrics to be measured** have strong influence over The **intended metrics to be measured** have strong influence over
skipping to change at page 6, line 43 skipping to change at page 7, line 11
measurements in both (one-way) directions of transmission (this measurements in both (one-way) directions of transmission (this
requirement is consistent with previous protocol specifications, and requirement is consistent with previous protocol specifications, and
it is not a unique problem for rate measurements). it is not a unique problem for rate measurements).
The following paragraphs describe features for the roles of test The following paragraphs describe features for the roles of test
packet SENDER, RECEIVER, and results REPORTER. packet SENDER, RECEIVER, and results REPORTER.
SENDER: SENDER:
Generate streams of test packets with various characteristics as Generate streams of test packets with various characteristics as
desired (see Section 4). The SENDER may be located at the user end desired (see Section 4). The SENDER MAY be located at the user end
of the access path, or may be located elsewhere in the production of the access path or elsewhere in the production network, such as at
network, such as at one end of an aggregated leased network segment. one end of an aggregated leased network segment.
RECEIVER: RECEIVER:
Collect streams of test packets with various characteristics (as Collect streams of test packets with various characteristics (as
described above), and make the measurements necessary to support rate described above), and make the measurements necessary to support rate
measurement at the receiving end of an access or aggregated leased measurement at the receiving end of an access or aggregated leased
network segment. network segment.
REPORTER: REPORTER:
Use information from test packets and local processes to measure Use information from test packets and local processes to measure
delivered packet rates, and prepare results in the required format. delivered packet rates, and prepare results in the required format.
4. Measurement Method Categories 4. Measurement Method Categories
The design of rate measurement methods can be divided into two A protocol that addresses the rate measurement problem MUST serve the
phases: test stream design and measurement (SENDER and RECEIVER), and test stream generation and measurement functions (SENDER and
a follow-up phase for analysis of the measurement to produce results RECEIVER). The follow-up phase of analyzing the measurement results
(REPORTER). The measurement protocol that addresses this problem to produce a report is outside the scope of this problem and memo
MUST only serve the test stream generation and measurement functions. (REPORTER).
For the purposes of this problem statement, we categorize the many For the purposes of this problem statement, we categorize the many
possibilities for rate measurement stream generation as follows; possibilities for rate measurement stream generation as follows;
1. Packet pairs, with fixed intra-pair packet spacing and fixed or 1. Packet pairs, with fixed intra-pair packet spacing and fixed or
random time intervals between pairs in a test stream. random time intervals between pairs in a test stream.
2. Multiple streams of packet pairs, with a range of intra-pair 2. Multiple streams of packet pairs, with a range of intra-pair
spacing and inter-pair intervals. spacing and inter-pair intervals.
3. One or more packet ensembles in a test stream, using a fixed 3. One or more packet ensembles in a test stream, using a fixed
ensemble size in packets and one or more fixed intra-ensemble ensemble size in packets and one or more fixed intra-ensemble
packet spacings (including zero spacing, meaning that back-to- packet spacings (including zero spacing, meaning that back-to-
back burst ensembles and constant rate ensembles fall in this back burst ensembles and constant rate ensembles fall in this
category). category).
4. One or more packet chirps, where intra-packet spacing typically 4. One or more packet chirps, where intra-packet spacing typically
decreases between adjacent packets in the same chirp and each decreases between adjacent packets in the same chirp and each
pair of packets represents a rate for testing purposes. pair of packets represents a rate for testing purposes.
The test protocol SHALL support test packet ensemble generation
(category 3), as this appears to minimize the demands on measurement
accuracy. Other stream generation categories are OPTIONAL.
For all categories, the test protocol MUST support: For all categories, the test protocol MUST support:
a. Variable payload lengths among packet streams a. Variable payload lengths among packet streams
b. Variable length (in packets) among packet streams or ensembles b. Variable length (in packets) among packet streams or ensembles
c. Variable IP header markings among packet streams c. Variable IP header markings among packet streams
d. Choice of UDP transport and variable port numbers, OR, choice of d. Choice of UDP transport and variable port numbers, OR, choice of
TCP transport and variable port numbers for two-way architectures TCP transport and variable port numbers for two-way architectures
only, OR BOTH. only, OR BOTH.
e. Variable number of packets-pairs, ensembles, or streams used in a e. Variable number of packets-pairs, ensembles, or streams used in a
test session test session
The items above are additional variables that the test protocol MUST The items above are additional variables that the test protocol MUST
be able to identify and control. The ability to revise these be able to identify and control. The ability to revise these
variables during an established test session is OPTIONAL, as multiple variables during an established test session is OPTIONAL, as multiple
test sessions could serve the same purpose. test sessions could serve the same purpose.
The test protocol SHALL support test packet ensemble generation For measurement systems employing TCP as the transport protocol, the
(category 3), as this appears to minimize the demands on measurement ability to generate specific stream characteristics requires a sender
accuracy. Other stream generation categories are OPTIONAL. with the ability to establish and prime the connection such that the
For measurement systems employing TCP Transport protocol, the ability
to generate specific stream characteristics requires a sender with
the ability to establish and prime the connection such that the
desired stream characteristics are allowed. See Mathis' work in desired stream characteristics are allowed. See Mathis' work in
progress for more background [I-D.mathis-ippm-model-based-metrics]. progress for more background [I-D.ietf-ippm-model-based-metrics].
>>>>>> Beyond simple connection handshake and options establishment, an
"open-loop" TCP sender requires the SENDER ability to:
The general requirement statements needed to describe an "open-loop" o generate TCP packets with well-formed headers (all fields valid),
TCP sender require some additional discussion. It may be necessary including Acknowledgement aspects.
to defer specification of the details required to configure and
control a TCP SENDER for future work.
>>>>>> o produce packet streams at controlled rates and variable inter-
packet spacings, including packet ensembles (back-to-back at
server rate).
It may also be useful to specify a control for Bulk Transfer Capacity o continue the configured sending stream characteristics despite all
measurement with fully-specified TCP senders and receivers, as control indications except receive window exhaust.
envisioned in [RFC3148], but this would be a brute-force assessment
which does not follow the conservative tenets of IPPM measurement
[RFC2330].
>>>>>> The corresponding TCP RECEIVER performs normally, having some ability
to configure the receive window sufficiently large so as to allow the
SENDER to transmit at will (up to a configured target).
It may also be useful to provide a control for Bulk Transfer Capacity
measurement with fully-specified (and congestion-controlled) TCP
senders and receivers, as envisioned in [RFC3148], but this would be
a brute-force assessment which does not follow the conservative
tenets of IPPM measurement [RFC2330].
Measurements for each UDP test packet transferred between SENDER and Measurements for each UDP test packet transferred between SENDER and
RECEIVER MUST be compliant with the singleton measurement methods RECEIVER MUST be compliant with the singleton measurement methods
described in IPPM RFCs [RFC2679][RFC2680] (these could be listed described in IPPM RFCs [RFC2679][RFC2680] (these could be listed
later, if desired). The time-stamp information or loss/arrival later, if desired). The time-stamp information or loss/arrival
status for each packet MUST be available for communication to the status for each packet MUST be available for communication to the
protocol entity that collects results. protocol entity that collects results.
5. Test Protocol Control & Generation Requirements 5. Test Protocol Control & Generation Requirements
Essentially, the test protocol MUST support the measurement features Essentially, the test protocol MUST support the measurement features
described in the sections above. This requires: described in the sections above. This requires:
1. Communicating all test variables to the Sender and Receiver 1. Communicating all test variables to the SENDER and RECEIVER
2. Results collection in a one-way architecture 2. Results collection in a one-way architecture
3. Remote device control for both one-way and two-way architectures 3. Remote device control for both one-way and two-way architectures
4. Asymmetric packet size and/or pseudo-one-way test capability in a 4. Asymmetric packet size and/or pseudo-one-way test capability in a
two-way measurement architecture (along with symmetric packet two-way measurement architecture (along with symmetric packet
size tests in common use) size tests in common use)
The ability to control packet size on the tested path and enable The ability to control packet size on the tested path and enable
asymmetrical packet size testing in a two-way architecture are asymmetrical packet size testing in a two-way architecture are
skipping to change at page 9, line 45 skipping to change at page 10, line 19
by unauthorized parties. by unauthorized parties.
7. IANA Considerations 7. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
8. Acknowledgements 8. Acknowledgements
Dave McDysan provided comments and text for the aggregated leased use Dave McDysan provided comments and text for the aggregated leased use
case. Yaakov Stein suggested many considerations to address, case. Yaakov Stein suggested many considerations to address,
including the In-Service vs. Out-of-Service distinction and its including the In-Service vs. Out-of-Service distinction and its
implication on test traffic limits and protocols. Bill Cerveny, implication on test traffic limits and protocols. Bill Cerveny,
Marcelo Bagnulo, and Kostas Pentikousis have contributed insightful, Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have
clarifying comments that made this a better draft. contributed insightful, clarifying comments that made this a better
draft.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[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, May "Framework for IP Performance Metrics", RFC 2330,
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.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
skipping to change at page 10, line 48 skipping to change at page 11, line 26
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010. Features", RFC 6038, October 2010.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012. RFC 6703, August 2012.
9.2. Informative References 9.2. Informative References
[I-D.mathis-ippm-model-based-metrics] [I-D.ietf-ippm-lmap-path]
Mathis, M. and A. Morton, "Model Based Internet
Performance Metrics", draft-mathis-ippm-model-based-
metrics-01 (work in progress), February 2013.
[I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-01 (work in progress), LMAP", draft-ietf-ippm-lmap-path-00 (work in progress),
February 2013. July 2013.
[I-D.ietf-ippm-model-based-metrics]
Mathis, M. and A. Morton, "Model Based Bulk Performance
Metrics", draft-ietf-ippm-model-based-metrics-00 (work in
progress), June 2013.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, July Empirical Bulk Transfer Capacity Metrics", RFC 3148,
2001. July 2001.
[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.
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare,
S., and E. Yedavalli, "Cisco Service-Level Assurance S., and E. Yedavalli, "Cisco Service-Level Assurance
Protocol", RFC 6812, January 2013. Protocol", RFC 6812, January 2013.
Author's Address Author's Address
 End of changes. 29 change blocks. 
79 lines changed or deleted 88 lines changed or added

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