Internet DRAFT - draft-trammell-ippm-hybrid-ps
draft-trammell-ippm-hybrid-ps
IP Performance Measurement (ippm) B. Trammell
Internet-Draft ETH Zurich
Intended status: Informational L. Zheng
Expires: August 18, 2014 Huawei
S. Silva
LACNIC
M. Bagnulo
UC3M
February 14, 2014
Hybrid Measurement using IPPM Metrics
draft-trammell-ippm-hybrid-ps-01
Abstract
Hybrid measurement is the combination of metrics derived from passive
and active measurement to produce a measurement result. This
document discusses use cases for hybrid measurement using metrics
defined within the IPPM framework, and discusses requirements for the
definition of passive methodologies for selected IPPM metrics.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Trammell, et al. Expires August 18, 2014 [Page 1]
Internet-Draft Hybrid Measurement February 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
Hybrid measurement is the combination of metrics derived from passive
and active measurement to produce a measurement result. This
combination can be either spatial or temporal. For example, one way
delay to a given endpoint could be derived from passive measurements
from a sample of remote endpoints with which traffic is frequently
exchanged, and supplemented with active measurements from endpoints
with less frequent traffic, to build a "delay map" to a certain point
in the network. On the temporal side, loss or delay metrics could be
passively measured and stored over time to provide a baseline against
which actively-measured loss or delay metrics could be compared
during troubleshooting, in order to determine whether a specific path
or path segment is contributing to an observed performance problem.
The IPPM working group has produced a framework [RFC2330] for and
rich set of well-defined metrics (e.g. [RFC2679], [RFC2680]) for IP
performance measurement using active methods, and protocols for
measuring them. These metrics could form the basis of a platform for
hybrid measurement, provided that passively-derived metrics were
defined to compatible with the corresponding actively-derived
metrics; or alternately, provided that methodologies for passive
measurement can be defined for each of the existing active metrics to
be used, such that those methodologies produce values for the metrics
equivalent to the active methodology for the same metric parameters,
given some assumptions about the packet stream to be observed to
perform the passive measurement, and given tolerances for uncertainty
in the results.
2. Problem Statement
Complicating the definition of hybrid measurements is that passive
measurement must make do with the traffic that is observable, while
active measurement has some control over the traffic observed.
Measurements for some set of parameters are not possible if no
suitable traffic is observed, and the timing of the measurement
cannot be controlled. Placement of the observation points for
passive measurement along a path additionally introduces uncertainty
in the results. For example, passive one-way delay measurement could
be performed using two measurement points, one close to each
endpoint, with synchronized clocks, comparing the observation times
of packets via their hashes. This will not produce a value which is
Trammell, et al. Expires August 18, 2014 [Page 2]
Internet-Draft Hybrid Measurement February 2014
directly comparable to a Type-P-One-way-Delay measured as specified
in section 3.6 of [RFC2679], because it will not account for the one-
way-delay from the source to the source-side observation point, or
from the destination-side observation point to the destination. Any
specification of hybrid measurement using IPPM metrics must handle
these complications.
The proposed specification entails:
o Definition of scenarios and requirements for hybrid measurement.
o Selection of existing IPPM metrics to be used for the active side
of hybrid measurements to meet these requirements.
o Definition of equivalent passive measurement methodologies for
each selected metric, specifically addressing the assumptions
about the observed packet stream which must hold for the metric to
be valid, and with a specific allowance for the measurement and/or
estimation of uncertainty due to uncontrollable conditions or
observation point placement.
o Definition of metrics based on these passive methodologies, or
modification of the definition of existing metrics to add passive
methodologies.
o Definition of methods for comparison between active and passive
metrics allowing for estimated uncertainty.
o Definition of methods for spatial and temporal composition of
active and passive metrics together allowing for estimated
uncertainty.
3. Selected IPPM Metrics
[EDITOR'S NOTE: this section will contain information on the metrics
selected for passive measurement, and initial discussion of passive
measurement methodologies for them. Metric definition will
presumably be left for a future document.]
3.1. Packet Loss
In order to perform packet loss measurements on a live traffic flow,
different approaches exist. An approach is to count the number of
packets sent on one end, and the number of packets received on the
other end. Packet loss over a path is the difference between the
number of packets transmitted at the starting interface of the path
and received at the ending interface of this path.
Trammell, et al. Expires August 18, 2014 [Page 3]
Internet-Draft Hybrid Measurement February 2014
3.1.1. Passive Measurement Method
In order to count the number of packets sent and received and to
compare two counters, it is required that the two counters refer
exactly to the same set of packets. One difficulty is it is hard to
determine exactly when to read the counter since a flow is
continuous. A possible solution is to virtually split the flow in
consecutive blocks by periodically inserting a delimiting packet, so
that each counter refers exactly to the same block of packets.
However, delimiting the flow using specific packets requires
generating additional packets within the flow and requires the
equipment to be able to process those packets. In addition, the
method is vulnerable to out of order reception and the loss of
delimiting packets.
An existing method by "coloring" IP packets for performance
measurement is introduced in [I-D.tempia-opsawg-p3m]. This "colored"
based approach doesn't use delimiting packets. Instead, it "colours"
the packets so that the packets belonging to the same block will have
the same "colour", while consecutive blocks will have different
colours. Each change of colour represents a sort of auto-
synchronization signal that guarantees the consistency of
measurements taken by different devices along the path.
3.2. One-way Delay
IPPM has defined a protocol for active one way delay measurement
OWAMP in [RFC4656] It consists of a control protocol for negotiating
measurement sessions and a data plane protocol for test packets.
OWAMP is an active protocol meaning that the one delay is measured
for artificial packets the are generated for this purpose.
It would be natural to pursue passive and/or hybrid approaches for
measuring one way delay. In this case, the goal would be to measure
one way delay for packets that are flowing through the network. This
can be achieved by defining two observation points that will record
the packets they see and the corresponding timestamps. This
information will be used to determine the one way delay of the
observed packets, similarly than in the active measurement approach.
In order to do that, it is necessary to identify which packets are
the ones that the measurement will be performed with. One way to do
this is to define a certain flow of packets and then record some
fields of the packets that are unlikely to change during its journey
through their journey between the observation points. One the
packets have been properly identified, and the timestamp information
about them has been recorded in the observation points, it should be
possible to calculate the one way delay for the observed packets.
Trammell, et al. Expires August 18, 2014 [Page 4]
Internet-Draft Hybrid Measurement February 2014
If defining a passive metric for one way delay is deemed interesting,
it would be then needed to perform a gap analysis for the additional
protocols that are needed for this. As the passive approach would
also need to negotiate measurement sessions, it may be worth
exploring the re use of OWAMP for this. Similarly, both observation
points should agree what packet flow will be used for the
measurement, so additional negotiation is needed. Finally, IPFIX
could be used to report the results so that the actual delay can be
calculated.
An additional exercise that would be then relevant is to understand
how comparable are measurements obtained through the active and
passive measurements. In particular, depending on the packet
frequency, it may or may not be possible to achieve the different
packet streams available in active measurements.
A hybrid approach for measuring one way delay seems attractive as it
would be possible to measure reliably one way delay reusing the
packets available in the network when they exist and generating
artificial traffic when they don't exist. This requires careful
consideration in order to obtain the desired packet streams and it is
likely to require additional control protocol to specific the hybrid
measurement.
3.3. Round-trip Delay
Round-trip delay is used to measure the expected time for network
interaction between two hosts on a network; conceptually, it is
equivalent to Delay in each direction between the two hosts.
Active measurement of round-trip delay as defined in [RFC2681]
requires the observation of test packets transmitted in both
directions between two endpoints across a network, a "source" host,
which sends the first packet, and a "destination" host, which
receives the first test packet and sends a test packet back to the
source in reply. The round-trip delay is then calculated as the
difference between the time at which the reply is received at the
source and the time at which the original test packet was sent from
this same source.
IPPM has defined the Two-Way Active Measurement Protocol (TWAMP)
[RFC5357] for round trip delay measurement. TWAMP is essentially an
extension of OWAMP for the IPPM round-trip delay metric. Like OWAMP,
TWAMP consists of a control protocol to negotiate active performance
measurement sessions, and a test protocol for transmission of actual
test packets.
Trammell, et al. Expires August 18, 2014 [Page 5]
Internet-Draft Hybrid Measurement February 2014
TWAMP is defined for active performance metrics, which means that the
Round-trip delay is measured for packets the are generated
specifically for this purpose.
3.3.1. Passive Measurement Method
The passive approach for measuring Round-trip delay would consist on
measuring this delay for existent packets in contrast with the active
approach in which test packets are generated. Similarly to the
method used for measuring One-way Delay, for Round-trip Delay it
would be needed to define two observation points that will record the
packets they see and the corresponding timestamps.
The procedure for passive measurement of round-trip delay is similar
to the procedure for active measurement: a packet sent from a source
to a destination is recorded; that packet causes the destination to
send a reply back to the source. This reply is also recorded. The
packets are identifiable at the source in order to correlate each
packet of the round trip in order to calculate a delay.
There are two potential architectures here; one utilizing a source
Observation Point (OP) placed topologically close to the source of
traffic, and one utilizing an additional destination OP placed
topologically close to the destination of traffic.
In order to be able to measure the Round-trip Delay of the observed
packets, it would be necessary to identify which packets will be used
to perform the measurement.
4. Methodology
For certain performance metrics, many passive measurement
methodologies may exist. This section give the fuctional reqirements
and design considerations of the passive measurement methodology.
4.1. Measurement Session Management
A measurement session refers to the period of time in which
measurement for certain performance metrics is enabled over a
forwarding path. When an interface on the measurement node is
activated, the interfaces start collecting statistics. When both the
upstream and downstream measurement interfaces are activated, the
measurement session starts. During a measurement session, data from
two active interfaces are periodically collected and the performance
metrics, such as loss rate or delay, are derived. A measurement
session SHOULD be started either proactively or on demand.
Trammell, et al. Expires August 18, 2014 [Page 6]
Internet-Draft Hybrid Measurement February 2014
4.1.1. Measurement Configuration
A measurement session can be configured statically. In this case,
network operators activate the two interfaces or configure their
parameter settings on the relevant nodes either manually or
automatically through agents of network management system (NMS).
Alternatively, a measurement session can be configured dynamically.
In this case, an interface may coordinate another interface on its
forwarding path to start or stop a session. Accordingly, the format
and process routines of the measurement session control packets need
to be specified. The delivery of such packets SHOULD be reliable and
it MUST be possible to secure the delivery of such packets.
4.2. Measurement Result Report
Performance reports contain streams of measurement data over a period
of time. A data collection agent MAY actively poll the monitoring
nodes and collect the measurement reports from all active interfaces.
Alternatively, the monitoring nodes might be configured to upload the
reports to the specific data collection agents once the data become
available. To save bandwidth, the content of the reports might be
aggregated and compressed. The period of reporting SHOULD be able to
be configured or controlled by rate limitation mechanisms.
4.3. Synchronization
During a measurement session, data from the active upstream and
downstream interfaces are periodically collected and the performance
metrics are derived. Certain synchronization mechenism is required
to ensure the data are correlated. This may further requires that
the upstream and downstream interfaces having a certain time
synchronization capability (e.g., supporting the Network Time
Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol
(PTP) [IEEE1588].) For packet delay measurement, this requirement
for time synchronization is already present.
4.4. Scalability
The measurement methodology MUST be scalable. A service provider
production network usually comprises of thousands of nodes. Given
the scale, the collecting, processing and reporting overhead of
performance measurement data SHOULD NOT overwhelm either monitoring
nodes or management nodes. The volume of reporting traffic should be
reasonable and not cause any network congestion.
Trammell, et al. Expires August 18, 2014 [Page 7]
Internet-Draft Hybrid Measurement February 2014
4.5. Robustness
The measurements MUST be independent of the failure of the underlying
network. For example, the correct measurement result SHOULD be
generated even if some measurement coordinating packets are lost;
invalid performance reports should be able to be identified in case
that the underlying network is undergoing drastic changes. If
dynamic measurement configuration is supported, the delivery of
measurement session control packets SHOULD be reliable so that the
measurement sessions can be started, ended and performed in a
predictable manner.
4.6. Security
The measurement methodology MUST not impose security risks on the
network. For example, the monitoring nodes should be prevented from
being exploited by third parties to control measurement sessions
arbitrarily, which might make the nodes vulnerable for DDoS attacks.
If dynamic configuration is supported, the measurement session
control packets need to be encrypted and authenticated.
5. Security Considerations
[EDITOR'S NOTE: this section will discuss general security
considerations of using passive measurement for performance, both on
the potential for attacks against the measurement system as well as
the potential for privacy or security threats posed by the
measurement system itself.]
6. IANA Considerations
This document contains no considerations for IANA.
7. References
7.1. Normative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
7.2. Informative References
[I-D.tempia-opsawg-p3m]
Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
"A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-04 (work in
progress), February 2014.
Trammell, et al. Expires August 18, 2014 [Page 8]
Internet-Draft Hybrid Measurement February 2014
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
Authors' Addresses
Brian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
Email: trammell@tik.ee.ethz.ch
Lianshu Zheng
Huawei Technologies
China
Email: vero.zheng@huawei.com
Sofia Silva
LACNIC
Uruguay
Email: sofia@lacnic.net
Trammell, et al. Expires August 18, 2014 [Page 9]
Internet-Draft Hybrid Measurement February 2014
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes
Spain
Email: bagnulo@it.uc3m.es
Trammell, et al. Expires August 18, 2014 [Page 10]
