One document matched: draft-morton-ippm-rt-loss-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-morton-ippm-rt-loss-00" ipr="trust200902">
  <front>
    <title abbrev="Round-trip Loss">Round-trip Loss Metrics</title>

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

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

          <city>Middletown,</city>

          <region>NJ</region>

          <code>07748</code>

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

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

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

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

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

    <date day="4" month="July" year="2010" />

    <abstract>
      <t>Many user applications and the transport protocols that make them
      possible require two-way communications. To address this need, and also
      for system simplicity, round-trip loss measurements are frequently
      conducted in practice. The Two-Way Active Measurement Protocol specified
      in RFC 5357 establishes a round-trip loss measurement capability for the
      Internet. However, there is currently no metric specified according to
      the RFC 2330 framework.</t>

      <t>This memo proposes/adds round-trip loss to the set of IP Performance
      Metrics (IPPM).</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></t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This memo defines a metric for round-trip loss on Internet paths. It
      builds on the notions and conventions introduced in the IP Performance
      Metrics (IPPM) framework <xref target="RFC2330"></xref>. Also, the
      specifications of the One-way Loss metric <xref target="RFC2680"></xref>
      and the Round-trip Delay metric <xref target="RFC2681"></xref> are
      frequently referenced and modified to match the round-trip circumstances
      addressed here. However, this memo assumes that the reader is familiar
      with the references, and does not repeat material as was done in <xref
      target="RFC2681"></xref>.</t>

      <t>This memo uses the terms "two-way" and "round-trip" synonymously.</t>

      <section title="Motivation">
        <t>Many user applications and the transport protocols that make them
        possible require two-way communications. For example, the TCP
        SYN->, <-SYN-ACK, ACK-> three-way handshake attempted
        billions of times each day cannot be completed without two-way
        connectivity in a near-simultaneous time interval. Thus, measurements
        of Internet round-trip loss performance provide a basis to infer
        application performance more easily.</t>

        <t>Measurement system designers have also recognized advantages of
        system simplicity when one host simply echoes or reflects test packets
        to the sender. Round-trip loss measurements are frequently conducted
        and reported in practice. The Two-Way Active Measurement Protocol
        specified in <xref target="RFC5357"></xref> establishes a round-trip
        loss measurement capability for the Internet. However, there is
        currently no round-trip loss metric specified according to the <xref
        target="RFC2330"></xref> framework.</t>

        <t><xref target="RFC2681"></xref> indicates that round-trip
        measurements may sometimes encounter "asymmetric" paths. When loss is
        observed using a round-trip measurement, there is often a desire to
        ascertain which of the two directional paths "lost" the packet. Under
        some circumstances, it is possible to make this inference. The
        round-trip measurement method raises a few complications when
        interpreting the embedded one-way results, and the user should be
        aware of them.</t>

        <t><xref target="RFC2681"></xref> also points out that loss
        measurement conducted sequentially in both directions of a path and
        reported as a round-trip result may be exactly the desired metric. On
        the other hand, it may be difficult to derive the state of round-trip
        loss from one-way measurements conducted in each direction unless a
        method to match the appropriate one-way measurements has
        pre-arranged.</t>

        <t>Finally, many measurement systems report statistics on a
        conditional delay distribution, where the condition is packet arrival
        at the destination. This condition is encouraged in <xref
        target="RFC3393"></xref>, <xref target="RFC5481"></xref>, and
        [draft-ietf-ippm-reporting-metrics]. As a result, lost packets need to
        be reported separately, according to a standardized metric. This memo
        defines such a metric.</t>

        <t>See Section 1.1 of<xref target="RFC2680"></xref> for additional
        motivation of the packet loss metric.</t>
      </section>

      <section title="First Draft">
        <t>In this first draft, some sections are sections are very short or
        to-be-provided (TBP).</t>
      </section>
    </section>

    <section title="Scope">
      <t>This memo defines a round-trip loss metric using the conventions of
      the IPPM framework <xref target="RFC2330"></xref>.</t>

      <t>The memo defines a singleton metric, a sample metric, and a
      statistic, as per <xref target="RFC2330"></xref>.</t>

      <t>The memo also investigates topic of one-way loss inference from a
      two-way measurement, and lists some key considerations.</t>
    </section>

    <section title="Common Specifications for Round-trip 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>

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

      <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)
            as it leaves for Dst.</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 to arrive, set
            sufficiently long to disambiguate packets with long delays from
            packets that are discarded (lost).</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 <<<<<<<<<< this variable will
            be removed/re-used >>>>>>>>></t>

            <t>Type-P, as defined in <xref target="RFC2330"></xref>, which
            includes any field that may affect a packet's treatment as it
            traverses the network</t>
          </list></t>
      </section>

      <section title="Metric Definition">
        <t>This section is specific to each metric.</t>
      </section>

      <section title="Metric Units">
        <t>The metric units are logical (1 or 0) when describing a single
        packet's loss performance, where a 0 indicates successful packet
        transmission and a 1 indicates packet loss.</t>

        <t>Units of time are as specified in <xref
        target="RFC2330"></xref>.</t>

        <t>Other units used are defined in the associated section.</t>
      </section>
    </section>

    <section title="A Singleton Round-trip Loss Metric">
      <t></t>

      <section title="Name: Type-P-Round-trip-Loss">
        <t></t>
      </section>

      <section title="Metric Parameters">
        <t>See section 3.2.</t>
      </section>

      <section title="Definition and Metric Units">
        <t>Type-P-Round-trip-Loss SHALL be represented by the binary logical
        values (or their equivalents) when the following conditions are
        met:</t>

        <t>Type-P-Round-trip-Loss = 0:<list style="symbols">
            <t>Src sent the first bit of a Type-P packet to Dst at wire-time
            TstampSrc,</t>

            <t>that Dst received that packet,</t>

            <t>the Dst immediately sent a Type-P packet back to the Src,
            and</t>

            <t>that Src received the last bit of the reflected packet at
            wire-time TstampSrc + Tmax.</t>
          </list></t>

        <t>Type-P-Round-trip-Loss = 1:<list style="symbols">
            <t>Src sent the first bit of a Type-P packet to Dst at wire-time
            TstampSrc,</t>

            <t>that Src did not receive the last bit of the reflected packet
            before the waiting time lapsed at TstampSrc + Tmax</t>

            <t>(possibly because that Dst did not receive that packet,</t>

            <t>the Dst did not immediately sent a Type-P packet back to the
            Src, or</t>

            <t>the Src did not receive a reflected Type-P packet sent from the
            Dst).</t>
          </list></t>

        <t>Following the precedent of<xref target="RFC2681"></xref>, we make
        the simplifying assertion:</t>

        <t>Type-P-Round-trip-Loss(Src->Dst) =
        Type-P-Round-trip-Loss(Dst->Src)</t>

        <t>(and agree with the rationale, that the ambiguity introduced is a
        small price to pay for measurement efficiency).</t>

        <t>Therefore, each singleton can be represented by pairs of elements
        as follows: <list style="symbols">
            <t>TstampSrc, the wire time of the packet at the Src (beginning
            the round-trip journey).</t>

            <t>L, either zero or one (or some logical equivalent), where L=1
            indicates loss and L=0 indicates successful round-trip arrival
            prior to TstampSrc + Tmax.</t>
          </list></t>
      </section>

      <section title="Discussion and other details">
        <t>See <xref target="RFC2680"></xref> and <xref
        target="RFC2681"></xref> for extensive discussion, methods of
        measurement, errors and uncertainties, and other fundamental
        considerations that need not be repeated here.</t>
      </section>
    </section>

    <section title="A Sample Round-trip Loss Metric">
      <t>Given the singleton metric Type-P-Round-trip-Loss, we now define one
      particular sample of such singletons. The idea of the sample is to
      select a particular binding of the parameters Src, Dst, and Type-P, then
      define a sample of values of parameter TstampSrc. This can be done in
      several ways, including:<list style="numbers">
          <t>a pseudo-random Poisson process of rate lambda, whose values fall
          between T and Tf. The time interval between successive values of
          TstampSrc will then average 1/lambda, as per <xref
          target="RFC2330"></xref>.</t>

          <t>a periodic process stream process with pseudo-random start time
          T0 between T and dT, and nominal inter-packet interval incT, as per
          <xref target="RFC3432"></xref>.</t>
        </list></t>

      <section title="Name: Type-P-Round-trip-Loss-<Sample>-Stream">
        <t></t>
      </section>

      <section title="Metric Parameters">
        <t>See section 3.2.</t>
      </section>

      <section title="Definition and Metric Units">
        <t>Given one of the methods for defining the test interval, the sample
        of times (TstampSrc) and other metric parameters, we obtain a sequence
        of Type-P-Round-trip-Loss singletons as defined in section 4.3.</t>

        <t>Type-P-Round-trip-Loss-<Sample>-Stream SHALL be a sequence of
        pairs with elements as follows: <list style="symbols">
            <t>TstampSrc, as above</t>

            <t>L, either zero or one (or some logical equivalent), where L=1
            indicates loss and L=0 indicates successful round-trip arrival
            prior to TstampSrc + Tmax.</t>
          </list>where <Sample> SHALL be replaced with "Poisson",
        "Periodic", or an appropriate term to designate another sample method
        meeting the criteria of <xref target="RFC2330"></xref>.</t>
      </section>

      <section title="Discussion and other details">
        <t>See <xref target="RFC2680"></xref> and <xref
        target="RFC2681"></xref> for extensive discussion, methods of
        measurement, errors and uncertainties, and other fundamental
        considerations that need not be repeated here.</t>
      </section>
    </section>

    <section title="Round-trip Loss Statistic">
      <t>This section gives the primary and overall statistic for loss
      performance. Additional statistics and metrics originally prepared for
      One-way loss MAY also be applicable.</t>

      <section title="Type-P-Round-trip-Loss-<Sample>-Ratio">
        <t>Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average
        of all the logical values, L, in the Stream is the
        Type-P-Round-trip-Loss-<Sample>-Ratio. This ratio is in units of
        lost packets per round-trip transmissions attempted.</t>

        <t>In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is
        undefined if the sample is empty.</t>
      </section>
    </section>

    <section title="Round-trip Testing and One-way Reporting">
      <t>This section raises considerations for results collected using a
      round-trip measurement architecture, such as in TWAMP <xref
      target="RFC5357"></xref>.</t>

      <t>The sampling process for the return path (Dst->Src) is a
      conditional process that depends on successful packet arrival at the Dst
      and correct operation at the Dst to generate the reflected packet.</t>

      <t>Further, the sampling times for the return path (Dst->Src) are a
      random process that depends on the original sample times (TstampSrc),
      the one-way-delay for successful packet arrival at the Dst, and time
      taken at the Dst to generate the reflected packet.</t>

      <t>More details to-be-provided.</t>
    </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,
        and back. This method could be abused for denial of service attacks
        directed at the 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 IETF are typically registered in the IANA IPPM
      METRICS REGISTRY as described in initial version of the registry <xref
      target="RFC4148"></xref>. However, areas for improvement of this
      registry have been identified, and the registry structure has to be
      revisited when there is consensus to do so.</t>

      <t>Therefore, the metrics in this draft may be considered for
      registration in the future, and no IANA Action is requested at this
      time.</t>
    </section>

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

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

      <?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 include='reference.RFC.3432'?>

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

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

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

    <references title="Informative References">
      <reference anchor="Stats">
        <front>
          <title>Introduction to the Theory of Statistics, 3rd
          Edition,</title>

          <author fullname="A Mood, F Graybill and D Boes" surname="">
            <organization>McGraw-Hill NY NY</organization>
          </author>

          <date month=" " year="1974" />
        </front>
      </reference>

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

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

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