draft-ietf-ippm-rate-problem-05.txt   draft-ietf-ippm-rate-problem-06.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational December 12, 2013 Intended status: Informational August 6, 2014
Expires: June 15, 2014 Expires: February 7, 2015
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-05 draft-ietf-ippm-rate-problem-06
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 15, 2014. This Internet-Draft will expire on February 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 4, line 10 skipping to change at page 3, line 34
The rates may be expressed as raw capacity or restricted capacity The rates may be expressed as raw capacity or restricted capacity
as described in [RFC6703]. These are the quantities that must be as described in [RFC6703]. These are the quantities that must be
measured according to one or more standard metrics, and for which measured according to one or more standard metrics, and for which
measurement methods must also be agreed as a part of the solution. measurement methods must also be agreed as a part of the solution.
o Referring to the reference path illustrated below and defined in o Referring to the reference path illustrated below and defined in
[I-D.ietf-ippm-lmap-path], possible measurement points include a [I-D.ietf-ippm-lmap-path], possible measurement points include a
Subscriber's host, the access service demarcation point, Intra IP Subscriber's host, the access service demarcation point, Intra IP
access where a globally routable address is present, or the access where a globally routable address is present, or the
gateway between the measured access network and other networks. gateway between the measured access network and other networks.
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
device Net #1 Net #2 Demarc. Access GW GRA GW Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
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 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
skipping to change at page 9, line 41 skipping to change at page 9, line 20
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 pseudo-one-way test capability in a
two-way measurement architecture (along with symmetric packet two-way measurement architecture (along with symmetric packet
size tests in common use) size tests in common use)
The ability to control packet size on the tested path and enable The ability to control and generate asymmetric rates in a two-way
asymmetrical packet size testing in a two-way architecture are architecture is REQUIRED. The ability to control and generate
REQUIRED. This allows both the conventional symmetric packet size symmetric and asymmetric packet sizes in a two-way architecture are
testing and asymmetrical packet size testing to employed to solve both RECOMMENDED.
various aspects of rate measurement: real-time communications often
have symmetrical streams, while file transfers have highly The asymmetric packet size control and generation capability is
asymmetrical streams in the data and acknowledgement traffic necessary when:
directions.
o there is a link in the path with asymmetrical capacity in opposite
directions (in combination with one or more of the conditions
below, but their presence or specific details may be unknown to
the tester),
o there is a link in the path which aggregates (or divides) packets
into link-level frames, and may have a capacity that depends on
packet size, rate, or timing,
o there is a link in the path where transmission in one direction
influences performance on the opposite direction,
o there is a device in the path where transmission capacity depends
on packet header processing capacity (in other words, the capacity
is sensitive to packet size),
o the target application stream is nominally MTU size packets in one
direction vs. ACK stream in the other, (noting that there are a
vanishing number of symmetrical-rate application streams for which
rate measurement is wanted or interesting),
o the distribution of packet losses is critical to rate assessment,
and possibly other circumstances revealed by measurements comparing
streams with symmetrical size and asymmetrical size.
Implementations MAY support control and generation for only symmetric
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
metric, either Out-of-Service, In-Service, or both. Other [RFC5136] metric, either Out-of-Service, In-Service, or both. Other [RFC5136]
metrics are OPTIONAL. metrics are OPTIONAL.
6. Security Considerations 6. Security Considerations
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and live networks are relevant here as well. See [RFC4656] and
[RFC5357]. [RFC5357].
skipping to change at page 10, line 45 skipping to change at page 10, line 50
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.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330, May
May 1998. 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
skipping to change at page 11, line 40 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-01 (work in progress), LMAP", draft-ietf-ippm-lmap-path-04 (work in progress),
September 2013. June 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-01 (work in Metrics", draft-ietf-ippm-model-based-metrics-03 (work in
progress), October 2013. 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, Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
July 2001. 2001.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, February 2008. RFC 5136, February 2008.
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare,
S., and E. Yedavalli, "Cisco Service-Level Assurance S., and E. Yedavalli, "Cisco Service-Level Assurance
Protocol", RFC 6812, January 2013. Protocol", RFC 6812, January 2013.
Author's Address Author's Address
 End of changes. 12 change blocks. 
36 lines changed or deleted 66 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/