One document matched: draft-morton-ippm-2679-bis-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="info" docName="draft-morton-ippm-2679-bis-00" ipr="trust200902">
  <front>
    <title abbrev="A One-Way Delay Metric for IPPM">A One-Way Delay Metric for
    IPPM</title>

    <author fullname="Guy Almes" initials="G." surname="Almes">
      <organization/>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email/>

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

    <author fullname="S. Kalidindi" initials="S." surname="Kalidindi">
      <organization/>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email/>

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

    <author fullname="Matt Zekauskas" initials="M." surname="Zekauskas">
      <organization/>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email/>

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

    <author fullname="Al Morton" initials="A." surname="Morton, Ed.">
      <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="15" month="October" year="2012"/>

    <abstract>
      <t>This memo defines a metric for one-way delay of packets across
      Internet paths. It builds on notions introduced and discussed in the
      IPPM Framework document, RFC 2330; the reader is assumed to be familiar
      with that document.</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> This memo defines a metric for one-way delay of packets across
      Internet paths. It builds on notions introduced and discussed in the
      IPPM Framework document, RFC 2330 [1]; the reader is assumed to be
      familiar with that document. </t>

      <t>This memo is intended to be parallel in structure to a companion
      document for Packet Loss ("A One-way Packet Loss Metric for IPPM") [2].
      </t>

      <t>Although RFC 2119 was written with protocols in mind, the key words
      are used in this document for similar reasons. They are used to ensure
      the results of measurements from two different implementations are
      comparable, and to note instances when an implementation could perturb
      the network. </t>

      <t>The structure of the memo is as follows: </t>

      <t>+ A 'singleton' analytic metric, called Type-P-One-way-Delay, will be
      introduced to measure a single observation of one-way delay. </t>

      <t> + Using this singleton metric, a 'sample', called Type-P-One-way-
      Delay-Poisson-Stream, will be introduced to measure a sequence of
      singleton delays measured at times taken from a Poisson process. </t>

      <t>+ Using this sample, several 'statistics' of the sample will be
      defined and discussed. This progression from singleton to sample to
      statistics, with clear separation among them, is important. </t>

      <t>Whenever a technical term from the IPPM Framework document is first
      used in this memo, it will be tagged with a trailing asterisk. For
      example, "term*" indicates that "term" is defined in the Framework. </t>

      <section title="Motivation">
        <t/>
      </section>

      <section title="General Issues Regarding Time">
        <t/>
      </section>
    </section>

    <section title="A Singleton Definition for One-way Delay">
      <t/>

      <section title="Metric Name:">
        <t/>
      </section>

      <section title="Metric Parameters:">
        <t/>
      </section>

      <section title="Metric Units:">
        <t/>
      </section>

      <section title="Definition:">
        <t/>
      </section>

      <section title="Discussion:">
        <t/>
      </section>

      <section title="Methodologies:">
        <t/>
      </section>

      <section title="Errors and Uncertainties:">
        <t/>

        <section title="Errors or uncertainties related to Clocks">
          <t/>
        </section>

        <section title="Errors or uncertainties related to Wire-time vs Host-time">
          <t/>
        </section>

        <section title="Calibration">
          <t/>
        </section>
      </section>

      <section title="Reporting the metric:">
        <t/>

        <section title="Type-P">
          <t/>
        </section>

        <section title="Loss Threshold">
          <t/>
        </section>

        <section title="Calibration Results">
          <t/>
        </section>

        <section title="Path">
          <t/>
        </section>
      </section>
    </section>

    <section title="A Definition for Samples of One-way Delay">
      <t/>

      <section title="Metric Name:">
        <t/>
      </section>

      <section title="Metric Parameters:">
        <t/>
      </section>

      <section title="Metric Units:">
        <t/>
      </section>

      <section title="Definition:">
        <t/>
      </section>

      <section title="Discussion:">
        <t/>
      </section>

      <section title="Methodologies:">
        <t/>
      </section>

      <section title="Errors and Uncertainties:">
        <t/>
      </section>

      <section title="Reporting the metric:">
        <t/>
      </section>
    </section>

    <section title="Some Statistics Definitions for One-way Delay">
      <t/>

      <section title="Type-P-One-way-Delay-Percentile">
        <t/>
      </section>

      <section title="Type-P-One-way-Delay-Median">
        <t/>
      </section>

      <section title="Type-P-One-way-Delay-Minimum">
        <t/>
      </section>

      <section title="Type-P-One-way-Delay-Inverse-Percentile">
        <t/>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The</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</t>
    </section>

    <section title="Refetrences (temporary)">
      <t>[1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
      IP Performance Metrics", RFC 2330, May 1998. </t>

      <t>[2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss
      Metric for IPPM", RFC 2680, September 1999. </t>

      <t>[3] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
      </t>

      <t>[4] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
      Connectivity", RFC 2678, September 1999. </t>

      <t>[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
      </t>

      <t>[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997. </t>

      <t>[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996. </t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc ?>

      <?rfc ?>

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

      <reference anchor="ADK">
        <front>
          <title>K-sample Anderson-Darling Tests of fit, for continuous and
          discrete cases</title>

          <author fullname="Fred Scholz" initials="F.W." surname="Scholz">
            <!-- fullname="F.W. Scholz" -->

            <organization abbrev="Boeing">Boeing Computer
            Services</organization>
          </author>

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

            <organization>Simon Fraser University</organization>
          </author>

          <date month="May" year="1986"/>
        </front>

        <seriesInfo name="University of Washington, Technical Report"
                    value="No. 81"/>
      </reference>
    </references>
  </back>
</rfc>