draft-ietf-ippm-rate-problem-02.txt   draft-ietf-ippm-rate-problem-03.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational February 1, 2013 Intended status: Informational April 24, 2013
Expires: August 5, 2013 Expires: October 26, 2013
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-02 draft-ietf-ippm-rate-problem-03
Abstract Abstract
There is a rate measurement scenario which has wide-spread attention This memo presents an access rate-measurement problem statement for
of Internet access subscribers and seemingly all industry players, test protocols to measure IP Performance Metrics. The rate
including regulators. This memo presents an access rate-measurement measurement scenario has wide-spread attention of Internet access
problem statement for test protocols to measure IP Performance subscribers and seemingly all industry players, including regulators.
Metrics. Key test protocol aspects require the ability to control Key test protocol aspects require the ability to control packet size
packet size on the tested path and enable asymmetrical packet size on the tested path and enable asymmetrical packet size testing in a
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 August 5, 2013. This Internet-Draft will expire on October 26, 2013.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5
4. Measurement Method Categories . . . . . . . . . . . . . . . . 7 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7
5. Test Protocol Control & Generation Requirements . . . . . . . 8 5. Test Protocol Control & Generation Requirements . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 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).
The access-rate scenario or use case has wide-spread attention of When selecting a form of access to the Internet, subscribers are
Internet access subscribers and seemingly all Internet industry interested in the performance characteristics of the various
players, including regulators. This problem is being approached with alternatives. Standardized measurements can be a basis for
many different measurement methods. This memo comparison between these alternatives. There is an underlying need
to coordinate measurements that support such comparisons, and test
control protocols to fulfill this need. The figure below depicts
some typical measurement points of access networks.
User ====== Fiber ======= Access Node \
Device ----- Copper ------- Access Node -|--- Infrastructure --- GW
or Host ------ Radio ------- Access Node /
The access-rate scenario or use case has received wide-spread
attention of Internet access subscribers and seemingly all Internet
industry players, including regulators. This problem is being
approached with many different measurement methods.
2. Purpose and Scope 2. Purpose and Scope
The scope and purpose of this memo is to define the measurement The scope and purpose of this memo is to define the measurement
problem statement for test protocols conducting access rate problem statement for test protocols conducting access rate
measurement on production networks. Relevant test protocols include measurement on production networks. Relevant test protocols include
[RFC4656] and [RFC5357]), but the problem is stated in a general way [RFC4656] and [RFC5357], but the problem is stated in a general way
so that it can be addressed by any existing test protocol, such as so that it can be addressed by any existing test protocol, such as
[RFC6812]. [RFC6812].
This memo discusses possibilities for methods of measurement, but This memo discusses possibilities for methods of measurement, but
does not specify exact methods which would normally be part of the does not specify exact methods which would normally be part of the
solution, not the problem. solution, not the problem.
We characterize the access rate measurement scenario as follows: We are interested in access measurement scenarios with the following
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 for which measured according to one or more standard metrics, and for which
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 defined in
[I-D.morton-ippm-lmap-path], possible measurement points include a [I-D.morton-ippm-lmap-path], possible measurement points include a
Subscriber's host (mp000), the access service demarcation point Subscriber's host, the access service demarcation point, Intra IP
(mp100), Intra IP access where a globally routable address is access where a globally routable address is present, or the
present (mp150), or the gateway between the measured access gateway between the measured access network and other networks.
network and other networks (mp190).
o Rates at the edge of the network are several orders of magnitude Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
less than aggregation and core portions. device Net #1 Net #2 Demarc. Access GW GRA GW
o Asymmetrical ingress and egress rates are prevalent. GRA = Globally Routable Address, GW = Gateway
o Rates at some links near the edge of the provider's network can
often be several orders of magnitude less links in than
aggregation and core portions of the network.
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.
Today, the majority of widely deployed access services achieve rates
less than 100 Mbit/s, and this is the order of magnitude for which a
solution is sought now.
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
device. device.
Other use cases for rate measurement involve situations where the Other use cases for rate measurement involve situations where the
packet switching and transport facilities are leased by one operator packet switching and transport facilities are leased by one operator
from another and the actual capacity available cannot be directly from another and the link capacity available cannot be directly
determined (e.g., from device interface utilization). These determined (e.g., from device interface utilization). These
scenarios could include mobile backhaul, Ethernet Service access scenarios could include mobile backhaul, Ethernet Service access
networks, and/or extensions of layer 2 or layer 3 networks. The networks, and/or extensions of layer 2 or layer 3 networks. The
results of rate measurements in such cases could be employed to results of rate measurements in such cases could be employed to
select alternate routing, investigate whether capacity meets some select alternate routing, investigate whether capacity meets some
previous agreement, and/or adapt the rate of traffic sources if a previous agreement, and/or adapt the rate of traffic sources if a
capacity bottleneck is found via the rate measurement. In the case capacity bottleneck is found via the rate measurement. In the case
of aggregated leased networks, available capacity may also be of aggregated leased networks, available capacity may also be
asymmetric. In these cases, the tester is assumed to have a sender asymmetric. In these cases, the tester is assumed to have a sender
and receiver location under their control. We refer to this scenario and receiver location under their control. We refer to this scenario
below as the aggregated leased network case. below as the aggregated leased network case.
Support of active measurement methods will be addressed here, Support of active measurement methods will be addressed here,
consistent with the IPPM working group's traditional charter. Active consistent with the IPPM working group's traditional charter. Active
measurements require synthetic traffic dedicated to testing, and do measurements require synthetic traffic dedicated to testing, and do
not use user traffic. not make measurements on user traffic.
The actual path used by traffic may influence the rate measurement As noted in [RFC2330] the actual traffic handling may influence the
results for some forms of access, as it may differ between user and rate measurement results for some forms of access, as it may differ
test traffic if the test traffic has different characteristics, between user and test traffic if the test traffic has different
primarily in terms of the packets themselves (the Type-P described in characteristics, primarily in terms of the packets themselves (see
[RFC2330]). section 13 of [RFC2330] for the considerations on packet type, or
Type-P).
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 directed to special treatment that may affect examined and selected for special treatment that may affect
transmission rates. The possibilities include: transmission rates. Without being exhaustive, the possibilities
include:
o Packet length o Packet length
o IP addresses used o IP addresses
o Transport protocol used (where TCP packets may be routed
differently from UDP)
o Transport Protocol port numbers used o Transport protocol (where TCP packets may be routed differently
from UDP)
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 the 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
multiple access instances, but discussion of this is beyond the multiple access instances, but treatment of this scenario is beyond
current scope. the current scope this document.
A key consideration is whether active measurements will be conducted A key consideration is whether active measurements will be conducted
with user traffic present (In-Service testing), or not present (Out- with user traffic present (In-Service testing), or not present (Out-
of-Service testing), such as during pre-service testing or of-Service testing), such as during pre-service testing or
maintenance that interrupts service temporarily. Out-of-Service maintenance that interrupts service temporarily. Out-of-Service
testing includes activities described as "service commissioning", testing includes activities described as "service commissioning",
"service activation", and "planned maintenance". Opportunistic In- "service activation", and "planned maintenance". Opportunistic In-
Service testing when there is no user traffic present throughout the Service testing when there is no user traffic present throughout the
test interval is essentially equivalent to Out-of-Service testing. test interval is essentially equivalent to Out-of-Service testing.
Both In-Service and Out-of-Service testing are within the scope of Both In-Service and Out-of-Service testing are within the scope of
this problem. this problem.
It is a non-goal to solve the measurement protocol specification It is a non-goal to solve the measurement protocol specification
problem in this memo. problem in this memo.
It is a non-goal to standardize methods of measurement in this memo. It is a non-goal to standardize methods of measurement in this memo.
However, the problem statement will mandate that support for one or However, the problem statement will mandate support for one or more
more categories of rate measurement methods and adequate control categories of rate measurement methods in the test protocol and
features for the methods in the test protocol. adequate control features for the methods in the control protocol
(assuming the control and test protocols are separate).
3. Active Rate Measurement 3. Active Rate Measurement
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.
Test coordination between source and destination devices through Coordination between source and destination devices through control
control messages and other basic capabilities described in the messages and other basic capabilities described in the methods of
methods of IPPM RFCs [RFC2679][RFC2680] are taken as given (these IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as
could be listed later, if desired). [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. One key tenet of IPPM methods is to minimize test traffic
effects on user traffic in the production network. Section 5 of effects on user traffic in the production network. Section 5 of
[RFC2680] lists the problems with high measurement traffic rates, and [RFC2680] lists the problems with high measurement traffic rates, and
the most relevant for rate measurement is the tendency for the most relevant for rate measurement is the tendency for
measurement traffic to skew the results, followed by the possibility measurement traffic to skew the results, followed by the possibility
of introducing congestion on the access link. Obviously, categories of introducing congestion on the access link. In-Service testing
of rate measurement methods that use less active test traffic than MUST respect these traffic constraints. Obviously, categories of
others with similar accuracy SHALL be preferred for In-Service rate measurement methods that use less active test traffic than
testing. 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 concerns 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
the categories of measurement methods required. For example, using the categories of measurement methods required. For example, using
the terminology of [RFC5136], a it may be possible to measure a Path the terminology of [RFC5136], a it may be possible to measure a Path
Capacity Metric while In-Service if the level of background (user) Capacity Metric while In-Service if the level of background (user)
traffic can be assessed and included in the reported result. traffic can be assessed and included in the reported result.
skipping to change at page 7, line 5 skipping to change at page 7, line 7
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 may be located elsewhere in the production
network, such as at one end of an aggregated leased network segment. network, such as at 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 other end of an end-user access or aggregated measurement at the receiving end of an access or aggregated leased
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. 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 The design of rate measurement methods can be divided into two
phases: test stream design and measurement (SENDER and RECEIVER), and phases: test stream design and measurement (SENDER and RECEIVER), and
a follow-up phase for analysis of the measurement to produce results a follow-up phase for analysis of the measurement to produce results
(REPORTER). The measurement protocol that addresses this problem (REPORTER). The measurement protocol that addresses this problem
MUST only serve the test stream generation and measurement functions. MUST only serve the test stream generation and measurement functions.
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). packet spacings (including zero spacing, meaning that back-to-
back burst ensembles and constant rate ensembles fall in this
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.
For all categories, the test protocol MUST support: For all categories, the test protocol MUST support:
1. Variable payload lengths among packet streams a. Variable payload lengths among packet streams
2. Variable length (in packets) among packet streams or ensembles b. Variable length (in packets) among packet streams or ensembles
3. Variable IP header markings among packet streams c. Variable IP header markings among packet streams
4. 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.
5. 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. be able to identify and control. The ability to revise these
variables during an established test session is OPTIONAL, as multiple
test sessions could serve the same purpose.
The test protocol SHALL support test packet ensemble generation The test protocol SHALL support test packet ensemble generation
(category 3), as this appears to minimize the demands on measurement (category 3), as this appears to minimize the demands on measurement
accuracy. Other stream generation categories are OPTIONAL. accuracy. Other stream generation categories are OPTIONAL.
>>>>>> For measurement systems employing TCP Transport protocol, the ability
to generate specific stream characteristics requires a sender with
Note: For measurement systems employing TCP Transport protocol, the the ability to establish and prime the connection such that 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.mathis-ippm-model-based-metrics].
>>>>>>
The general requirement statements needed to describe an "open-loop" The general requirement statements needed to describe an "open-loop"
TCP sender require some additional discussion. TCP sender require some additional discussion. It may be necessary
to defer specification of the details required to configure and
control a TCP SENDER for future work.
>>>>>>
It may also be useful to specify a control for Bulk Transfer Capacity It may also be useful to specify a control for Bulk Transfer Capacity
measurement with fully-specified TCP senders and receivers, as measurement with fully-specified TCP senders and receivers, as
envisioned in [RFC3148], but this would be a brute-force assessment envisioned in [RFC3148], but this would be a brute-force assessment
which does not follow the conservative tenets of IPPM measurement which does not follow the conservative tenets of IPPM measurement
[RFC2330]. [RFC2330].
>>>>>> >>>>>>
Measurements for each 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:
skipping to change at page 8, line 46 skipping to change at page 9, line 4
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 and/or pseudo-one-way test capability in a two-way
measurement architecture 4. Asymmetric packet size and/or pseudo-one-way test capability in a
two-way measurement architecture (along with symmetric packet
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
REQUIRED. REQUIRED. This allows both the conventional symmetric packet size
testing and asymmetrical packet size testing to employed to solve
various aspects of rate measurement: real-time communications often
have symmetrical streams, while file transfers have highly
asymmetrical streams in the data and acknowledgement traffic
directions.
The test protocol SHOULD enable measurement of the [RFC5136] Capacity The test protocol SHOULD enable measurement of the [RFC5136] Capacity
metric, either Out-of-Service, In-Service, or both. Other [RFC5136] metric, either Out-of-Service, In-Service, or both. Other [RFC5136]
metrics are OPTIONAL. metrics are OPTIONAL.
6. Security Considerations 6. 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] and live networks are relevant here as well. See [RFC4656] and
[RFC5357]. [RFC5357].
skipping to change at page 9, line 35 skipping to change at page 9, line 45
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 and implication on test traffic limits and protocols. Bill Cerveny,
Marcelo Bagnulo have contributed insightful, clarifying comments that Marcelo Bagnulo, and Kostas Pentikousis have contributed insightful,
made this a better draft. clarifying comments that made this a better draft.
9. Appendix
This Appendix was proposed to briefly summarize previous rate
measurement experience. (There is a large body of research on rate
measurement, so there is a question of what to include and what to
omit. Suggestions are welcome.)
10. References
10.1. Normative References 9. 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, "Framework for IP Performance Metrics", RFC 2330, May
May 1998. 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 49 skipping to change at page 10, line 46
(TWAMP)", RFC 5938, August 2010. (TWAMP)", RFC 5938, August 2010.
[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.
10.2. Informative References 9.2. Informative References
[I-D.mathis-ippm-model-based-metrics] [I-D.mathis-ippm-model-based-metrics]
Mathis, M., "Model Based Internet Performance Metrics", Mathis, M. and A. Morton, "Model Based Internet
draft-mathis-ippm-model-based-metrics-00 (work in Performance Metrics", draft-mathis-ippm-model-based-
progress), October 2012. metrics-01 (work in progress), February 2013.
[I-D.morton-ippm-lmap-path] [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-00 (work in progress), LMAP", draft-morton-ippm-lmap-path-01 (work in progress),
January 2013. February 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, Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
July 2001. 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. 52 change blocks. 
120 lines changed or deleted 140 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/