One document matched: draft-morton-ippm-rate-problem-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-morton-ippm-rate-problem-02"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="Rate Problem Statement">Rate Measurement Problem
    Statement</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri>http://home.comcast.net/~acmacm/</uri>
      </address>
    </author>

    <date day="29" month="February" year="2012" />

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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).</t>

      <t>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.</t>
    </section>

    <section title="Purpose and Scope">
      <t>The scope and purpose of this memo is to define the measurement
      problem statement for access rate measurement on production networks. We
      characterize this scenario as follows:<list style="symbols">
          <t>Rates at the edge of the network are several orders of magnitude
          less than aggregation and core portions.</t>

          <t>Asymmetrical ingress and egress rates are prevalent.</t>

          <t>Extremely large scale of access services requires low complexity
          devices participating at the user end of the path.</t>
        </list></t>

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

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

      <t>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 the case of aggregated
      leased networks, available capacity may also be asymmetric. 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.</t>

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

      <t>A key consideration is whether active measurements will be conducted
      with user traffic present (In-Service Testing), or not present
      (Out-of-Service Testing), such as during pre-service testing or
      maintenance that interrupts service temporarily. Out-of-Service testing
      includes activities described as "service commissioning", "service
      activation", and "planned maintenance". Both In-Service and
      Out-of-Service Testing are within the scope of this problem.</t>

      <t>It is a non-goal to solve the measurement protocol specification
      problem in this memo.</t>

      <t>It is a non-goal to standardize methods of measurement in this memo.
      However, the problem statement will mandate that support for one or more
      categories of rate measurement methods and adequate control features for
      the methods in the test protocol.</t>
    </section>

    <section title="Active Rate Measurement">
      <t>This section lists features of active measurement methods needed to
      measure access rates in production networks.</t>

      <t>Test coordination between Source and Destination devices through
      control messages and other basic capabilities described in the methods
      of IPPM RFCs <xref target="RFC2679"></xref><xref
      target="RFC2680"></xref> are taken as given (these could be listed
      later, if desired).</t>

      <t>Most forms of active testing intrude on user performance to some
      degree. One key tenet of IPPM methods is to minimize test traffic
      effects on user traffic in the production network. Section 5 of <xref
      target="RFC2680"></xref> 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,
      categories of rate measurement methods that use less active test traffic
      than others with similar accuracy SHALL be preferred for In-Service
      Testing.</t>

      <t>On the other hand, Out-of-Service Tests where the test path shares no
      links with In-Service user traffic have none of the congestion or skew
      concerns, but must address other practical concerns such as conducting
      measurements within a reasonable time from the tester's point of view.
      Out-of-Service Tests where some part of the test path is shared with
      In-Service traffic MUST respect the In-Service constraints.</t>

      <t>The **intended metrics to be measured** have strong influence over
      the categories of measurement methods required. For example, using the
      terminology of <xref target="RFC5136"></xref>, a it may be possible to
      measure a Path Capacity Metric while In-Service if the level of
      background (user) traffic can be assessed and included in the reported
      result.</t>

      <t>The measurement *architecture* MAY be either of one-way (e.g., <xref
      target="RFC4656"></xref>) or two-way (e.g., <xref
      target="RFC5357"></xref>), but the scale and complexity aspects of
      end-user or aggregated access measurement clearly favor two-way (with
      low-complexity user-end device and round-trip results collection, as
      found in <xref target="RFC5357"></xref>). However, the asymmetric rates
      of many access services mean that the measurement system MUST be able to
      assess each direction of transmission. In the two-way architecture, it
      is expected that both end devices MUST include the ability to launch
      test streams and collect the results of measurements in both (one-way)
      directions of transmission (this requirement is consistent with previous
      protocol specifications, it is not a unique problem for rate
      measurements).</t>

      <t>The following paragraphs describe features for the roles of test
      packet SENDER, RECEIVER, and results REPORTER.</t>

      <t>SENDER:</t>

      <t>Ability to generate streams of test packets with various
      characteristics as desired (see Section 4). The SENDER may be located at
      the user end of the access path, or may be located elsewhere in the
      production network, such as at one end of an aggregated leased network
      segment.</t>

      <t>RECEIVER:</t>

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

      <t>REPORTER:</t>

      <t>Ability to use information from test packets and local processes to
      measure delivered packet rates.</t>
    </section>

    <section title="Measurement Method Categories">
      <t>The design of rate measurement methods can be divided into two
      phases: test stream design and measurement (SENDER and RECEIVER), and a
      follow-up phase for analysis of the measurement to produce results
      (REPORTER). The measurement protocol that addresses this problem MUST
      only serve the test stream generation and measurement functions.</t>

      <t>For the purposes of this problem statement, we categorize the many
      possibilities for rate measurement stream generation as follows;<list
          style="numbers">
          <t>Packet pairs, with fixed intra-pair packet spacing and fixed or
          random time intervals between pairs in a test stream.</t>

          <t>Multiple streams of packet pairs, with a range intra-pair spacing
          and inter-pair intervals.</t>

          <t>One or more packet ensembles in a test stream, using a fixed
          ensemble size in packets and one or more fixed intra-ensemble packet
          spacings (including zero).</t>

          <t>One or more packet chirps, where intra-packet spacing typically
          decreases between adjacent packets in the same chirp and each pair
          of packets represents a rate for testing purposes.</t>
        </list></t>

      <t>For all categories, the test protocol MUST support:</t>

      <t><list style="numbers">
          <t>Variable payload lengths among packet streams</t>

          <t>Variable length (in packets) among packet streams or
          ensembles</t>

          <t>Variable header markings among packet streams</t>

          <t>Variable number of packets-pairs, ensembles, or streams used in a
          test session</t>
        </list>are additional variables that the test protocol MUST be able to
      communicate.</t>

      <t>The test protocol SHALL support test packet ensemble generation
      (category 3), as this appears to minimize the demands on measurement
      accuracy. Other stream generation categories are OPTIONAL.</t>

      <t>Measurements for each test packet transferred between SENDER and
      RECEIVER MUST be compliant with the singleton measurement methods
      described in IPPM RFCs <xref target="RFC2679"></xref><xref
      target="RFC2680"></xref> (these could be listed later, if desired). The
      time-stamp information or loss/arrival status for each packet MUST be
      available for communication to the protocol entity that collects
      results.</t>
    </section>

    <section title="Test Protocol Control & Generation Requirements">
      <t>Essentially, the test protocol MUST support the measurement features
      described in the sections above. This requires:</t>

      <t><list style="numbers">
          <t>Communicating all test variables to the Sender and Receiver</t>

          <t>Results collection in a one-way architecture</t>

          <t>Remote device control for both one-way and two-way
          architectures</t>

          <t>Asymmetric and/or pseudo-one-way test capability in a two-way
          measurement architecture</t>
        </list></t>

      <t>The ability to control packet size on the tested path and enable
      asymmetrical packet size testing in a two-way architecture are
      REQUIRED.</t>

      <t>The test protocol SHOULD enable measurement of the <xref
      target="RFC5136"></xref> Capacity metric, either Out-of-Service,
      In-Service, or both. Other <xref target="RFC5136"></xref> metrics are
      OPTIONAL.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations that apply to any active measurement of
      live networks are relevant here as well. See <xref
      target="RFC4656"></xref> and <xref target="RFC5357"></xref>.</t>

      <t>There may be a serious issue if a proprietary Service Level Agreement
      involved with the access network segment provider were somehow leaked in
      the process of rate measurement. To address this, test protocols SHOULD
      NOT convey this information in a way that could be discovered by
      unauthorized parties.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo makes no requests of IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Dave McDysan provided comments and text for the aggregated leased use
      case. Yaakov Stein suggested many considerations to address, including
      the in-service vs. out-of-service distinction and its implication on
      test traffic limits.</t>

      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.2679'?>

      <?rfc include='reference.RFC.2680'?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.1305'?>

      <?rfc include='reference.RFC.5618'?>

      <?rfc include='reference.RFC.5938'?>

      <?rfc include='reference.RFC.6038'?>
    </references>

    <references title="Informative References">
      <?rfc ?>

      <?rfc include='reference.RFC.5136'?>
    </references>
  </back>
</rfc>