draft-ietf-ippm-route-05.txt   draft-ietf-ippm-route-06.txt 
Network Working Group J. Alvarez-Hamelin Network Working Group J. Alvarez-Hamelin
Internet-Draft Universidad de Buenos Aires Internet-Draft Universidad de Buenos Aires
Updates: 2330 (if approved) A. Morton Updates: 2330 (if approved) A. Morton
Intended status: Standards Track AT&T Labs Intended status: Standards Track AT&T Labs
Expires: March 14, 2020 J. Fabini Expires: May 6, 2020 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
September 11, 2019 November 3, 2019
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-05 draft-ietf-ippm-route-06
Abstract Abstract
This memo introduces an advanced unidirectional route assessment This memo introduces an advanced unidirectional route assessment
(AURA) metric and associated measurement methodology, based on the IP (AURA) metric and associated measurement methodology, based on the IP
Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC
2330 in the areas of path-related terminology and path description, 2330 in the areas of path-related terminology and path description,
primarily to include the possibility of parallel subpaths between a primarily to include the possibility of parallel subpaths between a
given Source and Destination pair, owing to the presence of multi- given Source and Destination pair, owing to the presence of multi-
path technologies. path technologies.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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, 2020. This Internet-Draft will expire on May 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Issues with Earlier Work to define Route . . . . . . . . 3 1.1. Issues with Earlier Work to define Route . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Route Metric Terms and Definitions . . . . . . . . . . . . . 5 3. Route Metric Terms and Definitions . . . . . . . . . . . . . 5
3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7
3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9 3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
4. Route Assessment Methodologies . . . . . . . . . . . . . . . 11 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 10
4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 11 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10
4.1.1. Temporal Composition for Route Metrics . . . . . . . 13 4.1.1. Temporal Composition for Route Metrics . . . . . . . 12
4.1.2. Routing Class C Identification . . . . . . . . . . . 14 4.1.2. Routing Class C Identification . . . . . . . . . . . 13
4.1.3. Intermediate Observation Point Route Measurement . . 15 4.1.3. Intermediate Observation Point Route Measurement . . 14
4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15
4.3. Combining Different Methods . . . . . . . . . . . . . . . 16 4.3. Combining Different Methods . . . . . . . . . . . . . . . 15
5. Background on Round-Trip Delay Measurement Goals . . . . . . 16 5. Background on Round-Trip Delay Measurement Goals . . . . . . 16
6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17 6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17
7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18 7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21 12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group first created a The IETF IP Performance Metrics (IPPM) working group first created a
framework for metric development in [RFC2330]. This framework has framework for metric development in [RFC2330]. This framework has
stood the test of time and enabled development of many fundamental stood the test of time and enabled development of many fundamental
metrics. It has been updated in the area of metric composition metrics. It has been updated in the area of metric composition
[RFC5835], and in several areas related to active stream measurement [RFC5835], and in several areas related to active stream measurement
of modern networks with reactive properties [RFC7312]. of modern networks with reactive properties [RFC7312].
skipping to change at page 3, line 24 skipping to change at page 3, line 24
The [RFC2330] framework motivated the development of "performance and The [RFC2330] framework motivated the development of "performance and
reliability metrics for paths through the Internet," and Section 5 of reliability metrics for paths through the Internet," and Section 5 of
[RFC2330] defines terms that support description of a path under [RFC2330] defines terms that support description of a path under
test. However, metrics for assessment of path components and related test. However, metrics for assessment of path components and related
performance aspects had not been attempted in IPPM when the [RFC2330] performance aspects had not been attempted in IPPM when the [RFC2330]
framework was written. framework was written.
This memo takes-up the route measurement challenge and specifies a This memo takes-up the route measurement challenge and specifies a
new route metric, two practical frameworks for methods of measurement new route metric, two practical frameworks for methods of measurement
(using either active or hybrid active-passive methods [RFC7799]), and (using either active or hybrid active-passive methods [RFC7799]), and
round-trip delay and link information discovery using the results of Round-Trip Delay and link information discovery using the results of
measurements. All route measurements are limited by the willingness measurements. All route measurements are limited by the willingness
of hosts along the path to be discovered, to cooperate with the of hosts along the path to be discovered, to cooperate with the
methods used, or to recognize that the measurement operation is methods used, or to recognize that the measurement operation is
taking place (such as when tunnels are present). taking place (such as when tunnels are present).
1.1. Issues with Earlier Work to define Route 1.1. Issues with Earlier Work to define Route
Section 7 of [RFC2330] presented a simple example of a "route" metric Section 7 of [RFC2330] presented a simple example of a "route" metric
along with several other examples. The example is reproduced below along with several other examples. The example is reproduced below
(where the reference is to Section 5 of [RFC2330]): (where the reference is to Section 5 of [RFC2330]):
skipping to change at page 4, line 5 skipping to change at page 4, line 5
because active path detection methods like [PT] rely on TTL limits because active path detection methods like [PT] rely on TTL limits
for their operation and cannot accomplish discovery of all hosts for their operation and cannot accomplish discovery of all hosts
using a single packet. using a single packet.
Type-P: The legacy route definition lacks the option to cater for Type-P: The legacy route definition lacks the option to cater for
packet-dependent routing. In this memo, we assess the route for a packet-dependent routing. In this memo, we assess the route for a
specific packet of Type-P, and reflect this in the metric specific packet of Type-P, and reflect this in the metric
definition. The methods of measurement determine the specific definition. The methods of measurement determine the specific
Type-P used. Type-P used.
Parallel Paths: This a reality of Internet paths and a strength of Parallel Paths: Parallel paths are a reality of the Internet and a
advanced route assessment methods, so the metric must acknowledge strength of advanced route assessment methods, so the metric must
this possibility. Use of Equal Cost Multi-Path (ECMP) and Unequal acknowledge this possibility. Use of Equal Cost Multi-Path (ECMP)
Cost Multi-Path (UCMP) technologies are common sources of parallel and Unequal Cost Multi-Path (UCMP) technologies are common sources
subpaths. of parallel subpaths.
Cloud Subpath: May contain hosts that do not decrement TTL or Hop Cloud Subpath: May contain hosts that do not decrement TTL or Hop
Limit, but may have two or more exchange links connecting Limit, but may have two or more exchange links connecting
"discoverable" hosts or routers. Parallel subpaths contained "discoverable" hosts or routers. Parallel subpaths contained
within clouds cannot be discovered. The assessment methods only within clouds cannot be discovered. The assessment methods only
discover hosts or routers on the path that decrement TTL or Hop discover hosts or routers on the path that decrement TTL or Hop
Count, or cooperate with interrogation protocols. The presence of Count, or cooperate with interrogation protocols. The presence of
tunnels and nested tunnels further complicate assessment by hiding tunnels and nested tunnels further complicate assessment by hiding
hops. hops.
Hop: Although the [RFC2330] definition was a link-host pair, only Hop: Although the [RFC2330] definition of a hop was a link-host
hosts are discoverable or have the capability to cooperate with pair, only hosts are discoverable or have the capability to
interrogation protocols where link information may be exposed. cooperate with interrogation protocols where link information may
be exposed.
The refined definition of Route metrics begins in the sections that The refined definition of Route metrics begins in the sections that
follow. follow.
2. Scope 2. Scope
The purpose of this memo is to add new route metrics and methods of The purpose of this memo is to add new route metrics and methods of
measurement to the existing set of IPPM metrics. measurement to the existing set of IPPM metrics.
The scope is to define route metrics that can identify the path taken The scope is to define route metrics that can identify the path taken
skipping to change at page 5, line 21 skipping to change at page 5, line 21
Path (ECMP) and Unequal Cost Multi-Path (UCMP) technologies). Path (ECMP) and Unequal Cost Multi-Path (UCMP) technologies).
There are several simple non-goals of this memo. There is no attempt There are several simple non-goals of this memo. There is no attempt
to assess the reverse path from any host on the path to the host to assess the reverse path from any host on the path to the host
attempting the path measurement. The reverse path contribution to attempting the path measurement. The reverse path contribution to
delay will be that experienced by ICMP packets (in active methods), delay will be that experienced by ICMP packets (in active methods),
and may be different from delays experienced by UDP or TCP packets. and may be different from delays experienced by UDP or TCP packets.
Also, the round trip delay will include an unknown contribution of Also, the round trip delay will include an unknown contribution of
processing time at the host that generates the ICMP response. processing time at the host that generates the ICMP response.
Therefore, the ICMP-based active methods are not supposed to yield Therefore, the ICMP-based active methods are not supposed to yield
accurate, reproducible estimations of the round-trip delay that UDP accurate, reproducible estimations of the Round-Trip Delay that UDP
or TCP packets will experience. or TCP packets will experience.
3. Route Metric Terms and Definitions 3. Route Metric Terms and Definitions
This section sets requirements for the following components to This section sets requirements for the following components to
support the Route Metric: support the Route Metric:
Host A Host as defined in [RFC2330] (a computer capable of IP Host A Host as defined in [RFC2330] (a computer capable of IP
communication, includes routers), a.k.a. RFC 2330 Host. communication, includes routers), a.k.a. RFC 2330 Host.
Node A Node is any network function on the path capable of IP-layer Node A Node is any network function on the path capable of IP-layer
Communication, includes RFC 2330 Hosts. Communication, includes RFC 2330 Hosts.
Node Identity The unique address for Nodess communicating within the Node Identity The unique address for Nodes communicating within the
network domain. For Nodes communicating on the Internet with IP, network domain. For Nodes communicating on the Internet with IP,
it is the globally routable IP address(es) which the Node uses it is the globally routable IP address(es) which the Node uses
when communicating with other Nodes under normal or error when communicating with other Nodes under normal or error
conditions. The Node Identity revealed (and its connection to a conditions. The Node Identity revealed (and its connection to a
Node Name through reverse DNS) determines whether interfaces to Node Name through reverse DNS) determines whether interfaces to
parallel links can be associated with a single Node, or appear to parallel links can be associated with a single Node, or appear to
identify unique Nodes. identify unique Nodes.
Discoverable Node Nodes that convey their Node Identity according to Discoverable Node Nodes that convey their Node Identity according to
the requirements of their network domain, such as when error the requirements of their network domain, such as when error
skipping to change at page 6, line 45 skipping to change at page 6, line 45
o i, the limit on the number of Hops a specific packet may visit as o i, the limit on the number of Hops a specific packet may visit as
it traverses from the Node at Src to the Node at Dst (such as the it traverses from the Node at Src to the Node at Dst (such as the
TTL or Hop Limit). TTL or Hop Limit).
o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops). o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops).
o T0, a time (start of measurement interval) o T0, a time (start of measurement interval)
o Tf, a time (end of measurement interval) o Tf, a time (end of measurement interval)
o MP(address), Measurement Point at address, such as Src or Dst,
usually at the same node stack layer as "address".
o T, the Node time of a packet as measured at MP(Src), meaning o T, the Node time of a packet as measured at MP(Src), meaning
Measurement Point at the Source. Measurement Point at the Source.
o Ta, the Node time of a reply packet's *arrival* as measured at o Ta, the Node time of a reply packet's *arrival* as measured at
MP(Src), assigned to packets that arrive within a "reasonable" MP(Src), assigned to packets that arrive within a "reasonable"
time (see parameter below). time (see parameter below).
o Tmax, a maximum waiting time for reply packets to return to the o Tmax, a maximum waiting time for reply packets to return to the
source, set sufficiently long to disambiguate packets with long source, set sufficiently long to disambiguate packets with long
delays from packets that are discarded (lost), such that the delays from packets that are discarded (lost), such that the
distribution of round-trip delay is not truncated. distribution of Round-Trip Delay is not truncated.
o F, the number of different flows simulated by the method and o F, the number of different flows simulated by the method and
variant. variant.
o flow, the stream of packets with the same n-tuple of designated o flow, the stream of packets with the same n-tuple of designated
header fields that (when held constant) result in identical header fields that (when held constant) result in identical
treatment in a multi-path decision (such as the decision taken in treatment in a multi-path decision (such as the decision taken in
load balancing). Note: The IPv6 flow label MAY be included in the load balancing). Note: The IPv6 flow label MAY be included in the
flow definition when routers have complied with [RFC6438] flow definition if the MP(Src) is a Tunnel End Point (TEP)
guidelines at the Tunnel End Points (TEP), and the source of the complying with [RFC6438] guidelines.
measurement is a TEP.
o Type-P, the complete description of the packets for which this o Type-P, the complete description of the packets for which this
assessment applies (including the flow-defining fields). assessment applies (including the flow-defining fields).
3.3. Metric Definitions 3.3. Metric Definitions
This section defines the REQUIRED measurement components of the Route This section defines the REQUIRED measurement components of the Route
metrics (unless otherwise indicated): metrics (unless otherwise indicated):
M, the total number of packets sent between T0 and Tf. M, the total number of packets sent between T0 and Tf.
skipping to change at page 7, line 49 skipping to change at page 8, line 4
interval. interval.
A Hop, designated h(i,j), the IP address and/or identity of one of j A Hop, designated h(i,j), the IP address and/or identity of one of j
Discoverable Nodes (or Cooperating Nodes) that are i hops away from Discoverable Nodes (or Cooperating Nodes) that are i hops away from
the Node with address = Src during the measurement interval, T0 to the Node with address = Src during the measurement interval, T0 to
Tf. As defined above, a Hop singleton measurement MUST contain a Tf. As defined above, a Hop singleton measurement MUST contain a
Node Identity, hid(i,j), and MAY contain one or more of the following Node Identity, hid(i,j), and MAY contain one or more of the following
attributes: attributes:
o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported) o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported)
o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported) o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported)
o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the
hop, or approximated from the sending time of the packet that Hop, or approximated from the sending time of the packet that
revealed the hop) revealed the Hop)
o Measurements of Round Trip Delay (for each packet that reveals the o Measurements of Round-Trip Delay (for each packet that reveals the
same Node Identity and attributes, but not timestamp of course, same Node Identity and flow attributes, but not timestamp of
see next section) course, see next section)
Now that Node Identities and related information can be positioned Node Identities and related information can be ordered by their
according to their distance from the Node with address Src in hops, distance from the Node with address Src in Hops h(i,j). Based on
we introduce two forms of Routes: this, two forms of Routes are distinguished:
A Route Ensemble is defined as the combination of all routes A Route Ensemble is defined as the combination of all routes
traversed by different flows from the Node at Src address to the Node traversed by different flows from the Node at Src address to the Node
at Dst address. The route traversed by each flow (with addresses Src at Dst address. A single Route traversed by a single flow
and Dst, and other fields which constitute flow criteria) is a member (determined by an unambiguous tuple of addresses Src and Dst, and
of the ensemble and called a Member Route. other identical flow criteria) is a member of the Route Ensemble and
called a Member Route.
Using h(i,j) and components and parameters, further define: Using h(i,j) and components and parameters, further define:
When considering the set of Hops in the context of a single flow, a When considering the set of Hops in the context of a single flow, a
Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1, Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1,
j) and h(i, j) are by 1 hop away from each other and Nj satisfying j) and h(i, j) are by 1 hop away from each other and Nj satisfying
h(Nj,j)=Dst is the minimum count of hops needed by the packet on h(Nj,j)=Dst is the minimum count of Hops needed by the packet on
Member Route j to reach Dst. Member Routes must be unique. The Member Route j to reach Dst. Member Routes must be unique. The
uniqueness property requires that any two Member routes j and k that uniqueness property requires that any two Member routes j and k that
are part of the same Route Ensemble differ either in terms of minimum are part of the same Route Ensemble differ either in terms of minimum
hop count Nj and Nk to reach the destination Dst, or, in the case of hop count Nj and Nk to reach the destination Dst, or, in the case of
identical hop count Nj=Nk, they have at least one distinct hop: identical hop count Nj=Nk, they have at least one distinct Hop:
h(i,j) != h(i, k) for at least one i (i=1..Nj). h(i,j) != h(i, k) for at least one i (i=1..Nj).
All the optional information collected to describe a Member Route, All the optional information collected to describe a Member Route,
such as the arrival interface, departure interface, and Round Trip such as the arrival interface, departure interface, and Round Trip
Delay at each Hop, turs each list item into a rich structure. There Delay at each Hop, turns each list item into a rich structure. There
may be information on the links between Hops, possibly information on may be information on the links between Hops, possibly information on
the routing (arrival int. to departure int.), an estimate of distance the routing (arrival interface and departure interface), an estimate
between Hops based on Round Trip Delay measurements and calculations, of distance between Hops based on Round-Trip Delay measurements and
and a time stamp indicating when all the additional detail was valid. calculations, and a time stamp indicating when all these additional
details were valid.
The Route Ensemble from Src to Dst, during the measurement interval The Route Ensemble from Src to Dst, during the measurement interval
T0 to Tf, is the aggregate of all m distinct Member Routes discovered T0 to Tf, is the aggregate of all m distinct Member Routes discovered
between the two Nodes with Src and Dst addresses. More formally, between the two Nodes with Src and Dst addresses. More formally,
with the Node having address Src omitted: with the Node having address Src omitted:
Route Ensemble = { Route Ensemble = {
{h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst}, {h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst},
{h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst}, {h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst},
... ...
skipping to change at page 9, line 22 skipping to change at page 9, line 22
where the following conditions apply: i <= Nj <= Nmax (j=1..m) where the following conditions apply: i <= Nj <= Nmax (j=1..m)
Note that some h(i,j) may be empty (null) in the case that systems do Note that some h(i,j) may be empty (null) in the case that systems do
not reply (not discoverable, or not cooperating). not reply (not discoverable, or not cooperating).
h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop
away from each other. away from each other.
Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which
means there may be portions shared among different Member Routes means there may be portions shared among different Member Routes
(parts of various routes may overlap). (parts of Member Routes may overlap).
3.4. Related Round-Trip Delay and Loss Definitions 3.4. Related Round-Trip Delay and Loss Definitions
RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-trip RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-Trip
Delay between the Node with address = Src and the Node at Hop h(i,j) Delay between the Node with address = Src and the Node at Hop h(i,j)
at time T. at time T.
RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss
between the Node with address = Src and the Node at Hop h(i,j) at between the Node with address = Src and the Node at Hop h(i,j) at
time T. time T.
3.5. Discussion 3.5. Discussion
Depending on the way that Node Identity is revealed, it may be Depending on the way that Node Identity is revealed, it may be
skipping to change at page 10, line 4 skipping to change at page 9, line 51
o If a pair of discovered Nodes identify two different addresses, o If a pair of discovered Nodes identify two different addresses,
then they will appear to be different Nodes. then they will appear to be different Nodes.
o If a pair of discovered Nodes identify two different IP addresses, o If a pair of discovered Nodes identify two different IP addresses,
and the IP addresses resolve to the same Node name (in the DNS), and the IP addresses resolve to the same Node name (in the DNS),
then they will appear to be the same Nodes. then they will appear to be the same Nodes.
o If a discovered Node always replies using the same network o If a discovered Node always replies using the same network
address, regardless of the interface a packet arrives on, then address, regardless of the interface a packet arrives on, then
multiple parallel links cannot be detected in that network domain. multiple parallel links cannot be detected in that network domain.
This condition may apply to traceroute-style methods, but may not This condition may apply to traceroute-style methods, but may not
apply to other hybrid methods based on IOAM. apply to other hybrid methods based on In-situ Operations,
Administration, and Maintenance (IOAM).
o If parallel links between routers are aggregated below the IP o If parallel links between routers are aggregated below the IP
layer, In other words, all links share the same pair of IP layer, then from Node point of view, all these links share the
addresses, then the existence of these parallel links can't be same pair of IP addresses. The existence of these parallel links
detected at IP layer. This applies to other network domains with can't be detected at IP layer. This applies to other network
layers below them, as well. domains with layers below them, as well. This condition may apply
to traceroute-style methods, but may not apply to other hybrid
@@@@ This paragraph on Temporal Composition moved to support a more methods based on IOAM.
complete section on Methodology (section 4).
When a route assessment employs IP packets (for example), the reality When a route assessment employs IP packets (for example), the reality
of flow assignment to parallel subpaths involves layers above IP. of flow assignment to parallel subpaths involves layers above IP.
Thus, the measured Route Ensemble is applicable to IP and higher Thus, the measured Route Ensemble is applicable to IP and higher
layers (as described in the methodology's packet of Type-P and flow layers (as described in the methodology's packet of Type-P and flow
parameters). parameters).
@@@@ The Temporal Measurement and Route Class C (unrelated to address
classes of the past) is now partly addressed in Section 4.
3.6. Reporting the Metric 3.6. Reporting the Metric
@@@@ now partly addressed, based on feedback at IETF-101:
An Information Model and an XML Data Model for Storing Traceroute An Information Model and an XML Data Model for Storing Traceroute
Measurements is available in [RFC5388]. The measured information at Measurements is available in [RFC5388]. The measured information at
each hop includes four pieces of information: a one-dimensional hop each hop includes four pieces of information: a one-dimensional hop
index, Node symbolic address, Node IP address, and RTD for each index, Node symbolic address, Node IP address, and RTD for each
response. response.
The description of Hop information that may be collected according to The description of Hop information that may be collected according to
this memo covers more dimensions, as defined in Section 3.3 above. this memo covers more dimensions, as defined in Section 3.3 above.
For example, the Hop index is two-dimensional to capture the For example, the Hop index is two-dimensional to capture the
complexity of a Route Ensemble, and it contains corresponding Node complexity of a Route Ensemble, and it contains corresponding Node
identities at a minimum. The models need to be expanded to include identities at a minimum. The models need to be expanded to include
these features, as well as Arrival Interface ID, Departure Interface these features, as well as Arrival Interface ID, Departure Interface
ID, and Arrival Timestamp, when available. ID, and Arrival Timestamp, when available. The original sending
Timestamp from the Src Node anchors a particular measurement in time.
@@@@ can we leave updates to RFC 5388 for further work? Or, do we
need to take-on this topic in an Appendix here? IETF-105 feedback
indicates that we should collect requirements here, and punt future
work to a YANG model.
4. Route Assessment Methodologies 4. Route Assessment Methodologies
There are two classes of methods described in this section, active There are two classes of methods described in this section, active
methods relying on the reaction to TTL or Hop Limit Exceeded methods relying on the reaction to TTL or Hop Limit Exceeded
condition to discover Nodes on a path, and Hybrid active-passive condition to discover Nodes on a path, and Hybrid active-passive
methods that involve direct interrogation of cooperating Nodes methods that involve direct interrogation of cooperating Nodes
(usually within a single domain). Description of these methods (usually within a single domain). Description of these methods
follow. follow.
@@@@ Editor's Note: We need to incorporate description of Type-P
packets (with the flow parameters) used in each method below (done
for Active).
4.1. Active Methodologies 4.1. Active Methodologies
We have chosen to describe the method based on that employed in This section describes the method employed by current open source
current open source tools, thereby providing a practical framework tools, thereby providing a practical framework for further advanced
for further advanced techniques to be included as method variants. techniques to be included as method variants. This method is
This method is applicable to use across multiple administrative applicable for use across multiple administrative domains.
domains.
Paris-traceroute [PT] provides some measure of protection from path Paris-traceroute [PT] provides some measure of protection from path
variation generated by ECMP load balancing, and it ensures traceroute variation generated by ECMP load balancing, and it ensures traceroute
packets will follow the same path in 98% of cases according to packets will follow the same path in 98% of cases according to
[SCAMPER]. If it is necessary to find every path possible between [SCAMPER]. If it is necessary to find every usable path between two
two Nodes, Paris-traceroute provides "exhaustive" mode while scamper Nodes, Paris-traceroute provides "exhaustive" mode while scamper
provides "tracelb" (stands for traceroute load balance). provides "tracelb" (stands for traceroute load balance).
The Type-P of packets used could be ICMP (as in the original The Type-P of packets used could be ICMP (as in the original
traceroute), UDP or TCP. The later are used when a particular traceroute), UDP or TCP. The latter are used when a particular
characteristic needs to be to verified, such as filtering or traffic characteristic needs to be to verified, such as filtering or traffic
shaping on specific ports (i.e., services). [SCAMPER] supports IPv6 shaping on specific ports (i.e., services). [SCAMPER] supports IPv6
traceroute measurements, keeping the FlowLable constant in all traceroute measurements, keeping the FlowLabel constant in all
packets. packets.
The advanced route assessment methods used in Paris-traceroute [PT] The advanced route assessment methods used in Paris-traceroute [PT]
keep the critical fields constant for every packet to maintain the keep the critical fields constant for every packet to maintain the
appearance of the same flow. Since route assessment can be conducted appearance of the same flow. Since route assessment can be conducted
using TCP, UDP or ICMP packets, this method REQUIRES the Diffserv using TCP, UDP or ICMP packets, this method REQUIRES the Diffserv
field, the protocol number, IP source and destination addresses, and field, the protocol number, IP source and destination addresses, and
the port settings for TCP or UDP kept constant. For ICMP probes, the the port settings for TCP or UDP to be kept constant. For ICMP
method additionally REQUIRES keeping the type, code, and ICMP probes, the method additionally REQUIRES keeping the type, code, and
checksum constant; which occupy the corresponding positions in the ICMP checksum constant (the latter occupy the corresponding positions
header of an IP packet, e.g., bytes 20 to 23 when the header IP has in the header of an IP packet, e.g., bytes 20 to 23 when the header
no options. IP has no options).
Maintaining a constant checksum in ICMP is most challenging because Maintaining a constant checksum in ICMP is most challenging because
the ICMP Sequence Number is part of the calculation. The advanced the ICMP Sequence Number is part of the calculation. The advanced
traceroute method requires calculations using the IP Sequence Number traceroute method requires calculations using the IP Sequence Number
Field and the Identifier Field, yielding a constant ICMP checksum in Field and the Identifier Field, yielding a constant ICMP checksum in
successive packets. For an example of calculations to maintain a successive packets. For an example of calculations to maintain a
constant checksum, see Appendix A of [RFC7820], where revision of a constant checksum, see Appendix A of [RFC7820], where revision of a
timestamp field is complemented by modifying the 2 octet checksum timestamp field is complemented by modifying the 2 octet checksum
complement field (these fields take the roles of the ICMP Sequence complement field (these fields take the roles of the ICMP Sequence
Number and Identifier Fields, respectively). Number and Identifier Fields, respectively).
For TCP and UDP packets, the checksum must also be kept constant. For TCP and UDP packets, the checksum must also be kept constant.
Therefore, the first four bytes of UDP (or TCP) data field are Therefore, the first four bytes of UDP (or TCP) data field are
modified to compensate for fields that change from packet to packet. modified to compensate for fields that change from packet to packet.
@@@@ Note: other variants of advanced traceroute are planned be
described.
Finally, the return path is also important to check. Taking into Finally, the return path is also important to check. Taking into
account that it is an ICMP time exceeded (during transit) packet, the account that it is an ICMP time exceeded (during transit) packet, the
source and destination IP are constant for every reply. Then, we source and destination IP are constant for every reply. Then, we
should consider the fields in the first 32 bits of the protocol on should consider the fields in the first 32 bits of the protocol on
the top of IP: the type and code of ICMP packet, and its checksum. the top of IP: the type and code of ICMP packet, and its checksum.
Again, to maintain the ICMP checksum constant for the returning Again, to keep the ICMP checksum constant for the returning packets,
packets, we need to consider the whole ICMP message. It contains the we need to consider the whole ICMP message. It contains the IP
IP header of the discarded packet plus the first 8 bytes of the IP header of the discarded packet plus the first 8 bytes of the IP
payload; that is some of the fields of TCP header, the UDP header payload; that is some of the fields of the TCP header, the UDP header
plus four data bytes, the ICMP header plus four bytes. Therefore, plus four data bytes, the ICMP header plus four bytes. Therefore,
for UDP case the data field is used to maintain the ICMP checksum for the UDP case the data field is used to maintain the ICMP checksum
constant in the returning packet. For the ICMP case, the identifier constant in the returning packet. For the ICMP case, the identifier
and sequence fields of the sent ICMP probe are manipulated to be and sequence fields of the sent ICMP probe are manipulated to be
constant. The TCP case presents no problem because its first eight constant. The TCP case presents no problem because its first eight
bytes will be the same for every packet probe. bytes will be the same for every packet probe.
Formally, to maintain the same flow in the measurements to a certain Formally, to maintain the same flow in the measurements to a certain
hop, the Type-P-Route-Ensemble-Method-Variant packets should be[PT]: hop, the Type-P-Route-Ensemble-Method-Variant packets should be[PT]:
o TCP case: Fields Src, Dst, port-Src, port_Dst, and Diffserv Field o TCP case: Fields Src, Dst, port-Src, port_Dst, and Diffserv Field
should be the same. should be the same.
o UDP case: Fields Src, Dst, port-Src, port-Dst, and Diffserv Field o UDP case: Fields Src, Dst, port-Src, port-Dst, and Diffserv Field
should be the same, the UDP-checksum should change to maintain should be the same, the UDP-checksum should change to keep the IP
constant the IP checksum of the ICMP time exceeded reply. Then, checksum of the ICMP time exceeded reply constant. Then, the data
the data length should be fixed, and the data field is used to length should be fixed, and the data field is used to fixing it
fixing it (consider that ICMP checksum uses its data field, which (consider that ICMP checksum uses its data field, which contains
contains the original IP header plus 8 bytes of UDP, where TTL, IP the original IP header plus 8 bytes of UDP, where TTL or Hop
identification, IP checksum, and UDP checksum changes). Limit, IP identification, IP checksum, and UDP checksum changes).
o ICMP case: The Data field should compensate variations on TTL, IP o ICMP case: The Data field should compensate variations on TTL or
identification, and IP checksum for every packet. Hop Limit, IP identification, and IP checksum for every packet.
Then, the way to identify different hops and attempts of the same Then, the way to identify different hops and attempts of the same
flow is: flow is:
o TCP case: The IP identification field. o TCP case: The IP identification field.
o UDP case: The IP identification field. o UDP case: The IP identification field.
o ICMP case: The IP identification field, and ICMP Sequence number. o ICMP case: The IP identification field, and ICMP Sequence number.
skipping to change at page 14, line 16 skipping to change at page 13, line 43
stable results over time, particularly ingress and egress stable results over time, particularly ingress and egress
portions of the path. portions of the path.
2. SHOULD continue testing portions of the path that have previously 2. SHOULD continue testing portions of the path that have previously
exhibited ECMP load balancing. exhibited ECMP load balancing.
3. SHALL trigger re-assessment of the complete path and Route 3. SHALL trigger re-assessment of the complete path and Route
Ensemble, if any change in hops is observed for a specific (and Ensemble, if any change in hops is observed for a specific (and
previously tested) flow. previously tested) flow.
@@@@ Comments on this material are very welcome!
4.1.2. Routing Class C Identification 4.1.2. Routing Class C Identification
There is an opportunity to apply the [RFC2330] notion of equal There is an opportunity to apply the [RFC2330] notion of equal
treatment for a class of packets, "...very useful to know if a given treatment for a class of packets, "...very useful to know if a given
Internet component treats equally a class C of different types of Internet component treats equally a class C of different types of
packets", as it applies to Route measurements. Knowledge of "class packets", as it applies to Route measurements. Knowledge of "class
C" parameters (unrelated to address classes of the past) on a path C" parameters (unrelated to address classes of the past) on a path
potentially reduces the number of flows required for a given method potentially reduces the number of flows required for a given method
to assess a Route Ensemble over time. to assess a Route Ensemble over time.
skipping to change at page 15, line 13 skipping to change at page 14, line 39
publish information about these hash functions, examples are here publish information about these hash functions, examples are here
https://www.researchgate.net/ https://www.researchgate.net/
publication/281571413_COMPARISON_OF_HASH_STRATEGIES_FOR_FLOW- publication/281571413_COMPARISON_OF_HASH_STRATEGIES_FOR_FLOW-
BASED_LOAD_BALANCING ). BASED_LOAD_BALANCING ).
o ability to direct the emphasis of current measurements on ECMP o ability to direct the emphasis of current measurements on ECMP
portions of the path, based on recent past measurement results portions of the path, based on recent past measurement results
(the Routing Class C of some portions of the path is essentially (the Routing Class C of some portions of the path is essentially
"all packets"). "all packets").
@@@@ Comments on this material are very welcome! Especially
suggestions for tools that might lend themselves to support these
measurements.
4.1.3. Intermediate Observation Point Route Measurement 4.1.3. Intermediate Observation Point Route Measurement
There are many examples where passive monitoring of a flow at an There are many examples where passive monitoring of a flow at an
Observation Point within the network can detect unexpected Round Trip Observation Point within the network can detect unexpected Round Trip
Delay or Delay Variation. But how can the cause of the anomolous Delay or Delay Variation. But how can the cause of the anomalous
dely be investigated further --from the Observation Point -- possibly delay be investigated further --from the Observation Point --
located at an intermediate point on the path? possibly located at an intermediate point on the path?
In this case, knowledge that the flow of interest belongs to a In this case, knowledge that the flow of interest belongs to a
specific Routing Class C will enable mesurement of the route where specific Routing Class C will enable measurement of the route where
anomolous delay has been observed. Specifically, Round Trip Delay anomalous delay has been observed. Specifically, Round-Trip Delay
assessment to each Hop on the path between the Observation Point and assessment to each Hop on the path between the Observation Point and
the Destination for the flow of interest may discover high or the Destination for the flow of interest may discover high or
variable delay on a specific link and Hop combination. variable delay on a specific link and Hop combination.
The determination of a Routing Class C which includes the flow of The determination of a Routing Class C which includes the flow of
interest is as described in the section above, aided by computation interest is as described in the section above, aided by computation
of the relevant hash function output as the target. of the relevant hash function output as the target.
@@@@ Comments on this new material are very welcome!
4.2. Hybrid Methodologies 4.2. Hybrid Methodologies
The Hybrid Type I methods provide an alternative method for Route The Hybrid Type I methods provide an alternative method for Route
Member assessment. As mentioned in the Scope section, Member assessment. As mentioned in the Scope section,
[I-D.ietf-ippm-ioam-data] provides a possible set of data fields that [I-D.ietf-ippm-ioam-data] provides a possible set of data fields that
would support route identification. would support route identification.
In general, nodes in the measured domain would be equipped with In general, nodes in the measured domain would be equipped with
specific abilities: specific abilities:
o Support of the "Loopback" Flag (L-bit), where a copy of the packet o Support of the "Loopback" Flag (L-bit), where a copy of the packet
is returned to the source, and the packet is processed like any is returned to the encapsulating node, and the packet is processed
other IOAM packet on the return transfer. like any other IOAM packet on the return transfer.
In addition to node identity, nodes may also identify the ingress and In addition to node identity, nodes may also identify the ingress and
egress interfaces utilized by the tracing packet, the time of day egress interfaces utilized by the tracing packet, the time of day
when the packet was processed, and other generic data (as described when the packet was processed, and other generic data (as described
in section 4 of [I-D.ietf-ippm-ioam-data]). in section 4 of [I-D.ietf-ippm-ioam-data]). Interface identification
isn't necessarily limited to IP, i.e. different links in a bundle
(LACP) could be identified. Equally well, links without explicit IP
addresses can be identified (like with unnumbered interfaces in an
IGP deployment).
Note that Type-P packet specification for this method will likely be
a partial specification, because most of the packet fields are
determined by the user traffic. The packet header(s) added by the
Hybrid method can certainly be specified in Type-P.
4.3. Combining Different Methods 4.3. Combining Different Methods
In principle, there are advantages if the entity conducting Route In principle, there are advantages if the entity conducting Route
measurements can utilize both forms of advanced methods (active and measurements can utilize both forms of advanced methods (active and
hybrid), and combine the results. For example, if there are Nodes hybrid), and combine the results. For example, if there are Nodes
involved in the path that qualify as Cooperating Nodes, but not as involved in the path that qualify as Cooperating Nodes, but not as
Discoverable Nodes, then a more complete view of hops on the path is Discoverable Nodes, then a more complete view of Hops on the path is
possible when a hybrid method (or interrogation protocol) is applied possible when a hybrid method (or interrogation protocol) is applied
and the results are combined with the active method results collected and the results are combined with the active method results collected
across all other domains. across all other domains.
In order to combine the results of active and hybrid/interrogation In order to combine the results of active and hybrid/interrogation
methods, the network Nodes that are part of a domain supporting an methods, the network Nodes that are part of a domain supporting an
interrogation protocol have the following attributes: interrogation protocol have the following attributes:
1. Nodes at the ingress to the domain SHOULD be both Discoverable 1. Nodes at the ingress to the domain SHOULD be both Discoverable
and Cooperating, and SHOULD reveal the same Node Identity in and Cooperating, and SHOULD reveal the same Node Identity in
skipping to change at page 17, line 19 skipping to change at page 16, line 48
3. Congestion 3. Congestion
4. Inter-domain paths 4. Inter-domain paths
This categorization is widely accepted in the literature and among This categorization is widely accepted in the literature and among
operators alike, and it can be trusted with empirical data and operators alike, and it can be trusted with empirical data and
several sources as ground of truth (e.g., [RTTSub] ) but it is an several sources as ground of truth (e.g., [RTTSub] ) but it is an
inference measurement nonetheless [bdrmap][IDCong]. inference measurement nonetheless [bdrmap][IDCong].
The first two categories correspond to the physical distance The first two categories correspond to the physical distance
dependency on Round Trip Delay (RTD) while the last one binds RTD dependency on Round-Trip Delay (RTD) while the last one binds RTD
with queueing delay on routers. Due to the significant contribution with queueing delay on routers. Due to the significant contribution
of propagation delay in long distance hops, RTD will be on the order of propagation delay in long distance hops, RTD will be on the order
of 100ms on transatlantic hops, depending on the geolocation of the of 100ms on transatlantic hops, depending on the geolocation of the
vantage points. Moreover, RTD is typically greater than 480ms when vantage points. Moreover, RTD is typically greater than 480ms when
two hops are connected using geostationary satellite technology two hops are connected using geostationary satellite technology
(i.e., their orbit is at 36000km). Detecting congestion with latency (i.e., their orbit is at 36000km). Detecting congestion with latency
implies deeper mathematical understanding since network traffic load implies deeper mathematical understanding since network traffic load
is not stationary. Nonetheless, as the first approach, a link seems is not stationary. Nonetheless, as the first approach, a link seems
to be congested if after sending several traceroute probes, it is to be congested if after sending several traceroute probes, it is
possible to detect congestion observing different statistics possible to detect congestion observing different statistics
parameters (e.g., see [IDCong]). parameters (e.g., see [IDCong]).
6. Tools to Measure Delays in the Internet 6. Tools to Measure Delays in the Internet
Internet routing is complex because it depends on the policies of Internet routing is complex because it depends on the policies of
thousands Autonomous Systems (AS). While most of the routers perform thousands Autonomous Systems (AS). While most of the routers perform
load balancing on flows using Equal Cost Multiple Path (ECMP), a few load balancing on flows using Equal Cost Multiple Path (ECMP), a few
still divide the workload through packet-based techniques. The still divide the workload through packet-based techniques. The
former scenario is defined according to [RFC2991] while the latter former scenario is defined according to [RFC2991] while the latter
generates a round-robin scheme to deliver every new outgoing packet. generates a round-robin scheme to deliver every new outgoing packet.
ECMP keeps flow state in the router to ensure every packet of a flow ECMP uses a hashing function to ensure that every packet of a flow is
is delivered by the same path, and this avoids increasing the packet delivered by the same path, and this avoids increasing the packet
delay variation and possibly producing overwhelming packet reordering delay variation and possibly producing overwhelming packet reordering
in TCP flows. in TCP flows.
Taking into account that Internet protocol was designed under the Taking into account that Internet protocol was designed under the
"end-to-end" principle, the IP payload and its header do not provide "end-to-end" principle, the IP payload and its header do not provide
any information about the routes or path necessary to reach some any information about the routes or path necessary to reach some
destination. For this reason, the well-known tool traceroute was destination. For this reason, the well-known tool traceroute was
developed to gather the IP addresses of each hop along a path using developed to gather the IP addresses of each hop along a path using
the ICMP protocol [RFC0792]. Besides, traceroute adds the measured the ICMP protocol [RFC0792]. Besides, traceroute adds the measured
RTD from each hop. However, the growing complexity of the Internet RTD from each hop. However, the growing complexity of the Internet
makes it more challenging to develop accurate traceroute makes it more challenging to develop an accurate traceroute
implementation. For instance, the early traceroute tools would be implementation. For instance, the early traceroute tools would be
inaccurate in the current network, mainly because they were not inaccurate in the current network, mainly because they were not
designed to retain flow state. However, evolved traceroute tools, designed to retain flow state. However, evolved traceroute tools,
such as Paris-traceroute [PT] [MLB] and Scamper [SCAMPER], expect to such as Paris-traceroute [PT] [MLB] and Scamper [SCAMPER], expect to
encounter ECMP and achieve more accurate results when they do. encounter ECMP and achieve more accurate results when they do.
Paris-traceroute-like tools operate in the following way: every Paris-traceroute-like tools operate in the following way: every
packet should follow the same path because the sensitive fields of packet should follow the same path because the sensitive fields of
the header are controlled to appear as the same flow. This means the header are controlled to appear as the same flow. This means
that source and destination IP addresses, source and destination port that source and destination IP addresses, source and destination port
numbers are the same in every packet. Additionally, Differentiated numbers are the same in every packet. Additionally, Differentiated
Services Code Point (DSCP), checksum and ICMP code should remain Services Code Point (DSCP), checksum and ICMP code should remain
constant since they may affect the path selection. constant since they may affect the path selection.
Today's traceroute tools can send either UDP, TCP or ICMP packet Today's traceroute tools can send either UDP, TCP or ICMP packet
probes. Since ICMP header does not include transport layer probes. Since ICMP header does not include transport layer
information, there are no fields for source and destination port information, there are no fields for source and destination port
numbers. For this reason, these tools keep constant ICMP type, code, numbers. For this reason, these tools keep constant ICMP type, code,
and checksum fields to generate a kind of flow. However, the and checksum fields to generate a kind of flow. However, the
checksum may vary in every packet, therefore when probes use ICMP checksum may vary in every packet, therefore when probes use ICMP
packets, ICMP Identifier and Sequence Number are manipulated to packets, ICMP Identifier and sequence number are manipulated to
maintain constant checksum in every packet. On the other hand, when maintain constant checksum in every packet. On the other hand, when
UDP probes are generated, the expected variation in the checksum of UDP probes are generated, the expected variation in the checksum of
each packet is again compensated by manipulating the payload. each packet is again compensated by manipulating the payload.
Paris-traceroute allows its users to measure RTD in every hop of the Paris-traceroute allows its users to measure RTD in every hop of the
path for a particular flow. Furthermore, either Paris-traceroute or path for a particular flow. Furthermore, either Paris-traceroute or
Scamper is capable of unveiling the many available paths between a Scamper is capable of unveiling the many available paths between a
source and destination (which are visible to this method). This task source and destination (which are visible to this method). This task
is accomplished by repeating complete traceroute measurements with is accomplished by repeating complete traceroute measurements with
different flow parameters for each measurement. The Framework for IP different flow parameters for each measurement. The Framework for IP
Performance Metrics (IPPM) ([RFC2330] updated by[RFC7312]) has the Performance Metrics (IPPM) ([RFC2330] updated by[RFC7312]) has the
flexibility to require that the round-trip delay measurement flexibility to require that the Round-Trip Delay measurement
[RFC2681] uses packets with the constraints to assure that all [RFC2681] uses packets with the constraints to assure that all
packets in a single measurement appear as the same flow. This packets in a single measurement appear as the same flow. This
flexibility covers ICMP, UDP, and TCP. The accompanying methodology flexibility covers ICMP, UDP, and TCP. The accompanying methodology
of [RFC2681] needs to be expanded to report the sequential hop of [RFC2681] needs to be expanded to report the sequential hop
identifiers along with RTD measurements, but no new metric definition identifiers along with RTD measurements, but no new metric definition
is needed. is needed.
7. RTD Measurements Statistics 7. RTD Measurements Statistics
Several articles have shown that network traffic presents a self- Several articles have shown that network traffic presents a self-
skipping to change at page 19, line 23 skipping to change at page 19, line 5
values: minimum RTD (m), RTD value of the 25% of the Empirical values: minimum RTD (m), RTD value of the 25% of the Empirical
Cumulative Distribution Function (ECDF) (Q1), the median value (Q2), Cumulative Distribution Function (ECDF) (Q1), the median value (Q2),
the RTD value of the 75% of the ECDF (Q3) and the maximum RTD (M). the RTD value of the 75% of the ECDF (Q3) and the maximum RTD (M).
Congestion can be inferred when RTD measurements are spread apart, Congestion can be inferred when RTD measurements are spread apart,
and consequently, the Inter-Quartile Range (IQR), the distance and consequently, the Inter-Quartile Range (IQR), the distance
between Q3 and Q1, increases its value. between Q3 and Q1, increases its value.
This procedure requires to compute quartile values "on the fly" using This procedure requires to compute quartile values "on the fly" using
the algorithm presented in [P2]. the algorithm presented in [P2].
This procedure allow us to update the quartiles value whenever a new This procedure allows us to update the quartiles value whenever a new
measurement arrives, which is radically different from classic measurement arrives, which is radically different from classic
methods of computing quartiles because they need to use the whole methods of computing quartiles because they need to use the whole
dataset to compute the values. This way of calculus provides savings dataset to compute the values. This way of calculus provides savings
in memory and computing time. in memory and computing time.
To sum up, the proposed measurement procedure consists in performing To sum up, the proposed measurement procedure consists in performing
traceroutes several times to obtain samples of the RTD in every hop traceroutes several times to obtain samples of the RTD in every hop
from a path, during a time window (W) and compute the quantiles for from a path, during a time window (W) and compute the quantiles for
every hop. This could be done for a single path flow or for every every hop. This could be done for a single Member Route flow or for
detected path flow. every detected Route Ensemble flow.
Even though a particular hop may be understood as the amount of hops Even though a particular hop may be understood as the amount of hops
away from the source, a more detailed classification could be used. away from the source, a more detailed classification could be used.
For example, a possible classification may be identify ICMP Time For example, a possible classification may be identify ICMP Time
Exceeded packets coming from the same routers to those who have the Exceeded packets coming from the same routers to those who have the
same hop distance, IP address of the router which is replying and TTL same hop distance, IP address of the router which is replying and TTL
value of the received ICMP packet. or Hop Limit value of the received ICMP packet.
Thus, the proposed methodology is based on this algorithm: Thus, the proposed methodology is based on this algorithm:
================================================================ ================================================================
1 input: W (window time of the measurement) 1 input: W (window time of the measurement)
2 i_t (time between two measurements) 2 i_t (time between two measurements)
3 E (True: exhaustive, False: a single path) 3 E (True: exhaustive, False: a single path)
4 Dst (destination IP address) 4 Dst (destination IP address)
5 output: Qs (quartiles for every hop and alt in the path(s) to Dst) 5 output: Qs (quartiles for every hop and alt in the path(s) to Dst)
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 20, line 49 skipping to change at page 20, line 23
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live paths are relevant here as well. See [RFC4656] and [RFC5357]. live paths are relevant here as well. See [RFC4656] and [RFC5357].
The active measurement process of "changing several fields to keep The active measurement process of "changing several fields to keep
the checksum of different packets identical" does not require special the checksum of different packets identical" does not require special
security considerations because it is part of synthetic traffic security considerations because it is part of synthetic traffic
generation, and is designed to have minimal to zero impact on network generation, and is designed to have minimal to zero impact on network
processing (to process the packets for ECMP). processing (to process the packets for ECMP).
@@@@ add reference to security considerations from For applicable Hybrid methods, the security considerations
[I-D.ietf-ippm-ioam-data]. in[I-D.ietf-ippm-ioam-data] apply.
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
potential observers is greatly reduced when using active techniques potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework [RFC7594], Measurement of Broadband Performance (LMAP) Framework [RFC7594],
which covers active and passive techniques. which covers active and passive techniques.
skipping to change at page 21, line 26 skipping to change at page 20, line 47
This memo makes no requests of IANA. We thank the good folks at IANA This memo makes no requests of IANA. We thank the good folks at IANA
for having checked this section anyway. for having checked this section anyway.
11. Acknowledgements 11. Acknowledgements
The original 3 authors acknowledge Ruediger Geib, for his penetrating The original 3 authors acknowledge Ruediger Geib, for his penetrating
comments on the initial draft, and his initial text for the comments on the initial draft, and his initial text for the
Appendix on MPLS. Carlos Pignataro challenged the authors to Appendix on MPLS. Carlos Pignataro challenged the authors to
consider a wider scope, and applied his substantial expertise with consider a wider scope, and applied his substantial expertise with
many technologies and their measurement features in his extensive many technologies and their measurement features in his extensive
comments. Frank Brockners also shared useful comments. We thank comments. Frank Brockners also shared useful comments, so did Footer
them all! Foote. We thank them all!
12. Appendix I MPLS Methods for Route Assessment 12. Appendix I MPLS Methods for Route Assessment
A Node assessing an MPLS path must be part of the MPLS domain where A Node assessing an MPLS path must be part of the MPLS domain where
the path is implemented. When this condition is met, RFC 8029 the path is implemented. When this condition is met, RFC 8029
provides a powerful set of mechanisms to detect "correct operation of provides a powerful set of mechanisms to detect "correct operation of
the data plane, as well as a mechanism to verify the data plane the data plane, as well as a mechanism to verify the data plane
against the control plane" [RFC8029]. against the control plane" [RFC8029].
MPLS routing is based on the presence of a Forwarding Equivalence MPLS routing is based on the presence of a Forwarding Equivalence
skipping to change at page 22, line 13 skipping to change at page 21, line 38
support the Downstream Detailed Mapping TLV (was Downstream Mapping support the Downstream Detailed Mapping TLV (was Downstream Mapping
initially, but the latter has been deprecated). The MPLS echo initially, but the latter has been deprecated). The MPLS echo
response includes the incoming interface where a router received the response includes the incoming interface where a router received the
MPLS Echo request. The MPLS Echo reply further informs which of the MPLS Echo request. The MPLS Echo reply further informs which of the
n addresses relevant for the load sharing decision results in a n addresses relevant for the load sharing decision results in a
particular next hop interface and contains the next hop's interface particular next hop interface and contains the next hop's interface
address (if available). This ensures that the next hop will receive address (if available). This ensures that the next hop will receive
a properly coded MPLS Echo request in the next step route of a properly coded MPLS Echo request in the next step route of
assessment. assessment.
RFC to be 8403 (draft-ietf-spring-oam-usecase-10) explains how a [RFC8403] explains how a central Path Monitoring System could be used
central Path Monitoring System could be used to detect arbitrary MPLS to detect arbitrary MPLS paths between any routers within a single
paths between any routers within a single MPLS domain. The MPLS domain. The combination of MPLS forwarding, Segment Routing and
combination of MPLS forwarding, Segment Routing and MPLS traceroute MPLS traceroute offers a simple architecture and a powerful mechanism
offers a simple architecture and a powerful mechanism to detect and to detect and validate (segment routed) MPLS paths.
validate (segment routed) MPLS paths.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- d., and J. Lemon, "Data Fields for In-situ OAM", draft-
data-07 (work in progress), September 2019. ietf-ippm-ioam-data-08 (work in progress), October 2019.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 26, line 16 skipping to change at page 25, line 42
and C. Pignataro, "MPLS Forwarding Compliance and and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <https://www.rfc-editor.org/info/rfc7325>. August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
[RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of [RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of
Cuba: Characterizing Cuba's connectivity", In Proceedings Cuba: Characterizing Cuba's connectivity", In Proceedings
of the 2015 ACM Conference on Internet Measurement of the 2015 ACM Conference on Internet Measurement
Conference, pp. 487-493. ACM, 2015. Conference, pp. 487-493. ACM, 2015.
[SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible [SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible
packet prober for active measurement of the packet prober for active measurement of the
Internet", Proceedings of the 10th ACM SIGCOMM conference Internet", Proceedings of the 10th ACM SIGCOMM conference
on Internet measurement, pp. 239-245. ACM, 2010., 2010. on Internet measurement, pp. 239-245. ACM, 2010., 2010.
[SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic [SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic
and Performance Evaluation (1st ed.)", John Wiley & Sons, and Performance Evaluation (1st ed.)", John Wiley & Sons,
Inc., New York, NY, USA, 2000. Inc., New York, NY, USA, 2000.
Authors' Addresses Authors' Addresses
Jose Ignacio Alvarez-Hamelin J. Ignacio Alvarez-Hamelin
Universidad de Buenos Aires Universidad de Buenos Aires
Av. Paseo Colon 850 Av. Paseo Colon 850
Buenos Aires C1063ACV Buenos Aires C1063ACV
Argentine Argentine
Phone: +54 11 5285-0716 Phone: +54 11 5285-0716
Email: ihameli@cnet.fi.uba.ar Email: ihameli@cnet.fi.uba.ar
URI: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ URI: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
Al Morton Al Morton
 End of changes. 67 change blocks. 
145 lines changed or deleted 137 lines changed or added

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