One document matched: draft-morton-ippm-2330-update-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="info" docName="draft-morton-ippm-2330-update-01"
ipr="trust200902">
<front>
<title abbrev="Advanced Sampling">Advanced Stream and Sampling Framework
for IPPM</title>
<author fullname="Joachim Fabini" initials="J." surname="Fabini">
<organization>Vienna University of Technology</organization>
<address>
<postal>
<street>Favoritenstrasse 9/E389</street>
<city>Vienna</city>
<region/>
<code>1040</code>
<country>Austria</country>
</postal>
<phone>+43 1 58801 38813</phone>
<facsimile>+43 1 58801 38898</facsimile>
<email>Joachim.Fabini@tuwien.ac.at</email>
<uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri>
</address>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acmorton@att.com</email>
<uri>http://home.comcast.net/~acmacm/</uri>
</address>
</author>
<date day="22" month="February" year="2013"/>
<abstract>
<t>To obtain repeatable results in modern networks, test descriptions
need an expanded stream parameter framework that also augments aspects
specified as Type-P for test packets. This memo proposes to update the
IP Performance Metrics (IPPM) Framework with advanced considerations for
measurement methodology and testing. The existing framework mostly
assumes deterministic connectivity, and that a single test stream will
represent the characteristics of the path when it is aggregated with
other flows. Networks have evolved and test stream descriptions must
evolve with them, otherwise unexpected network features may dominate the
measured performance. This memo describes new stream parameters for both
network characterization and support of application design using IPPM
metrics.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The IETF IP Performance Metrics (IPPM) working group first created a
framework for metric development in <xref target="RFC2330"/>. This
framework has stood the test of time and enabled development of many
fundamental metrics, while only being updated once in a specific area
<xref target="RFC5835"/>.</t>
<t>The IPPM framework <xref target="RFC2330"/> generally relies on
several assumptions, one of which is not explicitly stated but assumed:
the network behaves (halfway) deterministic and without
state/history-less (with some exceptions, firewalls are mentioned).
However, this does not hold true for many modern network technologies,
such as reactive networks (those with demand-driven resource allocation)
and links with time-slotted operation. Per-flow state can be observed on
test packet streams, and such treatment will influence network
characterization if it is not taken into account. Flow history will also
affect the performance of applications and be perceived by their
users.</t>
<t>Moreover, Sections 4 and 6.2 of <xref target="RFC2330"/> explicitly
recommend repeatable measurement metrics and methodologies. Measurements
in today's access networks illustrate that methodological guidelines of
<xref target="RFC2330"/> must be extended to capture the reactive nature
of these networks. Although the proposed extensions can support
methodologies to fulfill the continuity requirement stated in section
6.2 of <xref target="RFC2330"/>, there is no guarantee. Practical
measurements confirm that some link types exhibit distinct responses to
repeated measurements with identical stimulus, i.e., identical traffic
patterns. If feasible, appropriate fine-tuning of measurement traffic
patterns can improve measurement continuity and repeatability for these
link types as shown in <xref target="IBD"/>.</t>
<section title="Definition: Reactive Network Behavior">
<t>Reactive behavior is present when link-or host-internal sensing of
packet arrival for the flow of interest indicates that traffic is
absent or present, or that traffic during an assessment interval is
above or below a threshold, and the results of one or more successive
assessments cause one or more network components to process future
packets using a different mode of operation than for other assessment
outcomes.</t>
<t>Reactive network behavior must be observable by the measurement
flow as a repeatable phenomenon where packet transfer performance
characteristics *change* according to prior node- or link-internal
observations of the packet flow of interest. Therefore, reactive
network behavior is deterministic with respect to the flow of
interest. Other flows or traffic load conditions may result in
additional performance-affecting reactions, but these are external to
the characteristics of the flow of interest.</t>
<t>Other than the size of the payload at the layer of interest and the
header itself, packet content does not influence the measurement.
Reactive behavior at the IP layer is not influenced by the TCP ports
in use, for example. Therefore, the finding of reactive behavior must
specify the layer at which assessment leading to reaction appears to
be taking place. In any case, the full packet Type-P used in
measurement should always be specified.</t>
<t>Examples include links with Active/In-active state detectors, and
network devices or links that revise their traffic serving and
forwarding rates (up or down) based on packet arrival history.</t>
<t>A network or network path is said to be reactive when at least one
of the links or hosts comprising the path exhibits reactive
behavior.</t>
</section>
</section>
<section title="Scope">
<t>The scope of his memo is to describe useful stream parameters in
addition to the information in Section 11.1 of <xref target="RFC2330"/>
and described in <xref target="RFC3432"/> for periodic streams. The
purpose is to foster repeatable measurement results in modern networks
by highlighting the key aspects of test streams and packets and make
them part of the IPPM performance metric framework.</t>
</section>
<section title="New Stream Parameters">
<t>There are several areas where measurement methodology definition and
test result interpretation will benefit from an increased understanding
of the stream characteristics and the (possibly unknown) network
condition that influence the measured metrics.</t>
<t><list style="numbers">
<t>Network treatment depends on the fullest extent on the "packet of
Type-P" definition in <xref target="RFC2330"/>, and has for some
time. <list style="symbols">
<t>State is often maintained on the per-flow basis at various
points in the network, where "flows" are determined by IP and
other layers. Significant treatment differences occur with the
simplest of Type-P parameters: packet length.</t>
<t>Payload content optimization (compression or format
conversion) in intermediate segments. This breaks the convention
of payload correspondence when correlating measurements made at
different points in a path.</t>
</list></t>
<t>Packet history (instantaneous or recent test rate or inactivity,
also for non-test traffic) profoundly influences measured
performance, in addition to all the Type-P parameters described in
<xref target="RFC2330"/>.</t>
<t>Access technology may change during testing. A range of transfer
capacities and access methods may be encountered during a test
session. When different interfaces are used, the host seeking access
will be aware of the technology change which differentiates this
form of path change from other changes in network state. Section 14
of <xref target="RFC2330"/> treats the possibility that a host may
have more than one attachment to the network, and also that
assessment of the measurement path (route) is valid for some length
of time (in Section 5 and Section 7 of <xref target="RFC2330"/>).
Here we combine these two considerations under the assumption that
changes may be more frequent and possibly have greater consequences
on performance metrics.</t>
<t>Paths including links or nodes with time-slotted service
opportunities represent several challenges to measurement (when
service time period is appreciable):<list style="symbols">
<t>Random/unbiased sampling is not possible beyond one such link
in the path.</t>
<t>The above encourages a segmented approach to end to end
measurement, as described in <xref target="RFC6049"/> for
Network Characterization (as defined in <xref
target="RFC6703"/>) to understand the full range of delay and
delay variation on the path. Alternatively, if application
performance estimation is the goal (also defined in <xref
target="RFC6703"/>), then a stream with un-biased or known-bias
properties <xref target="RFC3432"/> may be sufficient.</t>
<t>Multi-modal delay variation makes central statistics
unimportant, others must be used instead.</t>
</list></t>
</list> Each of these topics is treated in detail below.</t>
<section title="Test Packet Type-P">
<t>We recommend two Type-P parameters to be added to the factors which
have impact on network performance measurements, namely packet length
and payload type. Carefully choosing these parameters can improve
measurement methodologies in their continuity and repeatability when
deployed in reactive networks.</t>
<section title="Test Packet Length">
<t>Many instances of network characterization using IPPM metrics
have relied on a single test packet length. When testing to assess
application performance or an aggregate of traffic, benchmarking
methods have used a range of fixed lengths and frequently augmented
fixed size tests with a mixture of sizes, or IMIX as described in
<xref target="I-D.ietf-bmwg-imix-genome"/>.</t>
<t>Test packet length influences delay measurements, in that the
IPPM one-way delay metric <xref target="RFC2679"/> includes
serialization time in its first-bit to last bit time stamping
requirements. However, different sizes can have a larger effect on
link delay and link delay variation than serialization would explain
alone. This effect can be non-linear and change instantaneous or
future network performance.</t>
<t>Repeatability is a main measurement methodology goal as stated in
section 6.2 of <xref target="RFC2330"/>. To eliminate packet length
as a potential measurement uncertainty factor, successive
measurements must use identical traffic patterns. In practice a
combination of random payload and random start time can yield
representative results as illustrated in <xref target="IRR"/>.</t>
</section>
<section title="Test Packet Payload Content Optimization">
<t>The aim for efficient network resource use has resulted in a
series of "smart" networks to deploy server-only or client-server
lossless or lossy payload compression techniques on some links or
paths. These optimizers attempt to compress high-volume traffic in
order to reduce network load. Files are analyzed by
application-layer parsers and parts (like comments) might be
dropped. Although typically acting on HTTP or JPEG files,
compression might affect measurement packets, too. In particular
measurement packets are qualified for efficient compression when
they use standard plain-text payload.</t>
<t>IPPM-conforming measurements should add packet payload content as
a Type-P parameter which can help to improve measurement
determinism. Some packet payloads are more susceptible to
compression than others, but optimizers in the measurement path can
be out ruled by using incompressible packet payload. This payload
content could be either generated by a random device or by using
part of a compressed file (e.g., a part of a ZIP compressed
archive).</t>
</section>
</section>
<section title="Packet History">
<t>Recent packet history and instantaneous data rate influence
measurement results for reactive links supporting on-demand capacity
allocation. Measurement uncertainty may be reduced by knowledge of
measurement packet history and total host load. Additionally, small
changes in history, e.g., because of lost packets along the path, can
be the cause of large performance variations.</t>
<t>For instance delay in reactive 3G networks like High Speed Packet
Access (HSPA) depends to a large extent on the test traffic data rate.
The reactive resource allocation strategy in these networks affects
the uplink direction in particular. Small changes in data rate can be
the reason of more than 200% increase in delay, depending on the
specific packet size.</t>
<t>The reactive behavior of a network under test may require to
"pre-load" paths with traffic, or to separate early traffic that
captures the reactive network performance signature from steady
conditions that follow.</t>
</section>
<section title="Access Technology Change">
<t><xref target="RFC2330"/> discussed the scenario of multi-homed
hosts. If hosts become aware of access technology changes (e.g.,
because of IP address changes or lower layer information) and make
this information available, measurement methodologies can use this
information to improve measurement representativeness and
relevance.</t>
<t>However, today's various access network technologies can present
the same physical interface to the host. A host may or may not become
aware when its access technology changes on such an interface.
Measurements for networks which support on-demand capacity allocation
are therefore challenging in that it is difficult to differentiate
between access technology changes (e.g., because of mobility) and
reactive network behavior (e.g., because of data rate change).</t>
</section>
<section title="Time-Slotted Network Paths ">
<t>Time-Slotted operation of network entities - interfaces, routers or
links - in a network path is a particular challenge for measurements,
especially if the time slot period is substantial. The central
observation as an extension to Poisson stream sampling in <xref
target="RFC2330"/> is that the first such time-slotted component
cancels unbiased measurement stream sampling. In the worst case,
time-slotted operation converts an unbiased, random measurement packet
stream into a periodic packet stream. Being heavily biased, these
packets may interact with periodic network behavior of subsequent
time-slotted network entities.</t>
<t>Practical measurements confirm that such interference limits delay
measurement variation to a sub-set of theoretical value range.
Measurement samples for such cases can aggregate on artificial limits,
generating multi-modal distributions as demonstrated in <xref
target="IRR"> </xref>. In this context, the desirable measurement
sample statistics differentiate between multi-modal delay
distributions caused by reactive network behavior and the ones due to
time-slotted interference.</t>
<t>The amount of measurement bias is determined by the relative offset
between allocated time-slots in subsequent network entities, delay
variation in these networks, and other sources of variation.
Measurement results might change over time, depending on how
accurately the sending host, receiving host, and time-slotted
components in the measurement path are synchronized to each other and
to global time. If network segments maintain flow state, flow
parameter change or flow re-allocations can cause substantial
variation in measurement results.</t>
<t>Measurement methodology selection for time-slotted paths depends to
a large extent on the respective viewpoint. End-to-end metrics can
provide accurate measurement results for short-term sessions and low
likelihood of flow state modifications. Applications or services which
aim at approximating network performance for a short time interval (in
the order of minutes) and expect stable network conditions should
therefore prefer end-to-end metrics. Here stable network conditions
refer to any kind of global knowledge concerning measurement path flow
state and flow parameters.</t>
<t>However, if long-term forecast of time-slotted network performance
is the main measurement goal, a segmented approach relying on
hop-by-hop metrics is preferred. Re-generating unbiased measurement
traffic at any hop can help to unleash the true range of network
performance for all network segments.</t>
<t/>
</section>
</section>
<section title="Conclusions">
<t>Safeguarding continuity and repeatability as key properties of
measurement methodologies is highly challenging and sometimes impossible
in reactive networks. Measurements in networks with demand-driven
allocation strategies must use a prototypical application packet stream
to infer a specific application's performance. Measurement repetition
with unbiased network and flow states (e.g., by rebooting measurement
hosts) can help to avoid interference with periodic network behavior,
randomness being a mandatory feature for avoiding correlation with
network timing. Inferring from one measurement session or packet stream
onto network performance for alternative streams is highly discouraged
in reactive networks because of the huge set of global parameters which
influence on instantaneous network performance.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations that apply to any active measurement of
live networks are relevant here as well. See <xref target="RFC4656"/>
and <xref target="RFC5357"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo makes no requests of IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Rudiger Geib and Matt Mathis for their helpful
comments on this draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2026'?>
<?rfc include='reference.RFC.2330'?>
<?rfc include='reference.RFC.2679'?>
<?rfc include='reference.RFC.2680'?>
<?rfc include='reference.RFC.3432'?>
<?rfc include='reference.RFC.4656'?>
<?rfc include='reference.RFC.6049'?>
<?rfc include='reference.RFC.5835'?>
<?rfc include='reference.RFC.5357'?>
<?rfc include='reference.RFC.5657'?>
<?rfc include='reference.RFC.6576'?>
<?rfc include='reference.RFC.6703'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-bmwg-imix-genome'?>
<?rfc ?>
<?rfc ?>
<reference anchor="IBD">
<front>
<title>The Illusion of Being Deterministic – Application-Level
Considerations on Delay in 3G HSPA Networks</title>
<author fullname="Joachim Fabini et al." initials="J.F."
surname="Fabini">
<!-- fullname="J.Fabini"-->
<organization>Vienna University of Technology</organization>
</author>
<date day="" month="May" year="2009"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science,"
value=" Springer, Volume 5550, 2009, pp 301-312 "/>
</reference>
<reference anchor="IRR">
<front>
<title>The Importance of Being Really Random: Methodological Aspects
of IP-Layer 2G and 3G Network Delay Assessment</title>
<author fullname="Joachim Fabini et al." initials="J.F."
surname="Fabini">
<!-- fullname="J.Fabini" -->
<organization>Vienna University of Technology</organization>
</author>
<date month="June" year="2009"/>
</front>
<seriesInfo name="ICC'09 Proceedings of the 2009 IEEE International Conference on Communications,"
value="doi: 10.1109/ICC.2009.5199514"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:26:49 |