One document matched: draft-mornuley-ippm-initial-registry-01.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-mornuley-ippm-initial-registry-01"
ipr="trust200902">
<front>
<title abbrev="Initial Registry">Initial Performance Metric Registry
Entries</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>
<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="Philip Eardley" initials="P." surname="Eardley">
<organization abbrev="BT">BT</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="9" month="March" year="2015"/>
<abstract>
<t>This memo defines the Initial Entries for the Performance Metrics
Registry.</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>Note: Efforts to synchronize structure and terminology with <xref
target="I-D.ietf-ippm-metric-registry"/> will likely be incomplete until
both drafts are stable.</t>
<t>This memo defines the Initial set of entries for the Performance
Metric Registry. The registry will contain Active Performance Metrics,
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 were intended to become the basis for
the columns of an IETF-wide registry of metrics. As we examined the
aspects of metric specifications which need to be registered, it was
clear that none of the existing metric templates fully satisfies the
particular needs of a registry.</t>
</section>
<section title="Scope">
<t><xref target="I-D.ietf-ippm-metric-registry"/> defines the overall
structure for a Performance Metric Registry and provides guidance for
the process to examine proposed metrics and maitain Registered
Metrics.</t>
<t>This document defines the initial set of Performance Metrics Registry
entries; all are active metrics, or those where the packets measured
have been specially generated for the purpose.</t>
<t>A row in the registry corresponds to one Registered Performance
Metric, with entries in the various columns specifying the metric.</t>
<t>As discussed in <xref target="I-D.ietf-ippm-metric-registry"/>, each
entry (row) must be tightly defined; the definition must leave open only
a few parameters that do not change the fundamental nature of the
measurement (such as source and destination addresses), and so promotes
comparable results across independent implementations. Also, each
registered entry must be based on existing reference RFCs (or other
standards) for performance metrics, and must be operationally useful and
have significant industry interest. This is ensured by expert review for
every entry before IANA action.</t>
</section>
<section title="Registry Categories and Columns">
<t>This section defines the categories and columns of the registry.
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. An entry (row) therefore gives a complete description of a
Registered Metric.</t>
<t>Each column serves as a check-list item and helps to avoid omissions
during registration and expert review. In some cases an entry (row) may
have some columns without specific entries, marked Not Applicable (NA).
<figure>
<artwork><![CDATA[THIS NEEDS UPDATING
Registry Categories and Columns, shown as
Category
------------------
Column | Column |
Comments and Remarks
--------------------
]]></artwork>
</figure></t>
</section>
<section title="UDP Round-trip Latency Registry Entry">
<t>This section gives an initial registry entry for the UDP Round-trip
Latency.</t>
<t>Note: If each Registry entry should only produce a "raw" output or a
statistical summary, then the "Output" Category can be split and this
section can become two closely-related metrics.</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<section title="ID (Identifier)">
<t><insert numeric identifier, an integer></t>
</section>
<section title="Name">
<t><insert name according to metric naming convention></t>
<t>Act_IP_UDP_Round-trip_Delay_Raw_95th-percentile_Poisson</t>
<t>URL: ??</t>
</section>
<section title="URI">
<t>URI: Prefix urn:ietf:params:performance:metric...<name></t>
</section>
<section title="Description">
<t>This metric assesses the delay of a stream of packets exchanged
between two hosts (or measurement points), and reports the
Round-trip delay for all successfully exchanged packets and the 95th
percentile of their conditional delay distribution.</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.</t>
<section title="Reference Definition">
<t><Full bibliographic reference to an immutable doc.></t>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><xref target="RFC2681"/></t>
<t><specific section reference and additional clarifications, if
needed></t>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference
definition of the singleton (single value) Round-trip delay metric.
Section 3.4 of <xref target="RFC2681"/> provides the reference
definition expanded to cover a multi-value sample. Note that terms
such as singleton and sample are defined in Section 11 of <xref
target="RFC2330"/>.</t>
<t>Note that although the definition of "Round-trip-Delay between
Src and Dst at T" is directionally ambiguous in the text, this
metric tightens the definition further to recognize that the host in
the "Src" role will send the first packet to "Dst", and ultimately
receive the corresponding return packet from "Dst" (when neither are
lost).</t>
</section>
<section title="Fixed Parameters">
<t><list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed></t>
<t>Type-P: <list style="symbols">
<t>IPv4 header values: <list style="symbols">
<t>DSCP: set to 0</t>
<t>TTL set to 255</t>
<t>Protocol: Set to 17 (UDP)</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum must be calculated</t>
</list></t>
<t>Payload <list style="symbols">
<t>Sequence number: 8-byte integer</t>
<t>Timestamp: 8 byte integer. Expressed as 64-bit NTP
timestamp as per section 6 of <xref target="RFC5905">RFC
5905</xref></t>
<t>No padding (total of 9 bytes)</t>
</list></t>
</list></t>
<t>Timeout, Tmax: 3 seconds</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 metric, insert relevant section references and
supplemental info></t>
<t>The methodology for this metric is defined as
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
target="RFC2681">RFC 2681</xref> using the Type-P and Timeout
defined under Fixed Parameters.</t>
<t>The method requires sequence numbers or other send-order
information to be retained at the Src or included with each packet
to dis-ambiguate packet reordering if it occurs. Sequence number is
part of the payload described under Fixed Parameters.</t>
<t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded
discussion of the instruction to "send a Type-P packet back to the
Src as quickly as possible" in Section 2.6 of <xref
target="RFC2681">RFC 2681</xref>. Section 8 of <xref
target="RFC6673"/> presents additional requirements which shall be
included in the method of measurement for this metric.</t>
</section>
<section title="Packet Generation Stream">
<t>This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream
parameters.</t>
<t><list of generation parameters and section/spec references if
needed></t>
<t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides
three methods to generate Poisson sampling intervals. the reciprocal
of lambda is the average packet rate, thus the Run-time Parameter is
1/lambda.</t>
<t>>>> Check with Sam, most likely it is this...</t>
<t>Method 3 is used, where given a start time (Run-time Parameter),
the subsequent send times are all computed prior to measurement by
computing the pseudo-random distribution of inter-packet send times,
(truncating the distribution as specified in the Run-time
Parameters), and the Src sends each packet at the computed
times.</t>
</section>
<section title="Traffic Filtering (observation) Details">
<t>The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).</t>
<t><section reference>.</t>
<t>NA</t>
</section>
<section title="Sampling Distribution">
<t><insert time distribution details, or how this is diff from
the filter></t>
<t>NA</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.</t>
<t><list of run-time parameters, and their data formats></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>T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>). When T0 is
"all-zeros", a start time is unspecified and Tf is to be
interpreted as the Duration of the measurement interval.</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>), interpreted
as the Duration of the measurement interval.</t>
<t>1/lambda, average packet rate (for Poisson Streams).
(1/lambda = 1 packet per second, if fixed)</t>
<t>Upper limit on Poisson distribution (values above this limit
will be clipped and set to the limit value). (if fixed, Upper
limit = 30 seconds.)</t>
</list>The format for 1/lambda and Upper limit of Poisson Dist.
are the short format in <xref target="RFC5905"/> (32 bits) and is as
follows: the first 16 bits represent the integer number of seconds;
the next 16 bits represent the fractional part of a second.</t>
<t>>>> should Poisson run-time params be fixed instead?
probably yes if modeling a specific version of MBA tests.</t>
</section>
<section title="Roles">
<t><lists the names of the different roles from the measurement
method></t>
<t>Src - launches each packet and waits for return transmissions
from Dst.</t>
<t>Dst - waits for each packet from Src and sends a return packet to
Src.</t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the Output of measurements
using the metric.</t>
<section title="Type/Value (two diff terms used)">
<t><insert name of the output type, raw or a selected summary
statistic></t>
<t>Raw -- for each packet sent, pairs of values.</t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of Round-trip delay (undefined delays are
excluded), a single value corresponding to the 95th percentile.</t>
</section>
<section title="Data Format">
<t><describe the data format for each type of result></t>
<t>For all outputs ---</t>
<t><list style="symbols">
<t>T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
</list></t>
<t>Raw -- for each packet sent, pairs of values as follows:</t>
<t><list style="symbols">
<t>T, the time when the packet was sent from Src, 128-bit NTP
Date Format, see section 6 of <xref target="RFC5905"/>)</t>
<t>dT, a value of Round-trip delay, format is *similar to* the
32-bit short NTP Time format in Section 6 of <xref
target="RFC5905"/> 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>
<t>dT is undefined when the packet is not received at Src in
waiting time Tmxax seconds (need undefined code)</t>
</list></t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of Round-trip delay (undefined delays are
excluded), a single value as follows:</t>
<t>See section 4.1 of <xref target="RFC3393"/> for details on the
conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this
analysis choice.</t>
<t>See section 4.3 of <xref target="RFC3393"/> for details on the
percentile statistic (where Round-trip delay should be substituted
for "ipdv").</t>
<t>The percentile = 95.</t>
<t>Data format is a 32-bit signed value, *similar to* the 32-bit
short NTP Time format in Section 6 of <xref target="RFC5905"/> 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="Reference">
<t><pointer to section/spec where output type/format is
defined></t>
<t>See the Data Format column for references.</t>
</section>
<section title="Metric Units">
<t><insert units for the measured results, and the reference
specification>.</t>
<t>Round-trip Delay, dT, is expressed in seconds.</t>
<t>The 95th Percentile of Round-trip Delay is expressed in
seconds.</t>
</section>
</section>
<section title="Administrative items">
<t/>
<section title="Status">
<t><current or depricated></t>
</section>
<section title="Requestor (keep?)">
<t>name or RFC, etc.</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this entry</t>
</section>
</section>
<section title="Packet Delay Variation Registry Entry">
<t>This section gives an initial registry entry for a Packet Delay
Variation metric.</t>
<t>Note: If each Registry entry should only produce a "raw" output or a
statistical summary, then the "Output" Category can be split and this
section can become two closely-related metrics.</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<t><skipping some Summary columns for now></t>
<section title="ID (Identifier)">
<t><insert numeric identifier, an integer></t>
</section>
<section title="Name">
<t><insert name according to metric naming convention></t>
<t>Act_IP-UDP-One-way-pdv-95th-percentile-Poisson</t>
<t>URL: ??</t>
</section>
<section title="URI">
<t>URI: Prefix urn:ietf:params:performance:metric<add
name></t>
</section>
<section title="Description">
<t>An assessment of packet delay variation with respect to the
minimum delay observed on the stream.</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.</t>
<section title="Reference Definition">
<t><Full bibliographic reference to an immutable doc.></t>
<t>Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998. <xref
target="RFC2330"/></t>
<t>Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)", RFC 3393, November 2002. <xref
target="RFC3393"/></t>
<t>Morton, A. and B. Claise, "Packet Delay Variation Applicability
Statement", RFC 5481, March 2009. <xref target="RFC5481"/></t>
<t>Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
Protocol Version 4: Protocol and Algorithms Specification", RFC
5905, June 2010.<xref target="RFC5905"> </xref></t>
<t><specific section reference and additional clarifications, if
needed></t>
<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><list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed></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>
<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 metric, insert relevant section references and
supplemental info></t>
<t>See section 2.6 and 3.6 of <xref target="RFC3393"/> for singleton
elements.</t>
</section>
<section title="Packet Generation Stream">
<t><list of generation parameters and section/spec references if
needed></t>
<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="Traffic Filtering (observation) Details">
<t><insert the measured results based on a filtered version of
the packets observed, and this section provides the filter details
(when present), and section reference>.</t>
<t>NA</t>
</section>
<section title="Sampling Distribution">
<t><insert time distribution details, or how this is diff from
the filter></t>
<t>NA</t>
</section>
<section title="Run-time Parameters and Data Format">
<t><list of run-time parameters, and any reference(s)>.</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 measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>). When T0 is
"all-zeros", a start time is unspecified and Tf is to be
interpreted as the Duration of the measurement interval.</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>), interpreted
as the Duration of the measurement interval.</t>
</list></t>
</section>
<section title="Roles">
<t><lists the names of the different roles from the measurement
method></t>
<t>Src - the host that sends the stream of packets.</t>
<t>Dst - the host that receives the stream of packets.</t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the Output of measurements
using the metric.</t>
<section title="Type/Value (two diff terms used)">
<t><insert name of the output type, raw or a selected summary
statistic></t>
<t>Raw -- for each packet sent, pairs of values.</t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of one-way delay (undefined delays are excluded),
a single value corresponding to the 95th percentile of the
singletons, ddT.</t>
</section>
<section title="Data Format">
<t><describe the data format for each type of result></t>
<t>For all Output types</t>
<t><list style="symbols">
<t>T, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
</list></t>
<t>Raw -</t>
<t><list style="symbols">
<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 >=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>
<t>When the one-way delay of a packet in the calculation pair
for ddT is undefined, then ddT is undefined for that pair.</t>
</list></t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of one-way delay (undefined delays are excluded),
a single value as follows:</t>
<t>See section 4.1 of <xref target="RFC3393"/> for details on the
conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this
analysis choice.</t>
<t>See section 4.3 of <xref target="RFC3393"/> for details on the
percentile statistic (where pdv should be substituted for
"ipdv").</t>
<t>The percentile = 95.</t>
<t>Data format is a 32-bit signed floating point value, *similar to*
the 32-bit short NTP Time format in Section 6 of <xref
target="RFC5905"/> 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="Reference">
<t><pointer to section/spec where output type/format is
defined></t>
<t>see Data Format column.</t>
</section>
<section title="Metric Units">
<t><insert units for the measured results, and the reference
specification>.</t>
<t>See section 3.3 of <xref target="RFC3393"/> for singleton
elements, ddT. The units are seconds, and the same units are used
for 95th percentile.</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="Administrative items">
<t/>
<section title="Status">
<t><current or depricated></t>
</section>
<section title="Requestor (keep?)">
<t><name of individual or RFC, etc.></t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
</section>
<section title="Comments and Remarks">
<t><Additional (Informational) details for this entry></t>
<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 an alternate metric, IPDV.</t>
</section>
</section>
<section title="DNS Response Latency Registry Entry">
<t>This section gives an initial registry entry for DNS Response
Latency. <xref target="RFC2681">RFC 2681</xref> defines a Round-trip
delay metric. We build on that metric by specifying several of the input
parameters to precisely define a metric for measuring DNS latency.</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<t><skipping some admin columns for now></t>
<section title="ID (Identifier)">
<t><insert numeric identifier, an integer></t>
</section>
<section title="Name">
<t><insert name according to metric naming convention></t>
<t>URL: ??</t>
</section>
<section title="URI">
<t>URI: Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Description">
<t>This metric assesses the response time, the interval from the
query transmission to the response.</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.</t>
<section title="Reference Definition">
<t><Full bibliographic reference to an immutable doc.></t>
<t>Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. (and updates)</t>
<t><xref target="RFC1035"/></t>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><xref target="RFC2681"/></t>
<t><specific section reference and additional clarifications, if
needed></t>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference
definition of the singleton (single value) Round-trip delay metric.
Section 3.4 of <xref target="RFC2681"/> provides the reference
definition expanded to cover a multi-value sample. Note that terms
such as singleton and sample are defined in Section 11 of <xref
target="RFC2330"/>.</t>
<t>For DNS Response Latency, the entities in <xref
target="RFC1035"/> must be mapped to <xref target="RFC2681"/>. The
Local Host with its User Program and Resolver take the role of
"Src", and the Foreign Name Server takes the role of "Dst".</t>
<t>Note that although the definition of "Round-trip-Delay between
Src and Dst at T" is directionally ambiguous in the text, this
metric tightens the definition further to recognize that the host in
the "Src" role will send the first packet to "Dst", and ultimately
receive the corresponding return packet from "Dst" (when neither are
lost).</t>
</section>
<section title="Fixed Parameters">
<t><list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed></t>
<t>Type-P: <list style="symbols">
<t>IPv4 header values: <list style="symbols">
<t>DSCP: set to 0</t>
<t>TTL set to 255</t>
<t>Protocol: Set to 17 (UDP)</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Source port: 53</t>
<t>Destination port: 53</t>
<t>Checksum: the checksum must be calculated</t>
</list></t>
<t>Payload: The payload contains a DNS message as defined in
<xref target="RFC1035">RFC 1035</xref> with the following
values: <list style="symbols">
<t>The DNS header section contains: <list style="symbols">
<t>QR: set to 0 (Query)</t>
<t>OPCODE: set to 0 (standard query)</t>
<t>AA: not set</t>
<t>TC: not set</t>
<t>RD: set to one (recursion desired)</t>
<t>RA: not set</t>
<t>RCODE: not set</t>
<t>QDCOUNT: set to one (only one entry)</t>
<t>ANCOUNT: not set</t>
<t>NSCOUNT: not set</t>
<t>ARCOUNT: not set</t>
</list></t>
<t>The Question section contains: <list style="symbols">
<t>QNAME: the FQDN provided as input for the test</t>
<t>QTYPE: the query type provided as input for the
test</t>
<t>QCLASS: set to IN</t>
</list></t>
<t>The other sections do not contain any Resource
Records.</t>
</list></t>
</list></t>
<t>Observation: reply packets will contain a DNS response and may
contain RRs.</t>
<t>Timeout: Tmax = 5 seconds (to help disambiguate queries)</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 metric, insert relevant section references and
supplemental info></t>
<t>The methodology for this metric is defined as
Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
target="RFC2681">RFC 2681</xref> using the Type-P and Timeout
defined under Fixed Parameters.</t>
<t>The method requires sequence numbers or other send-order
information to be retained at the Src or included with each packet
to dis-ambiguate packet reordering if it occurs. Sequence number is
part of the payload described under Fixed Parameters.</t>
<t>DNS Messages bearing Queries provide for random ID Numbers, so
more than one query may be launched while a previous request is
outstanding when the ID Number is used.</t>
<t>IF a DNS response does not arrive within Tmax, the result is
undefined. The Message ID SHALL be used to disambiguate the
successive queries.</t>
<t>>>> This would require support of ID generation and
population in the Message. An alternative would be to use a random
Source port on the Query Message, but we would choose ONE before
proceding.</t>
<t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded
discussion of the instruction to "send a Type-P packet back to the
Src as quickly as possible" in Section 2.6 of <xref
target="RFC2681">RFC 2681</xref>. Section 8 of <xref
target="RFC6673"/> presents additional requirements which shall be
included in the method of measurement for this metric.</t>
</section>
<section title="Packet Generation Stream">
<t>This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream
parameters.</t>
<t><list of generation parameters and section/spec references if
needed></t>
<t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides
three methods to generate Poisson sampling intervals. the reciprocal
of lambda is the average packet rate, thus the Run-time Parameter is
1/lambda.</t>
<t>>>> Check with Sam, most likely it is this...</t>
<t>Method 3 is used, where given a start time (Run-time Parameter),
the subsequent send times are all computed prior to measurement by
computing the pseudo-random distribution of inter-packet send times,
(truncating the distribution as specified in the Run-time
Parameters), and the Src sends each packet at the computed
times.</t>
</section>
<section title="Traffic Filtering (observation) Details">
<t>The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).</t>
<t><section reference>.</t>
<t>NA</t>
</section>
<section title="Sampling Distribution">
<t><insert time distribution details, or how this is diff from
the filter></t>
<t>NA</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.</t>
<t><list of run-time parameters, and their data formats></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>T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>). When T0 is
"all-zeros", a start time is unspecified and Tf is to be
interpreted as the Duration of the measurement interval.</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>), interpreted
as the Duration of the measurement interval.</t>
<t>1/lambda, average packet rate (for Poisson Streams).
(1/lambda = 0.1 packet per second, if fixed)</t>
<t>Upper limit on Poisson distribution (values above this limit
will be clipped and set to the limit value). (if fixed, Upper
limit = 300 seconds.)</t>
<t>ID, the 16-bit identifier assigned by the program that
generates the query, and which must vary in successive queries,
see Section 4.1.1 of <xref target="RFC1035"/>. This identifier
is copied into the corresponding reply and can be used by the
requester to match-up replies to outstanding queries.</t>
</list>The format for 1/lambda and Upper limit of Poisson Dist.
are the short format in <xref target="RFC5905"/> (32 bits) and is as
follows: the first 16 bits represent the integer number of seconds;
the next 16 bits represent the fractional part of a second.</t>
<t>>>> should Poisson run-time params be fixed instead?
probably yes if modeling a specific version of MBA tests.</t>
</section>
<section title="Roles">
<t><lists the names of the different roles from the measurement
method></t>
<t>Src - launches each packet and waits for return transmissions
from Dst.</t>
<t>Dst - waits for each packet from Src and sends a return packet to
Src.</t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the Output of measurements
using the metric.</t>
<section title="Type/Value (two diff terms used)">
<t><insert name of the output type, raw or a selected summary
statistic></t>
<t>For all output types:</t>
<t><list style="symbols">
<t>T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
<t>Tf, a time (end of measurement interval, 128-bit NTP Date
Format, see section 6 of <xref target="RFC5905"/>)</t>
</list></t>
<t>Raw -- for each packet sent, pairs of values.</t>
<t>>>> and the status of the response, only assigning
values to successful query-response pairs.</t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of Round-trip delay (undefined delays are
excluded), a single value corresponding to the 95th percentile.</t>
</section>
<section title="Data Format">
<t><describe the data format for each type of result></t>
<t>Raw -- for each packet sent, pairs of values as follows:</t>
<t><list style="symbols">
<t>T, the time when the packet was sent from Src, 128-bit NTP
Date Format, see section 6 of <xref target="RFC5905"/>)</t>
<t>dT, a value of Round-trip delay, format is *similar to* the
32-bit short NTP Time format in Section 6 of <xref
target="RFC5905"/> 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>
<t>dT is undefined when the packet is not received at Src in
waiting time Tmxax seconds (need undefined code for no-response
or un-successful response)</t>
</list></t>
<t>Percentile -- for the conditional distribution of all packets
with a valid value of Round-trip delay (undefined delays are
excluded), a single value as follows:</t>
<t>See section 4.1 of <xref target="RFC3393"/> for details on the
conditional distribution to exclude undefined values of delay, and
Section 5 of <xref target="RFC6703"/> for background on this
analysis choice.</t>
<t>See section 4.3 of <xref target="RFC3393"/> for details on the
percentile statistic (where Round-trip delay should be substituted
for "ipdv").</t>
<t>The percentile = 95.</t>
<t>Data format is a 32-bit signed floating point value, *similar to*
the 32-bit short NTP Time format in Section 6 of <xref
target="RFC5905"/> 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="Reference">
<t><pointer to section/spec where output type/format is
defined></t>
<t>See the Data Format column for references.</t>
</section>
<section title="Metric Units">
<t><insert units for the measured results, and the reference
specification>.</t>
<t>Round-trip Delay, dT, is expressed in seconds.</t>
<t>The 95th Percentile of Round-trip Delay is expressed in
seconds.</t>
</section>
</section>
<section title="Administrative items">
<t/>
<section title="Status">
<t><current or depricated></t>
</section>
<section title="Requestor (keep?)">
<t>name or RFC, etc.</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this entry</t>
</section>
</section>
<section title="partly BLANK Registry Entry">
<t>This section gives an initial registry entry for ....</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<t><skipping the admin columns for now></t>
<section title="ID (Identifier)">
<t><insert numeric identifier, an integer></t>
</section>
<section title="Name">
<t><insert name according to metric naming convention></t>
<t>URL: ??</t>
</section>
<section title="URI">
<t>URI: Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Description">
<t>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.</t>
<section title="Reference Definition">
<t><Full bibliographic reference to an immutable doc.></t>
<t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.</t>
<t><specific section reference and additional clarifications, if
needed></t>
<t>Section 2.4 of <xref target="RFC2681"/> provides the reference
definition of the singleton (single value) Round-trip delay metric.
Section 3.4 of <xref target="RFC2681"/> provides the reference
definition expanded to cover a multi-value sample. Note that terms
such as singleton and sample are defined in Section 11 of <xref
target="RFC2330"/>.</t>
<t>Note that although the definition of "Round-trip-Delay between
Src and Dst at T" is directionally ambiguous in the text, this
metric tightens the definition further to recognize that the host in
the "Src" role will send the first packet to "Dst", and ultimately
receive the corresponding return packet from "Dst" (when neither are
lost).</t>
<t><<< Check how the Methodology also makes this clear (or
not) >>></t>
</section>
<section title="Fixed Parameters">
<t><list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed></t>
<t>Type-P: <list style="symbols">
<t>IPv4 header values: <list style="symbols">
<t>DSCP: set to 0</t>
<t>TTL set to 255</t>
<t>Protocol: Set to 17 (UDP)</t>
</list></t>
<t>UDP header values: <list style="symbols">
<t>Checksum: the checksum must be calculated</t>
</list></t>
<t>Payload <list style="symbols">
<t>Sequence number: 8-byte integer</t>
<t>Timestamp: 8 byte integer. Expressed as 64-bit NTP
timestamp as per section 6 of <xref target="RFC5905">RFC
5905</xref></t>
<t>No padding (total of 9 bytes)</t>
</list></t>
</list></t>
<t>Timeout: 3 seconds</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 metric, insert relevant section references and
supplemental info></t>
</section>
<section title="Packet Generation Stream">
<t>This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream
parameters.</t>
<t><list of generation parameters and section/spec references if
needed></t>
</section>
<section title="Traffic Filtering (observation) Details">
<t>The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).</t>
<t><section reference>.</t>
</section>
<section title="Sampling Distribution">
<t><insert time distribution details, or how this is diff from
the filter></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.</t>
<t><list of run-time parameters></t>
<t><reference(s)>.</t>
</section>
<section title="Roles">
<t><lists the names of the different roles from the measurement
method></t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the Output of measurements
using the metric.</t>
<section title="Type/Value (two diff terms used)">
<t><insert name of the output type, raw or a selected summary
statistic></t>
</section>
<section title="Data Format">
<t><describe the data format for each type of result></t>
<t><list style="symbols">
<t>Value:</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 reference></t>
</list></t>
</section>
<section title="Reference">
<t><pointer to section/spec where output type/format is
defined></t>
</section>
<section title="Metric Units">
<t><insert units for the measured results, and the reference
specification>.</t>
</section>
</section>
<section title="Administrative items">
<t/>
<section title="Status">
<t><current or depricated></t>
</section>
<section title="Requestor (keep?)">
<t>name or RFC, etc.</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this entry</t>
</section>
</section>
<section title="BLANK Registry Entry">
<t>This section gives an initial registry entry for ....</t>
<section title="Summary">
<t>This category includes multiple indexes to the registry entries,
the element ID and metric name.</t>
<t><skipping the Summary columns for now></t>
<section title="ID (Identifier)">
<t><insert numeric identifier, an integer></t>
</section>
<section title="Name">
<t><insert name according to metric naming convention></t>
<t>URL: ??</t>
</section>
<section title="URI">
<t>URI: Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Description">
<t>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.</t>
<section title="Reference Definition">
<t><Full bibliographic reference to an immutable doc.></t>
<t><specific section reference and additional clarifications, if
needed></t>
<t/>
</section>
<section title="Fixed Parameters">
<t><list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed></t>
<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 metric, insert relevant section references and
supplemental info></t>
</section>
<section title="Packet Generation Stream">
<t><list of generation parameters and section/spec references if
needed></t>
</section>
<section title="Traffic Filtering (observation) Details">
<t><insert the measured results based on a filtered version of
the packets observed, and this section provides the filter details
(when present), and section reference>.</t>
</section>
<section title="Sampling Distribution">
<t><insert time distribution details, or how this is diff from
the filter></t>
</section>
<section title="Run-time Parameters and Data Format">
<t><list of run-time parameters, and any reference(s)>.</t>
</section>
<section title="Roles">
<t><lists the names of the different roles from the measurement
method></t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the Output of measurements
using the metric.</t>
<section title="Type/Value (two diff terms used)">
<t><insert name of the output type, raw or a selected summary
statistic></t>
</section>
<section title="Data Format">
<t><describe the data format for each type of result></t>
<t/>
</section>
<section title="Reference">
<t><pointer to section/spec where output type/format is
defined></t>
</section>
<section title="Metric Units">
<t><insert units for the measured results, and the reference
specification>.</t>
</section>
</section>
<section title="Administrative items">
<t/>
<section title="Status">
<t><current or depricated></t>
</section>
<section title="Requestor (keep?)">
<t><name of individual or RFC, etc.></t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>YYYY-MM-DD</t>
</section>
</section>
<section title="Comments and Remarks">
<t>Additional (Informational) details for this entry</t>
</section>
</section>
<section title="Example RTCP-XR Registry Entry">
<t>This section is MAY BE DELETED or adapted before submission.</t>
<t>This section gives an example registry entry for the 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="Identifier">
<t>An integer having enough digits to uniquely identify each entry
in the Registry.</t>
</section>
<section title="Name">
<t>A metric naming convention is TBD.</t>
</section>
<section title="URI">
<t>Prefix urn:ietf:params:performance:metric</t>
</section>
<section title="Status">
<t>current</t>
</section>
<section title="Requestor">
<t>Alcelip Mornuley</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>2014-07-04</t>
</section>
<section title="Description">
<t>TBD.</t>
</section>
<section title="Reference Specification(s)">
<t><xref target="RFC3611"/><xref target="RFC4566"/><xref
target="RFC6776"/><xref target="RFC6792"/><xref
target="RFC7003"/></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 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>
<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="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 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—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 — 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 — 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 192.0.2.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 233.252.0.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>TBD.</t>
</section>
</section>
<section title="Security Considerations">
<t>These registry entries represent no known security implications for
Internet Security. Each referenced Metric contains a Security
Considerations section.</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 this and other
memos, and IANA Action will be requested when the initial contents of
the registry are prepared.</t>-->
<t>IANA is requested to create The Active Performance Metric
Sub-registry within the Performance Metric Registry defined in <xref
target="I-D.ietf-ippm-metric-registry"/>. The Sub-registry will contain
the following categories and (bullet) columns, (as defined in section 3
above):</t>
<t>Common Registry Indexes and Info</t>
<t><list style="symbols">
<t>Identifier</t>
<t>Name</t>
<t>Status</t>
<t>Requester</t>
<t>Revision</t>
<t>Revision Date</t>
<t>Description</t>
<t>Reference Specification(s)</t>
</list>Metric Definition<list style="symbols">
<t>Reference Definition</t>
<t>Fixed Parameters</t>
</list>Method of Measurement<list style="symbols">
<t>Reference Method</t>
<t>Stream Type and Parameters</t>
<t>Output type and Data format</t>
<t>Metric Units</t>
<t>Run-time Parameters</t>
</list>Comments and Remarks</t>
</section>
<section title="Acknowledgements">
<t>The authors thank Brian Trammell for suggesting the term "Run-time
Parameters", which led to the distinction between run-time and fixed
parameters implemented in this memo, for raising the IPFIX metric with
Flow Key as an example, and for many other productive suggestions.Thanks
to Peter Koch, who provided several useful suggestions for
disambiguating successive DNS Queries in the DNS Response time
metric.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1035"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2330"?>
<?rfc include="reference.RFC.2679"?>
<?rfc include='reference.RFC.2680'?>
<?rfc include='reference.RFC.2681'?>
<?rfc include='reference.RFC.3393'?>
<?rfc include='reference.RFC.3432'?>
<?rfc ?>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.4737'?>
<?rfc include='reference.RFC.5357'?>
<?rfc include='reference.RFC.6673'?>
<reference anchor="I-D.ietf-ippm-metric-registry">
<front>
<title>Registry for Performance Metrics</title>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization/>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization/>
</author>
<author fullname="Phil Eardley" initials="P." surname="Eardley">
<organization/>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization/>
</author>
<date year="2014"/>
</front>
<seriesInfo name="Internet Draft (work in progress)"
value="draft-ietf-ippm-metric-registry"/>
<format type="TXT"/>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1242'?>
<?rfc include='reference.RFC.3611'?>
<?rfc include='reference.RFC.4148'?>
<?rfc include='reference.RFC.4566'?>
<?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.6703'?>
<?rfc include='reference.RFC.6776'?>
<?rfc include='reference.RFC.6792'?>
<?rfc include='reference.RFC.7003'?>
<?rfc include='reference.I-D.ietf-lmap-framework'?>
<reference anchor="Brow00">
<front>
<title>Packet Matching for NeTraMet Distributions</title>
<author fullname="N.Brownlee" initials="N." surname="Brownlee">
<organization><http://www.caida.org/tools/measurement/
netramet/packetmatching/></organization>
</author>
<date month="March" year="2000"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:46 |