One document matched: draft-ietf-ippm-rate-problem-05.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-ietf-ippm-rate-problem-05"
ipr="trust200902" updates="">
<front>
<title abbrev="Rate Problem Statement">Rate Measurement Test Protocol
Problem Statement</title>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown,</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acmorton@att.com</email>
<uri>http://home.comcast.net/~acmacm/</uri>
</address>
</author>
<date day="12" month="December" year="2013"/>
<abstract>
<t>This memo presents an access rate-measurement problem statement for
test protocols to measure IP Performance Metrics. The rate measurement
scenario has wide-spread attention of Internet access subscribers and
seemingly all industry players, including regulators. Key test protocol
aspects require the ability to control packet size on the tested path
and enable asymmetrical packet size testing in a controller-responder
architecture.</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>There are many possible rate measurement scenarios. This memo
describes one rate measurement problem and presents a rate-measurement
problem statement for test protocols to measure IP Performance Metrics
(IPPM).</t>
<t>When selecting a form of access to the Internet, subscribers are
interested in the performance characteristics of the various
alternatives. Standardized measurements can be a basis for comparison
between these alternatives. There is an underlying need to coordinate
measurements that support such comparisons, and test control protocols
to fulfill this need. The figure below depicts some typical measurement
points of access networks.</t>
<t><figure>
<artwork><![CDATA[ User ====== Fiber ======= Access Node \
Device ----- Copper ------- Access Node -|--- Infrastructure --- GW
or Host ------ Radio ------- Access Node /
]]></artwork>
</figure></t>
<t>The access-rate scenario or use case has received wide-spread
attention of Internet access subscribers and seemingly all Internet
industry players, including regulators. This problem is being approached
with many different measurement methods.</t>
</section>
<section title="Purpose and Scope">
<t>The scope and purpose of this memo is to define the measurement
problem statement for test protocols conducting access rate measurement
on production networks. Relevant test protocols include <xref
target="RFC4656"/> and <xref target="RFC5357"/>, but the problem is
stated in a general way so that it can be addressed by any existing test
protocol, such as <xref target="RFC6812"/>.</t>
<t>This memo discusses possibilities for methods of measurement, but
does not specify exact methods which would normally be part of the
solution, not the problem.</t>
<t>We are interested in access measurement scenarios with the following
characteristics:<list style="symbols">
<t>The Access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with
bi-directional access partly described by rates in bits per second.
The rates may be expressed as raw capacity or restricted capacity as
described in <xref target="RFC6703"/>. These are the quantities that
must be measured according to one or more standard metrics, and for
which measurement methods must also be agreed as a part of the
solution.</t>
<t>Referring to the reference path illustrated below and defined in
<xref target="I-D.ietf-ippm-lmap-path"/>, possible measurement
points include a Subscriber's host, the access service demarcation
point, Intra IP access where a globally routable address is present,
or the gateway between the measured access network and other
networks. <figure align="center">
<artwork><![CDATA[Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
device Net #1 Net #2 Demarc. Access GW GRA GW]]></artwork>
<postamble>GRA = Globally Routable Address, GW =
Gateway</postamble>
</figure></t>
<t>Rates at some links near the edge of the provider's network can
often be several orders of magnitude less than link rates in the
aggregation and core portions of the network.</t>
<t>Asymmetrical access rates on ingress and egress are
prevalent.</t>
<t>In many scenarios of interest, extremely large scale of access
services requires low complexity devices participating at the user
end of the path.</t>
</list></t>
<t>This problem statement assumes that the most-likely bottleneck device
or link is adjacent to the remote (user-end) measurement device, or is
within one or two router/switch hops of the remote measurement
device.</t>
<t>Other use cases for rate measurement involve situations where the
packet switching and transport facilities are leased by one operator
from another and the link capacity available cannot be directly
determined (e.g., from device interface utilization). These scenarios
could include mobile backhaul, Ethernet Service access networks, and/or
extensions of layer 2 or layer 3 networks. The results of rate
measurements in such cases could be employed to select alternate
routing, investigate whether capacity meets some previous agreement,
and/or adapt the rate of traffic sources if a capacity bottleneck is
found via the rate measurement. In the case of aggregated leased
networks, available capacity may also be asymmetric. In these cases, the
tester is assumed to have a sender and receiver location under their
control. We refer to this scenario below as the aggregated leased
network case.</t>
<t>Support of active measurement methods will be addressed here,
consistent with the IPPM working group's traditional charter. Active
measurements require synthetic traffic dedicated to testing, and do not
make measurements on user traffic.</t>
<t>As noted in <xref target="RFC2330"/> the focus of access traffic
management may influence the rate measurement results for some forms of
access, as it may differ between user and test traffic if the test
traffic has different characteristics, primarily in terms of the packets
themselves (see section 13 of <xref target="RFC2330"/> for the
considerations on packet type, or Type-P).</t>
<t>There are several aspects of Type-P where user traffic may be
examined and selected for special treatment that may affect transmission
rates. Without being exhaustive, the possibilities include:</t>
<t><list style="symbols">
<t>Packet length</t>
<t>IP addresses</t>
<t>Transport protocol (e.g. where TCP packets may be routed
differently from UDP)</t>
<t>Transport Protocol port numbers</t>
</list></t>
<t>This issue requires further discussion when specific
solutions/methods of measurement are proposed, but for this problem
statement it is sufficient to identify the problem and indicate that the
solution may require an extremely close emulation of user traffic, in
terms of one or more factors above.</t>
<t>Although the user may have multiple instances of network access
available to them, the primary problem scope is to measure one form of
access at a time. It is plausible that a solution for the single access
problem will be applicable to simultaneous measurement of multiple
access instances, but treatment of this scenario is beyond the current
scope this document.</t>
<t>A key consideration is whether active measurements will be conducted
with user traffic present (In-Service testing), or not present
(Out-of-Service testing), such as during pre-service testing or
maintenance that interrupts service temporarily. Out-of-Service testing
includes activities described as "service commissioning", "service
activation", and "planned maintenance". Opportunistic In-Service testing
when there is no user traffic present (e.g., outside normal business
hours) throughout the test interval is essentially equivalent to
Out-of-Service testing. Both In-Service and Out-of-Service testing are
within the scope of this problem.</t>
<t>It is a non-goal to solve the measurement protocol specification
problem in this memo.</t>
<t>It is a non-goal to standardize methods of measurement in this memo.
However, the problem statement will mandate support for one or more
categories of rate measurement methods in the test protocol and adequate
control features for the methods in the control protocol (assuming the
control and test protocols are separate).</t>
</section>
<section title="Active Rate Measurement">
<t>This section lists features of active measurement methods needed to
measure access rates in production networks.</t>
<t>Coordination between source and destination devices through control
messages and other basic capabilities described in the methods of IPPM
RFCs <xref target="RFC2679"/><xref target="RFC2680"/>, and assumed for
test protocols such as <xref target="RFC5357"/> and <xref
target="RFC4656"/>, are taken as given.</t>
<t>Most forms of active testing intrude on user performance to some
degree, especially In-Service testing. One key tenet of IPPM methods is
to minimize test traffic effects on user traffic in the production
network. Section 5 of <xref target="RFC2680"/> lists the problems with
high measurement traffic rates, and the most relevant for rate
measurement is the tendency for measurement traffic to skew the results,
followed by the possibility of introducing congestion on the access
link. In-Service testing MUST respect these traffic constraints.
Obviously, categories of rate measurement methods that use less active
test traffic than others with similar accuracy are preferred for
In-Service testing.</t>
<t>On the other hand, Out-of-Service tests where the test path shares no
links with In-Service user traffic have none of the congestion or skew
concerns, but these tests must address other practical matters such as
conducting measurements within a reasonable time from the tester's point
of view. Out-of-Service tests where some part of the test path is shared
with In-Service traffic MUST respect the In-Service constraints.</t>
<t>The **intended metrics to be measured** have strong influence over
the categories of measurement methods required. For example, using the
terminology of <xref target="RFC5136"/>, a it may be possible to measure
a Path Capacity Metric while In-Service if the level of background
(user) traffic can be assessed and included in the reported result.</t>
<t>The measurement *architecture* MAY be either of one-way (e.g., <xref
target="RFC4656"/>) or two-way (e.g., <xref target="RFC5357"/>), but the
scale and complexity aspects of end-user or aggregated access
measurement clearly favor two-way (with low-complexity user-end device
and round-trip results collection, as found in <xref
target="RFC5357"/>). However, the asymmetric rates of many access
services mean that the measurement system MUST be able to evaluate
performance in each direction of transmission. In the two-way
architecture, it is expected that both end devices MUST include the
ability to launch test streams and collect the results of measurements
in both (one-way) directions of transmission (this requirement is
consistent with previous protocol specifications, and it is not a unique
problem for rate measurements).</t>
<t>The following paragraphs describe features for the roles of test
packet SENDER, RECEIVER, and results REPORTER.</t>
<t>SENDER:</t>
<t>Generate streams of test packets with various characteristics as
desired (see Section 4). The SENDER MAY be located at the user end of
the access path or elsewhere in the production network, such as at one
end of an aggregated leased network segment.</t>
<t>RECEIVER:</t>
<t>Collect streams of test packets with various characteristics (as
described above), and make the measurements necessary to support rate
measurement at the receiving end of an access or aggregated leased
network segment.</t>
<t>REPORTER:</t>
<t>Use information from test packets and local processes to measure
delivered packet rates, and prepare results in the required format (the
REPORTER role may be combined with another role, most likely the
SENDER).</t>
</section>
<section title="Measurement Method Categories">
<t>A protocol that addresses the rate measurement problem MUST serve the
test stream generation and measurement functions (SENDER and RECEIVER).
The follow-up phase of analyzing the measurement results to produce a
report is outside the scope of this problem and memo (REPORTER).</t>
<t>For the purposes of this problem statement, we categorize the many
possibilities for rate measurement stream generation as follows;<list
style="numbers">
<t>Packet pairs, with fixed intra-pair packet spacing and fixed or
random time intervals between pairs in a test stream.</t>
<t>Multiple streams of packet pairs, with a range of intra-pair
spacing and inter-pair intervals.</t>
<t>One or more packet ensembles in a test stream, using a fixed
ensemble size in packets and one or more fixed intra-ensemble packet
spacings (including zero spacing, meaning that back-to-back burst
ensembles and constant rate ensembles fall in this category).</t>
<t>One or more packet chirps, where intra-packet spacing typically
decreases between adjacent packets in the same chirp and each pair
of packets represents a rate for testing purposes.</t>
</list></t>
<t>The test protocol SHALL support test packet ensemble generation
(category 3), as this appears to minimize the demands on measurement
accuracy. Other stream generation categories are OPTIONAL.</t>
<t>For all categories, the test protocol MUST support:</t>
<t><list style="letters">
<t>Variable payload lengths among packet streams</t>
<t>Variable length (in packets) among packet streams or
ensembles</t>
<t>Variable IP header markings among packet streams</t>
<t>Choice of UDP transport and variable port numbers, OR, choice of
TCP transport and variable port numbers for two-way architectures
only, OR BOTH. See below for additional requirements on TCP
transport generation.</t>
<t>Variable number of packets-pairs, ensembles, or streams used in a
test session.</t>
</list>The items above are additional variables that the test protocol
MUST be able to identify and control. The ability to revise these
variables during an established test session is OPTIONAL, as multiple
test sessions could serve the same purpose. Another OPTIONAL feature is
the ability to generate streams with VLAN tags and other markings.</t>
<t>For measurement systems employing TCP as the transport protocol, the
ability to generate specific stream characteristics requires a sender
with the ability to establish and prime the connection such that the
desired stream characteristics are allowed. See Mathis' work in progress
for more background <xref
target="I-D.ietf-ippm-model-based-metrics"/>.</t>
<t>Beyond simple connection handshake and options establishment, an
"open-loop" TCP sender requires the SENDER ability to:</t>
<t><list style="symbols">
<t>generate TCP packets with well-formed headers (all fields valid),
including Acknowledgement aspects.</t>
<t>produce packet streams at controlled rates and variable
inter-packet spacings, including packet ensembles (back-to-back at
server rate).</t>
<t>continue the configured sending stream characteristics despite
all control indications except receive window exhaust.</t>
</list>The corresponding TCP RECEIVER performs normally, having some
ability to configure the receive window sufficiently large so as to
allow the SENDER to transmit at will (up to a configured target).</t>
<t>It may also be useful to provide a control for Bulk Transfer Capacity
measurement with fully-specified (and congestion-controlled) TCP senders
and receivers, as envisioned in <xref target="RFC3148"/>, but this would
be a brute-force assessment which does not follow the conservative
tenets of IPPM measurement <xref target="RFC2330"/>.</t>
<t>Measurements for each UDP test packet transferred between SENDER and
RECEIVER MUST be compliant with the singleton measurement methods
described in IPPM RFCs <xref target="RFC2679"/><xref target="RFC2680"/>
(these could be listed later, if desired). The time-stamp information or
loss/arrival status for each packet MUST be available for communication
to the protocol entity that collects results.</t>
</section>
<section title="Test Protocol Control & Generation Requirements">
<t>Essentially, the test protocol MUST support the measurement features
described in the sections above. This requires:</t>
<t><list style="numbers">
<t>Communicating all test variables to the SENDER and RECEIVER</t>
<t>Results collection in a one-way architecture</t>
<t>Remote device control for both one-way and two-way
architectures</t>
<t>Asymmetric packet size and/or pseudo-one-way test capability in a
two-way measurement architecture (along with symmetric packet size
tests in common use)</t>
</list></t>
<t>The ability to control packet size on the tested path and enable
asymmetrical packet size testing in a two-way architecture are REQUIRED.
This allows both the conventional symmetric packet size testing and
asymmetrical packet size testing to employed to solve various aspects of
rate measurement: real-time communications often have symmetrical
streams, while file transfers have highly asymmetrical streams in the
data and acknowledgement traffic directions.</t>
<t>The test protocol SHOULD enable measurement of the <xref
target="RFC5136"/> Capacity metric, either Out-of-Service, In-Service,
or both. Other <xref target="RFC5136"/> metrics are OPTIONAL.</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>
<t>There may be a serious issue if a proprietary Service Level Agreement
involved with the access network segment provider were somehow leaked in
the process of rate measurement. To address this, test protocols SHOULD
NOT convey this information in a way that could be discovered by
unauthorized parties.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo makes no requests of IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Dave McDysan provided comments and text for the aggregated leased use
case. Yaakov Stein suggested many considerations to address, including
the In-Service vs. Out-of-Service distinction and its implication on
test traffic limits and protocols. Bill Cerveny, Marcelo Bagnulo, and
Kostas Pentikousis (a persistent reviewer) have contributed insightful,
clarifying comments that made this a better draft. Barry Constantine
also provided suggestions for clarification.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2330'?>
<?rfc include='reference.RFC.2679'?>
<?rfc include='reference.RFC.2680'?>
<?rfc include='reference.RFC.4656'?>
<?rfc include='reference.RFC.5357'?>
<?rfc include='reference.RFC.1305'?>
<?rfc include='reference.RFC.5618'?>
<?rfc include='reference.RFC.5938'?>
<?rfc include='reference.RFC.6038'?>
<?rfc include='reference.RFC.6703'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3148'?>
<?rfc include='reference.RFC.6812'?>
<?rfc include='reference.RFC.5136'?>
<?rfc include='reference.I-D.ietf-ippm-lmap-path'?>
<?rfc ?>
<?rfc include='reference.I-D.ietf-ippm-model-based-metrics'?>
<?rfc ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:42:42 |