draft-ietf-ippm-rate-problem-04.txt   draft-ietf-ippm-rate-problem-05.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational September 19, 2013 Intended status: Informational December 12, 2013
Expires: March 23, 2014 Expires: June 15, 2014
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-04 draft-ietf-ippm-rate-problem-05
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 March 23, 2014. This Internet-Draft will expire on June 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10
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 4, line 20 skipping to change at page 4, line 20
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
device Net #1 Net #2 Demarc. Access GW GRA GW device Net #1 Net #2 Demarc. Access GW GRA GW
GRA = Globally Routable Address, GW = Gateway GRA = Globally Routable Address, GW = Gateway
o Rates at some links near the edge of the provider's network can o Rates at some links near the edge of the provider's network can
often be several orders of magnitude less 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 Extremely large scale of access services requires low complexity o In many scenarios of interest, extremely large scale of access
devices participating at the user end of the path. services requires low complexity devices participating at the user
end of the path.
This problem statement assumes that the most-likely bottleneck device This problem statement assumes that the most-likely bottleneck device
or link is adjacent to the remote (user-end) measurement device, or or link is adjacent to the remote (user-end) measurement device, or
is within one or two router/switch hops of the remote measurement is within one or two router/switch hops of the remote measurement
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 48 skipping to change at page 4, line 49
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 make measurements on user traffic. not make measurements on user traffic.
As noted in [RFC2330] the actual traffic handling may influence the As noted in [RFC2330] the focus of access traffic management may
rate measurement results for some forms of access, as it may differ influence the rate measurement results for some forms of access, as
between user and test traffic if the test traffic has different it may differ between user and test traffic if the test traffic has
characteristics, primarily in terms of the packets themselves (see different characteristics, primarily in terms of the packets
section 13 of [RFC2330] for the considerations on packet type, or themselves (see section 13 of [RFC2330] for the considerations on
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. Without being exhaustive, the possibilities
include: include:
o Packet length o Packet length
o IP addresses o IP addresses
skipping to change at page 5, line 39 skipping to change at page 5, line 40
access problem will be applicable to simultaneous measurement of access problem will be applicable to simultaneous measurement of
multiple access instances, but treatment of this scenario is beyond multiple access instances, but treatment of this scenario is beyond
the current scope this document. 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 (e.g., outside
test interval is essentially equivalent to Out-of-Service testing. normal business hours) throughout the test interval is essentially
Both In-Service and Out-of-Service testing are within the scope of equivalent to Out-of-Service testing. Both In-Service and Out-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 will mandate support for one or more
categories of rate measurement methods in the test protocol and categories of rate measurement methods in the test protocol and
adequate control features for the methods in the control protocol adequate control features for the methods in the control protocol
(assuming the control and test protocols are separate). (assuming the control and test protocols are separate).
skipping to change at page 7, line 25 skipping to change at page 7, line 28
RECEIVER: RECEIVER:
Collect streams of test packets with various characteristics (as Collect streams of test packets with various characteristics (as
described above), and make the measurements necessary to support rate described above), and make the measurements necessary to support rate
measurement at the receiving end of an access or aggregated leased measurement at the receiving end of an access or aggregated leased
network segment. network segment.
REPORTER: REPORTER:
Use information from test packets and local processes to measure Use information from test packets and local processes to measure
delivered packet rates, and prepare results in the required format. delivered packet rates, and prepare results in the required format
(the REPORTER role may be combined with another role, most likely the
SENDER).
4. Measurement Method Categories 4. Measurement Method Categories
A protocol that addresses the rate measurement problem MUST serve the A protocol that addresses the rate measurement problem MUST serve the
test stream generation and measurement functions (SENDER and test stream generation and measurement functions (SENDER and
RECEIVER). The follow-up phase of analyzing the measurement results RECEIVER). The follow-up phase of analyzing the measurement results
to produce a report is outside the scope of this problem and memo to produce a report is outside the scope of this problem and memo
(REPORTER). (REPORTER).
For the purposes of this problem statement, we categorize the many For the purposes of this problem statement, we categorize the many
skipping to change at page 8, line 20 skipping to change at page 8, line 26
For all categories, the test protocol MUST support: For all categories, the test protocol MUST support:
a. Variable payload lengths among packet streams a. Variable payload lengths among packet streams
b. Variable length (in packets) among packet streams or ensembles b. Variable length (in packets) among packet streams or ensembles
c. Variable IP header markings among packet streams c. Variable IP header markings among packet streams
d. Choice of UDP transport and variable port numbers, OR, choice of d. Choice of UDP transport and variable port numbers, OR, choice of
TCP transport and variable port numbers for two-way architectures TCP transport and variable port numbers for two-way architectures
only, OR BOTH. only, OR BOTH. See below for additional requirements on TCP
transport generation.
e. Variable number of packets-pairs, ensembles, or streams used in a e. Variable number of packets-pairs, ensembles, or streams used in a
test session test session.
The items above are additional variables that the test protocol MUST The items above are additional variables that the test protocol MUST
be able to identify and control. The ability to revise these be able to identify and control. The ability to revise these
variables during an established test session is OPTIONAL, as multiple variables during an established test session is OPTIONAL, as multiple
test sessions could serve the same purpose. test sessions could serve the same purpose. Another OPTIONAL feature
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 10, line 23 skipping to change at page 10, line 31
This memo makes no requests of IANA. This memo makes no requests of IANA.
8. Acknowledgements 8. Acknowledgements
Dave McDysan provided comments and text for the aggregated leased use Dave McDysan provided comments and text for the aggregated leased use
case. Yaakov Stein suggested many considerations to address, case. Yaakov Stein suggested many considerations to address,
including the In-Service vs. Out-of-Service distinction and its including the In-Service vs. Out-of-Service distinction and its
implication on test traffic limits and protocols. Bill Cerveny, implication on test traffic limits and protocols. Bill Cerveny,
Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have
contributed insightful, clarifying comments that made this a better contributed insightful, clarifying comments that made this a better
draft. draft. Barry Constantine also provided suggestions for
clarification.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 11, line 29 skipping to change at page 11, line 40
[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
LMAP", draft-ietf-ippm-lmap-path-00 (work in progress), LMAP", draft-ietf-ippm-lmap-path-01 (work in progress),
July 2013. September 2013.
[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-00 (work in Metrics", draft-ietf-ippm-model-based-metrics-01 (work in
progress), June 2013. progress), October 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 2001. July 2001.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, February 2008. RFC 5136, February 2008.
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare,
S., and E. Yedavalli, "Cisco Service-Level Assurance S., and E. Yedavalli, "Cisco Service-Level Assurance
 End of changes. 15 change blocks. 
27 lines changed or deleted 33 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/