One document matched: draft-morton-ippm-rate-problem-01.txt
Differences from draft-morton-ippm-rate-problem-00.txt
Network Working Group A. Morton
Internet-Draft AT&T Labs
Intended status: Standards Track January 14, 2012
Expires: July 17, 2012
Rate Measurement Problem Statement
draft-morton-ippm-rate-problem-01
Abstract
There is a rate measurement scenario which has wide-spread attention
of users and seemingly all industry participants, including
regulators. This memo presents an access rate-measurement problem
statement for IP Performance Metrics. Key aspects require the
ability to control packet size on the tested path and enable
asymmetrical packet size testing in a controller-responder
architecture.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Morton Expires July 17, 2012 [Page 1]
Internet-Draft Rate Problem Statement January 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . . 4
4. Test Protocol Control & Generation Requirements . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Morton Expires July 17, 2012 [Page 2]
Internet-Draft Rate Problem Statement January 2012
1. Introduction
There are many possible rate measurement scenarios. This memo
describes one rate measurement problem and presents a rate-
measurement problem statement for IP Performance Metrics (IPPM).
The access-rate scenario or use case has wide-spread attention of
users and seemingly all industry participants, including regulators.
It is being approached with many different measurement methods.
2. Purpose and Scope
The scope and purpose of this memo is to define the measurement
problem statement for access rate measurement. We characterize this
scenario as follows:
o Rates at the edge of the network are several orders of magnitude
less than aggregation and core portions.
o Asymmetrical ingress and egress rates are prevalent.
o Extremely large scale of access services requires low complexity
devices participating at the user end of the path.
Today, the majority of widely deployed access services achieve rates
less than 100 Mbit/s, and this is the rate-regime for which a
solution is sought now.
This problem statement assumes that the most-likely bottleneck device
or link is adjacent to the remote (user-end) measurement device, or
is within one or two router/switch hops of the remote measurement
device.
Other use cases for rate measurement involve situations where the
packet switching and transport facilities are leased by one operator
from another and the actual capacity available cannot be directly
determined (e.g., from device interface utilization). These
scenarios could include mobile backhaul, Ethernet Service access
networks, and/or extensions of a layer 2 or layer 3 networks. The
results of rate measurements in such cases could be employed to
select alternate routing, investigate whether capacity meets some
previous agreement, and/or adapting the rate of certain traffic
sources if a capacity bottleneck is found via the rate measurement.
In these cases, the tester is assumed to have a sender and receiver
location under their control. We refer to this scenario below as the
aggregated leased network case.
Morton Expires July 17, 2012 [Page 3]
Internet-Draft Rate Problem Statement January 2012
Only active measurement methods will be addressed here, consistent
with the IPPM working group's current charter. Active measurements
require synthetic traffic dedicated to testing, and do not use user
traffic.
It is a non-goal to solve the measurement protocol specification
problem in this memo.
3. Active Rate Measurement
This section lists features of active measurement methods needed to
measure access rates in production networks.
Test coordination between Src and Dst devices through control
messages, and other basic capabilities described in the methods of
IPPM RFCs [RFC2679][RFC2680] are taken as given (these could be
listed later, if desired).
One key tenant of IPPM methods is to minimize test traffic effects on
user traffic in the production network. Section 5 of [RFC2680] lists
the problems with high measurement traffic rates, and the most
relevant for rate measurement is the tendency for measurement traffic
to skew the results, followed by the possibility to introduce
congestion on the access link. Obviously, methods that use less
active test traffic than others with similar accuracy SHALL be
preferred.
The measurement architecture MAY be either of one-way (e.g.,
[RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity
aspects of end-user or aggregated access measurement clearly favor
two-way. However, the asymmetric rates of many access services means
that the measurement system MUST be able to assess each direction of
transmission separately. In the case of aggregated leased networks,
available capacity may also be asymmetric. In the two-way
architecture, it is expected that both directions of transmission MAY
affect the ability to launch streams or collect the results of
measurements (this has always been true, it is not a unique problem
for rate measurements).
The following paragraphs describe features for the roles of test
packet SENDER, RECEIVER, and results REPORTER.
SENDER:
Ability to generate streams of test packets with various
characteristics as desired. The SENDER may be located at the user
end of the access path, or may be located elsewhere in the production
Morton Expires July 17, 2012 [Page 4]
Internet-Draft Rate Problem Statement January 2012
network, such as at one end of an aggregated leased network segment.
1. Variable payload lengths among packet streams
2. Variable stream length among packet streams
3. Variable header markings among packet streams
4. others?
RECEIVER:
Ability to collect streams of test packets with various
characteristics (as described above), and make the measurements
necessary to support rate measurement at the other end of an end-user
access or aggregated leased network segment.
REPORTER:
Ability to use information from test packets and local processes to
measure delivered packet rates.
4. Test Protocol Control & Generation Requirements
Essentially, the test protocol MUST support the measurement features
described in Section 3. This REQUIRES:
1. Communicating all test variables to the Sender and Receiver
2. Results collection in a one-way architecture
3. Remote device control for a two-way architecture
4. Asymmetric and/or pseudo-one-way test capability in a two-way
measurement architecture
5. Security Considerations
The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and
[RFC5357].
[QUESTION: Is there an additional consideration if there is a legal
SLA involved with the access network segment provider to make sure
this information is not leaked?]
Morton Expires July 17, 2012 [Page 5]
Internet-Draft Rate Problem Statement January 2012
6. IANA Considerations
This memo makes no requests of IANA.
7. Acknowledgements
Dave McDysan provided comments and text for the aggregated leased use
case.
8. References
8.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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
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.
Morton Expires July 17, 2012 [Page 6]
Internet-Draft Rate Problem Statement January 2012
8.2. Informative References
Author's Address
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown,, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Morton Expires July 17, 2012 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 04:38:00 |