< draft-ietf-ippm-rfc8321bis-00.txt   draft-ietf-ippm-rfc8321bis-01.txt >
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 8321 (if approved) M. Cociglio Obsoletes: 8321 (if approved) M. Cociglio
Intended status: Standards Track Telecom Italia Intended status: Standards Track Telecom Italia
Expires: October 28, 2022 G. Mirsky Expires: October 30, 2022 G. Mirsky
Ericsson Ericsson
T. Mizrahi T. Mizrahi
T. Zhou T. Zhou
Huawei Technologies Huawei Technologies
April 26, 2022 April 28, 2022
Alternate-Marking Method Alternate-Marking Method
draft-ietf-ippm-rfc8321bis-00 draft-ietf-ippm-rfc8321bis-01
Abstract Abstract
This document describes the Alternate-Marking technique to perform This document describes the Alternate-Marking technique to perform
packet loss, delay, and jitter measurements on live traffic. This packet loss, delay, and jitter measurements on live traffic. This
technology can be applied in various situations and for different technology can be applied in various situations and for different
protocols. It could be considered Passive or Hybrid depending on the protocols. It could be considered Passive or Hybrid depending on the
application. This document obsoletes [RFC8321]. application. This document obsoletes [RFC8321].
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 October 28, 2022. This Internet-Draft will expire on October 30, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Summary of Changes from RFC 8321 . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4 2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4
3. Detailed Description of the Method . . . . . . . . . . . . . 5 3. Detailed Description of the Method . . . . . . . . . . . . . 5
3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 5 3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 6
3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9 3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9
3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9 3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9
3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10 3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10
3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11 3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11
4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12 4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12
4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12 4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12
4.2. Counting and Timestamping Packets . . . . . . . . . . . . 12 4.2. Counting and Timestamping Packets . . . . . . . . . . . . 13
4.3. Data Collection and Correlation . . . . . . . . . . . . . 13 4.3. Data Collection and Correlation . . . . . . . . . . . . . 13
5. Synchronization and Timing . . . . . . . . . . . . . . . . . 14 5. Synchronization and Timing . . . . . . . . . . . . . . . . . 14
6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 16 6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 16
7. Results of the Alternate Marking Experiment . . . . . . . . . 16 7. Results of the Alternate Marking Experiment . . . . . . . . . 17
7.1. Controlled Domain requirement . . . . . . . . . . . . . . 18 7.1. Controlled Domain requirement . . . . . . . . . . . . . . 18
8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 18 8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Most Service Providers' networks carry traffic with contents that are Most Service Providers' networks carry traffic with contents that are
highly sensitive to packet loss [RFC7680], delay [RFC7679], and highly sensitive to packet loss [RFC7680], delay [RFC7679], and
jitter [RFC3393]. jitter [RFC3393].
Service Providers need methodologies and tools to monitor and Service Providers need methodologies and tools to monitor and
accurately measure network performance, in order to constantly accurately measure network performance, in order to constantly
control the quality of experience perceived by their customers. control the quality of experience perceived by their customers.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
usually more easily understood by customers and provide much better usually more easily understood by customers and provide much better
accuracy, especially for packet loss measurements. accuracy, especially for packet loss measurements.
Therefore, the Alternate-Marking Method could be considered Hybrid or Therefore, the Alternate-Marking Method could be considered Hybrid or
Passive, depending on the case. In the case where the marking method Passive, depending on the case. In the case where the marking method
is obtained by changing existing field values of the packets the is obtained by changing existing field values of the packets the
technique is Hybrid. In the case where the marking field is technique is Hybrid. In the case where the marking field is
dedicated, reserved, and included in the protocol specification, the dedicated, reserved, and included in the protocol specification, the
Alternate-Marking technique can be considered as Passive. Alternate-Marking technique can be considered as Passive.
1.1. Requirements Language 1.1. Summary of Changes from RFC 8321
This document defines the Alternate-Marking Method, addressing
ambiguities and overtaking its experimental phase in the original
specification [RFC8321].
The relevant changes are:
o Added the recommendations about the methods to employ in case one
or two flag bits are available for marking (Section 7).
o Changed the structure to improve the readability.
o Removed the wording about the initial experiments of the method
and considerations that no longer apply.
o Extended the description of detailed aspects of the methodology,
e.g. synchronization, timing, packet fragmentation, marked and
unmarked traffic handling.
It is important to note that all the changes are totally backward
compatible with [RFC8321] and no new additional technique has been
introduced in this document compared to [RFC8321].
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview of the Method 2. Overview of the Method
In order to perform packet loss measurements on a production traffic In order to perform packet loss measurements on a production traffic
skipping to change at page 10, line 7 skipping to change at page 10, line 18
if packet misordering can be avoided; otherwise, the first packet of if packet misordering can be avoided; otherwise, the first packet of
a block on R1 could be different from the first packet of the same a block on R1 could be different from the first packet of the same
block on R2 (for instance, if that packet is lost between R1 and R2 block on R2 (for instance, if that packet is lost between R1 and R2
or it arrives after the next one). Since packet misordering is or it arrives after the next one). Since packet misordering is
generally undetectable it is not possible to check whether the first generally undetectable it is not possible to check whether the first
packet on R1 is the same on R2 and this is part of the intrinsic packet on R1 is the same on R2 and this is part of the intrinsic
error in this measurement. error in this measurement.
3.2.1.1. Mean Delay 3.2.1.1. Mean Delay
As mentioned before, the method previously exposed for measuring the The method previously exposed for measuring the delay is sensitive to
delay is sensitive to out-of-order reception of packets. In order to out-of-order reception of packets. In order to overcome this
overcome this problem, a different approach has been considered: it problem, an approach based on the concept of mean delay can be
is based on the concept of mean delay. The mean delay is calculated considered. The mean delay is calculated by considering the average
by considering the average arrival time of the packets within a arrival time of the packets within a single block. The network
single block. The network device locally stores a timestamp for each device locally stores a timestamp for each packet received within a
packet received within a single block: summing all the timestamps and single block: summing all the timestamps and dividing by the total
dividing by the total number of packets received, the average arrival number of packets received, the average arrival time for that block
time for that block of packets can be calculated. By subtracting the of packets can be calculated. By subtracting the average arrival
average arrival times of two adjacent devices, it is possible to times of two adjacent devices, it is possible to calculate the mean
calculate the mean delay between those nodes. When computing the delay between those nodes. This method greatly reduces the number of
mean delay, the measurement error could be augmented by accumulating timestamps that have to be collected (only one per block for each
the measurement error of a lot of packets. This method is robust to network device) and it is robust to out-of-order packets with only a
out-of-order packets and also to packet loss (only a small error is small error introduced in case of packet loss. But, when computing
introduced). Moreover, it greatly reduces the number of timestamps the mean delay, the measurement error could be augmented by
(only one per block for each network device) that have to be accumulating the measurement error of a lot of packets.
collected by the management system. On the other hand, it only gives Additionally, it only gives one measure for the duration of the
one measure for the duration of the block, and it doesn't give the block, and it doesn't give the minimum, maximum, and median delay
minimum, maximum, and median delay values [RFC6703]. This limitation values [RFC6703]. This limitation could be overcome by reducing the
could be overcome by reducing the duration of the block (for duration of the block (for instance, from minutes to seconds), which
instance, from 5 minutes to a few seconds), which implies a highly implies a highly optimized implementation of the method. For this
optimized implementation of the method. reason, the mean delay calculation may not be so viable in some
cases.
3.2.2. Double-Marking Methodology 3.2.2. Double-Marking Methodology
The Single-Marking methodology for one-way delay measurement is As mentioned above, the Single-Marking methodology for one-way delay
sensitive to out-of-order reception of packets. The first approach measurement has some limitations, since it is sensitive to out-of-
to overcome this problem has been described before and is based on order reception of packets and even the mean delay calculation is
the concept of mean delay. But the limitation of mean delay is that limited because it doesn't give information about the delay value's
it doesn't give information about the delay value's distribution for distribution for the duration of the block. Actually, it may be
the duration of the block. Additionally, it may be useful to have useful to have not only the mean delay but also the minimum, maximum,
not only the mean delay but also the minimum, maximum, and median and median delay values and, in wider terms, to know more about the
delay values and, in wider terms, to know more about the statistic statistic distribution of delay values. So, in order to have more
distribution of delay values. So, in order to have more information information about the delay and to overcome out-of-order issues, a
about the delay and to overcome out-of-order issues, a different different approach can be introduced and it is based on a Double-
approach can be introduced; it is based on a Double-Marking Marking methodology.
methodology.
Basically, the idea is to use the first marking to create the Basically, the idea is to use the first marking to create the
alternate flow and, within this colored flow, a second marking to alternate flow and, within this colored flow, a second marking to
select the packets for measuring delay/jitter. The first marking is select the packets for measuring delay/jitter. The first marking is
needed for packet loss and mean delay measurement. The second needed for packet loss and may be used for mean delay measurement.
marking creates a new set of marked packets that are fully identified The second marking creates a new set of marked packets that are fully
over the network, so that a network device can store the timestamps identified over the network, so that a network device can store the
of these packets; these timestamps can be compared with the timestamps of these packets; these timestamps can be compared with
timestamps of the same packets on a second router to compute packet the timestamps of the same packets on a second router to compute
delay values for each packet. The number of measurements can be packet delay values for each packet. The number of measurements can
easily increased by changing the frequency of the second marking. be easily increased by changing the frequency of the second marking.
But the frequency of the second marking must not be too high in order But the frequency of the second marking must not be too high in order
to avoid out-of-order issues. Between packets with the second to avoid out-of-order issues. Between packets with the second
marking, there should be a security time gap (e.g., this gap could marking, there should be a security time gap (e.g., this gap could
be, at the minimum, the mean network delay calculated with the be, at the minimum, the mean network delay calculated with the
previous methodology) to avoid out-of-order issues and also to have a previous methodology) to avoid out-of-order issues and also to have a
number of measurement packets that are rate independent. If a number of measurement packets that are rate independent. If a
second-marking packet is lost, the delay measurement for the second-marking packet is lost, the delay measurement for the
considered block is corrupted and should be discarded. considered block is corrupted and should be discarded.
Mean delay is calculated on all the packets of a sample and is a An efficient and robust mode is to select a single packet with the
simple computation to be performed for a Single-Marking Method. In second marking for each block, in this way there is no time gap to
some cases, the mean delay measure is not sufficient to characterize consider between the double-marked packets to avoid their reorder.
the sample, and more statistics of delay extent data are needed,
e.g., percentiles, variance, and median delay values. The The Double-Marking methodology can also be used to get more
conventional range (maximum-minimum) should be avoided for several statistics of delay extent data, e.g., percentiles, variance, and
reasons, including stability of the maximum delay due to the median delay values. Indeed, a subset of batch packets is selected
influence by outliers. RFC 5481 [RFC5481], Section 6.5 highlights for extensive delay calculation by using the second marking and it is
how the 99.9th percentile of delay and delay variation is more possible to perform a detailed analysis on these double-marked
helpful to performance planners. To overcome this drawback, the idea packets. It is worth noting that there are classic algorithms for
is to couple the mean delay measure for the entire batch with a
Double-Marking Method, where a subset of batch packets is selected
for extensive delay calculation by using a second marking. In this
way, it is possible to perform a detailed analysis on these double-
marked packets. Please note that there are classic algorithms for
median and variance calculation, but they are out of the scope of median and variance calculation, but they are out of the scope of
this document. The comparison between the mean delay for the entire this document. The conventional range (maximum-minimum) should be
batch and the mean delay on these double-marked packets gives useful avoided for several reasons, including stability of the maximum delay
information since it is possible to understand if the Double-Marking due to the influence by outliers. In this regard, RFC 5481
measurements are actually representative of the delay trends. [RFC5481], Section 6.5 highlights how the 99.9th percentile of delay
and delay variation is more helpful to performance planners.
3.3. Delay Variation Measurement 3.3. Delay Variation Measurement
Similar to one-way delay measurement (both for Single Marking and Similar to one-way delay measurement (both for Single Marking and
Double Marking), the method can also be used to measure the inter- Double Marking), the method can also be used to measure the inter-
arrival jitter. We refer to the definition in RFC 3393 [RFC3393]. arrival jitter. We refer to the definition in RFC 3393 [RFC3393].
The alternation of colors, for a Single-Marking Method, can be used The alternation of colors, for a Single-Marking Method, can be used
as a time reference to measure delay variations. In case of Double as a time reference to measure delay variations. In case of Double
Marking, the time reference is given by the second-marked packets. Marking, the time reference is given by the second-marked packets.
Considering the example depicted in Figure 2, R1 stores the timestamp Considering the example depicted in Figure 2, R1 stores the timestamp
skipping to change at page 16, line 5 skipping to change at page 16, line 10
network delay between the network devices, and D_stddev is the network delay between the network devices, and D_stddev is the
standard deviation of the delay. standard deviation of the delay.
The available counting interval is L - 2d that must be > 0. The available counting interval is L - 2d that must be > 0.
The condition that must be satisfied and is a requirement on the The condition that must be satisfied and is a requirement on the
synchronization accuracy is: synchronization accuracy is:
d < L/2. d < L/2.
This is the fundamental rule for deciding when to read the counters
and when to select the packets to be double-marked, indeed packet
counter and double-marked packets MUST respectively be taken and
chosen within the available counting interval that is not affected by
error factors.
It is worth mentioning that, if the time duration L of each block is It is worth mentioning that, if the time duration L of each block is
not so small, the synchronization requirement could be satisfied even not so small, the synchronization requirement could be satisfied even
with a relatively inaccurate synchronization method. This is true with a relatively inaccurate synchronization method. This is true
for packet loss and two-way delay measurement, but not for one-way for packet loss and two-way delay measurement, but not for one-way
delay measurement, where clock synchronization must be accurate. delay measurement, where clock synchronization must be accurate.
Therefore, a system that uses only packet loss and two-way delay Therefore, a system that uses only packet loss and two-way delay
measurement may not require a very precise synchronization. This is measurement may not require a very precise synchronization. This is
because the value of the clocks of network devices does not affect because the value of the clocks of network devices does not affect
the computation of the two-way delay measurement. the computation of the two-way delay measurement.
skipping to change at page 26, line 37 skipping to change at page 26, line 51
Changes in draft-fioccola-rfc8321bis-04/draft-ietf-ippm-rfc8321bis-00 Changes in draft-fioccola-rfc8321bis-04/draft-ietf-ippm-rfc8321bis-00
include: include:
o Revised "Introduction" section o Revised "Introduction" section
o Revised sections 4.2 "Counting and Timestamping Packets" and 4.3 o Revised sections 4.2 "Counting and Timestamping Packets" and 4.3
on "Data Collection and Correlation" on "Data Collection and Correlation"
o Revised section 5 on "Synchronization and Timing" o Revised section 5 on "Synchronization and Timing"
Changes in draft-ietf-ippm-rfc8321bis-01 include:
o New section on "Summary of Changes from RFC 8321"
o Revised sections on "Single-Marking Methodology" and "Double-
Marking Methodology"
Authors' Addresses Authors' Addresses
Giuseppe Fioccola (editor) Giuseppe Fioccola (editor)
Huawei Technologies Huawei Technologies
Riesstrasse, 25 Riesstrasse, 25
Munich 80992 Munich 80992
Germany Germany
Email: giuseppe.fioccola@huawei.com Email: giuseppe.fioccola@huawei.com
Mauro Cociglio Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: mauro.cociglio@telecomitalia.it Email: mauro.cociglio@telecomitalia.it
Greg Mirsky Greg Mirsky
Ericsson Ericsson
 End of changes. 20 change blocks. 
73 lines changed or deleted 108 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/