One document matched: draft-morton-ippm-rate-problem-00.txt

Network Working Group                                          A. Morton
Internet-Draft                                                 AT&T Labs
Intended status: Standards Track                        October 23, 2011
Expires: April 25, 2012


                   Rate Measurement Problem Statement
                   draft-morton-ippm-rate-problem-00

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 April 25, 2012.

Copyright Notice

   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



Morton                   Expires April 25, 2012                 [Page 1]

Internet-Draft           Rate Problem Statement             October 2011


   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 . . . . . . . . . . . . . . . . . . . . 3
   4.  Test Protocol Control & Generation Requirements . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6




























Morton                   Expires April 25, 2012                 [Page 2]

Internet-Draft           Rate Problem Statement             October 2011


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 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.


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



Morton                   Expires April 25, 2012                 [Page 3]

Internet-Draft           Rate Problem Statement             October 2011


   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.

   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.

   REPORTER:




Morton                   Expires April 25, 2012                 [Page 4]

Internet-Draft           Rate Problem Statement             October 2011


   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].


6.  IANA Considerations

   This memo makes no requests of IANA.


7.  Acknowledgements

   The authors thank folks for review and comment.


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.



Morton                   Expires April 25, 2012                 [Page 5]

Internet-Draft           Rate Problem Statement             October 2011


   [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.

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 April 25, 2012                 [Page 6]