<?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="info" docName="draft-morton-ippm-2330-update-00"
     ipr="trust200902">
  <front>
    <title abbrev="Advanced Sampling">Advanced Stream and Sampling Framework
    for IPPM</title>

    <author fullname="Joachim Fabini" initials="J." surname="Fabini">
      <organization>Vienna University of Technology</organization>

      <address>
        <postal>
          <street>Favoritenstrasse 9/E389</street>

          <city>Vienna</city>

          <region/>

          <code>1040</code>

          <country>Austria</country>
        </postal>

        <phone>+43 1 58801 38813</phone>

        <facsimile>+43 1 58801 38898</facsimile>

        <email>Joachim.Fabini@tuwien.ac.at</email>

        <uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri>
      </address>
    </author>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;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="8" month="October" year="2012"/>

    <abstract>
      <t>To obtain repeatable results in modern networks, test descriptions
      need an expanded stream parameter framework that also augments aspects
      specified as Type-P for test packets. This memo proposes to update the
      IP Performance Metrics (IPPM) Framework with advanced considerations for
      measurement methodology and testing. The existing framework mostly
      assumes deterministic connectivity, and that a single test stream will
      represent the characteristics of the path when it is aggregated with
      other flows. Networks have evolved and test stream descriptions must
      evolve with them, otherwise unexpected network features may dominate the
      measured performance. This memo describes new stream parameters for both
      network characterization and support of application design using IPPM
      metrics.</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>The IETF IP Performance Metrics (IPPM) working group first created a
      framework for metric development in <xref target="RFC2330"/>. This
      framework has stood the test of time and enabled development of many
      fundamental metrics, while only being updated once in a specific area
      <xref target="RFC5835"/>.</t>

      <t>The IPPM framework <xref target="RFC2330"/> generally relies on
      several assumptions, one of which is not explicitly stated but assumed:
      the network behaves (halfway) deterministic and without
      state/history-less (with some exceptions, firewalls are mentioned).
      However, this does not hold true for many modern network technologies,
      such as reactive networks (those with demand-driven resource allocation)
      and links with time-slotted operation. Per-flow state can be observed on
      test packet streams, and such treatment will influence network
      characterization if it is not taken into account. Flow history will also
      affect the performance of applications and be perceived by their
      users.</t>

      <t>Moreover, Sections 4 and 6.2 of <xref target="RFC2330"/> explicitly
      recommend repeatable measurement metrics and methodologies. Measurements
      in today's access networks illustrate that methodological guidelines of
      <xref target="RFC2330"/> must be extended to capture the reactive nature
      of these networks. Although the proposed extensions can support
      methodologies to fulfill the continuity requirement stated in section
      6.2 of <xref target="RFC2330"/>, there is no guarantee. Practical
      measurements confirm that some link types exhibit distinct responses to
      repeated measurements with identical stimulus, i.e., identical traffic
      patterns. If feasible, appropriate fine-tuning of measurement traffic
      patterns can improve measurement continuity and repeatability for these
      link types as shown in <xref target="IBD"/>.</t>
    </section>

    <section title="Scope">
      <t>The scope of his memo is to describe useful stream parameters in
      addition to the information in Section 11.1 of <xref target="RFC2330"/>
      and described in <xref target="RFC3432"/> for periodic streams. The
      purpose is to foster repeatable measurement results in modern networks
      by highlighting the key aspects of test streams and packets and make
      them part of the IPPM performance metric framework.</t>
    </section>

    <section title="New Stream Parameters">
      <t>There are several areas where measurement methodology definition and
      test result interpretation will benefit from an increased understanding
      of the stream characteristics and the (possibly unknown) network
      condition that influence the measured metrics.</t>

      <t><list style="numbers">
          <t>Network treatment depends on the fullest extent on the "packet of
          Type-P" definition in <xref target="RFC2330"/>, and has for some
          time. <list style="symbols">
              <t>State is often maintained on the per-flow basis at various
              points in the network, where "flows" are determined by IP and
              other layers. Significant treatment differences occur with the
              simplest of Type-P parameters: packet length.</t>

              <t>Payload content optimization (compression or format
              conversion) in intermediate segments. This breaks the convention
              of payload correspondence when correlating measurements made at
              different points in a path.</t>
            </list></t>

          <t>Packet history (instantaneous or recent test rate or inactivity,
          also for non-test traffic) profoundly influences measured
          performance, in addition to all the Type-P parameters described in
          <xref target="RFC2330"/>.</t>

          <t>Access technology may change during testing. A range of transfer
          capacities and access methods may be encountered during a test
          session. When different interfaces are used, the host seeking access
          will be aware of the technology change which differentiates this
          form of path change from other changes in network state. Section 14
          of <xref target="RFC2330"/> treats the possibility that a host may
          have more than one attachment to the network, and also that
          assessment of the measurement path (route) is valid for some length
          of time (in Section 5 and Section 7 of <xref target="RFC2330"/>).
          Here we combine these two considerations under the assumption that
          changes may be more frequent and possibly have greater consequences
          on performance metrics.</t>

          <t>Paths including links or nodes with time-slotted service
          opportunities represent several challenges to measurement (when
          service time period is appreciable):<list style="symbols">
              <t>Random/unbiased sampling is not possible beyond one such link
              in the path.</t>

              <t>The above encourages a segmented approach to end to end
              measurement, as described in <xref target="RFC6049"/> for
              Network Characterization (as defined in <xref
              target="RFC6703"/>) to understand the full range of delay and
              delay variation on the path. Alternatively, if application
              performance estimation is the goal (also defined in <xref
              target="RFC6703"/>), then a stream with un-biased or known-bias
              properties <xref target="RFC3432"/> may be sufficient.</t>

              <t>Multi-modal delay variation makes central statistics
              unimportant, others must be used instead.</t>
            </list></t>
        </list> Each of these topics is treated in detail below.</t>

      <section title="Test Packet Type-P">
        <t>We recommend two Type-P parameters to be added to the factors which
        have impact on network performance measurements, namely packet length
        and payload type. Carefully choosing these parameters can improve
        measurement methodologies in their continuity and repeatability when
        deployed in reactive networks.</t>

        <section title="Test Packet Length">
          <t>Many instances of network characterization using IPPM metrics
          have relied on a single test packet length. When testing to assess
          application performance or an aggregate of traffic, benchmarking
          methods have used a range of fixed lengths and frequently augmented
          fixed size tests with a mixture of sizes, or IMIX as described in
          <xref target="I-D.ietf-bmwg-imix-genome"/>.</t>

          <t>Test packet length influences delay measurements, in that the
          IPPM one-way delay metric <xref target="RFC2679"/> includes
          serialization time in its first-bit to last bit time stamping
          requirements. However, different sizes can have a larger effect on
          link delay and link delay variation than serialization would explain
          alone. This effect can be non-linear and change instantaneous or
          future network performance.</t>

          <t>Repeatability is a main measurement methodology goal as stated in
          section 6.2 of <xref target="RFC2330"/>. To eliminate packet length
          as a potential measurement uncertainty factor, successive
          measurements must use identical traffic patterns. In practice a
          combination of random payload and random start time can yield
          representative results as illustrated in <xref target="IRR"/>.</t>
        </section>

        <section title="Test Packet Payload Content Optimization">
          <t>The aim for efficient network resource use has resulted in a
          series of "smart" networks to deploy server-only or client-server
          lossless or lossy payload compression techniques on some links or
          paths. These optimizers attempt to compress high-volume traffic in
          order to reduce network load. Files are analyzed by
          application-layer parsers and parts (like comments) might be
          dropped. Although typically acting on HTTP or JPEG files,
          compression might affect measurement packets, too. In particular
          measurement packets are qualified for efficient compression when
          they use standard plain-text payload.</t>

          <t>IPPM-conforming measurements should add packet payload content as
          a Type-P parameter which can help to improve measurement
          determinism. Some packet payloads are more susceptible to
          compression than others, but optimizers in the measurement path can
          be out ruled by using incompressible packet payload. This payload
          content could be either generated by a random device or by using
          part of a compressed file (e.g., a part of a ZIP compressed
          archive).</t>
        </section>
      </section>

      <section title="Packet History">
        <t>Recent packet history and instantaneous data rate influence
        measurement results for reactive links supporting on-demand capacity
        allocation. Measurement uncertainty may be reduced by knowledge of
        measurement packet history and total host load. Additionally, small
        changes in history, e.g., because of lost packets along the path, can
        be the cause of large performance variations.</t>

        <t>For instance delay in reactive 3G networks like High Speed Packet
        Access (HSPA) depends to a large extent on the test traffic data rate.
        The reactive resource allocation strategy in these networks affects
        the uplink direction in particular. Small changes in data rate can be
        the reason of more than 200% increase in delay, depending on the
        specific packet size.</t>
      </section>

      <section title="Access Technology Change">
        <t><xref target="RFC2330"/> discussed the scenario of multi-homed
        hosts. If hosts become aware of access technology changes (e.g.,
        because of IP address changes or lower layer information) and make
        this information available, measurement methodologies can use this
        information to improve measurement representativeness and
        relevance.</t>

        <t>However, today's various access network technologies can present
        the same physical interface to the host. A host may or may not become
        aware when its access technology changes on such an interface.
        Measurements for networks which support on-demand capacity allocation
        are therefore challenging in that it is difficult to differentiate
        between access technology changes (e.g., because of mobility) and
        reactive network behavior (e.g., because of data rate change).</t>
      </section>

      <section title="Time-Slotted Network Paths ">
        <t>Time-Slotted operation of network entities - interfaces, routers or
        links - in a network path is a particular challenge for measurements,
        especially if the time slot period is substantial. The central
        observation as an extension to Poisson stream sampling in <xref
        target="RFC2330"/> is that the first such time-slotted component
        cancels unbiased measurement stream sampling. In the worst case,
        time-slotted operation converts an unbiased, random measurement packet
        stream into a periodic packet stream. Being heavily biased, these
        packets may interact with periodic network behavior of subsequent
        time-slotted network entities.</t>

        <t>Practical measurements confirm that such interference limits delay
        measurement variation to a sub-set of theoretical value range.
        Measurement samples for such cases can aggregate on artificial limits,
        generating multi-modal distributions as demonstrated in <xref
        target="IRR"> </xref>. In this context, the desirable measurement
        sample statistics differentiate between multi-modal delay
        distributions caused by reactive network behavior and the ones due to
        time-slotted interference.</t>

        <t>The amount of measurement bias is determined by the relative offset
        between allocated time-slots in subsequent network entities, delay
        variation in these networks, and other sources of variation.
        Measurement results might change over time, depending on how
        accurately the sending host, receiving host, and time-slotted
        components in the measurement path are synchronized to each other and
        to global time. If network segments maintain flow state, flow
        parameter change or flow re-allocations can cause substantial
        variation in measurement results.</t>

        <t>Measurement methodology selection for time-slotted paths depends to
        a large extent on the respective viewpoint. End-to-end metrics can
        provide accurate measurement results for short-term sessions and low
        likelihood of flow state modifications. Applications or services which
        aim at approximating network performance for a short time interval (in
        the order of minutes) and expect stable network conditions should
        therefore prefer end-to-end metrics. Here stable network conditions
        refer to any kind of global knowledge concerning measurement path flow
        state and flow parameters.</t>

        <t>However, if long-term forecast of time-slotted network performance
        is the main measurement goal, a segmented approach relying on
        hop-by-hop metrics is preferred. Re-generating unbiased measurement
        traffic at any hop can help to unleash the true range of network
        performance for all network segments.</t>

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

    <section title="Conclusions">
      <t>Safeguarding continuity and repeatability as key properties of
      measurement methodologies is highly challenging and sometimes impossible
      in reactive networks. Measurements in networks with demand-driven
      allocation strategies must use a prototypical application packet stream
      to infer a specific application's performance. Measurement repetition
      with unbiased network and flow states (e.g., by rebooting measurement
      hosts) can help to avoid interference with periodic network behavior,
      randomness being a mandatory feature for avoiding correlation with
      network timing. Inferring from one measurement session or packet stream
      onto network performance for alternative streams is highly discouraged
      in reactive networks because of the huge set of global parameters which
      influence on instantaneous network performance.</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"/>
      and <xref target="RFC5357"/>.</t>
    </section>

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

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank folks for reading and commenting on this draft.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-bmwg-imix-genome'?>

      <?rfc ?>

      <?rfc ?>

      <reference anchor="IBD">
        <front>
          <title>The Illusion of Being Deterministic &ndash; Application-Level
          Considerations on Delay in 3G HSPA Networks</title>

          <author fullname="Joachim Fabini et al." initials="J.F."
                  surname="Fabini">
            <!-- fullname="J.Fabini"-->

            <organization>Vienna University of Technology</organization>
          </author>

          <date day="" month="May" year="2009"/>
        </front>

        <seriesInfo name="Lecture Notes in Computer Science,"
                    value=" Springer, Volume 5550, 2009, pp 301-312 "/>
      </reference>

      <reference anchor="IRR">
        <front>
          <title>The Importance of Being Really Random: Methodological Aspects
          of IP-Layer 2G and 3G Network Delay Assessment</title>

          <author fullname="Joachim Fabini et al." initials="J.F."
                  surname="Fabini">
            <!-- fullname="J.Fabini" -->

            <organization>Vienna University of Technology</organization>
          </author>

          <date month="June" year="2009"/>
        </front>

        <seriesInfo name="ICC'09 Proceedings of the 2009 IEEE International Conference on Communications,"
                    value="doi: 10.1109/ICC.2009.5199514"/>
      </reference>
    </references>
  </back>
</rfc>
