draft-ietf-ippm-rate-problem-09.txt   draft-ietf-ippm-rate-problem-10.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational January 9, 2015 Intended status: Informational February 5, 2015
Expires: July 13, 2015 Expires: August 9, 2015
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement and Requirements
draft-ietf-ippm-rate-problem-09 draft-ietf-ippm-rate-problem-10
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. Key rate test protocols to measure IP Performance Metrics. Key rate
measurement test protocol aspects include the ability to control measurement test protocol aspects include the ability to control
packet characteristics on the tested path, such as asymmetric rate packet characteristics on the tested path, such as asymmetric rate
and asymmetric packet size. and asymmetric packet size.
Requirements Language Requirements Language
skipping to change at page 1, line 40 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 July 13, 2015. This Internet-Draft will expire on August 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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. Operational Considerations . . . . . . . . . . . . . . . . . 10 7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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 2, line 49 skipping to change at page 2, line 49
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. The eventual
protocol solutions to this problem (and the systems that utilize the
protocol) may not directly involve users, such as when tests reach
from the Infrastructure to a service-specific device, such as a
residential gateway. However, no aspect of the problem precludes
users from developing a test protocol controlled via command line
interfaces on both ends. Thus, a very wide range of test protocols,
active measurement methods and system solutions are the possible
outcomes of this problem statement.
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].
skipping to change at page 4, line 39 skipping to change at page 4, line 47
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
transmission rates. Without being exhaustive, the possibilities transmission rates. Various aspects of Type-P are known to influence
include: Equal-Cost Multi-Path (ECMP) routing with possible rate measurement
variability across parallel paths. Without being exhaustive, the
possibilities include:
o Packet length o Packet length
o IP addresses o IP addresses
o Transport protocol (e.g. where TCP packets may be routed o Transport protocol (e.g. where TCP packets may be routed
differently from UDP) differently from UDP)
o Transport Protocol port numbers o Transport Protocol port numbers
This issue requires further discussion when specific solutions/ This issue requires further discussion when specific solutions/
methods of measurement are proposed, but for this problem statement methods of measurement are proposed, but for this problem statement
it is sufficient to identify the problem and indicate that the it is sufficient to identify the problem and indicate that the
solution may require an extremely close emulation of user traffic, in solution may require an extremely close emulation of user traffic, in
terms of one or more factors above. terms of one or more factors above.
Although the user may have multiple instances of network access Although the user may have multiple instances of network access
available to them, the primary problem scope is to measure one form available to them, the primary problem scope is to measure one form
of access at a time. It is plausible that a solution for the single of access at a time. It is plausible that a solution for the single
access problem will be applicable to simultaneous measurement of access problem will be applicable to simultaneous measurement of
skipping to change at page 10, line 33 skipping to change at page 10, line 42
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].
Privacy considerations for measurement systems, particularly when
Internet users participate in the tests in some way, are described in
[I-D.ietf-lmap-framework].
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. Operational Considerations 7. Operational Considerations
All forms of testing originate traffic on the network, through their All forms of testing originate traffic on the network, through their
communications for control and results collection, or from dedicated communications for control and results collection, or from dedicated
measurement packet streams, or both. Testing traffic primarily falls measurement packet streams, or both. Testing traffic primarily falls
in one of two categories, subscriber traffic or network management in one of two categories, subscriber traffic or network management
traffic. There is an on-going need to engineer networks so that traffic. There is an on-going need to engineer networks so that
various forms of traffic are adequately served, and publication of various forms of traffic are adequately served, and publication of
this memo does not change this need. Service subscribers and this memo does not change this need. Service subscribers and
authorized users SHOULD obtain their network operator's or service authorized users SHOULD obtain their network operator's or service
provider's permission before conducting tests. Likewise, a service provider's permission before conducting tests. Likewise, a service
provider or third party SHOULD obtain the subscriber's permission to provider or third party SHOULD obtain the subscriber's permission to
conduct tests, since they might temporarily reduce service quality. conduct tests, since they might temporarily reduce service quality.
The protocol SHOULD communicate the permission status once the
overall system has obtained it, either explicitly or through other
means.
Subscribers, their service providers and network operators, and Subscribers, their service providers and network operators, and
sometimes third parties, all seek to measure network performance. sometimes third parties, all seek to measure network performance.
Capacity testing with active traffic often affects the packet Capacity testing with active traffic often affects the packet
transfer performance of streams traversing shared components of the transfer performance of streams traversing shared components of the
test path, to some degree. The degradation can be minimized by test path, to some degree. The degradation can be minimized by
scheduling such tests infrequently, and restricting the amount of scheduling such tests infrequently, and restricting the amount of
measurement traffic required to assess capacity metrics. As a measurement traffic required to assess capacity metrics. As a
result, occasional short-duration estimates with minimal traffic are result, occasional short-duration estimates with minimal traffic are
preferred to measurements based on frequent file transfers of many preferred to measurements based on frequent file transfers of many
Megabytes with similar accuracy. New measurement methodologies Megabytes with similar accuracy. New measurement methodologies
intended for standardization should be evaluated individually for intended for standardization should be evaluated individually for
potential operational issues. However, the scheduled frequency of potential operational issues. However, the scheduled frequency of
testing is as important as the methods used (and schedules are not testing is as important as the methods used (and schedules are not
typically submitted for standardization). typically submitted for standardization).
The new test protocol feature of asymmetrical packet size generation The new test protocol feature of asymmetrical packet size generation
in two-way testing is recommended in this memo. It can appreciably in two-way testing is recommended in this memo. It can appreciably
reduce the load and packet processing demands of each test and reduce the load and packet processing demands of each test and
therefore reduce the likelihood of degradation in one direction of therefore reduce the likelihood of degradation in one direction of
the tested path. Current IETF standardized test protocols do not the tested path. Current IETF standardized test protocols (e.g.,
possess the asymmetric size generation capability with two-way [RFC5357], also [RFC6812]) do not possess the asymmetric size
testing. generation capability with two-way testing.
8. IANA Considerations 8. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
9. 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
skipping to change at page 12, line 36 skipping to change at page 13, line 10
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
progress), July 2014. progress), July 2014.
[I-D.ietf-lmap-framework]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A framework for large-scale
measurement platforms (LMAP)", draft-ietf-lmap-
framework-10 (work in progress), January 2015.
[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.
[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.
 End of changes. 14 change blocks. 
17 lines changed or deleted 40 lines changed or added

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