| Network Working Group | A. Morton |
| Internet-Draft | AT&T Labs |
| Intended status: Standards Track | October 24, 2011 |
| Expires: April 26, 2012 |
Rate Measurement Problem Statement
draft-morton-ippm-rate-problem-00
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.
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].
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 April 26, 2012.
Copyright (c) 2011 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 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.
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.
The scope and purpose of this memo is to define the measurement problem statement for access rate measurement. We characterize this scenario as follows:
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 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.
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 problem in this memo.
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 affects 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 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 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 network.
RECEIVER:
Ability to collect streams of test packets with various characteristics (as described above), and make the measurements necessary to support rate measurement.
REPORTER:
Ability to use information from test packets and local processes to measure delivered packet rates.
Essentially, the test protocol MUST support the measurement features described in Section 3. This REQUIRES:
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
This memo makes no requests of IANA.
The authors thank folks for review and comment.