draft-ietf-ippm-capacity-metric-method-04.txt   draft-ietf-ippm-capacity-metric-method-05.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Updates: ???? (if approved) R. Geib Intended status: Standards Track R. Geib
Intended status: Standards Track Deutsche Telekom Expires: August 5, 2021 Deutsche Telekom
Expires: March 14, 2021 L. Ciavattone L. Ciavattone
AT&T Labs AT&T Labs
September 10, 2020 February 1, 2021
Metrics and Methods for One-way IP Capacity Metrics and Methods for One-way IP Capacity
draft-ietf-ippm-capacity-metric-method-04 draft-ietf-ippm-capacity-metric-method-05
Abstract Abstract
This memo revisits the problem of Network Capacity metrics first This memo revisits the problem of Network Capacity metrics first
examined in RFC 5136. The memo specifies a more practical Maximum examined in RFC 5136. The memo specifies a more practical Maximum
IP-layer Capacity metric definition catering for measurement IP-layer Capacity metric definition catering for measurement
purposes, and outlines the corresponding methods of measurement. purposes, and outlines the corresponding methods of measurement.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2021. This Internet-Draft will expire on August 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Parameters and Definitions . . . . . . . . . . . . . 5 4. General Parameters and Definitions . . . . . . . . . . . . . 5
5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6 5. IP-Layer Capacity Singleton Metric Definitions . . . . . . . 6
5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 5.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6
5.4. Related Round-Trip Delay and One-way Loss Definitions . . 8 5.4. Related Round-Trip Delay and One-way Loss Definitions . . 8
5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8 5.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 8
6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 8 6. Maximum IP-Layer Capacity Metric Definitions (Statistic) . . 9
6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 9 6.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 9
6.4. Related Round-Trip Delay and One-way Loss Definitions . . 11 6.4. Related Round-Trip Delay and One-way Loss Definitions . . 11
6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11
6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 11 6.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 11
7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 12 7. IP-Layer Sender Bit Rate Singleton Metric Definitions . . . . 12
7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 7.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 13
7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13
7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 13 7.5. Reporting the Metric . . . . . . . . . . . . . . . . . . 13
8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13 8. Method of Measurement . . . . . . . . . . . . . . . . . . . . 13
8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13 8.1. Load Rate Adjustment Algorithm . . . . . . . . . . . . . 13
8.2. Measurement Qualification or Verification . . . . . . . . 15 8.2. Measurement Qualification or Verification . . . . . . . . 15
8.3. Measurement Considerations . . . . . . . . . . . . . . . 16 8.3. Measurement Considerations . . . . . . . . . . . . . . . 16
8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 17 8.4. Running Code . . . . . . . . . . . . . . . . . . . . . . 18
9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 18 9. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Configuration and Reporting Data Formats . . . . . . . . 20 9.1. Configuration and Reporting Data Formats . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Appendix - Load Rate Adjustment Pseudo Code . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The IETF's efforts to define Network and Bulk Transport Capacity have The IETF's efforts to define Network and Bulk Transport Capacity have
been chartered and progressed for over twenty years. Over that time, been chartered and progressed for over twenty years. Over that time,
the performance community has seen development of Informative the performance community has seen development of Informative
definitions in [RFC3148] for Framework for Bulk Transport Capacity definitions in [RFC3148] for Framework for Bulk Transport Capacity
(BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity, (BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity,
and the Experimental metric definitions and methods in [RFC8337], and the Experimental metric definitions and methods in [RFC8337],
Model-Based Metrics for BTC. Model-Based Metrics for BTC.
This memo revisits the problem of Network Capacity metrics examined This memo revisits the problem of Network Capacity metrics examined
first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity
and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics. and [RFC3148] Bulk Transfer Capacity (goodput) are different metrics.
Max IP-layer Capacity is like the theoretical goal for goodput. Maximum IP-layer Capacity is like the theoretical goal for goodput.
There are many metrics in [RFC5136], such as Available Capacity. There are many metrics in [RFC5136], such as Available Capacity.
Measurements depend on the network path under test and the use case. Measurements depend on the network path under test and the use case.
Here, the main use case is to assess the maximum capacity of the Here, the main use case is to assess the maximum capacity of the
access network, with specific performance criteria used in the access network, with specific performance criteria used in the
measurement. measurement.
This memo recognizes the importance of a definition of a Maximum IP- This memo recognizes the importance of a definition of a Maximum IP-
layer Capacity Metric at a time when access speeds have increased layer Capacity Metric at a time when access speeds have increased
dramatically; a definition that is both practical and effective for dramatically; a definition that is both practical and effective for
the performance community's needs, including Internet users. The the performance community's needs, including Internet users. The
skipping to change at page 4, line 43 skipping to change at page 4, line 43
SDOs without any special attempts at coordination, various solutions SDOs without any special attempts at coordination, various solutions
for metrics and methods have emerged. for metrics and methods have emerged.
There are five factors that have changed (or begun to change) in the There are five factors that have changed (or begun to change) in the
2013-2019 time frame, and the presence of any one of them on the path 2013-2019 time frame, and the presence of any one of them on the path
requires features in the measurement design to account for the requires features in the measurement design to account for the
changes: changes:
1. Internet access is no longer the bottleneck for many users. 1. Internet access is no longer the bottleneck for many users.
2. Both speed and latency are important to user's satisfaction. 2. Both transfer rate and latency are important to user's
satisfaction.
3. UDP's growing role in Transport, in areas where TCP once 3. UDP's growing role in Transport, in areas where TCP once
dominated. dominated.
4. Content and applications moving physically closer to users. 4. Content and applications moving physically closer to users.
5. Less emphasis on ISP gateway measurements, possibly due to less 5. Less emphasis on ISP gateway measurements, possibly due to less
traffic crossing ISP gateways in future. traffic crossing ISP gateways in future.
4. General Parameters and Definitions 4. General Parameters and Definitions
This section lists the REQUIRED input factors to specify a Sender or This section lists the REQUIRED input factors to specify a Sender or
Receiver metric. Receiver metric.
o Src, the address of a host (such as the globally routable IP o Src, the address of a host (such as the globally routable IP
address). address).
o Dst, the address of a host (such as the globally routable IP o Dst, the address of a host (such as the globally routable IP
address). address).
o i, the limit on the number of Hops a specific packet may visit as o MaxHops, the limit on the number of Hops a specific packet may
it traverses from the host at Src to the host at Dst (such as the visit as it traverses from the host at Src to the host at Dst
TTL or Hop Limit). (implemented in the TTL or Hop Limit).
o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops).
o T0, the time at the start of measurement interval, when packets o T, the time at the start of measurement interval, when packets are
are first transmitted from the Source. first transmitted from the Source.
o I, the nominal duration of a measurement interval at the o I, the nominal duration of a measurement interval at the
destination (default 10 sec) destination (default 10 sec)
o dt, the nominal duration of m equal sub-intervals in I at the o dt, the nominal duration of m equal sub-intervals in I at the
destination (default 1 sec) destination (default 1 sec)
o dtn, a specific sub-interval, n, one of m sub-intervals in I o dtn, a specific sub-interval, n, one of m sub-intervals in I
o Tmax, a maximum waiting time for test packets to arrive at the o Tmax, a maximum waiting time for test packets to arrive at the
skipping to change at page 6, line 46 skipping to change at page 6, line 46
5.2. Parameters 5.2. Parameters
This section lists the REQUIRED input factors to specify the metric, This section lists the REQUIRED input factors to specify the metric,
beyond those listed in Section 4. beyond those listed in Section 4.
No additional Parameters are needed. No additional Parameters are needed.
5.3. Metric Definitions 5.3. Metric Definitions
This section defines the REQUIRED aspects of the measureable IP-layer This section defines the REQUIRED aspects of the measurable IP-layer
Capacity metric (unless otherwise indicated) for measurements between Capacity metric (unless otherwise indicated) for measurements between
specified Source and Destination hosts: specified Source and Destination hosts:
Define the IP-layer capacity, C(T,I,PM), to be the number of IP-layer Define the IP-layer capacity, C(T,dt,PM), to be the number of IP-
bits (including header and data fields) in packets that can be layer bits (including header and data fields) in packets that can be
transmitted from the Src host and correctly received by the Dst host transmitted from the Src host and correctly received by the Dst host
during one contiguous sub-interval, dt in length. The IP-layer during one contiguous sub-interval, dt in length. The IP-layer
capacity depends on the Src and Dst hosts, the host addresses, and capacity depends on the Src and Dst hosts, the host addresses, and
the path between the hosts. the path between the hosts.
The number of these IP-layer bits is designated n0[dtn,dtn+1] for a The number of these IP-layer bits is designated n0[dtn,dtn+1] for a
specific dt. specific dt.
When the packet size is known and of fixed size, the packet count When the packet size is known and of fixed size, the packet count
during a single sub-interval dt multiplied by the total bits in IP during a single sub-interval dt multiplied by the total bits in IP
header and data fields is equal to n0[dtn,dtn+1]. header and data fields is equal to n0[dtn,dtn+1].
Anticipating a Sample of Singletons, the interval dt SHOULD be set to Anticipating a Sample of Singletons, the interval dt SHOULD be set to
a natural number m so that T+I = T + m*dt with dtn+1 - dtn = dt and a natural number m so that T+I = T + m*dt with dtn+1 - dtn = dt and
with 1 <= n <= m. with 1 <= n <= m.
Parameter PM represents other performance metrics [see section Parameter PM represents other performance metrics [see section 5.4
Related Round-Trip Delay and Loss Definitions below]; their below]; their measurement results SHALL be collected during
measurement results SHALL be collected during measurement of IP-layer measurement of IP-layer Capacity and associated with the
Capacity and associated with the corresponding dtn for further corresponding dtn for further evaluation and reporting. Users SHALL
evaluation and reporting. specify the parameter Tmax as required by each metric's reference
definition.
Mathematically, this definition can be represented as: Mathematically, this definition can be represented as:
( n0[dtn,dtn+1] ) ( n0[dtn,dtn+1] )
C(T,I,PM) = ------------------------- C(T,dt,PM) = -------------------------
dt dt
Equation for IP-Layer Capacity Equation for IP-Layer Capacity
and: and:
o n0 is the total number of IP-layer header and payload bits that o n0 is the total number of IP-layer header and payload bits that
can be transmitted in Standard Formed packets [RFC8468] from the can be transmitted in Standard Formed packets [RFC8468] from the
Src host and correctly received by the Dst host during one Src host and correctly received by the Dst host during one
contiguous sub-interval, dt in length, during the interval [T, contiguous sub-interval, dt in length, during the interval [T,
T+I], T+I],
o C(T,I,PM) the IP-Layer Capacity, corresponds to the value of n0 o C(T,dt,PM) the IP-Layer Capacity, corresponds to the value of n0
measured in any sub-interval ending at dtn (meaning T + n*dt), measured in any sub-interval ending at dtn (meaning T + n*dt),
divided by the length of sub-interval, dt. divided by the length of sub-interval, dt.
o PM represents other performance metrics [see section 5.4 below];
their measurement results SHALL be collected during measurement of
IP-layer Capacity and associated with the corresponding dtn for
further evaluation and reporting.
o all sub-intervals MUST be of equal duration. Choosing dt as non- o all sub-intervals MUST be of equal duration. Choosing dt as non-
overlapping consecutive time intervals allows for a simple overlapping consecutive time intervals allows for a simple
implementation. implementation.
o The bit rate of the physical interface of the measurement device o The bit rate of the physical interface of the measurement device
must be higher than that of the link whose C(T,I,PM) is to be must be higher than that of the link whose C(T,I,PM) is to be
measured. measured.
Measurements according to these definitions SHALL use UDP transport Measurements according to these definitions SHALL use the UDP
layer. Standard Formed packets are specified in Section 5 of transport layer. Standard Formed packets are specified in Section 5
[RFC8468]. Some compression affects on measurement are discussed in of [RFC8468]. Some compression affects on measurement are discussed
Section 6 of [RFC8468], as well. in Section 6 of [RFC8468], as well.
5.4. Related Round-Trip Delay and One-way Loss Definitions 5.4. Related Round-Trip Delay and One-way Loss Definitions
RTD[dtn-1,dtn] is defined as a sample of the [RFC2681] Round-trip RTD[dtn-1,dtn] is defined as a sample of the [RFC2681] Round-trip
Delay between the Src host and the Dst host over the interval Delay between the Src host and the Dst host over the interval [T,T+I]
[T,T+I]. The statistics used to to summarize RTD[dtn-1,dtn] MAY (that contains equal non-overlapping intervals of dt). The
include the minimum, maximum, median, and mean. "reasonable period of time" in [RFC2681] is the parameter Tmax in
this memo. The statistics used to to summarize RTD[dtn-1,dtn] MAY
include the minimum, maximum, median, and mean, and the range =
(maximum - minimum) is referred to below in Section 8.1 for load
adjustment purposes.
OWL[dtn-1,dtn] is defined as a sample of the [RFC7680] One-way Loss OWL[dtn-1,dtn] is defined as a sample of the [RFC7680] One-way Loss
between the Src host and the Dst host over the interval [T,T+I]. The between the Src host and the Dst host over the interval [T,T+I] (that
statistics used to to summarize OWL[dtn-1,dtn] MAY include the lost contains equal non-overlapping intervals of dt). The statistics used
packet count and the lost packet ratio. to to summarize OWL[dtn-1,dtn] MAY include the lost packet count and
the lost packet ratio.
Other metrics MAY be measured: one-way reordering, duplication, and Other metrics MAY be measured: one-way reordering, duplication, and
delay variation. delay variation.
5.5. Discussion 5.5. Discussion
See the corresponding section for Maximum IP-Layer Capacity. See the corresponding section for Maximum IP-Layer Capacity.
5.6. Reporting the Metric 5.6. Reporting the Metric
The IP-Layer Capacity SHALL be reported with meaningful resolution, The IP-Layer Capacity SHOULD be reported with at least single Megabit
in units of Megabits per second (Mbps). resolution, in units of Megabits per second (Mbps).
The Related Round Trip Delay and/or Loss metric measurements for the The Related Round Trip Delay and/or Loss metric measurements for the
same Singleton SHALL be reported, also with meaningful resolution for same Singleton SHALL be reported, also with meaningful resolution for
the values measured. the values measured.
Individual Capacity measurements MAY be reported in a manner Individual Capacity measurements MAY be reported in a manner
consistent with the Maximum IP-Layer Capacity, see Section 9. consistent with the Maximum IP-Layer Capacity, see Section 9.
6. Maximum IP-Layer Capacity Metric Definitions (Statistic) 6. Maximum IP-Layer Capacity Metric Definitions (Statistic)
skipping to change at page 9, line 39 skipping to change at page 9, line 44
criteria. Equivalently the Maximum of a Sample of size m of criteria. Equivalently the Maximum of a Sample of size m of
C(T,I,PM) collected during the interval [T, T+I] and meeting the PM C(T,I,PM) collected during the interval [T, T+I] and meeting the PM
criteria. criteria.
The interval dt SHOULD be set to a natural number m so that T+I = T + The interval dt SHOULD be set to a natural number m so that T+I = T +
m*dt with dtn+1 - dtn = dt and with 1 <= n <= m. m*dt with dtn+1 - dtn = dt and with 1 <= n <= m.
Parameter PM represents the other performance metrics (see Parameter PM represents the other performance metrics (see
Section 6.4 below) and their measurement results for the maximum IP- Section 6.4 below) and their measurement results for the maximum IP-
layer capacity. At least one target performance threshold (PM layer capacity. At least one target performance threshold (PM
criterion) MUST be defined. If more than one target performance criterion) MUST be defined. If more than one metric and target
threshold is defined, then the sub-interval with maximum number of performance threshold are defined, then the sub-interval with maximum
bits transmitted MUST meet all the target performance thresholds. number of bits transmitted MUST meet all the target performance
thresholds. Users SHALL specify the parameter Tmax as required by
each metric's reference definition.
Mathematically, this definition can be represented as: Mathematically, this definition can be represented as:
max ( n0[dtn,dtn+1] ) max ( n0[dtn,dtn+1] )
[T,T+I] [T,T+I]
Maximum_C(T,I,PM) = ------------------------- Maximum_C(T,I,PM) = -------------------------
dt dt
where: where:
T T+I T T+I
_________________________________________ _________________________________________
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Equation for Maximum Capacity Equation for Maximum Capacity
and: and:
o n0 is the total number of IP-layer header and payload bits that o n0 is the total number of IP-layer header and payload bits that
can be transmitted in Standard Formed packets from the Src host can be transmitted in Standard Formed packets from the Src host
and correctly received by the Dst host during one contiguous sub- and correctly received by the Dst host during one contiguous sub-
interval, dt in length, during the interval [T, T+I], interval, dt in length, during the interval [T, T+I],
o Maximum _C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to o Maximum_C(T,I,PM) the Maximum IP-Layer Capacity, corresponds to
the maximum value of n0 measured in any sub-interval ending at dtn the maximum value of n0 measured in any sub-interval ending at dtn
(meaning T + n*dt), divided by the constant length of all sub- (meaning T + n*dt), divided by the constant length of all sub-
intervals, dt. intervals, dt.
o PM represents the other performance metrics (see Section 5.4) and
their measurement results for the maximum IP-layer capacity. At
least one target performance threshold (PM criterion) MUST be
defined.
o all sub-intervals MUST be of equal duration. Choosing dt as non- o all sub-intervals MUST be of equal duration. Choosing dt as non-
overlapping consecutive time intervals allows for a simple overlapping consecutive time intervals allows for a simple
implementation. implementation.
o The bit rate of the physical interface of the measurement systems o The bit rate of the physical interface of the measurement systems
must be higher than that of the link whose Maximum _C(T,I,PM) is must be higher than that of the link whose Maximum_C(T,I,PM) is to
to be measured (the bottleneck link). be measured (the bottleneck link).
In this definition, the m sub-intervals can be viewed as trials when In this definition, the m sub-intervals can be viewed as trials when
the Src host varies the transmitted packet rate, searching for the the Src host varies the transmitted packet rate, searching for the
maximum n0 that meets the PM criteria measured at the Dst host in a maximum n0 that meets the PM criteria measured at the Dst host in a
test of duration, I. When the transmitted packet rate is held test of duration, I. When the transmitted packet rate is held
constant at the Src host, the m sub-intervals may also be viewed as constant at the Src host, the m sub-intervals may also be viewed as
trials to evaluate the stability of n0 and metric(s) in the PM list trials to evaluate the stability of n0 and metric(s) in the PM list
over all dt-length intervals in I. over all dt-length intervals in I.
Measurements according to these definitions SHALL use UDP transport Measurements according to these definitions SHALL use the UDP
layer. transport layer.
6.4. Related Round-Trip Delay and One-way Loss Definitions 6.4. Related Round-Trip Delay and One-way Loss Definitions
RTD[dtn,dtn+1] is defined as a sample of the [RFC2681] Round-trip RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here,
Delay between the Src host and the Dst host over the interval the test intervals are increased to match the capacity samples,
[T,T+I], and corresponds to the dt interval containing RTD[T,I] and OWL[T,I].
Maximum_C(T,I,PM). The statistics used to to summarize
RTD[dtn,dtn+1] MAY include the minimum, maximum, median, and mean.
OWL[dtn,dtn+1] is defined as a sample of the [RFC7680] One-way Loss The interval dtn,dtn+1 where Maximum_C[T,I,PM] occurs is the
between the Src host and the Dst host over the interval [T,T+I] and reporting sub-interval for RTD[T,I] and OWL[T,I].
corresponds to the dt interval containing Maximum_C(T,I,PM). The
statistics used to to summarize OWL[dtn-1,dtn] MAY include the lost
packet count and the lost packet ratio.
Other metrics MAY be measured: one-way reordering, duplication, and Other metrics MAY be measured: one-way reordering, duplication, and
delay variation. delay variation.
6.5. Discussion 6.5. Discussion
If traffic conditioning applies along a path for which If traffic conditioning (e.g., shaping, policing) applies along a
Maximum_C(T,I,PM) is to be determined, different values for dt SHOULD path for which Maximum_C(T,I,PM) is to be determined, different
be picked and measurements be executed during multiple intervals [T, values for dt SHOULD be picked and measurements be executed during
T+I]. Any single interval dt SHOULD be chosen so that is an integer multiple intervals [T, T+I]. A single constant interval dt SHOULD be
multiple of increasing values k times serialisation delay of a path chosen so that is an integer multiple of increasing values k times
MTU at the physical interface speed where traffic conditioning is serialisation delay of a path MTU at the physical interface speed
expected. This should avoid taking configured burst tolerance where traffic conditioning is expected. This should avoid taking
singletons as a valid Maximum _C(T,I,PM) result. configured burst tolerance singletons as a valid Maximum_C(T,I,PM)
result.
A Maximum_C(T,I,PM) without any indication of bottleneck congestion, A Maximum_C(T,I,PM) without any indication of bottleneck congestion,
be that an increasing latency, packet loss or ECN marks during a be that an increasing latency, packet loss or ECN marks during a
measurement interval I, is likely to underestimate Maximum_C(T,I,PM). measurement interval I, is likely to underestimate Maximum_C(T,I,PM).
6.6. Reporting the Metric 6.6. Reporting the Metric
The Maximum IP-Layer Capacity SHALL be reported with meaningful The IP-Layer Capacity SHOULD be reported with at least single Megabit
resolution, in units of Megabits per second (which is 1,000,000 bits resolution, in units of Megabits per second (Mbps) (which is
per second to avoid any confusion). 1,000,000 bits per second to avoid any confusion).
The Related Round Trip Delay and/or Loss metric measurements for the The Related Round Trip Delay and/or Loss metric measurements for the
same Singleton SHALL be reported, also with meaningful resolution for same Singleton SHALL be reported, also with meaningful resolution for
the values measured. the values measured.
When there are demonstrated and repeatable Capacity modes in the When there are demonstrated and repeatable Capacity modes in the
Sample, then the Maximum IP-Layer Capacity SHALL be reported for each Sample, then the Maximum IP-Layer Capacity SHALL be reported for each
mode, along with the relative time from the beginning of the stream mode, along with the relative time from the beginning of the stream
that the mode was observed to be present. Bimodal Maxima have been that the mode was observed to be present. Bimodal Maxima have been
observed with some services, sometimes called a "turbo mode" observed with some services, sometimes called a "turbo mode"
skipping to change at page 12, line 21 skipping to change at page 12, line 21
constellations, or cellular modem technologies where the changes may constellations, or cellular modem technologies where the changes may
be initiated by a user moving from one coverage area to another. be initiated by a user moving from one coverage area to another.
Operation in the different transmission methods may be observed over Operation in the different transmission methods may be observed over
time, but the modes of Maximum IP-Layer Capacity will not be time, but the modes of Maximum IP-Layer Capacity will not be
activated deterministically as with the "turbo mode" described in the activated deterministically as with the "turbo mode" described in the
paragraph above. paragraph above.
7. IP-Layer Sender Bit Rate Singleton Metric Definitions 7. IP-Layer Sender Bit Rate Singleton Metric Definitions
This section sets requirements for the following components to This section sets requirements for the following components to
support the IP-layer Sender Bitrate Metric. support the IP-layer Sender Bitrate Metric. This metric helps to
check that the sender actually generated the desired rates during a
test, and measurement takes place at the Src host to network path
interface (or as close as practical). It is not a metric for path
performance.
7.1. Formal Name 7.1. Formal Name
Type-P-IP-Sender-Bit-Rate, or informally called IP-layer Sender Type-P-IP-Sender-Bit-Rate, or informally called IP-layer Sender
Bitrate. Bitrate.
Note that Type-P depends on the chosen method. Note that Type-P depends on the chosen method.
7.2. Parameters 7.2. Parameters
This section lists the REQUIRED input factors to specify the metric, This section lists the REQUIRED input factors to specify the metric,
beyond those listed in Section 4. beyond those listed in Section 4.
o S, the duration of the measurement interval at the Source o S, the duration of the measurement interval at the Source
o st, the nominal duration of N sub-intervals in S (default = 0.05 o st, the nominal duration of N sub-intervals in S (default = 0.05
seconds) seconds)
S SHALL be longer than I, primarily to account for on-demand S SHALL be longer than I, primarily to account for on-demand
activation of the path, or any preamble to testing required. activation of the path, or any preamble to testing required, and the
delay of the path.
st SHOULD be much smaller than the sub-interval dt. The st parameter st SHOULD be much smaller than the sub-interval dt. The st parameter
does not have relevance when the Source is transmitting at a fixed does not have relevance when the Source is transmitting at a fixed
rate throughout S. rate throughout S.
7.3. Metric Definition 7.3. Metric Definition
This section defines the REQUIRED aspects of the IP-layer Sender This section defines the REQUIRED aspects of the IP-layer Sender
Bitrate metric (unless otherwise indicated) for measurements at the Bitrate metric (unless otherwise indicated) for measurements at the
specified Source on packets addressed for the intended Destination specified Source on packets addressed for the intended Destination
host and matching the required Type-P: host and matching the required Type-P:
Define the IP-layer Sender Bit Rate, B(S,st), to be the number of IP- Define the IP-layer Sender Bit Rate, B(S,st), to be the number of IP-
layer bits (including header and data fields) that are transmitted layer bits (including header and data fields) that are transmitted
from the Source during one contiguous sub-interval, st, during the from the Source during one contiguous sub-interval, st, during the
test interval S (where S SHALL be longer than I), and where the test interval S (where S SHALL be longer than I), and where the
fixed-size packet count during that single sub-interval st also fixed-size packet count during that single sub-interval st also
provides the number of IP-layer bits in any interval: n0[stn-1,stn]. provides the number of IP-layer bits in any interval: n0[stn-1,stn].
Measurements according to these definitions SHALL use UDP transport Measurements according to these definitions SHALL use the UDP
layer. Any feedback from Dst host to Src host received by Src host transport layer. Any feedback from Dst host to Src host received by
during an interval [stn-1,stn] MUST NOT result in an adaptation of Src host during an interval [stn-1,stn] MUST NOT result in an
the Src host traffic conditioning during this interval. adaptation of the Src host traffic conditioning during this interval
(rate adjustment occurs on st boundaries).
7.4. Discussion 7.4. Discussion
Both the Sender and Receiver or (source and destination) bit rates Both the Sender and Receiver or (source and destination) bit rates
SHOULD be assessed as part of a measurement. SHOULD be assessed as part of an IP-layer Capacity measurement.
7.5. Reporting the Metric 7.5. Reporting the Metric
The IP-Layer Sender Bit Rate SHALL be reported with meaningful The IP-Layer Sender Bit Rate SHALL be reported with meaningful
resolution, in units of Megabits per second. resolution, in units of Megabits per second.
Individual IP-Layer Sender Bit Rate measurements are discussed Individual IP-Layer Sender Bit Rate measurements are discussed
further in Section 9. further in Section 9.
8. Method of Measurement 8. Method of Measurement
The architecture of the method REQUIRES two cooperating hosts The architecture of the method REQUIRES two cooperating hosts
operating in the roles of Src (test packet sender) and Dst operating in the roles of Src (test packet sender) and Dst
(receiver), with a measured path and return path between them. (receiver), with a measured path and return path between them.
The duration of a test, parameter I, MUST be constrained in a The duration of a test, parameter I, MUST be constrained in a
production network, since this is an active test method and it will production network, since this is an active test method and it will
likely cause congestion on the Src to Dst host path during a test. likely cause congestion on the Src to Dst host path during a test.
Additional Test methods and configurations may be provided in this
section, after review and further testing.
8.1. Load Rate Adjustment Algorithm 8.1. Load Rate Adjustment Algorithm
A table SHALL be pre-built defining all the offered load rates that A table SHALL be pre-built defining all the offered load rates that
will be supported (R1 - Rn, in ascending order). Each rate is will be supported (R1 through Rn, in ascending order, corresponding
defined as datagrams of size S, sent as a burst of count C, every to indexed rows in the table). Each rate is defined as datagrams of
time interval T. While it is advantageous to use datagrams of as size ss, sent as a burst of count cc, every time interval tt (default
large a size as possible, it may be prudent to use a slightly smaller for tt is 1ms, a likely system tick-interval). While it is
maximum that allows for secondary protocol headers and/or tunneling advantageous to use datagrams of as large a size as possible, it may
without resulting in IP-layer fragmentation. be prudent to use a slightly smaller maximum that allows for
secondary protocol headers and/or tunneling without resulting in IP-
layer fragmentation. Selection of a new rate is indicated by a
calculation on the current row, Rx. For example:
"Rx+1": the sender uses the next higher rate in the table.
"Rx-10": the sender uses the rate 10 rows lower in the table.
At the beginning of a test, the sender begins sending at rate R1 and At the beginning of a test, the sender begins sending at rate R1 and
the receiver starts a feedback timer at interval F (while awaiting the receiver starts a feedback timer at interval F (while awaiting
inbound datagrams). As datagrams are received they are checked for inbound datagrams). As datagrams are received they are checked for
sequence number anomalies (loss, out-of-order, duplication, etc.) and sequence number anomalies (loss, out-of-order, duplication, etc.) and
the delay variation is measured (one-way or round-trip). This the delay range is measured (one-way or round-trip). This
information is accumulated until the feedback timer F expires and a information is accumulated until the feedback timer F expires and a
status feedback message is sent from the receiver back to the sender, status feedback message is sent from the receiver back to the sender,
to communicate this information. The accumulated statistics are then to communicate this information. The accumulated statistics are then
reset by the receiver for the next feedback interval. As feedback reset by the receiver for the next feedback interval. As feedback
messages are received back at the sender, they are evaluated to messages are received back at the sender, they are evaluated to
determine how to adjust the current offered load rate (Rx). determine how to adjust the current offered load rate (Rx).
If the feedback indicates that there were no sequence number If the feedback indicates that no sequence number anomalies were
anomalies AND the delay variation was below the lower threshold, the detected AND the delay range was below the lower threshold, the
offered load rate is increased. If congestion has not been confirmed offered load rate is increased. If congestion has not been confirmed
up to this point, the offered load rate is increased by more than one up to this point, the offered load rate is increased by more than one
rate (e.g., Rx+10). This allows the offered load to quickly reach a rate (e.g., Rx+10). This allows the offered load to quickly reach a
near-maximum rate. Conversely, if congestion has been previously near-maximum rate. Conversely, if congestion has been previously
confirmed, the offered load rate is only increased by one (Rx+1). confirmed, the offered load rate is only increased by one (Rx+1).
If the feedback indicates that sequence number anomalies were If the feedback indicates that sequence number anomalies were
detected OR the delay variation was above the upper threshold, the detected OR the delay range was above the upper threshold, the
offered load rate is decreased. If congestion is confirmed by the offered load rate is decreased. Also, if congestion is now confirmed
current feedback message being processed, the offered load rate is by the current feedback message being processed, then the offered
decreased by more than one rate (e.g., Rx-30). This one-time load rate is decreased by more than one rate (e.g., Rx-30). This
reduction is intended to compensate for the fast initial ramp-up. In one-time reduction is intended to compensate for the fast initial
all other cases, the offered load rate is only decreased by one (Rx- ramp-up. In all other cases, the offered load rate is only decreased
1). by one (Rx-1).
If the feedback indicates that there were no sequence number If the feedback indicates that there were no sequence number
anomalies AND the delay variation was above the lower threshold, but anomalies AND the delay range was above the lower threshold, but
below the upper threshold, the offered load rate is not changed. below the upper threshold, the offered load rate is not changed.
This allows time for recent changes in the offered load rate to This allows time for recent changes in the offered load rate to
stabilize, and the feedback to represent current conditions more stabilize, and the feedback to represent current conditions more
accurately. accurately.
Lastly, the method for confirming congestion is that there were Lastly, the method for inferring congestion is that there were
sequence number anomalies OR the delay variation was above the upper sequence number anomalies AND/OR the delay range was above the upper
threshold for two consecutive feedback intervals. The algorithm threshold for two consecutive feedback intervals. The algorithm
described above is also presented in ITU-T Rec. Y.1540, 2020 described above is also illustrated in ITU-T Rec. Y.1540, 2020
version[Y.1540], in Annexes A and B, and implemented in the reference version[Y.1540], in Annex B, and implemented in the Appendix on Load
for Section 8.4, Running Code. Rate Adjustment Pseudo Code in this memo.
All the values used above are relevant to searches in the 1 Mbps to All the values used above are relevant to searches in the 1 Mbps to
10 Gbps capacity range. Searches can accommodate higher rate 10 Gbps capacity range. Searches can accommodate higher rate
capacities by changing the rates in the pre-built table. capacities by changing the rates in the pre-built table.
8.2. Measurement Qualification or Verification 8.2. Measurement Qualification or Verification
It is of course necessary to calibrate the equipment performing the It is of course necessary to calibrate the equipment performing the
IP-layer Capacity measurement, to ensure that the expected capacity IP-layer Capacity measurement, to ensure that the expected capacity
can be measured accurately, and that equipment choices (processing can be measured accurately, and that equipment choices (processing
skipping to change at page 16, line 26 skipping to change at page 16, line 33
8.3. Measurement Considerations 8.3. Measurement Considerations
In general, the wide-spread measurements that this memo encourages In general, the wide-spread measurements that this memo encourages
will encounter wide-spread behaviors. The bimodal IP Capacity will encounter wide-spread behaviors. The bimodal IP Capacity
behaviors already discussed in Section 6.6 are good examples. behaviors already discussed in Section 6.6 are good examples.
In general, it is RECOMMENDED to locate test endpoints as close to In general, it is RECOMMENDED to locate test endpoints as close to
the intended measured link(s) as practical (this is not always the intended measured link(s) as practical (this is not always
possible for reasons of scale; there is a limit on number of test possible for reasons of scale; there is a limit on number of test
endpoints coming from many perspecitves, management and measurement endpoints coming from many perspectives, management and measurement
traffic for example). traffic for example). The testing operator MUST set a value for the
MaxHops parameter, based on the expected path length. This parameter
can keep measurement traffic from straying too far beyond the
intended path.
The path measured may be state-full based on many factors, and the The path measured may be state-full based on many factors, and the
Parameter "Time of day" when a test starts may not be enough Parameter "Time of day" when a test starts may not be enough
information. Repeatable testing may require the time from the information. Repeatable testing may require the time from the
beginning of a measured flow, and how the flow is constructed beginning of a measured flow, and how the flow is constructed
including how much traffic has already been sent on that flow when a including how much traffic has already been sent on that flow when a
state-change is observed, because the state-change may be based on state-change is observed, because the state-change may be based on
time or bytes sent or both. time or bytes sent or both.
Many different traffic shapers and on-demand access technologies may Many different traffic shapers and on-demand access technologies may
skipping to change at page 17, line 6 skipping to change at page 17, line 14
Conditions which might be encountered during measurement, where Conditions which might be encountered during measurement, where
packet losses may occur independently from the measurement sending packet losses may occur independently from the measurement sending
rate: rate:
1. Congestion of an interconnection or backbone interface may appear 1. Congestion of an interconnection or backbone interface may appear
as packet losses distributed over time in the test stream, due to as packet losses distributed over time in the test stream, due to
much higher rate interfaces in the backbone. much higher rate interfaces in the backbone.
2. Packet loss due to use of Random Early Detection (RED) or other 2. Packet loss due to use of Random Early Detection (RED) or other
active queue management. active queue management may or may not affect the measurement
flow if competing background traffic (other flows) are
simultaneously present.
3. There may be only small delay variation independent of sending 3. There may be only small delay variation independent of sending
rate under these conditions, too. rate under these conditions, too.
4. Persistent competing traffic on measurement paths that include 4. Persistent competing traffic on measurement paths that include
shared media may cause random packet losses in the test stream. shared transmission media may cause random packet losses in the
test stream.
It is possible to mitigate these conditions using the flexibility of It is possible to mitigate these conditions using the flexibility of
the load-rate adjusting algorithm described in Section 8.1 above the load-rate adjusting algorithm described in Section 8.1 above
(tuning specific parameters). (tuning specific parameters).
If the measurement flow burst duration happens to be on the order of
or smaller than the burst size of a shaper or a policer in the path,
then the line rate might be measured rather than the bandwidth limit
imposed by the shaper or policer. If this condition is suspected,
alternate configurations SHOULD be used.
In general, results depend on the sending stream characteristics; the In general, results depend on the sending stream characteristics; the
measurement community has known this for a long time, and needs to measurement community has known this for a long time, and needs to
keep it front of mind. Although the default is a single flow (F=1) keep it front of mind. Although the default is a single flow (F=1)
for testing, use of multiple flows may be advantageous for the for testing, use of multiple flows may be advantageous for the
following reasons: following reasons:
1. the test hosts may be able to create higher load than with a 1. the test hosts may be able to create higher load than with a
single flow, or parallel test hosts may be used to generate 1 single flow, or parallel test hosts may be used to generate 1
flow each. flow each.
skipping to change at page 17, line 47 skipping to change at page 18, line 16
Load Adjustment (Search) Algorithm. Load Adjustment (Search) Algorithm.
As testing continues, implementers should expect some evolution in As testing continues, implementers should expect some evolution in
the methods. The ITU-T has published a Supplement (60) to the the methods. The ITU-T has published a Supplement (60) to the
Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP- Y-series of Recommendations, "Interpreting ITU-T Y.1540 maximum IP-
layer capacity measurements", [Y.Sup60], which is the result of layer capacity measurements", [Y.Sup60], which is the result of
continued testing with the metric and method described here. continued testing with the metric and method described here.
8.4. Running Code 8.4. Running Code
This section is for the benefit of the Document Shepherd's form, and
will be deleted prior to final review.
Much of the development of the method and comparisons with existing Much of the development of the method and comparisons with existing
methods conducted at IETF Hackathons and elsewhere have been based on methods conducted at IETF Hackathons and elsewhere have been based on
the example udpst Linux measurement tool (which is a working the example udpst Linux measurement tool (which is a working
reference for further development) [udpst]. The current project: reference for further development) [udpst]. The current project:
o is a utility that can function as a client or server daemon o is a utility that can function as a client or server daemon
o requires a successful client-initiated setup handshake between o requires a successful client-initiated setup handshake between
cooperating hosts and allows firewalls to control inbound cooperating hosts and allows firewalls to control inbound
unsolicited UDP which either go to a control port [expected and w/ unsolicited UDP which either go to a control port [expected and w/
authentication] or to ephemeral ports that are only created as authentication] or to ephemeral ports that are only created as
needed. Firewalls protecting each host can both continue to do needed. Firewalls protecting each host can both continue to do
their job normally. This aspect is similar to many other test their job normally. This aspect is similar to many other test
utilities available. utilities available.
o is written in C, and built with gcc (release 9.3) and its standard o is written in C, and built with gcc (release 9.3) and its standard
run-time libraries run-time libraries
skipping to change at page 18, line 31 skipping to change at page 19, line 4
9. Reporting Formats 9. Reporting Formats
The singleton IP-Layer Capacity results SHOULD be accompanied by the The singleton IP-Layer Capacity results SHOULD be accompanied by the
context under which they were measured. context under which they were measured.
o timestamp (especially the time when the maximum was observed in o timestamp (especially the time when the maximum was observed in
dtn) dtn)
o source and destination (by IP or other meaningful ID) o source and destination (by IP or other meaningful ID)
o other inner parameters of the test case (Section 4) o other inner parameters of the test case (Section 4)
o outer parameters, such as "done in motion" or other factors o outer parameters, such as "test conducted in motion" or other
belonging to the context of the measurement factors belonging to the context of the measurement
o result validity (indicating cases where the process was somehow o result validity (indicating cases where the process was somehow
interrupted or the attempt failed) interrupted or the attempt failed)
o a field where unusual circumstances could be documented, and o a field where unusual circumstances could be documented, and
another one for "ignore/mask out" purposes in further processing another one for "ignore/mask out" purposes in further processing
The Maximum IP-Layer Capacity results SHOULD be reported in the The Maximum IP-Layer Capacity results SHOULD be reported in the
format of a table with a row for each of the test Phases and Number format of a table with a row for each of the test Phases and Number
of Flows. There SHOULD be columns for the phases with number of of Flows. There SHOULD be columns for the phases with number of
skipping to change at page 20, line 14 skipping to change at page 20, line 33
9.1. Configuration and Reporting Data Formats 9.1. Configuration and Reporting Data Formats
As a part of the multi-Standards Development Organization (SDO) As a part of the multi-Standards Development Organization (SDO)
harmonization of this metric and method of measurement, one of the harmonization of this metric and method of measurement, one of the
areas where the Broadband Forum (BBF) contributed its expertise was areas where the Broadband Forum (BBF) contributed its expertise was
in the definition of an information model and data model for in the definition of an information model and data model for
configuration and reporting. These models are consistent with the configuration and reporting. These models are consistent with the
metric parameters and default values specified as lists is this memo. metric parameters and default values specified as lists is this memo.
[TR-471] provides the Information model that was used to prepare a [TR-471] provides the Information model that was used to prepare a
full data model in related BBF work. The BBF has als carefully full data model in related BBF work. The BBF has also carefully
considered topics within its purvue, such as placement of measurement considered topics within its purview, such as placement of
systems within the access archtecture. For example, timestamp measurement systems within the access architecture. For example,
resolution requirements that influence the choice of the test timestamp resolution requirements that influence the choice of the
protocol are provided in Table 2 of [TR-471]. test protocol are provided in Table 2 of [TR-471].
10. Security Considerations 10. Security Considerations
Active metrics and measurements have a long history of security Active metrics and measurements have a long history of security
considerations. The security considerations that apply to any active considerations. The security considerations that apply to any active
measurement of live paths are relevant here. See [RFC4656] and measurement of live paths are relevant here. See [RFC4656] and
[RFC5357]. [RFC5357].
When considering privacy of those involved in measurement or those When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to whose traffic is measured, the sensitive information available to
skipping to change at page 21, line 6 skipping to change at page 21, line 25
cooperating hosts and allows firewalls to control inbound cooperating hosts and allows firewalls to control inbound
unsolicited UDP which either go to a control port [expected and unsolicited UDP which either go to a control port [expected and
w/authentication] or to ephemeral ports that are only created as w/authentication] or to ephemeral ports that are only created as
needed. Firewalls protecting each host can both continue to do needed. Firewalls protecting each host can both continue to do
their job normally. their job normally.
3. Integrity protection for feedback messages conveying measurements 3. Integrity protection for feedback messages conveying measurements
is RECOMMENDED. is RECOMMENDED.
4. Hosts MUST limit the number of simultaneous tests to avoid 4. Hosts MUST limit the number of simultaneous tests to avoid
resource exhaust and inaccuate results. resource exhaustion and inaccurate results.
5. Senders MUST be rate-limited. This can be accomplished using the 5. Senders MUST be rate-limited. This can be accomplished using the
pre-built table defining all the offered load rates that will be pre-built table defining all the offered load rates that will be
supported (Section 8.1). The recommended load-control search supported (Section 8.1). The recommended load-control search
algorithm results in "ramp up" from the lowest rate in the table. algorithm results in "ramp up" from the lowest rate in the table.
6. Service subscribers with limited data volumes who conduct 6. Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of extensive capacity testing might experience the effects of
Service Provider controls on their service. Testing with the Service Provider controls on their service. Testing with the
Service Provider's measurement hosts SHOULD be limited in Service Provider's measurement hosts SHOULD be limited in
frequency and/or overall volume of test traffic. frequency and/or overall volume of test traffic.
The exact specification of these features is left for the future The exact specification of these features is left for the future
protocol development. protocol development.
11. IANA Considerations 11. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
12. Acknowledgements 12. Acknowledgments
Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin, Thanks to Joachim Fabini, Matt Mathis, J.Ignacio Alvarez-Hamelin,
Wolfgang Balzer, Frank Brockners and Greg Mirsky for their extensive Wolfgang Balzer, Frank Brockners, Greg Mirsky and Martin Duke for
comments on the memo and related topics. their extensive comments on the memo and related topics.
13. References 13. Appendix - Load Rate Adjustment Pseudo Code
13.1. Normative References The following is a pseudo-code implementation of the algorithm
described in Section 8.1.
Rx = 1 # The current sending rate (equivalent to a row of the table)
seqErr = 0 # Measured count of any of Loss or Reordering impairments
delay = 0 # Measured Range of Round Trip Time, RTT, ms
lowThresh = 30 # Low threshold on the Range of RTT, ms
upperThresh = 90 # Upper threshold on the Range of RTT, ms
hSpeedTresh = 1Gbps # Threshold for transition between sending rate step
sizes (such as 1 Mbps and 100 Mbps)
slowAdjCount = 0 # Measured Number of consecutive status reports
indicating loss and/or delay variation above upperThresh
slowAdjThresh = 2 # Threshold on slowAdjCount used to infer congestion.
Use values >1 to avoid misinterpreting transient loss
highSpeedDelta = 10 # The number of rows to move in a single adjustment
when initially increasing offered load (to ramp-up quickly)
maxLoadRates = 2000 # Maximum table index (rows)
if ( seqErr == 0 && delay < lowThresh ) {
if ( Rx < hSpeedTresh && slowAdjCount < slowAdjThresh ) {
Rx += highSpeedDelta;
slowAdjCount = 0;
} else {
if ( Rx < maxLoadRates - 1 )
Rx++;
}
} else if ( seqErr > 0 || delay > upperThresh ) {
slowAdjCount++;
if ( Rx < hSpeedTresh && c->slowAdjCount == slowAdjThresh ) {
if ( Rx > highSpeedDelta * 3 )
Rx -= highSpeedDelta * 3;
else
Rx = 0;
} else {
if ( Rx > 0 )
Rx--;
}
}
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
skipping to change at page 23, line 28 skipping to change at page 24, line 45
[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk
Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March
2018, <https://www.rfc-editor.org/info/rfc8337>. 2018, <https://www.rfc-editor.org/info/rfc8337>.
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for
the IP Performance Metrics (IPPM) Framework", RFC 8468, the IP Performance Metrics (IPPM) Framework", RFC 8468,
DOI 10.17487/RFC8468, November 2018, DOI 10.17487/RFC8468, November 2018,
<https://www.rfc-editor.org/info/rfc8468>. <https://www.rfc-editor.org/info/rfc8468>.
13.2. Informative References 14.2. Informative References
[copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet,
"copycat: Testing Differential Treatment of New Transport "copycat: Testing Differential Treatment of New Transport
Protocols in the Wild (ANRW '17)", July 2017, Protocols in the Wild (ANRW '17)", July 2017,
<https://irtf.org/anrw/2017/anrw17-final5.pdf>. <https://irtf.org/anrw/2017/anrw17-final5.pdf>.
[LS-SG12-A] [LS-SG12-A]
12, I. S., "LS - Harmonization of IP Capacity and Latency 12, I. S., "LS - Harmonization of IP Capacity and Latency
Parameters: Revision of Draft Rec. Y.1540 on IP packet Parameters: Revision of Draft Rec. Y.1540 on IP packet
transfer performance parameters and New Annex A with Lab transfer performance parameters and New Annex A with Lab
 End of changes. 59 change blocks. 
128 lines changed or deleted 207 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/