<?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-mornulo-ippm-registry-columns-01"
     ipr="trust200902">
  <front>
    <title abbrev="Registry for Perf Metrics">A(nother) Registry for
    Performance Metrics</title>

    <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
      <organization abbrev="UC3M">Universidad Carlos III de
      Madrid</organization>

      <address>
        <postal>
          <street>Av. Universidad 30</street>

          <city>Leganes</city>

          <region>Madrid</region>

          <code>28911</code>

          <country>SPAIN</country>
        </postal>

        <phone>34 91 6249500</phone>

        <email>marcelo@it.uc3m.es</email>

        <uri>http://www.it.uc3m.es</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>

    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">British Telecom</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>philip.eardley@bt.com</email>
      </address>
    </author>

    <date day="21" month="October" year="2013"/>

    <abstract>
      <t>This memo investigates a scheme to organize registry entries,
      especially those defined in RFCs prepared in the IP Performance Metrics
      (IPPM) Working Group of the IETF, and applicable to all IETF metrics.
      Three aspects make IPPM metric registration difficult: (1) Use of the
      Type-P notion to allow users to specify their own packet types. (2) Use
      of flexible input variables, called Parameters in IPPM definitions, some
      which determine the quantity measured and others which should not be
      specified until execution of the measurement. (3) Allowing flexibility
      in choice of statistics to summarize the results on a stream of
      measurement packets. Specifically, this memo proposes a way to organize
      registry entries into columns that are well-defined, permiting
      consistent development of entries over time. Also, this fosters
      development of registry entries based on existing reference RFCs for
      performance metrics, and requires expert review for every entry before
      IANA action.</t>

      <t>This version contains an example registry entry for a passive
      endpoint metric based on RFC7003, an example active metric entry based
      on RFC3393 and RFC5481, and an example pure passive metric based on
      RFC5472. Also, this version *continues* to allow blank entries in
      columns which have no applicability to a specific metric, or class of
      metrics. This is preferred to more general registry organization because
      each column serves as a check-list item and helps to avoid omissions
      during registration and expert review.</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/>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This memo investigates a scheme to organize registry entries,
      especially those defined in RFCs prepared in the IP Performance Metrics
      (IPPM) Working Group of the IETF, according to their framework <xref
      target="RFC2330"/>. Three aspects make IPPM metric registration
      difficult: (1) Use of the Type-P notion to allow users to specify their
      own packet types. (2) Use of Flexible input variables, called Parameters
      in IPPM definitions, some which determine the quantity measured and
      others which should not be specified until execution of the measurement.
      (3) Allowing flexibility in choice of statistics to summarize the
      results on a stream of measurement packets. This memo uses terms and
      definitions from the IPPM literature, primarily <xref
      target="RFC2330"/>, and the reader is assumed familiar with them or may
      refer questions there as necessary.</t>

      <t>Although there are several standard templates for organizing
      specifications of performance metrics (see <xref target="RFC2679"/> for
      an example of the traditional IPPM template, based to large extent on
      the Benchmarking Methodology Working Group's traditional template in
      <xref target="RFC1242"/>, and see <xref target="RFC6390"/> for a similar
      template), none of these templates was intended to become the basis for
      the columns of an IETF-wide registry of metrics. As we examine the
      aspects of metric specifications which need to be registered, we will
      see that none of the existing metric templates fully satisfies the needs
      of a registry.</t>

      <t>The authors of [draft-bagnulo-ippm-new-registry] and
      [draft-bagnulo-ippm-new-registry-independent] made important
      contributions to this memo in the registry column structure, and the
      problem of registry development in general. We also acknowledge input
      from the authors of [draft-claise-ippm-perf-metric-registry], especially
      the value of an Element ID and the need for naming conventions.</t>

      <section title="Background and Motivation">
        <t>The motivation for having such registry is to allow a controller to
        request a measurement agent to execute a measurement using a specific
        metric. Such request can be performed using any control protocol that
        refers to the value assigned to the specific metric in the registry.
        Similarly, the measurement agent can report the results of the
        measurement and by referring to the metric value it can unequivocally
        identify the metric that the results correspond to.</t>

        <t>There was a previous attempt to define a metric registry <xref
        target="RFC4148">RFC 4148</xref>. However, it was obsoleted by <xref
        target="RFC6248">RFC 6248</xref> because it was "found to be
        insufficiently detailed to uniquely identify IPPM metrics... [there
        was too much] variability possible when characterizing a metric
        exactly" which led to the RFC4148 registry having "very few users, if
        any".</t>

        <t>Our approach learns from this, by tightly defining each entry in
        the registry with only a few parameters open for each. The idea is
        that the entries in the registry represent different measurement
        tests, whilst the run-time parameters set things like source and
        destination addresses that don't change the fundamental nature of the
        test. The downside of this approach is that it could result in an
        explosion in the number of entries in the registry. We believe that
        less is more in this context - it is better to have a reduced set of
        useful metrics rather than a large set of metrics with questionable
        usefulness. Therefore this document defines that the registry only
        includes commonly used metrics that are well defined; hence we require
        both reference specification required AND expert review policies for
        the assignment of values in the registry.</t>

        <t>There are several side benefits of having such a registry. First
        the registry could serve as an inventory of useful and used metrics,
        that are normally supported by different implementations of
        measurement agents. Second, the results of the metrics would be
        comparable even if they are performed by different implementations and
        in different networks, as the metric is properly defined.</t>

        <t>The registry forms part of a Characterization Plan. It describes
        various factors that need to be set by the party controlling the
        measurements, for example: specific values for the parameters
        associated with the selected registry entry (for instance, source and
        destination addresses); and how often the measurement is made. The
        Characterization Plan determines the individual Measurement
        Instructions that will be communicated to measurement agents, whose
        task is then to execute the Instruction autonomously.</t>

        <t>Measurement Instructions might look something like: "Dear
        measurement agent: Please start test DNS(example.com) and
        RTT(server.com,150) every day at 2000 GMT. Run the DNS test 5 times
        and the RTT test 50 times. Do that when the network is idle. Generate
        both raw results and 99th percentile mean. Send measurement results to
        collector.com in IPFIX format". The Characterization Plan depends on
        the requirements of the controlling party. For instance the broadband
        consumer might want a one-off measurement made immediately to one
        specific server; a regulator might want the same measurement made once
        a day until further notice to the 'top 10' servers; whilst an operator
        might want a varying series of tests (some of which will be beyond
        those defined in the registry) as determined from time to time by
        their operational support system. While the registries defined in this
        document help to define the Characterization Plan, its full
        specification falls outside the scope of this document, and other IETF
        work as currently chartered.</t>
      </section>
    </section>

    <section title="Scope">
      <t>Specifically, this memo proposes a way to organize registry entries
      into columns that are well-defined, permiting consistent development of
      entries over time. Also, this fosters development of registry entries
      based on existing reference RFCs for performance metrics, and requires
      expert review for every entry before IANA action.</t>

      <t>In this memo, we attempt a combinatoric registry, where all factors
      that can be reasonably specified ARE specified, and changing even one
      factor would require a new registry entry (row). It is believed that
      this exercise can also be instructive for a registry based on
      independent factors, [draft-bagnulo-ippm-new-registry-independent] but
      that topic is beyond the scope of this effort.</t>

      <t>Entries in the registry must reference an existing RFC or other
      recognized standard, and are subject to expert review. The expert review
      must make sure that the proposed metric is operationally useful. This
      means that the metric has proven to be useful in operational/real
      scenarios.</t>
    </section>

    <section title="Registry Categories and Columns">
      <t>This section briefly describes the categories and columns proposed
      for the registry, as this is likely to be a topic for discussion and
      revision. Below, categories are described at the 3.x heading level, and
      columns are at the 3.x.y heading level. The Figure below illustrates
      this organization.</t>

      <t>Taken as a whole, the entries in the columns give a registered
      instance of a metric with sufficient specificity to promote comparable
      results across independent implementations. In other words, a *complete
      description* of a Metric Instance. Some instances may not require
      entries in all columns, but this is preferred to more general
      organization because each column serves as a check-list item and helps
      to avoid omissions during registration and expert review.<figure>
          <artwork><![CDATA[ Registry Categories and Columns, shown as
                                                Category
                                                ------------------
                                                Column |  Column |
Registry Indexes
---------------------------
Element ID |  Metric Name |


Metric Definition
--------------------------------------------------------
Reference Definition | Fixed Parameters | Metric Units |


Method of Measurement
-------------------------------------------------------------------------
Reference Method | Stream Type and Param | Output Type | Run-time Param |


Comments and Remarks
--------------------


]]></artwork>
        </figure></t>

      <section title="Registry Indexes">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="Element ID">
          <t>An integer having enough digits to uniquely identify each entry
          in the Registry.</t>
        </section>

        <section title="Metric Name">
          <t>A metric naming convention is TBD.</t>

          <t>The current guidance from Section 13 of <xref target="RFC2330"/>,
          where Type-P is a feature of all IPPM metric names, is:</t>

          <t>"... we introduce the generic notion of a "packet of type P",
          where in some contexts P will be explicitly defined (i.e., exactly
          what type of packet we mean), partially defined (e.g., "with a
          payload of B octets"), or left generic. Thus we may talk about
          generic IP-type-P-connectivity or more specific
          IP-port-HTTP-connectivity. Some metrics and methodologies may be
          fruitfully defined using generic type P definitions which are then
          made specific when performing actual measurements. Whenever a
          metric's value depends on the type of the packets involved in the
          metric, the metric's name will include either a specific type or a
          phrase such as "type-P". ..."</t>

          <t>Registry entries are a context where Type-P must be defined.</t>

          <t>IPPM Metric names have also included the typically included the
          stream type, to distinguish between singleton and sample metrics
          (see <xref target="RFC2330"/> for the definition of these
          terms).</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        detalis related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>This entry provides references to relevant sections of the RFC(s)
          defining the metric, as well as any supplemental information needed
          to ensure an unambiguous definition for implementations.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Fixed Parameters are input factors that must be determined and
          embedded in the measurement system for use when needed. The values
          of these parameters is specified in the Registry.</t>

          <t>Where referenced metrics supply a list of Parameters as part of
          their descriptive template, a sub-set of the Parameters will be
          designated as Fixed Parameters. For example, Fixed Parameters
          determine most or all of the IPPM Framework convention "packets of
          Type-P" as described in <xref target="RFC2330"/>, such as transport
          protocol, payload length, TTL, etc.</t>

          <t>A Parameter which is Fixed for one Registry entry may be
          designated as a Run-time Parameter for another Registry entry.</t>
        </section>

        <section title="Metric Units">
          <t>The measured results of a metric must be expressed using some
          standard dimension or units of measure. This column provides the
          units (and if possible, the data format, whose specification will
          simplify both measurement implementation and collection/storage
          tasks, see the Output Type column below).</t>

          <t>When a sample of singletons (see <xref target="RFC2330"/> for
          definitions of these terms) is collected, this entry will specify
          the units for each measured value.</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>This entry provides references to relevant sections of the RFC(s)
          describing the method of measurement, as well as any supplemental
          information needed to ensure unambiguous interpretation for
          implementations referring to the RFC text.</t>
        </section>

        <section title="Stream Type and Stream Parameters">
          <t>Principally, two different streams are used in IPPM metrics,
          Poisson distributed as described in <xref target="RFC2330"/> and
          Periodic as described in <xref target="RFC3432"/>. Both Poisson and
          Periodic have their own unique parameters, and the relevant set of
          values is specified in this column.</t>

          <t>Some metrics, such as those intended for passive monitoring or
          RTCP and RTCP-XR metrics, will not specifiy an entry for this
          column.</t>

          <t>Each entry for this column contains the following information:
          <list style="symbols">
              <t>Value: The name of the packet stream scheduling disipline</t>

              <t>Stream Parameters: The values and formats of input factors
              for each type of stream. For example, the average packet rate
              and distribution truncation value for streams with
              Poisson-distributed inter-packet sending times.</t>

              <t>Reference: the specification where the stream is defined</t>
            </list></t>

          <t>The simplest example of stream specification is Singleton
          scheduling, where a single atomic measurement is conducted. Each
          atomic measurement could consist of sending a single packet (such as
          a DNS request) or sending several packets (for example, to request a
          a webpage). Other streams support a series of atomic measurements in
          a "sample", with a schedule defining the timing between each
          transmited packet and subsequent measurement.</t>
        </section>

        <section title="Output Type and Data Format">
          <t>For entries which involve a stream and many singleton
          measurements, a statistic may be specified in this column to
          summarize the results to a single value. If the complete set of
          measured singletons is output, this will be specified here.</t>

          <t>Some metrics embed one specific statistic in the reference metric
          definition, while others allow several output types or
          statistics.</t>

          <t>Each entry in the output type column contains the following
          information: <list style="symbols">
              <t>Value: The name of the output type</t>

              <t>Data Format: provided to simplify the communication with
              collection systems and implementation of measurement
              devices.</t>

              <t>Reference: the specification where the output type is
              defined</t>
            </list></t>

          <t>The output type defines the type of result that the metric
          produces. It can be the raw results or it can be some form of
          statistic. The specification of the output type must define the
          format of the output. Note that if two different statistics are
          required from a single measurement (for example, both "Xth
          percentile mean" and "Raw"), then a new output type must be defined
          ("Xth percentile mean AND Raw").</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-Time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete. However, the values of these
          parameters is not specified in the Registry, rather these parameters
          are listed as an aid to the measurement system implementor or user
          (they must be left as variables, and supplied on execution).</t>

          <t>Where metrics supply a list of Parameters as part of their
          descriptive template, a sub-set of the Parameters will be designated
          as Run-Time Parameters.</t>

          <t>The Data Format of each Run-time Parameter SHALL be specified in
          this column, to simplify the control and implementation of
          measurement devices.</t>

          <t>Examples of Run-time Parameters include IP addresses, measurement
          point designations, start times and end times for measurement, and
          other measurement-specific information.</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Besides providing additional details which do not appear in other
        categories, this open Category (single column) allows for unforeseen
        issues to be addressed by simply updating this Informational
        entry.</t>
      </section>
    </section>

    <section title="Example RTCP-XR Registry Entry">
      <t>This section gives an example registry entry for the passive
      (end-point) metric described in RFC 7003 <xref target="RFC7003"/>, for
      RTCP-XR Burst/Gap Discard Metric reporting.</t>

      <section title="Registry Indexes">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="Element ID">
          <t>An integer having enough digits to uniquely identify each entry
          in the Registry.</t>
        </section>

        <section title="Metric Name">
          <t>A metric naming convention is TBD.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        detalis related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters. Section 3.2 of
        <xref target="RFC7003"/> provides the reference information for this
        category.</t>

        <section title="Reference Definition">
          <t>Packets Discarded in Bursts:</t>

          <t>The total number of packets discarded during discard bursts. The
          measured value is unsigned value. If the measured value exceeds
          0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an
          over-range measurement. If the measurement is unavailable, the value
          0xFFFFFF MUST be reported.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Fixed Parameters are input factors that must be determined and
          embedded in the measurement system for use when needed. The values
          of these parameters is specified in the Registry.</t>

          <t>Threshold: 8 bits, set to value = 3 packets.</t>

          <t>The Threshold is equivalent to Gmin in [RFC3611], i.e., the
          number of successive packets that must not be discarded prior to and
          following a discard packet in order for this discarded packet to be
          regarded as part of a gap. Note that the Threshold is set in
          accordance with the Gmin calculation defined in Section 4.7.2 of
          [RFC3611].</t>

          <t>Interval Metric flag: 2 bits, set to value 11=Cumulative
          Duration</t>

          <t>This field is used to indicate whether the burst/gap discard
          metrics are Sampled, Interval, or Cumulative metrics [RFC6792]:</t>

          <t>I=10: Interval Duration - the reported value applies to the most
          recent measurement interval duration between successive metrics
          reports.</t>

          <t>I=11: Cumulative Duration - the reported value applies to the
          accumulation period characteristic of cumulative measurements.</t>

          <t>Senders MUST NOT use the values I=00 or I=01.</t>
        </section>

        <section title="Metric Units">
          <t>The measured results are apparently expressed in packets,
          although there is no section of <xref target="RFC7003"/> titled
          "Metric Units".</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations. For the Burst/Gap Discard
        Metric, it appears that the only guidance on methods of measurement is
        in Section 3.0 of <xref target="RFC7003"/> and its supporting
        references. Relevant information is repeated below, although there
        appears to be no section titled "Method of Measurement" in <xref
        target="RFC7003"/>.</t>

        <section title="Reference Method">
          <t>Metrics in this block report on burst/gap discard in the stream
          arriving at the RTP system. Measurements of these metrics are made
          at the receiving end of the RTP stream. Instances of this metrics
          block use the synchronization source (SSRC) to refer to the separate
          auxiliary Measurement Information Block [RFC6776], which describes
          measurement periods in use (see [RFC6776], Section 4.2).</t>

          <t>This metrics block relies on the measurement period in the
          Measurement Information Block indicating the span of the report.
          Senders MUST send this block in the same compound RTCP packet as the
          Measurement Information Block. Receivers MUST verify that the
          measurement period is received in the same compound RTCP packet as
          this metrics block. If not, this metrics block MUST be
          discarded.</t>
        </section>

        <section title="Stream Type and Stream Parameters">
          <t>Since RTCP-XR Measurements are conducted on live RTP traffic, the
          complete description of the stream is contained in SDP messages that
          proceed the establishment of a compatible stream between two or more
          communicating hosts. See Run-time Parameters, below.</t>
        </section>

        <section title="Output Type and Data Format">
          <t>The output type defines the type of result that the metric
          produces.</t>

          <t><list style="symbols">
              <t>Value: Packets Discarded in Bursts</t>

              <t>Data Format: 24 bits</t>

              <t>Reference: Section 3.2 of <xref target="RFC7003"/></t>
            </list></t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-Time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete. However, the values of these
          parameters is not specified in the Registry, rather these parameters
          are listed as an aid to the measurement system implementor or user
          (they must be left as variables, and supplied on execution).</t>

          <t>The Data Format of each Run-time Parameter SHALL be specified in
          this column, to simplify the control and implementation of
          measurement devices.</t>

          <t>SSRC of Source: 32 bits As defined in Section 4.1 of
          [RFC3611].</t>

          <t>SDP Parameters: As defined in [RFC4566]</t>

          <t>Session description v= (protocol version number, currently only
          0)</t>

          <t>o= (originator and session identifier : username, id, version
          number, network address)</t>

          <t>s= (session name : mandatory with at least one UTF-8-encoded
          character)</t>

          <t>i=* (session title or short information) u=* (URI of
          description)</t>

          <t>e=* (zero or more email address with optional name of
          contacts)</t>

          <t>p=* (zero or more phone number with optional name of
          contacts)</t>

          <t>c=* (connection information&mdash;not required if included in all
          media)</t>

          <t>b=* (zero or more bandwidth information lines) One or more Time
          descriptions ("t=" and "r=" lines; see below)</t>

          <t>z=* (time zone adjustments)</t>

          <t>k=* (encryption key)</t>

          <t>a=* (zero or more session attribute lines)</t>

          <t>Zero or more Media descriptions (each one starting by an "m="
          line; see below)</t>

          <t>m= (media name and transport address)</t>

          <t>i=* (media title or information field)</t>

          <t>c=* (connection information &mdash; optional if included at
          session level)</t>

          <t>b=* (zero or more bandwidth information lines)</t>

          <t>k=* (encryption key)</t>

          <t>a=* (zero or more media attribute lines &mdash; overriding the
          Session attribute lines)</t>

          <t>An example Run-time SDP description follows:</t>

          <t>v=0</t>

          <t>o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5</t>

          <t>s=SDP Seminar i=A Seminar on the session description protocol</t>

          <t>u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com
          (Jane Doe)</t>

          <t>c=IN IP4 224.2.17.12/127</t>

          <t>t=2873397496 2873404696</t>

          <t>a=recvonly</t>

          <t>m=audio 49170 RTP/AVP 0</t>

          <t>m=video 51372 RTP/AVP 99</t>

          <t>a=rtpmap:99 h263-1998/90000</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Besides providing additional details which do not appear in other
        categories, this open Category (single column) allows for unforeseen
        issues to be addressed by simply updating this Informational
        entry.</t>
      </section>
    </section>

    <section title="Example IPPM Active Registry Entry">
      <t>This section gives an example registry entry for the active metric
      described in <xref target="RFC3393"/>, on Packet Delay Variation.</t>

      <section title="Registry Indexes">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="Element ID">
          <t>An integer having enough digits to uniquely identify each entry
          in the Registry.</t>
        </section>

        <section title="Metric Name">
          <t>A metric naming convention is TBD.</t>

          <t>One possibility based on IPPM's framework is:</t>

          <t>IP-UDP-One-way-pdv-95th-percentile-Poisson</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        detalis related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>See sections 2.4 and 3.4 of <xref target="RFC3393"/>. Singleton
          delay differences measured are referred to by the variable name
          "ddT".</t>
        </section>

        <section title="Fixed Parameters">
          <t>Where metrics supply a list of Parameters as part of their
          descriptive template, a sub-set of the Parameters will be designated
          as Fixed Parameters.</t>

          <t><list style="symbols">
              <t>F, a selection function defining unambiguously the packets
              from the stream selected for the metric. See section 4.2 of
              <xref target="RFC5481"/> for the PDV form.</t>

              <t>L, a packet length in bits. L = 200 bits.</t>

              <t>Tmax, a maximum waiting time for packets to arrive at Dst,
              set sufficiently long to disambiguate packets with long delays
              from packets that are discarded (lost). Tmax = 3 seconds.</t>

              <t>Type-P, as defined in <xref target="RFC2330"/>, which
              includes any field that may affect a packet's treatment as it
              traverses the network. The packets are IP/UDP, with DSCP = 0
              (BE).</t>
            </list></t>
        </section>

        <section title="Metric Units">
          <t>See section 3.3 of <xref target="RFC3393"/> for singleton
          elements.</t>

          <t><xref target="RFC2330"/> recommends that when a time is given, it
          will be expressed in UTC.</t>

          <t>The timestamp format (for T, Tf, etc.) is the same as in <xref
          target="RFC5905"/> (64 bits) and is as follows: the first 32 bits
          represent the unsigned integer number of seconds elapsed since 0h on
          1 January 1900; the next 32 bits represent the fractional part of a
          second that has elapsed since then.</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>See section 2.6 and 3.6 of <xref target="RFC3393"/> for singleton
          elements.</t>
        </section>

        <section title="Stream Type and Stream Parameters">
          <t>Poisson distributed as described in <xref target="RFC2330"/>,
          with the following Parameters.</t>

          <t><list style="symbols">
              <t>lambda, a rate in reciprocal seconds (for Poisson Streams).
              lambda = 1 packet per second</t>

              <t>Upper limit on Poisson distribution (values above this limit
              will be clipped and set to the limit value). Upper limit = 30
              seconds.</t>
            </list></t>
        </section>

        <section title="Output Type and Data Format">
          <t>See section 4.3 of <xref target="RFC3393"/> for details on the
          percentile statistic.</t>

          <t>The percentile = 95.</t>

          <t>Data format is a 32-bit unsigned floating point value.</t>

          <t>Individual results (singletons) should be represented by the
          following triple</t>

          <t><list style="symbols">
              <t>T1 and T2, times as described below in the Run-time
              parameters section.</t>

              <t>ddT as defined in section 2.4 of <xref target="RFC3393"/></t>
            </list>if needed. The result format for ddT is *similar to* the
          short format in <xref target="RFC5905"/> (32 bits) and is as
          follows: the first 16 bits represent the *signed* integer number of
          seconds; the next 16 bits represent the fractional part of a
          second.</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Where metrics supply a list of Parameters as part of their
          descriptive template, a sub-set of the Parameters will be designated
          as Run-Time Parameters. In related registry entries, some of the
          parameters below may be designated as Fixed Parameters instead.</t>

          <t><list style="symbols">
              <t>Src, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>Dst, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>T, a time (start of test interval, 128-bit NTP Date Format,
              see section 6 of <xref target="RFC5905"/>)</t>

              <t>Tf, a time (end of test interval, 128-bit NTP Date Format,
              see section 6 of <xref target="RFC5905"/>)</t>

              <t>T1, the wire time of the first packet in a pair, measured at
              MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see
              section 6 of <xref target="RFC5905"/>).</t>

              <t>T2, the wire time of the second packet in a pair, measured at
              MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see
              section 6 of <xref target="RFC5905"/>).</t>

              <t>I(i),I(i+1), i &gt;=0, pairs of times which mark the
              beginning and ending of the intervals in which the packet stream
              from which the measurement is taken occurs. Here, I(0) = T0 and
              assuming that n is the largest index, I(n) = Tf (pairs of 64-bit
              NTP Timestamp Format, see section 6 of <xref
              target="RFC5905"/>).</t>
            </list></t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Lost packets represent a challenge for delay variation metrics. See
        section 4.1 of <xref target="RFC3393"/> and the delay variation
        applicability statement<xref target="RFC5481"/> for extensive analysis
        and comparison of PDV and IPDV.</t>
      </section>
    </section>

    <section title="Example IPFIX RTT Pair Matching Registry Entry">
      <t>This section gives an example registry entry for the passive metric
      described in section 2.5.2.1 of <xref target="RFC5472"/>, for Round-Trip
      Time (RTT) Measurements with Packet Pair Matching (Single-Point).</t>

      <section title="Registry Indexes">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="Element ID">
          <t>An integer having enough digits to uniquely identify each entry
          in the Registry.</t>
        </section>

        <section title="Metric Name">
          <t>A metric naming convention is TBD.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters. Section 2.5.2.1
        of <xref target="RFC5472"/> provides the reference information for
        this category.</t>

        <section title="Reference Definition">
          <t>Observations of both directions are required to correlate
          request/response packet pairs.</t>

          <t>Pair matching techniques are described in <xref
          target="Brow00"/>.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Fixed Parameters are input factors that must be determined and
          embedded in the measurement system for use when needed. The values
          of these parameters is specified in the Registry.</t>

          <t>Protocol (Pair Type): TCP (SYN/SYN_ACK)</t>

          <t>Note: other possibilities are DNS, ICMP, SNMP or TCP (DATA/ACK),
          discussed in <xref target="Brow00"/>.</t>
        </section>

        <section title="Metric Units">
          <t>The measured results are expressed in microseconds, which follows
          the format of Information Elements per observed packet, see section
          8.4.3 of<xref target="RFC5477"/> titled
          "observationTimeMicroseconds".</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations. </t>

        <section title="Reference Method">
          <t>For the TCP(SYN/SYN_ACK) RTT metric, the guidance on methods of
          measurement is in slides 12 and 15 of <xref target="Brow00"/>. </t>

          <t>Recognition of request response pairs is a REQUIRED function, as
          is the correlation of data from both directions of transmission, see
          section 2.5.2.1 of <xref target="RFC5472"/>.</t>

          <t>The method requires the collection of the following Information
          Elements per packet:</t>

          <t><list style="symbols">
              <t>Packet arrival time: observationTimeMicroseconds, see section
              8.4.3 of<xref target="RFC5477"/></t>

              <t>TCP header: ipPayloadPacketSection, see section 8.5.2 of<xref
              target="RFC5477"/></t>
            </list></t>
        </section>

        <section title="Stream Type and Stream Parameters">
          <t>Since IPFIX passive Measurements are conducted on live/production
          network traffic, the measurement methods rely on user-generated
          packet flows. Such flows are not described in this column.</t>
        </section>

        <section title="Output Type and Data Format">
          <t>The output type defines the type of result that the metric
          produces.</t>

          <t><list style="symbols">
              <t>Value: RTT in microseconds</t>

              <t>Data Format: (There may be some precedent to follow here, but
              otherwise use 64-bit NTP Timestamp Format, see section 6 of
              <xref target="RFC5905"/>).</t>

              <t>Reference: Section 2.5.2.1 of <xref target="RFC5472"/></t>
            </list></t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete. However, the list of
          Run-time parameters is not specified for purely passive metrics, as
          there are infinite possibilities.</t>

          <t>A likely Run-time parameter is the Destination host, which may be
          given as a Fully-Qualified Domain Name as done in <xref
          target="Brow00"/>, or an IP address of the host (32-bit value for
          IPv4, 128-bit value for IPv6).</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Additional (Informational) details for this entry, from <xref
        target="Brow00"/>:</t>

        <t>Can't get RTT for every packet, only those which are ACKed.</t>

        <t>Overlapping packets (resent) are counted as lost, but not queued.
        This means the first copy of resent packets are used for RTTs, giving
        a high RTT estimate.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This registry has no known implications on Internet Security.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Metrics previously defined in IETF were registered in the IANA IPPM
      METRICS REGISTRY, however this process was discontinued when the
      registry structure was found to be inadequate, and the registry was
      declared Obsolete <xref target="RFC6248"/>.</t>

      <t>The form of metric registration will finalized in the future, and no
      IANA Action is requested at this time.</t>
    </section>

    <section title="Acknowledgements">
      <t>The author thanks Brian Trammell for suggesting the term "Run-time
      Parameters", which led to the distinction between run-time and fixed
      parameters implemented in this memo.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc ?>

      <?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.5905'?>

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

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

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

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

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

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

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

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

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

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

      <reference anchor="Brow00">
        <front>
          <title>Packet Matching for NeTraMet Distributions</title>

          <author fullname="N.Brownlee" initials="N." surname="Brownlee">
            <organization>&lt;http://www.caida.org/tools/measurement/
            netramet/packetmatching/&gt;</organization>
          </author>

          <date month="March" year="2000"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
