draft-ietf-ippm-rate-problem-06.txt   draft-ietf-ippm-rate-problem-07.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational August 6, 2014 Intended status: Informational October 7, 2014
Expires: February 7, 2015 Expires: April 10, 2015
Rate Measurement Test Protocol Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-06 draft-ietf-ippm-rate-problem-07
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 February 7, 2015. This Internet-Draft will expire on April 10, 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 9, line 21 skipping to change at page 9, line 21
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 and generate asymmetric rates in a two-way The ability to control and generate asymmetric rates in a two-way
architecture is REQUIRED. The ability to control and generate architecture is REQUIRED. Two-way architectures are RECOMMENDED to
symmetric and asymmetric packet sizes in a two-way architecture are include control and generation capability for both asymmetric and
both RECOMMENDED. symmetric packet sizes, because packet size often matters in the
scope of this problem and test systems SHOULD be equipped to detect
directional size dependency through comparative measurements.
The asymmetric packet size control and generation capability is Asymmetric packet size control is indicated when the result of a
necessary when: measurement may depend on the size of the packets used in each
direction, i.e. when any of the following conditions hold:
o there is a link in the path with asymmetrical capacity in opposite o there is a link in the path with asymmetrical capacity in opposite
directions (in combination with one or more of the conditions directions (in combination with one or more of the conditions
below, but their presence or specific details may be unknown to below, but their presence or specific details may be unknown to
the tester), the tester),
o there is a link in the path which aggregates (or divides) packets 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 into link-level frames, and may have a capacity that depends on
packet size, rate, or timing, packet size, rate, or timing,
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 on 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),
skipping to change at page 9, line 50 skipping to change at page 10, line 4
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),
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
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
skipping to change at page 10, line 43 skipping to change at page 10, line 45
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. Barry Constantine also provided suggestions for draft. Barry Constantine also provided suggestions for
clarification. clarification.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
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, 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 19 skipping to change at page 11, line 19
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.
[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.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
August 2009.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol
(TWAMP)", RFC 5938, August 2010.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010.
[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-04 (work in progress), Large-Scale Measurement of Broadband Performance", draft-
June 2014. ietf-ippm-lmap-path-06 (work in progress), September 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. 12 change blocks. 
30 lines changed or deleted 17 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/