draft-ietf-ippm-rate-problem-01.txt   draft-ietf-ippm-rate-problem-02.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 21, 2012 Intended status: Informational February 1, 2013
Expires: June 24, 2013 Expires: August 5, 2013
Rate Measurement Problem Statement Rate Measurement Test Protocol Problem Statement
draft-ietf-ippm-rate-problem-01 draft-ietf-ippm-rate-problem-02
Abstract Abstract
There is a rate measurement scenario which has wide-spread attention There is a rate measurement scenario which has wide-spread attention
of Internet access subscribers and seemingly all industry players, of Internet access subscribers and seemingly all industry players,
including regulators. This memo presents an access rate-measurement including regulators. This memo presents an access rate-measurement
problem statement for IP Performance Metrics. Key test protocol problem statement for test protocols to measure IP Performance
aspects require the ability to control packet size on the tested path Metrics. Key test protocol aspects require the ability to control
and enable asymmetrical packet size testing in a controller-responder packet size on the tested path and enable asymmetrical packet size
architecture. testing in a 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
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 June 24, 2013. This Internet-Draft will expire on August 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5
4. Measurement Method Categories . . . . . . . . . . . . . . . . 6 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7
5. Test Protocol Control & Generation Requirements . . . . . . . 8 5. Test Protocol Control & Generation Requirements . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 IP Performance Metrics (IPPM). measurement problem statement for test protocols to measure IP
Performance Metrics (IPPM).
The access-rate scenario or use case has wide-spread attention of The access-rate scenario or use case has wide-spread attention of
Internet access subscribers and seemingly all Internet industry Internet access subscribers and seemingly all Internet industry
players, including regulators. This problem is being approached with players, including regulators. This problem is being approached with
many different measurement methods. many different measurement methods. This memo
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. This memo so that it can be addressed by any existing test protocol, such as
discusses possibilities for methods of measurement, but does not [RFC6812].
specify exact methods which would normally be part of the solution,
not the problem. This memo discusses possibilities for methods of measurement, but
does not specify exact methods which would normally be part of the
solution, not the problem.
We characterize the access rate measurement scenario as follows: We characterize the access rate measurement scenario as follows:
o The Access portion of the network is the focus of this problem o The Access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with bi- statement. The user typically subscribes to a service with bi-
directional access partly described by rates in bits per second. directional access partly described by rates in bits per second.
The rates may be expressed as raw capacity or restricted capacity
as described in [RFC6703]. These are the quantities that must be
measured according to one or more standard metrics for which
methods must also be agreed as a part of the solution.
o Referring to the reference path defined in
[I-D.morton-ippm-lmap-path], possible measurement points include a
Subscriber's host (mp000), the access service demarcation point
(mp100), Intra IP access where a globally routable address is
present (mp150), or the gateway between the measured access
network and other networks (mp190).
o Rates at the edge of the network are several orders of magnitude o Rates at the edge of the network are several orders of magnitude
less than aggregation and core portions. less than aggregation and core portions.
o Asymmetrical ingress and egress rates are prevalent. o Asymmetrical ingress and egress rates are prevalent.
o Extremely large scale of access services requires low complexity o Extremely large scale of access services requires low complexity
devices participating at the user end of the path. devices participating at the user end of the path.
Today, the majority of widely deployed access services achieve rates Today, the majority of widely deployed access services achieve rates
skipping to change at page 4, line 17 skipping to change at page 4, line 32
networks, and/or extensions of layer 2 or layer 3 networks. The networks, and/or extensions of layer 2 or layer 3 networks. The
results of rate measurements in such cases could be employed to results of rate measurements in such cases could be employed to
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.
Only active measurement methods will be addressed here, consistent Support of active measurement methods will be addressed here,
with the IPPM working group's current charter. Active measurements consistent with the IPPM working group's traditional charter. Active
require synthetic traffic dedicated to testing, and do not use user measurements require synthetic traffic dedicated to testing, and do
traffic. not use user traffic.
The actual path used by traffic may influence the rate measurement The actual path used by traffic may influence the rate measurement
results for some forms of access, as it may differ between user and results for some forms of access, as it may differ between user and
test traffic if the test traffic has different characteristics, test traffic if the test traffic has different characteristics,
primarily in terms of the packets themselves (the Type-P described in primarily in terms of the packets themselves (the Type-P described in
[RFC2330]). [RFC2330]).
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 directed to special treatment that may affect examined and directed to special treatment that may affect
transmission rates. The possibilities include: transmission rates. The possibilities include:
skipping to change at page 5, line 11 skipping to change at page 5, line 25
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
multiple access instances, but discussion of this is beyond the multiple access instances, but discussion of this is beyond the
current scope. current scope.
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". Both In-Service and "service activation", and "planned maintenance". Opportunistic In-
Out-of-Service testing are within the scope of this problem. Service testing when there is no user traffic present throughout the
test interval is essentially equivalent to Out-of-Service testing.
Both In-Service and Out-of-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 that support for one or However, the problem statement will mandate that support for one or
more categories of rate measurement methods and adequate control more categories of rate measurement methods and adequate control
features for the methods in the test protocol. features for the methods in the test protocol.
3. Active Rate Measurement 3. Active Rate Measurement
skipping to change at page 7, line 51 skipping to change at page 8, line 21
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.
>>>>>> >>>>>>
Note: For measurement systems employing TCP Transport protocol, the Note: For measurement systems employing TCP 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 [draft-mathis-ippm-model-based-metrics]. progress for more background [I-D.mathis-ippm-model-based-metrics].
The general requirement statements needed to describe an "open-loop" The general requirement statements needed to describe an "open-loop"
TCP sender require some additional discussion. TCP sender require some additional discussion.
It may also be useful to specify a control for Bulk Transfer Capacity It may also be useful to specify a control for Bulk Transfer Capacity
measurement with fully-specified TCP senders and receivers, as measurement with fully-specified TCP senders and receivers, as
envisioned in [RFC3148], but this would be a brute-force assessment envisioned in [RFC3148], but this would be a brute-force assessment
which does not follow the conservative tenets of IPPM measurement. which does not follow the conservative tenets of IPPM measurement
[RFC2330].
>>>>>> >>>>>>
Measurements for each test packet transferred between SENDER and Measurements for each test packet transferred between SENDER and
RECEIVER MUST be compliant with the singleton measurement methods RECEIVER MUST be compliant with the singleton measurement methods
described in IPPM RFCs [RFC2679][RFC2680] (these could be listed described in IPPM RFCs [RFC2679][RFC2680] (these could be listed
later, if desired). The time-stamp information or loss/arrival later, if desired). The time-stamp information or loss/arrival
status for each packet MUST be available for communication to the status for each packet MUST be available for communication to the
protocol entity that collects results. protocol entity that collects results.
skipping to change at page 9, line 18 skipping to change at page 9, line 36
7. IANA Considerations 7. IANA Considerations
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. implication on test traffic limits and protocols. Bill Cerveny and
Marcelo Bagnulo have contributed insightful, clarifying comments that
made this a better draft.
9. Appendix 9. Appendix
This Appendix was proposed to briefly summarize previous rate This Appendix was proposed to briefly summarize previous rate
measurement experience. (There is a large body of research on rate measurement experience. (There is a large body of research on rate
measurement, so there is a question of what to include and what to measurement, so there is a question of what to include and what to
omit. Suggestions are welcome.) omit. Suggestions are welcome.)
10. References 10. References
skipping to change at page 10, line 24 skipping to change at page 10, line 45
August 2009. August 2009.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control [RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol Feature for the Two-Way Active Measurement Protocol
(TWAMP)", RFC 5938, August 2010. (TWAMP)", RFC 5938, August 2010.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010. Features", RFC 6038, October 2010.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012.
10.2. Informative References 10.2. Informative References
[I-D.mathis-ippm-model-based-metrics]
Mathis, M., "Model Based Internet Performance Metrics",
draft-mathis-ippm-model-based-metrics-00 (work in
progress), October 2012.
[I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-00 (work in progress),
January 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,
S., and E. Yedavalli, "Cisco Service-Level Assurance
Protocol", RFC 6812, January 2013.
Author's Address Author's Address
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
 End of changes. 21 change blocks. 
31 lines changed or deleted 69 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/