<?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-ietf-ippm-2330-update-04"
     ipr="trust200902" updates="2330">
  <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>Gusshausstrasse 25/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="16" month="April" year="2014"/>

    <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 updates the IP
      Performance Metrics (IPPM) Framework RFC 2330 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:
      lightly loaded paths conform to the linear "delay = packet size /
      capacity" equation, being state/history-less (with some exceptions,
      firewalls are mentioned). However, this does not hold true for many
      modern network technologies, such as reactive paths (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>

      <t>This memo updates the IP Performance Metrics (IPPM) Framework <xref
      target="RFC2330"/> with advanced considerations for measurement
      methodology and testing.</t>

      <t>We stress that this update of <xref target="RFC2330"/> does not
      invalidate or require changes to the analytic metric definitions
      prepared in the IPPM working group to date. Rather, it adds
      considerations for active measurement methodologies and expands the
      importance of existing conventions and notions in <xref
      target="RFC2330"/>, such as "packets of Type-P".</t>

      <t>Among the evolutionary networking changes is a phenomenon we call
      "reactive behavior", defined below.</t>

      <section title="Definition: Reactive Path Behavior">
        <t>Reactive path behavior will be observable by the test packet stream
        as a repeatable phenomenon where packet transfer performance
        characteristics *change* according to prior observations of the packet
        flow of interest (at the reactive host or link). Therefore, reactive
        path behavior is nominally deterministic with respect to the flow of
        interest. Other flows or traffic load conditions may result in
        additional performance-affecting reactions, but these are external to
        the characteristics of the flow of interest.</t>

        <t>In practice, a sender may not have absolute control of the ingress
        packet stream characteristics at a reactive host or link, but this
        does not change the deterministic reactions present there. If we
        measure a path, the arrival characteristics at the reactive host/link
        are determined by the sending characteristics and the transfer
        characteristics of intervening hosts and links. Identical traffic
        patterns at the sending host might generate distinct patterns at the
        reactive host's/link's input due to impairments in the intermediate
        subpath. The reactive host/link is expected to provide deterministic
        response on identical input patterns.</t>

        <t>Other than the size of the payload at the layer of interest and the
        header itself, packet content does not influence the measurement.
        Reactive behavior at the IP layer is not influenced by the TCP ports
        in use, for example. Therefore, the indication of reactive behavior
        must include the layer at which measurements are instituted.</t>

        <t>Examples include links with Active/In-active state detectors, and
        hosts or links that revise their traffic serving and forwarding rates
        (up or down) based on packet arrival history.</t>

        <t>Although difficult to handle from a measurement point of view,
        reactive paths entities are usually designed to improve overall
        network performance and user experience, for example by making
        capacity available to an active user. Reactive behavior may be an
        artifact of solutions to allocate scarce resources according to the
        demands of users, thus it is an important problem to solve for
        measurement and other disciplines, such as application design.</t>
      </section>
    </section>

    <section title="Scope">
      <t>The purpose of this memo 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>

      <t>The scope is to update key sections of <xref target="RFC2330"/>,
      adding considerations that will aid the development of new measurement
      methodologies intended for today's IP networks. Specifically, this memo
      describes 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.</t>

      <t>The memo also provides new considerations to update the criteria for
      metrics in section 4 of <xref target="RFC2330"/>, the measurement
      methodology in section 6.2 of <xref target="RFC2330"/>, and other topics
      related to the quality of metrics and methods (see section 4).</t>

      <t>Other topics in <xref target="RFC2330"/> which might be updated or
      augmented are deferred to future work. This includes the topics of
      passive and various forms of of hybrid active/passive measurements.</t>
    </section>

    <section title="New or Revised 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 path, where "flows" are determined by IP and other
              layers. Significant treatment differences occur with the
              simplest of Type-P parameters: packet length. Use of multiple
              lengths is RECOMMENDED.</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 path 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 paths.</t>

        <section title="Multiple Test Packet Lengths">
          <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="RFC6985"/>.</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 influence
          on link delay and link delay variation than serialization would
          explain alone. This effect can be non-linear and change the
          instantaneous network performance when a different size is used, or
          the performance of packets following the size change.</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
          deployment of 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>

          <t>Optimization can go beyond the scope of one single data- or
          measurement stream. Many more client- or network-centric
          optimization technologies have been proposed or standardized so far,
          including Robust Header Compression (ROHC) and Voice over IP
          aggregation as presented for instance in <xref target="EEAW"/>. The
          trend towards optimization being ubiquitous, many more of these
          technologies will follow. As general observation, the more
          concurrent flows an intermediate host treats and the longer the
          paths shared by flows are, the higher becomes the incentive of hosts
          to aggregate flows belonging to distinct sources. Measurements
          should consider this potential additional source of uncertainty with
          respect to repeatability. Aggregation of flows in networking devices
          can, for instance, result in reciprocal timing and performance
          influence of these flows which may exceed typical reciprocical
          queueing effects by orders of magnitude.</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. A detailed theoretical and practical analysis of
        RRC link transitions, which can cause such behavior in Universal
        Mobile Terrestrial System (UMTS) networks, is presented, e.g., in
        <xref target="RRC"/>.</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 paths 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 path behavior (e.g., because of data rate change).</t>
      </section>

      <section title="Time-Slotted Randomness Cancellation">
        <t>Time-Slotted operation of path 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 behavior of subsequent time-slotted
        network entities<xref target="TSRC"/>.</t>

        <t>Time-slotted randomness cancellation (TSRC) sources can be found in
        virtually any system, network component or path, their impact on
        measurements being a matter of the order of magnitude when compared to
        the metric under observation. Examples of TSRC sources include but are
        not limited to system clock resolution, operating system ticks,
        time-slotted component or network operation, etc. The amount of
        measurement bias is determined by the particular measurement stream,
        relative offset between allocated time-slots in subsequent path
        entities, delay variation in these paths, 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 path segments maintain flow state, flow parameter
        change or flow re-allocations can cause substantial variation in
        measurement results.</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"/>. In this context, the desirable measurement sample
        statistics differentiate between multi-modal delay distributions
        caused by reactive path behavior and the ones due to time-slotted
        interference.</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 path performance for a short time interval (in
        the order of minutes) and expect stable path conditions should
        therefore prefer end-to-end metrics. Here stable path 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 path performance is
        the main measurement goal, a segmented approach relying on measurement
        of sub-path metrics is preferred. Re-generating unbiased measurement
        traffic at any hop can help to reveal the true range of path
        performance for all path segments.</t>
      </section>
    </section>

    <section title="Quality of Metrics and Methodologies">
      <t><xref target="RFC6808"/> proposes repeatability and continuity as one
      of the metric and methodology properties to infer on measurement
      quality. Depending mainly on the set of controlled measurement
      parameters, measurements repeated for a specific network path using a
      specific methodology may or may not yield repeatable results.
      Challenging measurement scenarios for adequate parameter control include
      wireless, reactive, or time-slotted networks as discussed earlier in
      this document. This section presents an expanded definition of
      "repeatability" beyond the definition in <xref target="RFC2330"/> and an
      expanded examination of the <xref target="RFC2330"/> concept of
      "continuity" and its limited applicability.</t>

      <section title="Repeatability">
        <t><xref target="RFC2330"/> defines repeatability in a general
        way:</t>

        <t>"A methodology for a metric should have the property that it is
        repeatable: if the methodology is used multiple times under identical
        conditions, the same measurements should result in the same
        measurements."</t>

        <t>The challenge is to develop this definition further, such that it
        becomes an objective measurable criterion (and does not depend on the
        concept of continuity discussed below). Fortunately, this topic has
        been treated in other IPPM work. In BCP 176 <xref target="RFC6576"/>,
        the criteria of equivalent results was agreed as the surrogate for
        interoperability when assessing metric RFCs for standards track
        advancement. The criteria of equivalence were expressed as objective
        statistical requirements for comparison across same implementations
        and independent implementations in the test plans specific to each RFC
        evaluated (<xref target="RFC2679"/> in the test plan of <xref
        target="RFC6808"/>).</t>

        <t>The tests of <xref target="RFC6808"/> rely on nearly identical
        conditions to be present for analysis, but accept that these
        conditions cannot be exactly identical in the production network paths
        used. The test plans allow some correction factors to be applied (some
        statistical tests are hyper-sensitive to differences in the mean of
        distributions), and recognize the original findings of <xref
        target="RFC2330"/> regarding excess sample sizes.</t>

        <t>One way to view the reliance on identical conditions is to view it
        as a challenge: how few parameters and path conditions need to be
        controlled and still produce repeatable methods/measurements?</t>

        <t>Although the <xref target="RFC6808"/> test plan documented
        numerical criteria for equivalence, we cannot specify the exact
        numerical criteria for repeatability *in general*. The process in the
        BCP <xref target="RFC6576"/> and statistics in <xref
        target="RFC6808"/> have been used successfully, and the numerical
        criteria to declare a metric repeatable should be agreed by all
        interested parties prior to measurement.</t>

        <t>We revise the definition slightly, as follows:</t>

        <t>"A methodology for a metric should have the property that it is
        repeatable: if the methodology is used multiple times under identical
        conditions, the methods should produce equivalent measurement
        results."</t>
      </section>

      <section title="Continuity">
        <t>In the original framework <xref target="RFC2330"/>, the concept of
        continuity was introduced to provide a relaxed criteria for judging
        repeatability, and was described in section 6.2 of <xref
        target="RFC2330"/> as follows:</t>

        <t>"...a methodology for a given metric exhibits continuity if, for
        small variations in conditions, it results in small variations in the
        resulting measurements."</t>

        <t>Although there are conditions where metrics may exhibit continuity,
        there are others where this criteria would fail for both user traffic
        and active measurement traffic. Consider link fragmentation, and the
        non-linear increase in delay when we increase packet size just beyond
        the limit of a single fragment. An active measurement packet would see
        the same delay increase when exceeding the fragment size.</t>

        <t>The Bulk Transfer Capacity (BTC) <xref target="RFC3148"/> gives
        another example at bottom of page 2:</t>

        <t>"There is also evidence that most TCP implementations exhibit non-
        linear performance over some portion of their operating region. It is
        possible to construct simple simulation examples where incremental
        improvements to a path (such as raising the link data rate) results in
        lower overall TCP throughput (or BTC) <xref target="Mat98"/>."</t>

        <t>Clearly, the time-slotted network elements described in section 3.4
        above also qualifies as a new exception to the ideal of continuity.
        Therefore, we deprecate continuity as an alternate criterion on
        metrics, and prefer the more exact evaluation of repeatability
        instead.</t>
      </section>

      <section title="Actionable">
        <t>The IP Performance Metrics Framework <xref target="RFC2330"/>
        includes usefulness as a metric criterion:</t>

        <t>"...The metrics must be useful to users and providers in
        understanding the performance they experience or provide...".</t>

        <t>When considering measurements as part of a maintenance process,
        evaluation of measurement results for a path under observation can
        draw attention to potential performance problems "somewhere" on the
        path. Anomaly detection is therefore an important phase and first step
        which already satisfies the usefulness criterion for many metrics.</t>

        <t>This concept of usefulness can be extended, becoming a sub-set of
        what we refer to as "actionable" criterion in the following. Central
        to maintenance is the isolation of the root cause of reported
        anomalies down to a specific sub-path, link or host, and metrics
        should support this second step as well. While detection of path
        anomaly may be the result of an on-going monitoring process, the
        second step of cause isolation consists of specific, directed
        on-demand measurements on components and sub-paths. Metrics must
        support users in this directed search, becoming actionable:</t>

        <t>Metrics must enable users and operators to understand path
        performance and SHOULD help to direct corrective actions when
        warranted, based on the measurement results.</t>

        <t>Besides characterizing metrics, usefulness and actionable
        properties are also applicable to methodologies and measurements.</t>
      </section>

      <section title="Conservative">
        <t><xref target="RFC2330"/> adopts the term "conservative" for
        measurement methodologies for which:</t>

        <t>"... the act of measurement does not modify, or only slightly
        modifies, the value of the performance metric the methodology attempts
        to measure."</t>

        <t>It should be noted that this definition of "conservative" in the
        sense of <xref target="RFC2330"/> depends to a large extent on the
        measurement path's technology and characteristics. In particular, when
        deployed on reactive paths, sub-paths, links or hosts conforming to
        the definition in Section 1.1 of this document, measurement packets
        can originate capacity (re)allocations. In addition, small measurement
        flow variations can result in other users on the same path perceiving
        significant variations in measurement results.</t>
      </section>

      <section title="Spatial and Temporal Composition">
        <t>Concepts related to temporal and spatial composition of metrics in
        Section 9 of <xref target="RFC2330"/> have been extended in <xref
        target="RFC5835"/>. <xref target="RFC5835"/> defines multiple new
        types of metrics, including Spatial Composition, Temporal Aggregation,
        and Spatial Aggregation. So far, only the metrics for Spatial
        Composition have been standardized <xref target="RFC6049"/>, providing
        the ability to estimate the performance of a complete path from
        subpath metrics. Spatial Composition aligns with the finding of <xref
        target="TSRC"/>, that unbiased sampling is not possible beyond the
        first time-slotted link within a measurement path. In cases where
        measurement of subpaths is not feasible, restoring randomness of
        measurement samples when necessary is recommended as presented in
        <xref target="TSRC"/>.</t>
      </section>

      <section title="Poisson Sampling">
        <t>Section 11.1.1 of <xref target="RFC2330"/> describes Poisson
        sampling, where the inter-packet send times have a Poisson
        distribution. A path element with reactive behavior sensitive to flow
        inactivity could change state if the random inter-packet time is too
        long. It is recommended to truncate the tail of Poisson distribution
        to avoid reactive element state changes. Truncation has been used
        without issue to ensure that minimum sample sizes can be attained in a
        fixed test interval.</t>
      </section>
    </section>

    <section title="Conclusions">
      <t>Safeguarding repeatability as a key property of measurement
      methodologies is highly challenging and sometimes impossible in reactive
      paths. Measurements in paths 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 the path performance between one measurement session or packet
      stream and other streams with alternate characteristics is generally
      discouraged with reactive paths because of the huge set of global
      parameters which have influence on instantaneous path performance.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations that apply to any active measurement of
      live paths 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 Rudiger Geib, Matt Mathis and Konstantinos
      Pentikousis for their helpful comments on this memo, and Ann Cerveny for
      her editorial review and comments that helped to improve readability
      overall.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.RFC.6808'?>

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

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

      <?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" initials="J.F." surname="Fabini">
            <!-- fullname="J.Fabini"-->

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

          <author fullname="Wolfgang Karner" initials="W.K." surname="Karner">
            <!-- fullname="W.Karner" -->

            <organization>Mobilkom Austria AG</organization>
          </author>

          <author fullname="Lukas Wallentin" initials="L.W."
                  surname="Wallentin">
            <!-- fullname="L.Wallentin" -->

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

          <author fullname="Thomas Baumgartner" initials="T.B."
                  surname="Baumgartner">
            <!-- fullname="T.Baumgartner" -->

            <organization>Mobilkom Austria AG</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" initials="J.F." surname="Fabini">
            <!-- fullname="J.Fabini" -->

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

          <author fullname="Lukas Wallentin" initials="L.W."
                  surname="Wallentin">
            <!-- fullname="L.Wallentin" -->

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

          <author fullname="Peter Reichl" initials="P.R." surname="Reichl">
            <!-- fullname="P.Reichl" -->

            <organization>Telecommunications Research Center Vienna,
            ftw</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>

      <reference anchor="TSRC">
        <front>
          <title>Delay Measurement Methodology Revisited: Time-slotted
          Randomness Cancellation</title>

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

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

          <author fullname="Michael Abmayer" initials="M.A." surname="Abmayer">
            <!-- fullname="M.Abmayer" -->

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

          <date day="01" month="October" year="2013"/>
        </front>

        <seriesInfo name="IEEE Transactions on Instrumentation and Measurement"
                    value="doi:10.1109/TIM.2013.2263914"/>
      </reference>

      <reference anchor="RRC">
        <front>
          <title>Theory and Practice of RRC State Transitions in UMTS
          Networks</title>

          <author fullname="Pekka H.J. Per&auml;l&auml;" initials="P.H.J."
                  surname="Per&auml;l&auml;">
            <!-- fullname="P.Per?l?" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Antonio Barbuzzi" initials="A." surname="Barbuzzi">
            <!-- fullname="A.Barbuzzi" -->

            <organization>DEE - Politecnico di Bari</organization>
          </author>

          <author fullname="Gennaro Boggia" initials="G." surname="Boggia">
            <!-- fullname="G.Boggia" -->

            <organization>DEE - Politecnico di Bari</organization>
          </author>

          <author fullname="Kostas Pentikousis" initials="K."
                  surname="Pentikousis">
            <!-- fullname="K.Pentikousis" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <date day="30" month="November" year="2009"/>
        </front>

        <seriesInfo name="IEEE Globecom 2009 Workshops"
                    value="doi: 10.1109/GLOCOMW.2009.5360763"/>
      </reference>

      <reference anchor="EEAW">
        <front>
          <title>Empirical Evaluation of VoIP Aggregation over a Fixed WiMAX
          Testbed</title>

          <author fullname="Kostas Pentikousis" initials="K."
                  surname="Pentikousis">
            <!-- fullname="K.Pentikousis" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Esa Piri" initials="E." surname="Piri">
            <!-- fullname="E.Piri" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Jarno Pinola" initials="J." surname="Pinola">
            <!-- fullname="J.Pinola" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Frerk Fitzek" initials="F." surname="Fitzek">
            <!-- fullname="F.Fitzek" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Tuomas Nissil&auml;" initials="T."
                  surname="Nissil&auml;">
            <!-- fullname="T.Nissil?" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <author fullname="Ilkka Harjula" initials="I." surname="Harjula">
            <!-- fullname="I.Harjula" -->

            <organization>VTT Technical Research Centre of
            Finland</organization>
          </author>

          <date day="18" month="March" year="2008"/>
        </front>

        <seriesInfo name="Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks and communities (TridentCom '08)"
                    value="http://dl.acm.org/citation.cfm?id=1390599"/>
      </reference>

      <reference anchor="Mat98">
        <front>
          <title>Empirical Bulk Transfer Capacity</title>

          <author fullname="Matt Mathis" initials="M." surname="Mathis">
            <!-- fullname="M.Mathis" -->

            <organization>Pittsburgh Supercomputing Center</organization>
          </author>

          <date day="" month="December" year="1998"/>
        </front>

        <seriesInfo name="IP Performance Metrics Working Group report in Proceeding of the Forty Third Internet Engineering Task Force, Orlando, FL."
                    value="http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf"/>
      </reference>
    </references>
  </back>
</rfc>
