<?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-ietf-ippm-spatial-composition-08"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="Spatial Composition">Spatial Composition of Metrics</title>

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

    <author fullname="Emile Stephan" initials="E." surname="Stephan">
      <organization>France Telecom Division R&amp;D</organization>

      <address>
        <postal>
          <street>2 avenue Pierre Marzin</street>

          <city>Lannion</city>

          <region></region>

          <code>F-22307</code>

          <country>France</country>
        </postal>

        <phone></phone>

        <facsimile>+33 2 96 05 18 52</facsimile>

        <email>emile.stephan@orange-ftgroup.com</email>

        <uri></uri>
      </address>
    </author>

    <date day="7" month="March" year="2009" />

    <abstract>
      <t>This memo utilizes IPPM metrics that are applicable to both complete
      paths and sub-paths, and defines relationships to compose a complete
      path metric from the sub-path metrics with some accuracy w.r.t. the
      actual metrics. This is called Spatial Composition in RFC 2330. The memo
      refers to the Framework for Metric Composition, and provides background
      and motivation for combining metrics to derive others. The descriptions
      of several composed metrics and statistics follow.</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>

      <t>In this memo, the characters "&lt;=" should be read as "less than or
      equal to" and "&gt;=" as "greater than or equal to".</t>
    </note>
  </front>

  <middle>
    <section title="Contributors">
      <t>Thus far, the following people have contributed useful ideas,
      suggestions, or the text of sections that have been incorporated into
      this memo:</t>

      <t>- Phil Chimento &lt;vze275m9@verizon.net&gt;</t>

      <t>- Reza Fardid &lt;RFardid@Covad.COM&gt;</t>

      <t>- Roman Krzanowski &lt;roman.krzanowski@verizon.com&gt;</t>

      <t>- Maurizio Molina &lt;maurizio.molina@dante.org.uk&gt;</t>

      <t>- Al Morton &lt;acmorton@att.com&gt;</t>

      <t>- Emile Stephan &lt;emile.stephan@orange-ftgroup.com&gt;</t>

      <t>- Lei Liang &lt;L.Liang@surrey.ac.uk&gt;</t>

      <t>- Dave Hoeflin &lt;dhoeflin@att.com&gt;</t>
    </section>

    <section title="Introduction">
      <t>The IPPM framework <xref target="RFC2330"></xref> describes two forms
      of metric composition, spatial and temporal. The new composition
      framework <xref target="I-D.ietf-ippm-framework-compagg"></xref> expands
      and further qualifies these original forms into three categories. This
      memo describes Spatial Composition, one of the categories of metrics
      under the umbrella of the composition framework.</t>

      <t>Spatial composition encompasses the definition of performance metrics
      that are applicable to a complete path, based on metrics collected on
      various sub-paths.</t>

      <t>The main purpose of this memo is to define the deterministic
      functions that yield the complete path metrics using metrics of the
      sub-paths. The effectiveness of such metrics is dependent on their
      usefulness in analysis and applicability with practical measurement
      methods.</t>

      <t>The relationships may involve conjecture, and <xref
      target="RFC2330"></xref> lists four points that the metric definitions
      should include: <list style="symbols">
          <t>the specific conjecture applied to the metric and assumptions of
          the statistical model of the process being measured (if any, see
          <xref target="RFC2330"></xref> section 12),</t>

          <t>a justification of the practical utility of the composition in
          terms of making accurate measurements of the metric on the path,</t>

          <t>a justification of the usefulness of the composition in terms of
          making analysis of the path using A-frame concepts more effective,
          and</t>

          <t>an analysis of how the conjecture could be incorrect.</t>
        </list>Also, <xref target="RFC2330"></xref> gives an example using the
      conjecture that the delay of a path is very nearly the sum of the delays
      of the exchanges and clouds of the corresponding path digest. This
      example is particularly relevant to those who wish to assess the
      performance of an Inter-domain path without direct measurement, and the
      performance estimate of the complete path is related to the measured
      results for various sub-paths instead.</t>

      <t>Approximate functions between the sub-path and complete path metrics
      are useful, with knowledge of the circumstances where the relationships
      are/are not applicable. For example, we would not expect that delay
      singletons from each sub-path would sum to produce an accurate estimate
      of a delay singleton for the complete path (unless all the delays were
      essentially constant - very unlikely). However, other delay statistics
      (based on a reasonable sample size) may have a sufficiently large set of
      circumstances where they are applicable.</t>

      <section title="Motivation">
        <t>One-way metrics defined in other IPPM RFCs all assume that the
        measurement can be practically carried out between the source and the
        destination of the interest. Sometimes there are reasons that the
        measurement can not be executed from the source to the destination.
        For instance, the measurement path may cross several independent
        domains that have conflicting policies, measurement tools and methods,
        and measurement time assignment. The solution then may be the
        composition of several sub-path measurements. This means each domain
        performs the One-way measurement on a sub path between two nodes that
        are involved in the complete path following its own policy, using its
        own measurement tools and methods, and using its own measurement
        timing. Under the appropriate conditions, one can combine the sub-path
        One-way metric results to estimate the complete path One-way
        measurement metric with some degree of accuracy.</t>
      </section>
    </section>

    <section title="Scope and Application">
      <t></t>

      <section title="Scope of work">
        <t>For the primary IPPM metrics of Loss, Delay, and Delay Variation,
        this memo gives a set of metrics that can be composed from the same or
        similar sub-path metrics. This means that the composition function may
        utilize: <list style="symbols">
            <t>the same metric for each sub-path;</t>

            <t>multiple metrics for each sub-path (possibly one that is the
            same as the complete path metric);</t>

            <t>a single sub-path metric that is different from the complete
            path metric;</t>

            <t>different measurement techniques like active and passive
            (recognizing that PSAMP WG will define capabilities to sample
            packets to support measurement).</t>
          </list></t>
      </section>

      <section title="Application">
        <t>The new composition framework <xref
        target="I-D.ietf-ippm-framework-compagg"></xref> requires the
        specification of the applicable circumstances for each metric. In
        particular, each section addresses whether the metric:</t>

        <t>Requires the same test packets to traverse all sub-paths, or may
        use similar packets sent and collected separately in each
        sub-path.</t>

        <t>Requires homogeneity of measurement methodologies, or can allow a
        degree of flexibility (e.g., active or passive methods produce the
        "same" metric). Also, the applicable sending streams will be
        specified, such as Poisson, Periodic, or both.</t>

        <t>Needs information or access that will only be available within an
        operator's domain, or is applicable to Inter-domain composition.</t>

        <t>Requires synchronized measurement time intervals in all sub-paths,
        or largely overlapping, or no timing requirements.</t>

        <t>Requires assumption of sub-path independence w.r.t. the metric
        being defined/composed, or other assumptions.</t>

        <t>Has known sources of inaccuracy/error, and identifies the
        sources.</t>
      </section>

      <section title="Incomplete Information">
        <t>In practice, when measurements cannot be initiated on a sub-path
        (and perhaps the measurement system gives up during the test
        interval), then there will not be a value for the sub-path reported,
        and the entire test result SHOULD be recorded as "undefined". This
        case should be distinguished from the case where the measurement
        system continued to send packets throughout the test interval, but all
        were declared lost.</t>

        <t>When a composed metric requires measurements from sub paths A, B,
        and C, and one or more of the sub-path results are undefined, then the
        composed metric SHOULD also be recorded as undefined.</t>
      </section>
    </section>

    <section title="Common Specifications for Composed Metrics">
      <t>To reduce the redundant information presented in the detailed metrics
      sections that follow, this section presents the specifications that are
      common to two or more metrics. The section is organized using the same
      subsections as the individual metrics, to simplify comparisons.</t>

      <t></t>

      <section title="Name: Type-P">
        <t>All metrics use the Type-P convention as described in <xref
        target="RFC2330"></xref>. The rest of the name is unique to each
        metric.</t>

        <section title="Metric Parameters">
          <t><list style="symbols">
              <t>Src, the IP address of a host</t>

              <t>Dst, the IP address of a host</t>

              <t>T, a time (start of test interval)</t>

              <t>Tf, a time (end of test interval)</t>

              <t>lambda, a rate in reciprocal seconds (for Poisson
              Streams)</t>

              <t>incT, the nominal duration of inter-packet interval, first
              bit to first bit (for Periodic Streams)</t>

              <t>T0, a time that MUST be selected at random from the interval
              [T, T+dT] to start generating packets and taking measurements
              (for Periodic Streams)</t>

              <t>TstampSrc, the wire time of the packet as measured at
              MP(Src)</t>

              <t>TstampDst, the wire time of the packet as measured at
              MP(Dst), assigned to packets that arrive within a "reasonable"
              time.</t>

              <t>Tmax, a maximum waiting time for packets at the destination,
              set sufficiently long to disambiguate packets with long delays
              from packets that are discarded (lost), thus the distribution of
              delay is not truncated.</t>

              <t>M, the total number of packets sent between T0 and Tf</t>

              <t>N, the total number of packets received at Dst (sent between
              T0 and Tf)</t>

              <t>S, the number of sub-paths involved in the complete Src-Dst
              path</t>
            </list></t>
        </section>

        <section title="Definition and Metric Units">
          <t>This section is unique for every metric.</t>
        </section>

        <section title="Discussion and other details">
          <t>This section is unique for every metric.</t>
        </section>

        <section title="Statistic:">
          <t>This section is unique for every metric.</t>
        </section>

        <section title="Composition Function">
          <t>This section is unique for every metric.</t>
        </section>

        <section title="Statement of Conjecture and Assumptions">
          <t>This section is unique for each metric.</t>
        </section>

        <section title="Justification of the Composition Function">
          <t>It is sometimes impractical to conduct active measurements
          between every Src-Dst pair. Since the full mesh of N measurement
          points grows as N x N, the scope of measurement may be limited by
          testing resources.</t>

          <t>There may be varying limitations on active testing in different
          parts of the network. For example, it may not be possible to collect
          the desired sample size in each test interval when access link speed
          is limited, because of the potential for measurement traffic to
          degrade the user traffic performance. The conditions on a low-speed
          access link may be understood well-enough to permit use of a small
          sample size/rate, while a larger sample size/rate may be used on
          other sub-paths.</t>

          <t>Also, since measurement operations have a real monetary cost,
          there is value in re-using measurements where they are applicable,
          rather than launching new measurements for every possible
          source-destination pair.</t>
        </section>

        <section title="Sources of Deviation from the Ground Truth">
          <section title="Sub-path List Differs from Complete Path">
            <t>The measurement packets, each having source and destination
            addresses intended for collection at edges of the sub-path, may
            take a different specific path through the network equipment and
            parallel links when compared to packets with the source and
            destination addresses of the complete path. Therefore, the
            performance estimated from the composition of sub-path
            measurements may differ from the performance experienced by
            packets on the complete path. Multiple measurements employing
            sufficient sub-path address pairs might produce bounds on the
            extent of this error.</t>
          </section>

          <section title="Sub-path Contains Extra Network Elements">
            <t>Related to the case of an alternate path described above is the
            case where elements in the measured path are unique to measurement
            system connectivity. For example, a measurement system may use a
            dedicated link to a LAN switch, and packets on the complete path
            do not traverse that link. The performance of such a dedicated
            link would be measured continuously, and its contribution to the
            sub-path metrics SHOULD be minimized as a source of error.</t>
          </section>

          <section title="Sub-paths Have Incomplete Coverage">
            <t>Measurements of sub-path performance may not cover all the
            network elements on the complete path. For example, the network
            exchange points might be excluded unless a cooperative measurement
            is conducted. In this example, test packets on the previous
            sub-path are received just before the exchange point and test
            packets on the next sub-path are injected just after the same
            exchange point. Clearly, the set of sub-path measurements SHOULD
            cover all critical network elements in the complete path.</t>
          </section>

          <section title="Absence of route">
            <t>********************</t>

            <t>Note: this section may be expressing the point of 4.1.8.1 in
            different words - its status is TBD.</t>

            <t>********************</t>

            <t>Sub-path destination addresses and complete path addresses do
            not belong to the same network. Therefore routes selected to reach
            each sub-path destinations differ from the route that would be
            selected to reach the destination address of the complete path.
            Consequently spatial composition may produce finite estimation of
            a ground true metric between a source Src and a destination Dst
            when the route between Src and Dst is undefined.</t>
          </section>
        </section>

        <section title="Specific cases where the conjecture might fail">
          <t>This section is unique for each metric (see the metric-specific
          sections).</t>
        </section>

        <section title="Application of Measurement Methodology">
          <t>The methodology:</t>

          <t>SHOULD use similar packets sent and collected separately in each
          sub-path.</t>

          <t>Allows a degree of flexibility regarding test stream generation
          (e.g., active or passive methods can produce an equivalent result,
          but the lack of control over the source, timing and correlation of
          passive measurements is much more challenging).</t>

          <t>Poisson and/or Periodic streams are RECOMMENDED.</t>

          <t>Applies to both Inter-domain and Intra-domain composition.</t>

          <t>SHOULD have synchronized measurement time intervals in all
          sub-paths, but largely overlapping intervals MAY suffice.</t>

          <t>REQUIRES assumption of sub-path independence w.r.t. the metric
          being defined/composed.</t>
        </section>
      </section>
    </section>

    <section title="One-way Delay Composed Metrics and Statistics">
      <t></t>

      <section title="Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream">
        <t>This metric is a necessary element of Delay Composition metrics,
        and its definition does not formally exist elsewhere in IPPM
        literature.</t>

        <section title="Metric Parameters">
          <t>See the common parameters section above.</t>
        </section>

        <section title="Definition and Metric Units">
          <t>Using the parameters above, we obtain the value of
          Type-P-One-way-Delay singleton as per <xref
          target="RFC2679"></xref>.</t>

          <t>For each packet [i] that has a finite One-way Delay (in other
          words, excluding packets which have undefined one-way delay):</t>

          <t>Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] =</t>

          <t>FiniteDelay[i] = TstampDst - TstampSrc</t>

          <t>The units of measure for this metric are time in seconds,
          expressed in sufficiently low resolution to convey meaningful
          quantitative information. For example, resolution of microseconds is
          usually sufficient.</t>
        </section>

        <section title="Discussion and other details">
          <t>The &ldquo;Type-P-Finite-One-way-Delay&rdquo; metric permits
          calculation of the sample mean statistic. This resolves the problem
          of including lost packets in the sample (whose delay is undefined),
          and the issue with the informal assignment of infinite delay to lost
          packets (practical systems can only assign some very large
          value).</t>

          <t>The Finite-One-way-Delay approach handles the problem of lost
          packets by reducing the event space. We consider conditional
          statistics, and estimate the mean one-way delay conditioned on the
          event that all packets in the sample arrive at the destination
          (within the specified waiting time, Tmax). This offers a way to make
          some valid statements about one-way delay, and at the same time
          avoiding events with undefined outcomes. This approach is derived
          from the treatment of lost packets in <xref
          target="RFC3393"></xref>, and is similar to <xref
          target="Y.1540"></xref> .</t>
        </section>
      </section>

      <section title="Name: Type-P-Finite-Composite-One-way-Delay-Mean">
        <t>This section describes a statistic based on the
        Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream metric.</t>

        <section title="Metric Parameters">
          <t>See the common parameters section above.</t>
        </section>

        <section title="Definition and Metric Units of the Mean Statistic">
          <t>We define<figure>
              <preamble>Type-P-Finite-One-way-Delay-Mean =</preamble>

              <artwork align="center"><![CDATA[                  N
                 ---
            1    \
MeanDelay = - *   >   (FiniteDelay [i])
            N    /
                 ---
                i = 1]]></artwork>

              <postamble></postamble>
            </figure></t>

          <t>where all packets i= 1 through N have finite singleton
          delays.</t>

          <t>The units of measure for this metric are time in seconds,
          expressed in sufficiently low resolution to convey meaningful
          quantitative information. For example, resolution of microseconds is
          usually sufficient.</t>
        </section>

        <section title="Discussion and other details">
          <t>The Type-P-Finite-One-way-Delay-Mean metric requires the
          conditional delay distribution described in section 5.1.</t>
        </section>

        <section title="Composition Function: Sum of Means">
          <t>The Type-P-Finite&mdash;Composite-One-way-Delay-Mean, or
          CompMeanDelay, for the complete Source to Destination path can be
          calculated from sum of the Mean Delays of all its S constituent
          sub-paths.</t>

          <t>Then the<figure>
              <preamble>Type-P-Finite-Composite-One-way-Delay-Mean
              =</preamble>

              <artwork align="center"><![CDATA[                  S
                 ---
                 \
CompMeanDelay =   >   (MeanDelay [i])
                 /
                 ---
                i = 1]]></artwork>

              <postamble></postamble>
            </figure></t>
        </section>

        <section title="Statement of Conjecture and Assumptions">
          <t>The mean of a sufficiently large stream of packets measured on
          each sub-path during the interval [T, Tf] will be representative of
          the ground truth mean of the delay distribution (and the
          distributions themselves are sufficiently independent), such that
          the means may be added to produce an estimate of the complete path
          mean delay.</t>

          <t>It is assumed that the one-way delay distributions of the
          sub-paths and the complete path are continuous.</t>
        </section>

        <section title="Justification of the Composition Function">
          <t>See the common section.</t>
        </section>

        <section title="Sources of Deviation from the Ground Truth">
          <t>See the common section.</t>
        </section>

        <section title="Specific cases where the conjecture might fail">
          <t>If any of the sub-path distributions are bimodal, then the
          measured means may not be stable, and in this case the mean will not
          be a particularly useful statistic when describing the delay
          distribution of the complete path.</t>

          <t>The mean may not be sufficiently robust statistic to produce a
          reliable estimate, or to be useful even if it can be measured.</t>

          <t>others...</t>
        </section>

        <section title="Application of Measurement Methodology">
          <t>The requirements of the common section apply here as well.</t>
        </section>
      </section>

      <section title="Name: Type-P-Finite-Composite-One-way-Delay-Minimum">
        <t>This section describes is a statistic based on the
        Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream metric, and the
        composed metric based on that statistic.</t>

        <section title="Metric Parameters">
          <t>See the common parameters section above.</t>
        </section>

        <section title="Definition and Metric Units of the Mean Statistic">
          <t>We define<figure>
              <preamble>Type-P-Finite-One-way-Delay-Minimum =</preamble>

              <artwork align="center"><![CDATA[= MinDelay = (FiniteDelay [j]) 

such that for some index, j, where 1<= j <= N
FiniteDelay[j] <= FiniteDelay[i] for all i

]]></artwork>

              <postamble></postamble>
            </figure></t>

          <t>where all packets i= 1 through N have finite singleton
          delays.</t>

          <t>The units of measure for this metric are time in seconds,
          expressed in sufficiently low resolution to convey meaningful
          quantitative information. For example, resolution of microseconds is
          usually sufficient.</t>
        </section>

        <section title="Discussion and other details">
          <t>The Type-P-Finite-One-way-Delay-Minimum metric requires the
          conditional delay distribution described in section 5.1.3.</t>
        </section>

        <section title="Composition Function: Sum of Means">
          <t>The Type-P-Finite&mdash;Composite-One-way-Delay-Minimum, or
          CompMinDelay, for the complete Source to Destination path can be
          calculated from sum of the Minimum Delays of all its S constituent
          sub-paths.</t>

          <t>Then the<figure>
              <preamble>Type-P-Finite-Composite-One-way-Delay-Minimum
              =</preamble>

              <artwork align="center"><![CDATA[                  S
                 ---
                 \
CompMinDelay =    >  (MinDelay [i])
                 /
                 ---
                i = 1]]></artwork>

              <postamble></postamble>
            </figure></t>
        </section>

        <section title="Statement of Conjecture and Assumptions">
          <t>The minimum of a sufficiently large stream of packets measured on
          each sub-path during the interval [T, Tf] will be representative of
          the ground truth minimum of the delay distribution (and the
          distributions themselves are sufficiently independent), such that
          the minima may be added to produce an estimate of the complete path
          minimum delay.</t>

          <t>It is assumed that the one-way delay distributions of the
          sub-paths and the complete path are continuous.</t>
        </section>

        <section title="Justification of the Composition Function">
          <t>See the common section.</t>
        </section>

        <section title="Sources of Deviation from the Ground Truth">
          <t>See the common section.</t>
        </section>

        <section title="Specific cases where the conjecture might fail">
          <t>If the routing on any of the sub-paths is not stable, then the
          measured minimum may not be stable. In this case the composite
          minimum would tend to produce an estimate for the complete path that
          may be too low for the current path.</t>

          <t>others???</t>
        </section>

        <section title="Application of Measurement Methodology">
          <t>The requirements of the common section apply here as well.</t>
        </section>
      </section>
    </section>

    <section title="Loss Metrics and Statistics">
      <t></t>

      <section title="Type-P-Composite-One-way-Packet-Loss-Empirical-Probability">
        <t></t>

        <section title="Metric Parameters:">
          <t>Same as section 4.1.1.</t>
        </section>

        <section title="Definition and Metric Units">
          <t>Using the parameters above, we obtain the value of
          Type-P-One-way-Packet-Loss singleton and stream as per <xref
          target="RFC2680"></xref>.</t>

          <t>We obtain a sequence of pairs with elements as follows: <list
              style="symbols">
              <t>TstampSrc, as above</t>

              <t>L, either zero or one, where L=1 indicates loss and L=0
              indicates arrival at the destination within TstampSrc +
              Tmax.</t>
            </list></t>
        </section>

        <section title="Discussion and other details">
          <t></t>
        </section>

        <section title="Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability">
          <t>Given the stream parameter M, the number of packets sent, we can
          define the Empirical Probability of Loss Statistic (Ep), consistent
          with Average Loss in [RFC2680], as follows:<figure>
              <preamble>Type-P-One-way-Packet-Loss-Empirical-Probability
              =</preamble>

              <artwork align="center"><![CDATA[           M
          ---
     1    \
Ep = - *   >  (L[i])
     M    /
          ---
         i = 1]]></artwork>

              <postamble></postamble>
            </figure></t>

          <t>where all packets i= 1 through M have a value for L.</t>
        </section>

        <section title="Composition Function: Composition of Empirical Probabilities">
          <t>The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability,
          or CompEp for the complete Source to Destination path can be
          calculated by combining Ep of all its constituent sub-paths (Ep1,
          Ep2, Ep3, ... Epn) as</t>

          <t><figure>
              <preamble>Type-P-Composite-One-way-Packet-Loss-Empirical-Probability
              =</preamble>

              <artwork><![CDATA[CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)}]]></artwork>

              <postamble></postamble>
            </figure></t>

          <t>If any Epn is undefined in a particular measurement interval,
          possibly because a measurement system failed to report a value, then
          any CompEp that uses sub-path n for that measurement interval is
          undefined.</t>
        </section>

        <section title="Statement of Conjecture and Assumptions">
          <t>The empirical probability of loss calculated on a sufficiently
          large stream of packets measured on each sub-path during the
          interval [T, Tf] will be representative of the ground truth
          empirical loss probability (and the probabilities themselves are
          sufficiently independent), such that the sub-path probabilities may
          be combined to produce an estimate of the complete path empirical
          loss probability.</t>
        </section>

        <section title="Justification of the Composition Function">
          <t>See the common section.</t>
        </section>

        <section title="Sources of Deviation from the Ground Truth">
          <t>See the common section.</t>
        </section>

        <section title="Specific cases where the conjecture might fail">
          <t>A concern for loss measurements combined in this way is that root
          causes may be correlated to some degree.</t>

          <t>For example, if the links of different networks follow the same
          physical route, then a single catastrophic event like a fire in a
          tunnel could cause an outage or congestion on remaining paths in
          multiple networks. Here it is important to ensure that measurements
          before the event and after the event are not combined to estimate
          the composite performance.</t>

          <t>Or, when traffic volumes rise due to the rapid spread of an
          email-born worm, loss due to queue overflow in one network may help
          another network to carry its traffic without loss.</t>

          <t>others...</t>
        </section>

        <section title="Application of Measurement Methodology">
          <t>See the common section.</t>
        </section>
      </section>
    </section>

    <section title="Delay Variation Metrics and Statistics">
      <t></t>

      <section title="Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream">
        <t>This packet delay variation (PDV) metric is a necessary element of
        Composed Delay Variation metrics, and its definition does not formally
        exist elsewhere in IPPM literature.</t>

        <section title="Metric Parameters:">
          <t>In addition to the parameters of section 4.1.1:<list
              style="symbols">
              <t>TstampSrc[i], the wire time of packet[i] as measured at
              MP(Src) (measurement point at the source)</t>

              <t>TstampDst[i], the wire time of packet[i] as measured at
              MP(Dst), assigned to packets that arrive within a "reasonable"
              time.</t>

              <t>B, a packet length in bits</t>

              <t>F, a selection function unambiguously defining the packets
              from the stream that are selected for the packet-pair
              computation of this metric. F(first packet), the first packet of
              the pair, MUST have a valid Type-P-Finite-One-way-Delay less
              than Tmax (in other words, excluding packets which have
              undefined one-way delay) and MUST have been transmitted during
              the interval T, Tf. The second packet in the pair, F(second
              packet) MUST be the packet with the minimum valid value of
              Type-P-Finite-One-way-Delay for the stream, in addition to the
              criteria for F(first packet). If multiple packets have equal
              minimum Type-P-Finite-One-way-Delay values, then the value for
              the earliest arriving packet SHOULD be used.</t>

              <t>MinDelay, the Type-P-Finite-One-way-Delay value for F(second
              packet) given above.</t>

              <t>N, the number of packets received at the Destination meeting
              the F(first packet) criteria.</t>
            </list></t>
        </section>

        <section title="Definition and Metric Units">
          <t>Using the definition above in section 5.1.2, we obtain the value
          of Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the
          singleton for each packet[i] in the stream (a.k.a.
          FiniteDelay[i]).</t>

          <t>For each packet[i] that meets the F(first packet) criteria given
          above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[i] =</t>

          <t>PDV[i] = FiniteDelay[i] &ndash; MinDelay</t>

          <t>where PDV[i] is in units of time in seconds, expressed in
          sufficiently low resolution to convey meaningful quantitative
          information. For example, resolution of microseconds is usually
          sufficient.</t>
        </section>

        <section title="Discussion and other details">
          <t>This metric produces a sample of delay variation normalized to
          the minimum delay of the sample. The resulting delay variation
          distribution is independent of the sending sequence (although
          specific FiniteDelay values within the distribution may be
          correlated, depending on various stream parameters such as packet
          spacing). This metric is equivalent to the IP Packet Delay Variation
          parameter defined in <xref target="Y.1540"></xref>.</t>
        </section>

        <section title="Statistics: Mean, Variance, Skewness, Quanitle">
          <t>We define the mean PDV as follows (where all packets i= 1 through
          N have a value for PDV[i]):</t>

          <figure>
            <preamble>Type-P-One-way-pdv-refmin-Mean = MeanPDV =</preamble>

            <artwork align="center"><![CDATA[      N
     ---
1    \
- *   >   (PDV[i])
N    /
     ---
    i = 1]]></artwork>

            <postamble></postamble>
          </figure>

          <t>We define the variance of PDV as follows:</t>

          <figure>
            <preamble>Type-P-One-way-pdv-refmin-Variance = VarPDV =</preamble>

            <artwork align="center"><![CDATA[          N
         ---
   1     \                      2
-------   >   (PDV[i] - MeanPDV)
(N - 1)  /
         ---
        i = 1]]></artwork>

            <postamble></postamble>
          </figure>

          <t></t>

          <t>We define the skewness of PDV as follows:</t>

          <figure>
            <preamble>Type-P-One-way-pdv-refmin-Skewness = SkewPDV
            =</preamble>

            <artwork align="center"><![CDATA[     N
    ---                        3
    \     /                  \
     >   |  PDV[i]- MeanPDV  |
    /     \                 /
    ---
   i = 1
-----------------------------------
    /                         \
   |                  ( 3/2 )  |
    \ (N - 1) * VarPDV        /]]></artwork>

            <postamble></postamble>
          </figure>

          <t></t>

          <t>We define the Quantile of the IPDVRefMin sample as the value
          where the specified fraction of singletons is less than the given
          value.</t>
        </section>

        <section title="Composition Functions:">
          <t>This section gives two alternative composition functions. The
          objective is to estimate a quantile of the complete path delay
          variation distribution. The composed quantile will be estimated
          using information from the sub-path delay variation
          distributions.</t>

          <section title="Approximate Convolution">
            <t>The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples
            from each sub-path are summarized as a histogram with 1 ms bins
            representing the one-way delay distribution.</t>

            <t>From [TBP], the distribution of the sum of independent random
            variables can be derived using the relation:</t>

            <t><figure>
                <preamble>Type-P-Composite-One-way-pdv-refmin-quantile-a
                =</preamble>

                <artwork align="center"><![CDATA[                     /  /
P(X + Y + Z <= a) = |  | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz
                   /  /
                   z  y]]></artwork>

                <postamble>where X, Y, and Z are random variables representing
                the delay variation distributions of the sub-paths of the
                complete path (in this case, there are three sub-paths), and a
                is the quantile of interest. Note dy and dz indicate partial
                integration here.</postamble>
              </figure>This relation can be used to compose a quantile of
            interest for the complete path from the sub-path delay
            distributions. The histograms with 1 ms bins are discrete
            approximations of the delay distributions.</t>
          </section>

          <section title="Normal Power Approximation">
            <t>Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source
            to Destination path can be calculated by combining statistics of
            all the constituent sub-paths in the following process:</t>

            <t>&lt; see <xref target="Y.1541"></xref> clause 8 and Appendix X
            &gt;</t>
          </section>
        </section>

        <section title="Statement of Conjecture and Assumptions">
          <t>The delay distribution of a sufficiently large stream of packets
          measured on each sub-path during the interval [T, Tf] will be
          sufficiently stationary and the sub-path distributions themselves
          are sufficiently independent, so that summary information describing
          the sub-path distributions can be combined to estimate the delay
          distribution of complete path.</t>

          <t>It is assumed that the one-way delay distributions of the
          sub-paths and the complete path are continuous.</t>
        </section>

        <section title="Justification of the Composition Function">
          <t>See the common section.</t>
        </section>

        <section title="Sources of Deviation from the Ground Truth">
          <t>In addition to the common deviations, a few additional sources
          exist here. For one, very tight distributions with range on the
          order of a few milliseconds are not accurately represented by a
          histogram with 1 ms bins. This size was chosen assuming an implicit
          requirement on accuracy: errors of a few milliseconds are acceptable
          when assessing a composed distribution quantile.</t>

          <t>Also, summary statistics cannot describe the subtleties of an
          empirical distribution exactly, especially when the distribution is
          very different from a classical form. Any procedure that uses these
          statistics alone may incur error.</t>
        </section>

        <section title="Specific cases where the conjecture might fail">
          <t>If the delay distributions of the sub-paths are somehow
          correlated, then neither of these composition functions will be
          reliable estimators of the complete path distribution.</t>

          <t>In practice, sub-path delay distributions with extreme outliers
          have increased the error of the composed metric estimate.</t>
        </section>

        <section title="Application of Measurement Methodology">
          <t>See the common section.</t>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t></t>

      <section title="Denial of Service Attacks">
        <t>This metric requires a stream of packets sent from one host
        (source) to another host (destination) through intervening networks.
        This method could be abused for denial of service attacks directed at
        destination and/or the intervening network(s).</t>

        <t>Administrators of source, destination, and the intervening
        network(s) should establish bilateral or multi-lateral agreements
        regarding the timing, size, and frequency of collection of sample
        metrics. Use of this method in excess of the terms agreed between the
        participants may be cause for immediate rejection or discard of
        packets or other escalation procedures defined between the affected
        parties.</t>
      </section>

      <section title="User Data Confidentiality">
        <t>Active use of this method generates packets for a sample, rather
        than taking samples based on user data, and does not threaten user
        data confidentiality. Passive measurement must restrict attention to
        the headers of interest. Since user payloads may be temporarily stored
        for length analysis, suitable precautions MUST be taken to keep this
        information safe and confidential. In most cases, a hashing function
        will produce a value suitable for payload comparisons.</t>
      </section>

      <section title="Interference with the metrics">
        <t>It may be possible to identify that a certain packet or stream of
        packets is part of a sample. With that knowledge at the destination
        and/or the intervening networks, it is possible to change the
        processing of the packets (e.g. increasing or decreasing delay) that
        may distort the measured performance. It may also be possible to
        generate additional packets that appear to be part of the sample
        metric. These additional packets are likely to perturb the results of
        the sample measurement.</t>

        <t>To discourage the kind of interference mentioned above, packet
        interference checks, such as cryptographic hash, may be used.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Metrics defined in this memo will be registered in the IANA IPPM
      METRICS REGISTRY as described in initial version of the registry <xref
      target="RFC4148"></xref>.</t>
    </section>

    <section title="Acknowlegements">
      <t>A long time ago, in a galaxy far, far away (Minneapolis), Will Leland
      suggested the simple and elegant Type-P-Finite-One-way-Delay concept.
      Thanks Will.</t>

      <t></t>
    </section>

    <section title="Issues (Open and Closed)">
      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;Issue:</t>

      <t>Is Section 4.1.8.4 really describing a new error case, about
      Alternate Routing? Or does Section 4.1.8.1 on sub-path differences cover
      it all?</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;Issue:</t>

      <t>What is the relationship between the decomposition and composition
      metrics? Should we put both kinds in one draft to make up a framework?
      The motivation of decomposition is as follows:</t>

      <t>The One-way measurement can provide result to show what the network
      performance between two end hosts is and whether it meets operator
      expectations or not. It cannot provide further information to engineers
      where and how to improve the performance between the source and the
      destination. For instance, if the network performance is not acceptable
      in terms of the One-way measurement, in which part of the network the
      engineers should put their efforts. This question can to be answered by
      decompose the One-way measurement to sub-path measurement to investigate
      the performance of different part of the network.</t>

      <t>Editor&rsquo;s Questions for clarification: What additional
      information would be provided to the decomposition process, beyond the
      measurement of the complete path?</t>

      <t>Is the decomposition described above intended to estimate a metric
      for some/all disjoint sub-paths involved in the complete path?</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;RESOLUTION:
      treat this topic in a separate memo</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;Issue</t>

      <t>Section 7 defines a new type of metric, a &ldquo;combination&rdquo;
      of metrics for one-way delay and packet loss. The purpose of this metric
      is to link these two primary metrics in a convenient way.</t>

      <t>Readers are asked to comment on the efficiency of the combination
      metric.</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;RESOLUTION:
      If a delay singleton is recorded as having "undefined" delay when the
      packet does not arrive within the waiting time Tmax, then this
      information is sufficient to determine the fraction of lost packets in
      the sample, and the additional loss indication of this combo is not
      needed.</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;
      Issue</t>

      <t>Can we introduce multicast metrics here, without causing too much
      confusion? Should the multicast version of this draft wait until the
      Unicast concepts are stable (or maybe appear in a separate draft)?</t>

      <t>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;RESOLUTION:
      No and Yes.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.ietf-ippm-framework-compagg'?>

      <?rfc include="reference.RFC.2119"?>

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

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

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

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

      <?rfc ?>

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

    <references title="Informative References">
      <reference anchor="Y.1540">
        <front>
          <title>Internet protocol data communication service - IP packet
          transfer and availability performance parameters</title>

          <author fullname="" surname="ITU-T Recommendation Y.1540">
            <organization></organization>
          </author>

          <date month="December " year="2002" />
        </front>
      </reference>

      <reference anchor="Y.1541">
        <front>
          <title>Network Performance Objectives for IP-based Services</title>

          <author fullname="" surname="ITU-T Recommendation Y.1541">
            <organization></organization>
          </author>

          <date month="February " year="2006" />
        </front>
      </reference>

      <?rfc include='reference.I-D.ietf-ippm-multimetrics'?>
    </references>
  </back>
</rfc>