Technical Summary
This document describes a method to perform packet loss, delay and
jitter measurements on live traffic. This method is based on
Alternate Marking (Coloring) technique. A report on the operational
experiment done at Telecom Italia is explained in order to give an
example and show the method applicability. This technique can be
applied in various situations as detailed in this document and could
be considered passive or hybrid depending on the application.
Working Group Summary
The WG process as it relates to this document has been smooth and
without major controversies. The WGLC was also smooth, and the
editors have been very responsive and diligent in incorporating all
the WGLC comments in a timely fashion.
While the document contain a single Editor, it lists more than five
authors. The history and rationale for that is as follows: the ideas
on this methodology originated and were introduced to the IETF
from two I-Ds: draft-cociglio-mboned-multicast-pm and
draft-tempia-opsawg-p3m. Most recently, draft-tempia-opsawg-p3m
targeted the IPPM WG, and was renamed to draft-tempia-ippm-p3m.
After adotpion in IPPM, it merged with the descriptive portions of
draft-chen-ippm-coloring-based-ipfpm-framework (the architectural
portions were deamed out of scope for IPPM. This union added more
value to the work because it completed the technical explanation of
the methodology. Consequently new authors joined the draft after
this merge.
Document Quality
There is both significant and broad support for the methods defined
in this document. This manifests itself in the number of protocols
that are producing specifications (in other working groups) utilizing
these methods natively with them. For example, BIER, MPLS, etc.
This document has 12 other documents currently referencing it, as
per <https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/referencedby/>.
Further, there are many vendors (chip vendors, networking software
vendors, etc.) either with implementations, roadmaps, or plans
to implement these methods.
Personnel
Carlos Pignataro is the Document Shepherd.
Spencer Dawkins is the Responsible Area Director.
RFC Editor Note
RFC Editor Note
OLD
o no interoperability issues: the features required to experiment
and test the method (as described in Section 5.1) are available on
all current routing platforms. Both a centarlized or distributed
solution can be used to harvest data from the routers.
NEW
o no interoperability issues: the features required to experiment
and test the method (as described in Section 5.1) are available on
all current routing platforms. Both a centralized or distributed
solution can be used to harvest data from the routers.
OLD
Traffic coloring could be done by R1 itself or it is already done
before. R1 needs two counters, C(A)R1 and C(B)R1, on its egress
interface: C(A)R1 counts the packets with color A and C(B)R1 counts
those with color B. As long as traffic is colored A, only counter
C(A)R1 will be incremented, while C(B)R1 is not incremented; vice
versa, when the traffic is colored as B, only C(B)R1 is incremented.
C(A)R1 and C(B)R1 can be used as reference values to determine the
packet loss from R1 to any other measurement point down the path.
Router R2, similarly, will need two counters on its ingress
interface, C(A)R2 and C(B)R2, to count the packets received on that
interface and colored with color A and B respectively. When an A
block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
the packet loss within the block; similarly, when the successive B
block terminates, it is possible to compare C(B)R1 with C(B)R2, and
so on for every successive block.
NEW
Traffic coloring can be done by R1 itself if the traffic is not already
colored. R1 needs two counters, C(A)R1 and C(B)R1, on its egress
interface: C(A)R1 counts the packets with color A and C(B)R1 counts
those with color B. As long as traffic is colored A, only counter
C(A)R1 will be incremented, while C(B)R1 is not incremented; vice
versa, when the traffic is colored as B, only C(B)R1 is incremented.
C(A)R1 and C(B)R1 can be used as reference values to determine the
packet loss from R1 to any other measurement point down the path.
Router R2, similarly, will need two counters on its ingress
interface, C(A)R2 and C(B)R2, to count the packets received on that
interface and colored with color A and B respectively. When an A
block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
the packet loss within the block; similarly, when the successive B
block terminates, it is possible to compare C(B)R1 with C(B)R2, and
so on for every successive block.
OLD
The privacy concerns of network measurement are limited because the
method only relies on information contained in the header or
encapsulation without any release of user data.Although information
in the header or encapsulation is metadata that can be used to
compromise the privacy of users, the limited marking technique in
this document seems unlikely to substantially increase the existing
privacy risks from header or encapsulation metadata.It might be
theoretically possible to modulate the marking to serve as a covert
channel, but it would have a very low data rate if it is to avoid
adversely affecting the measurement systems that monitor the marking.
NEW
The privacy concerns of network measurement are limited because the
method only relies on information contained in the header or
encapsulation without any release of user data. Although information
in the header or encapsulation is metadata that can be used to
compromise the privacy of users, the limited marking technique in
this document seems unlikely to substantially increase the existing
privacy risks from header or encapsulation metadata. It might be
theoretically possible to modulate the marking to serve as a covert
channel, but it would have a very low data rate if it is to avoid
adversely affecting the measurement systems that monitor the marking.