draft-ietf-ippm-rate-problem-07.txt   draft-ietf-ippm-rate-problem-08.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational October 7, 2014 Intended status: Informational November 24, 2014
Expires: April 10, 2015 Expires: May 28, 2015
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-07 draft-ietf-ippm-rate-problem-08
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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2015. This Internet-Draft will expire on May 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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 than link rates in the 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 In many scenarios of interest, extremely large scale of access o In many scenarios of interest, extremely large scale of access
services requires low complexity devices participating at the user services requires low complexity devices participating at the user
end of the path. end of the path, and those devices place limits on clock and
control timing accuracy.
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 link 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
skipping to change at page 4, line 24 skipping to change at page 4, line 24
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 streams dedicated to testing,
not make measurements on user traffic. and do not make measurements on user traffic. See section 2 of
[RFC2679], where the concept of a stream is first introduced in IPPM
literature as the basis for collecting a sample (defined in section
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
different characteristics, primarily in terms of the packets different characteristics, primarily in terms of the packets
themselves (see section 13 of [RFC2330] for the considerations on themselves (see section 13 of [RFC2330] for the considerations on
packet type, or Type-P). 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 selected for special treatment that may affect examined and selected for special treatment that may affect
skipping to change at page 6, line 16 skipping to change at page 6, line 19
Service testing. 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 the
the categories of measurement methods required. For example, using categories of measurement methods required. For example, using the
the terminology of [RFC5136], a 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-
skipping to change at page 7, line 35 skipping to change at page 7, line 37
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 (a set of packets with specified
decreases between adjacent packets in the same chirp and each characteristics), where intra-packet spacing typically decreases
pair of packets represents a rate for testing purposes. between adjacent packets in the same chirp and each pair of
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 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
skipping to change at page 9, line 16 skipping to change at page 9, line 19
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 coordinated one-way test
two-way measurement architecture (along with symmetric packet capabilities in a two-way measurement architecture (along with
size tests in common use) symmetric packet size tests in common use)
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 11, line 29 skipping to change at page 11, line 37
[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.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-06 (work in progress), September 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
progress), July 2014. progress), July 2014.
[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, July
2001. 2001.
 End of changes. 11 change blocks. 
19 lines changed or deleted 24 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/