draft-ietf-ippm-rate-problem-08.txt   draft-ietf-ippm-rate-problem-09.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational November 24, 2014 Intended status: Informational January 9, 2015
Expires: May 28, 2015 Expires: July 13, 2015
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-08 draft-ietf-ippm-rate-problem-09
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. Key rate
measurement scenario has wide-spread attention of Internet access measurement test protocol aspects include the ability to control
subscribers and seemingly all industry players, including regulators. packet characteristics on the tested path, such as asymmetric rate
Key test protocol aspects require the ability to control packet size and asymmetric packet size.
on the tested path and enable asymmetrical packet size testing in a
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
skipping to change at page 1, line 42 skipping to change at page 1, line 40
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 May 28, 2015. This Internet-Draft will expire on July 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 9 5. Test Protocol Control & Generation Requirements . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Operational Considerations . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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
alternatives. Standardized measurements can be a basis for alternatives. Standardized measurements can be a basis for
comparison between these alternatives. There is an underlying need comparison between these alternatives. There is an underlying need
to coordinate measurements that support such comparisons, and test to coordinate measurements that support such comparisons, and test
control protocols to fulfill this need. The figure below depicts control protocols to fulfill this need. The figure below depicts
some typical measurement points of access networks. some typical measurement points of access networks.
User ====== Fiber ======= Access Node \ User /====== Fiber ======= Access Node \
Device ----- Copper ------- Access Node -|--- Infrastructure --- GW Device -|------ Copper ------- Access Node -|-- Infrastructure -- GW
or Host ------ Radio ------- Access Node / or Host \------ Radio ------- Access Node /
The access-rate scenario or use case has received wide-spread The access-rate scenario or use case has received wide-spread
attention of Internet access subscribers and seemingly all Internet attention of Internet access subscribers and seemingly all Internet
industry players, including regulators. This problem is being industry players, including regulators. This problem is being
approached with many different measurement methods. 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
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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, This memo describes protocol support for active measurement methods,
consistent with the IPPM working group's traditional charter. Active consistent with the IPPM working group's traditional charter. Active
measurements require synthetic traffic streams dedicated to testing, measurements require synthetic traffic streams dedicated to testing,
and do not make measurements on user traffic. See section 2 of and do not make measurements on user traffic. See section 2 of
[RFC2679], where the concept of a stream is first introduced in IPPM [RFC2679], where the concept of a stream is first introduced in IPPM
literature as the basis for collecting a sample (defined in section literature as the basis for collecting a sample (defined in section
11 of [RFC2330]). 11 of [RFC2330]).
As noted in [RFC2330] the focus of access traffic management may As noted in [RFC2330] the focus of access traffic management may
influence the rate measurement results for some forms of access, as influence the rate measurement results for some forms of access, as
it may differ between user and test traffic if the test traffic has it may differ between user and test traffic if the test traffic has
skipping to change at page 5, line 32 skipping to change at page 5, line 32
"service activation", and "planned maintenance". Opportunistic In- "service activation", and "planned maintenance". Opportunistic In-
Service testing when there is no user traffic present (e.g., outside Service testing when there is no user traffic present (e.g., outside
normal business hours) throughout the test interval is essentially normal business hours) throughout the test interval is essentially
equivalent to Out-of-Service testing. Both In-Service and Out-of- equivalent to Out-of-Service testing. Both In-Service and Out-of-
Service testing are within the scope of this problem. Service testing are within the scope of 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 support for one or more However, the problem statement mandates support for one category of
categories of rate measurement methods in the test protocol and rate measurement methods in the test protocol and adequate control
adequate control features for the methods in the control protocol features for the methods in the control protocol (assuming the
(assuming the control and test protocols are separate). 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.
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, especially In-Service testing. One key tenet of IPPM methods degree, especially In-Service testing. One key tenet of IPPM methods
is to minimize test traffic effects on user traffic in the production is to minimize test traffic effects on user traffic in the production
network. Section 5 of [RFC2680] lists the problems with high network. Section 5 of [RFC2680] lists the problems with high
measurement traffic rates, and the most relevant for rate measurement measurement traffic rates ("too much traffic"), and the most relevant
is the tendency for measurement traffic to skew the results, followed for rate measurement is the tendency for measurement traffic to skew
by the possibility of introducing congestion on the access link. In- the results, followed by the possibility of introducing congestion on
Service testing MUST respect these traffic constraints. Obviously, the access link. Section 4 of [RFC3148] provides additional
categories of rate measurement methods that use less active test considerations. The user of protocols for In-Service testing MUST
traffic than others with similar accuracy are preferred for In- respect these traffic constraints. Obviously, categories of rate
Service testing. measurement methods that use less active test traffic than others
with similar accuracy are preferred for In-Service testing, and the
specifications of this memo encourage traffic reduction through
asymmetric control capabilities.
On the other hand, Out-of-Service tests where the test path shares no Out-of-Service tests where the test path shares no links with In-
links with In-Service user traffic have none of the congestion or Service user traffic, have none of the congestion or skew concerns.
skew concerns, but these tests must address other practical matters Both types should address practical matters common to all test
such as conducting measurements within a reasonable time from the efforts, such as conducting measurements within a reasonable time
tester's point of view. Out-of-Service tests where some part of the from the tester's point of view, and ensuring that timestamp accuracy
test path is shared with In-Service traffic MUST respect the In- is consistent with the precision needed for measurement [RFC2330].
Service constraints. Out-of-Service tests where some part of the test path is shared with
In-Service traffic MUST respect the In-Service constraints described
above.
The intended metrics to be measured have strong influence over the 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], it may be possible to measure a Path terminology of [RFC5136], 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.
The measurement *architecture* MAY be either of one-way (e.g., The measurement *architecture* MAY be either of one-way (e.g.,
[RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity
aspects of end-user or aggregated access measurement clearly favor aspects of end-user or aggregated access measurement clearly favor
two-way (with low-complexity user-end device and round-trip results two-way (with low-complexity user-end device and round-trip results
collection, as found in [RFC5357]). However, the asymmetric rates of collection, as found in [RFC5357]). However, the asymmetric rates of
many access services mean that the measurement system MUST be able to many access services mean that the measurement system MUST be able to
evaluate performance in each direction of transmission. In the two- evaluate performance in each direction of transmission. In the two-
way architecture, it is expected that both end devices MUST include way architecture, both end devices MUST include the ability to launch
the ability to launch test streams and collect the results of test streams and collect the results of measurements in both (one-
measurements in both (one-way) directions of transmission (this way) directions of transmission (this requirement is consistent with
requirement is consistent with previous protocol specifications, and previous protocol specifications, and it is not a unique problem for
it is not a unique problem for rate measurements). 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 elsewhere in the production network, such as at of the access path or elsewhere in the production network, such as at
one end of an aggregated leased network segment. one end of an aggregated leased network segment.
skipping to change at page 7, line 38 skipping to change at page 7, line 43
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 (a set of packets with specified 4. One or more packet chirps (a set of packets with specified
characteristics), where intra-packet spacing typically decreases characteristics), where inter-packet spacing typically decreases
between adjacent packets in the same chirp and each pair of between adjacent packets in the same chirp and each pair of
packets represents a rate for testing purposes. packets represents a rate for testing purposes.
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 all categories, the test protocol MUST support: For all supported categories, the following is a list of additional
variables that the protocol(s) MUST be able to specify, control, and
generate:
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. See below for additional requirements on TCP only, OR BOTH. See below for additional requirements on TCP
transport generation. transport generation.
e. Variable number of packets-pairs, ensembles, or streams used in a e. Variable number of packet-pairs, ensembles, or streams used in a
test session. test session.
The items above are additional variables that the test protocol MUST The ability to revise these variables during an established test
be able to identify and control. The ability to revise these session is OPTIONAL, as multiple test sessions could serve the same
variables during an established test session is OPTIONAL, as multiple purpose. Another OPTIONAL feature is the ability to generate streams
test sessions could serve the same purpose. Another OPTIONAL feature with VLAN tags and other markings.
is the ability to generate streams with VLAN tags and other markings.
For measurement systems employing TCP as the transport protocol, the For measurement systems employing TCP as the transport protocol, the
ability to generate specific stream characteristics requires a sender ability to generate specific stream characteristics requires a sender
with the ability to establish and prime the connection such that the 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.ietf-ippm-model-based-metrics]. progress for more background [I-D.ietf-ippm-model-based-metrics].
Beyond simple connection handshake and options establishment, an Beyond simple connection handshake and options establishment, an
"open-loop" TCP sender requires the SENDER ability to: "open-loop" TCP sender requires the SENDER ability to:
skipping to change at page 8, line 43 skipping to change at page 8, line 51
packet spacings, including packet ensembles (back-to-back at packet spacings, including packet ensembles (back-to-back at
server rate). server rate).
o continue the configured sending stream characteristics despite all o continue the configured sending stream characteristics despite all
control indications except receive window exhaust. control indications except receive window exhaust.
The corresponding TCP RECEIVER performs normally, having some ability The corresponding TCP RECEIVER performs normally, having some ability
to configure the receive window sufficiently large so as to allow the to configure the receive window sufficiently large so as to allow the
SENDER to transmit at will (up to a configured target). SENDER to transmit at will (up to a configured target).
It may also be useful to provide a control for Bulk Transfer Capacity It may also be useful (for diagnostic purposes) to provide a control
measurement with fully-specified (and congestion-controlled) TCP for Bulk Transfer Capacity measurement with fully-specified (and
senders and receivers, as envisioned in [RFC3148], but this would be congestion-controlled) TCP senders and receivers, as envisioned in
a brute-force assessment which does not follow the conservative [RFC3148], but this would be a brute-force assessment which does not
tenets of IPPM measurement [RFC2330]. 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]. The time-stamp
later, if desired). The time-stamp information or loss/arrival information or loss/arrival status for each packet MUST be available
status for each packet MUST be available for communication to the for communication to the REPORTER function.
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 In summary, 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 coordinated one-way test 4. Asymmetric packet rates in a two-way measurement architecture, or
capabilities in a two-way measurement architecture (along with coordinated one-way test capabilities with the same effect
symmetric packet size tests in common use) (asymmetric rates may be achieved through directional control of
packet rate or packet size)
The ability to control and generate asymmetric rates in a two-way The ability to control and generate asymmetric rates in a two-way
architecture is REQUIRED. Two-way architectures are RECOMMENDED to architecture is REQUIRED. Two-way architectures are RECOMMENDED to
include control and generation capability for both asymmetric and include control and generation capability for both asymmetric and
symmetric packet sizes, because packet size often matters in the symmetric packet sizes, because packet size often matters in the
scope of this problem and test systems SHOULD be equipped to detect scope of this problem and test systems SHOULD be equipped to detect
directional size dependency through comparative measurements. directional size dependency through comparative measurements.
Asymmetric packet size control is indicated when the result of a Asymmetric packet size control is indicated when the result of a
measurement may depend on the size of the packets used in each measurement may depend on the size of the packets used in each
skipping to change at page 10, line 5 skipping to change at page 10, line 12
o there is a link in the path where transmission in one direction o there is a link in the path where transmission in one direction
influences performance in the opposite direction, influences performance in the opposite direction,
o there is a device in the path where transmission capacity depends o there is a device in the path where transmission capacity depends
on packet header processing capacity (in other words, the capacity on packet header processing capacity (in other words, the capacity
is sensitive to packet size), is sensitive to packet size),
o the target application stream is nominally MTU size packets in one o the target application stream is nominally MTU size packets in one
direction vs. ACK stream in the other, (noting that there are a direction vs. ACK stream in the other, (noting that there are a
vanishing number of symmetrical-rate application streams for which vanishing number of symmetrical-rate application streams for which
rate measurement is wanted or interesting), rate measurement is wanted or interesting, but such streams might
have some relevance at this time),
o the distribution of packet losses is critical to rate assessment, o the distribution of packet losses is critical to rate assessment,
and possibly other circumstances revealed by measurements comparing and possibly other circumstances revealed by measurements comparing
streams with symmetrical size and asymmetrical size. streams with symmetrical size and asymmetrical size.
Implementations may support control and generation for only symmetric Implementations may support control and generation for only symmetric
packet sizes when none of the above conditions hold. packet sizes when none of the above conditions hold.
The test protocol SHOULD enable measurement of the [RFC5136] Capacity The test protocol SHOULD enable measurement of the [RFC5136] Capacity
skipping to change at page 10, line 31 skipping to change at page 10, line 39
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].
There may be a serious issue if a proprietary Service Level Agreement There may be a serious issue if a proprietary Service Level Agreement
involved with the access network segment provider were somehow leaked involved with the access network segment provider were somehow leaked
in the process of rate measurement. To address this, test protocols in the process of rate measurement. To address this, test protocols
SHOULD NOT convey this information in a way that could be discovered SHOULD NOT convey this information in a way that could be discovered
by unauthorized parties. by unauthorized parties.
7. IANA Considerations 7. Operational Considerations
All forms of testing originate traffic on the network, through their
communications for control and results collection, or from dedicated
measurement packet streams, or both. Testing traffic primarily falls
in one of two categories, subscriber traffic or network management
traffic. There is an on-going need to engineer networks so that
various forms of traffic are adequately served, and publication of
this memo does not change this need. Service subscribers and
authorized users SHOULD obtain their network operator's or service
provider's permission before conducting tests. Likewise, a service
provider or third party SHOULD obtain the subscriber's permission to
conduct tests, since they might temporarily reduce service quality.
Subscribers, their service providers and network operators, and
sometimes third parties, all seek to measure network performance.
Capacity testing with active traffic often affects the packet
transfer performance of streams traversing shared components of the
test path, to some degree. The degradation can be minimized by
scheduling such tests infrequently, and restricting the amount of
measurement traffic required to assess capacity metrics. As a
result, occasional short-duration estimates with minimal traffic are
preferred to measurements based on frequent file transfers of many
Megabytes with similar accuracy. New measurement methodologies
intended for standardization should be evaluated individually for
potential operational issues. However, the scheduled frequency of
testing is as important as the methods used (and schedules are not
typically submitted for standardization).
The new test protocol feature of asymmetrical packet size generation
in two-way testing is recommended in this memo. It can appreciably
reduce the load and packet processing demands of each test and
therefore reduce the likelihood of degradation in one direction of
the tested path. Current IETF standardized test protocols do not
possess the asymmetric size generation capability with two-way
testing.
8. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
8. Acknowledgements 9. 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 (a persistent reviewer) have Marcelo Bagnulo, Kostas Pentikousis (a persistent reviewer), and
contributed insightful, clarifying comments that made this a better Joachim Fabini have contributed insightful, clarifying comments that
draft. Barry Constantine also provided suggestions for made this a better draft. Barry Constantine also provided
clarification. suggestions for clarification.
9. References 10. References
9.1. Normative References
10.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, May "Framework for IP Performance Metrics", RFC 2330, 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.
skipping to change at page 11, line 31 skipping to change at page 12, line 23
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008. RFC 5357, October 2008.
[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 10.2. Informative References
[I-D.ietf-ippm-lmap-path] [I-D.ietf-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
Large-Scale Measurement of Broadband Performance", draft- Large-Scale Measurement of Broadband Performance", draft-
ietf-ippm-lmap-path-07 (work in progress), October 2014. ietf-ippm-lmap-path-07 (work in progress), October 2014.
[I-D.ietf-ippm-model-based-metrics] [I-D.ietf-ippm-model-based-metrics]
Mathis, M. and A. Morton, "Model Based Bulk Performance Mathis, M. and A. Morton, "Model Based Bulk Performance
Metrics", draft-ietf-ippm-model-based-metrics-03 (work in Metrics", draft-ietf-ippm-model-based-metrics-03 (work in
 End of changes. 27 change blocks. 
74 lines changed or deleted 119 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/