draft-ietf-ippm-reporting-metrics-07.txt   draft-ietf-ippm-reporting-metrics-08.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft G. Ramachandran Internet-Draft G. Ramachandran
Intended status: Informational G. Maguluri Intended status: Informational G. Maguluri
Expires: August 16, 2012 AT&T Labs Expires: September 12, 2012 AT&T Labs
February 13, 2012 March 11, 2012
Reporting Metrics: Different Points of View Reporting Metrics: Different Points of View
draft-ietf-ippm-reporting-metrics-07 draft-ietf-ippm-reporting-metrics-08
Abstract Abstract
Consumers of IP network performance metrics have many different uses Consumers of IP network performance metrics have many different uses
in mind. The memo provides "long-term" reporting considerations in mind. The memo provides "long-term" reporting considerations
(e.g, days, weeks or months, as opposed to 10 seconds), based on (e.g, days, weeks or months, as opposed to 10 seconds), based on
analysis of the two key audience points-of-view. It describes how analysis of the two key audience points-of-view. It describes how
the audience categories affect the selection of metric parameters and the audience categories affect the selection of metric parameters and
options when seeking info that serves their needs. options when seeking info that serves their needs.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 16, 2012. This Internet-Draft will expire on September 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 21 skipping to change at page 3, line 21
3.2. Long-Term Reporting Considerations . . . . . . . . . . . . 6 3.2. Long-Term Reporting Considerations . . . . . . . . . . . . 6
4. Effect of POV on the Loss Metric . . . . . . . . . . . . . . . 8 4. Effect of POV on the Loss Metric . . . . . . . . . . . . . . . 8
4.1. Loss Threshold . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Loss Threshold . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Network Characterization . . . . . . . . . . . . . . . 8 4.1.1. Network Characterization . . . . . . . . . . . . . . . 8
4.1.2. Application Performance . . . . . . . . . . . . . . . 10 4.1.2. Application Performance . . . . . . . . . . . . . . . 10
4.2. Errored Packet Designation . . . . . . . . . . . . . . . . 10 4.2. Errored Packet Designation . . . . . . . . . . . . . . . . 10
4.3. Causes of Lost Packets . . . . . . . . . . . . . . . . . . 10 4.3. Causes of Lost Packets . . . . . . . . . . . . . . . . . . 10
4.4. Summary for Loss . . . . . . . . . . . . . . . . . . . . . 11 4.4. Summary for Loss . . . . . . . . . . . . . . . . . . . . . 11
5. Effect of POV on the Delay Metric . . . . . . . . . . . . . . 11 5. Effect of POV on the Delay Metric . . . . . . . . . . . . . . 11
5.1. Treatment of Lost Packets . . . . . . . . . . . . . . . . 11 5.1. Treatment of Lost Packets . . . . . . . . . . . . . . . . 11
5.1.1. Application Performance . . . . . . . . . . . . . . . 11 5.1.1. Application Performance . . . . . . . . . . . . . . . 12
5.1.2. Network Characterization . . . . . . . . . . . . . . . 12 5.1.2. Network Characterization . . . . . . . . . . . . . . . 12
5.1.3. Delay Variation . . . . . . . . . . . . . . . . . . . 13 5.1.3. Delay Variation . . . . . . . . . . . . . . . . . . . 13
5.1.4. Reordering . . . . . . . . . . . . . . . . . . . . . . 14 5.1.4. Reordering . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Preferred Statistics . . . . . . . . . . . . . . . . . . . 14 5.2. Preferred Statistics . . . . . . . . . . . . . . . . . . . 14
5.3. Summary for Delay . . . . . . . . . . . . . . . . . . . . 15 5.3. Summary for Delay . . . . . . . . . . . . . . . . . . . . 15
6. Reporting Raw Capacity Metrics . . . . . . . . . . . . . . . . 15 6. Reporting Raw Capacity Metrics . . . . . . . . . . . . . . . . 15
6.1. Type-P Parameter . . . . . . . . . . . . . . . . . . . . . 15 6.1. Type-P Parameter . . . . . . . . . . . . . . . . . . . . . 16
6.2. A priori Factors . . . . . . . . . . . . . . . . . . . . . 16 6.2. A priori Factors . . . . . . . . . . . . . . . . . . . . . 16
6.3. IP-layer Capacity . . . . . . . . . . . . . . . . . . . . 16 6.3. IP-layer Capacity . . . . . . . . . . . . . . . . . . . . 16
6.4. IP-layer Utilization . . . . . . . . . . . . . . . . . . . 17 6.4. IP-layer Utilization . . . . . . . . . . . . . . . . . . . 17
6.5. IP-layer Available Capacity . . . . . . . . . . . . . . . 17 6.5. IP-layer Available Capacity . . . . . . . . . . . . . . . 17
6.6. Variability in Utilization and Avail. Capacity . . . . . . 18 6.6. Variability in Utilization and Avail. Capacity . . . . . . 18
6.6.1. General Summary of Variability . . . . . . . . . . . . 18 6.6.1. General Summary of Variability . . . . . . . . . . . . 18
7. Reporting Restricted Capacity Metrics . . . . . . . . . . . . 19 7. Reporting Restricted Capacity Metrics . . . . . . . . . . . . 19
7.1. Type-P Parameter and Type-C Parameter . . . . . . . . . . 20 7.1. Type-P Parameter and Type-C Parameter . . . . . . . . . . 20
7.2. A priori Factors . . . . . . . . . . . . . . . . . . . . . 20 7.2. A priori Factors . . . . . . . . . . . . . . . . . . . . . 20
7.3. Measurement Interval . . . . . . . . . . . . . . . . . . . 20 7.3. Measurement Interval . . . . . . . . . . . . . . . . . . . 20
7.4. Bulk Transfer Capacity Reporting . . . . . . . . . . . . . 21 7.4. Bulk Transfer Capacity Reporting . . . . . . . . . . . . . 21
7.5. Variability in Bulk Transfer Capacity . . . . . . . . . . 22 7.5. Variability in Bulk Transfer Capacity . . . . . . . . . . 22
8. Reporting on Test Streams and Sample Size . . . . . . . . . . 22 8. Reporting on Test Streams and Sample Size . . . . . . . . . . 22
8.1. Test Stream Characteristics . . . . . . . . . . . . . . . 22 8.1. Test Stream Characteristics . . . . . . . . . . . . . . . 22
8.2. Sample Size . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Sample Size . . . . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
When designing measurements of IP networks and presenting the When designing measurements of IP networks and presenting the
results, knowledge of the audience is a key consideration. To results, knowledge of the audience is a key consideration. To
present a useful and relevant portrait of network conditions, one present a useful and relevant portrait of network conditions, one
must answer the following question: must answer the following question:
"How will the results be used?" "How will the results be used?"
skipping to change at page 5, line 7 skipping to change at page 5, line 7
the loss and delay metrics [RFC2680] [RFC2679]. It will also discuss the loss and delay metrics [RFC2680] [RFC2679]. It will also discuss
the delay variation [RFC3393] and reordering metrics [RFC4737] where the delay variation [RFC3393] and reordering metrics [RFC4737] where
applicable. applicable.
With capacity metrics growing in relevance to the industry, the memo With capacity metrics growing in relevance to the industry, the memo
also covers POV and reporting considerations for metrics resulting also covers POV and reporting considerations for metrics resulting
from the Bulk Transfer Capacity Framework [RFC3148] and Network from the Bulk Transfer Capacity Framework [RFC3148] and Network
Capacity Definitions [RFC5136]. These memos effectively describe two Capacity Definitions [RFC5136]. These memos effectively describe two
different categories of metrics, different categories of metrics,
o [RFC3148] with congestion flow-control and the notion of unique o [RFC3148] includes restrictions of congestion control and the
data bits delivered, and notion of unique data bits delivered, and
o [RFC5136] using a definition of raw capacity without the o [RFC5136] using a definition of raw capacity without the
restrictions of data uniqueness or congestion-awareness. restrictions of data uniqueness or congestion-awareness.
It might seem at first glance that each of these metrics has an It might seem at first glance that each of these metrics has an
obvious audience (Raw = Network Characterization, Restricted = obvious audience (Raw = Network Characterization, Restricted =
Application Performance), but reality is more complex and consistent Application Performance), but reality is more complex and consistent
with the overall topic of capacity measurement and reporting. For with the overall topic of capacity measurement and reporting. For
example, TCP is usually used in Restricted capacity measurement example, TCP is usually used in Restricted capacity measurement
methods, while UDP appears in Raw capacity measurement. The Raw and methods, while UDP appears in Raw capacity measurement. The Raw and
skipping to change at page 9, line 9 skipping to change at page 9, line 9
the metric design helps to distinguish more reliably between packets the metric design helps to distinguish more reliably between packets
that might yet arrive, and those that are no longer traversing the that might yet arrive, and those that are no longer traversing the
network. network.
It is possible to calculate a worst-case waiting time, assuming that It is possible to calculate a worst-case waiting time, assuming that
a routing loop is the cause. We model the path between Source and a routing loop is the cause. We model the path between Source and
Destination as a series of delays in links (t) and queues (q), as Destination as a series of delays in links (t) and queues (q), as
these two are the dominant contributors to delay. The normal path these two are the dominant contributors to delay. The normal path
delay across n hops without encountering a loop, D, is delay across n hops without encountering a loop, D, is
n n
--- ---
\ \
D = t + > t + q D = t + > (t + q )
0 / i i 0 / i i
--- ---
i = 1 i = 1
Figure 1: Normal Path Delay Figure 1: Normal Path Delay
and the time spent in the loop with L hops, is and the time spent in the loop with L hops, is
i + L-1 j + L-1
--- ---
\ (TTL - n) \ (TTL - n)
R = C > t + q where C = --------- R = C > (t + q ) where C = ---------
/ i i max L / i i max L
--- ---
i i=j where j is the hop number where the loop begins
Figure 2: Delay due to Rotations in a Loop Figure 2: Delay due to Rotations in a Loop
and where C is the number of times a packet circles the loop. where C is the number of times a packet circles the loop, and where
TTL is the packet's initial Time-to-Live value at the source (or Hop
Count in IPv6).
If we take the delays of all links and queues as 100ms each, the If we take the delays of all links and queues as 100ms each, the
TTL=255, the number of hops n=5 and the hops in the loop L=4, then TTL=255, the number of hops n=5 and the hops in the loop L=4, then
D = 1.1 sec and R ~= 50 sec, and D + R ~= 51.1 seconds D = 1.1 sec and R ~= 50 sec, and D + R ~= 51.1 seconds
We note that the link delays of 100ms would span most continents, and We note that the link delays of 100ms would span most continents, and
a constant queue length of 100ms is also very generous. When a loop a constant queue length of 100ms is also very generous. When a loop
occurs, it is almost certain to be resolved in 10 seconds or less. occurs, it is almost certain to be resolved in 10 seconds or less.
The value calculated above is an upper limit for almost any real- The value calculated above is an upper limit for almost any real-
skipping to change at page 10, line 48 skipping to change at page 11, line 4
Although many measurement systems use a waiting time to determine if Although many measurement systems use a waiting time to determine if
a packet is lost or not, most of the waiting is in vain. The packets a packet is lost or not, most of the waiting is in vain. The packets
are no-longer traversing the network, and have not reached their are no-longer traversing the network, and have not reached their
destination. destination.
There are many causes of packet loss, including: There are many causes of packet loss, including:
1. Queue drop, or discard 1. Queue drop, or discard
2. Corruption of the IP header, or other essential header info 2. Corruption of the IP header, or other essential header info
3. TTL expiration (or use of a TTL value that is too small) 3. TTL expiration (or use of a TTL value that is too small)
4. Link or router failure 4. Link or router failure
5. Layers below the source-to-destination IP layer can discard
packets that fail error checking and link-layer checksums often
cover the entire packet
After waiting sufficient time, packet loss can probably be attributed After waiting sufficient time, packet loss can probably be attributed
to one of these causes. to one of these causes.
4.4. Summary for Loss 4.4. Summary for Loss
Given that measurement post-processing is possible (even encouraged Given that measurement post-processing is possible (even encouraged
in the definitions of IPPM metrics), measurements of loss can easily in the definitions of IPPM metrics), measurements of loss can easily
serve both points of view: serve both points of view:
o Use a long waiting time to serve network characterization and o Use a long waiting time to serve network characterization and
 End of changes. 14 change blocks. 
26 lines changed or deleted 32 lines changed or added

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