One document matched: draft-morton-ippm-rate-problem-01.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-01"
     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="14" month="January" 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. 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 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>It is a non-goal to solve the measurement protocol specification
      problem in this memo.</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 Src and Dst 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>One key tenant 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,
      methods that use less active test traffic than others with similar
      accuracy SHALL be preferred.</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.
      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).</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. 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><list style="numbers">
          <t>Variable payload lengths among packet streams</t>

          <t>Variable stream length among packet streams</t>

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

          <t>others?</t>
        </list>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="Test Protocol Control & Generation Requirements">
      <t>Essentially, the test protocol MUST support the measurement features
      described in Section 3. 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 a two-way architecture</t>

          <t>Asymmetric and/or pseudo-one-way test capability in a two-way
          measurement architecture</t>
        </list></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>[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?]</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.</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 ?>
    </references>
  </back>
</rfc>