< draft-ietf-ippm-2330-update-01.txt   draft-ietf-ippm-2330-update-02.txt >
Network Working Group J. Fabini Network Working Group J. Fabini
Internet-Draft Vienna University of Technology Internet-Draft Vienna University of Technology
Intended status: Informational A. Morton Updates: 2330 (if approved) A. Morton
Expires: April 18, 2014 AT&T Labs Intended status: Informational AT&T Labs
October 15, 2013 Expires: August 11, 2014 February 7, 2014
Advanced Stream and Sampling Framework for IPPM Advanced Stream and Sampling Framework for IPPM
draft-ietf-ippm-2330-update-01 draft-ietf-ippm-2330-update-02
Abstract Abstract
To obtain repeatable results in modern networks, test descriptions To obtain repeatable results in modern networks, test descriptions
need an expanded stream parameter framework that also augments need an expanded stream parameter framework that also augments
aspects specified as Type-P for test packets. This memo proposes to aspects specified as Type-P for test packets. This memo proposes to
update the IP Performance Metrics (IPPM) Framework with advanced update the IP Performance Metrics (IPPM) Framework with advanced
considerations for measurement methodology and testing. The existing considerations for measurement methodology and testing. The existing
framework mostly assumes deterministic connectivity, and that a framework mostly assumes deterministic connectivity, and that a
single test stream will represent the characteristics of the path single test stream will represent the characteristics of the path
skipping to change at page 1, line 33 skipping to change at page 1, line 33
network features may dominate the measured performance. This memo network features may dominate the measured performance. This memo
describes new stream parameters for both network characterization and describes new stream parameters for both network characterization and
support of application design using IPPM metrics. support of application design using IPPM metrics.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 18, 2014. This Internet-Draft will expire on August 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definition: Reactive Path Behavior . . . . . . . . . . . . 3 1.1. Definition: Reactive Path Behavior . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New or Revised Stream Parameters . . . . . . . . . . . . . . . 4 3. New or Revised Stream Parameters . . . . . . . . . . . . . . 5
3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . . 6 3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . 6
3.1.1. Multiple Test Packet Lengths . . . . . . . . . . . . . 6 3.1.1. Multiple Test Packet Lengths . . . . . . . . . . . . 6
3.1.2. Test Packet Payload Content Optimization . . . . . . . 6 3.1.2. Test Packet Payload Content Optimization . . . . . . 7
3.2. Packet History . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Packet History . . . . . . . . . . . . . . . . . . . . . 7
3.3. Access Technology Change . . . . . . . . . . . . . . . . . 7 3.3. Access Technology Change . . . . . . . . . . . . . . . . 7
3.4. Time-Slotted Randomness Cancellation . . . . . . . . . . . 7 3.4. Time-Slotted Randomness Cancellation . . . . . . . . . . 8
4. Quality of Metrics and Methodologies . . . . . . . . . . . . . 9 4. Quality of Metrics and Methodologies . . . . . . . . . . . . 9
4.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Continuity . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Continuity . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Actionable . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Actionable . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Conservative . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Conservative . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Spatial and Temporal Composition . . . . . . . . . . . . . 12 4.5. Spatial and Temporal Composition . . . . . . . . . . . . 12
4.6. Poisson Sampling . . . . . . . . . . . . . . . . . . . . . 12 4.6. Poisson Sampling . . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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, while only being updated once in a specific area [RFC5835]. metrics, while only being updated once in a specific area [RFC5835].
The IPPM framework [RFC2330] generally relies on several assumptions, The IPPM framework [RFC2330] generally relies on several assumptions,
one of which is not explicitly stated but assumed: lightly loaded one of which is not explicitly stated but assumed: lightly loaded
skipping to change at page 4, line 12 skipping to change at page 4, line 8
characteristics *change* according to prior observations of the characteristics *change* according to prior observations of the
packet flow of interest (at the reactive host or link). Therefore, packet flow of interest (at the reactive host or link). Therefore,
reactive path behavior is nominally deterministic with respect to the reactive path behavior is nominally deterministic with respect to the
flow of interest. Other flows or traffic load conditions may result flow of interest. Other flows or traffic load conditions may result
in additional performance-affecting reactions, but these are external in additional performance-affecting reactions, but these are external
to the characteristics of the flow of interest. to the characteristics of the flow of interest.
In practice, a sender may not have absolute control of the ingress In practice, a sender may not have absolute control of the ingress
packet stream characteristics at a reactive host or link, but this packet stream characteristics at a reactive host or link, but this
does not change the deterministic reactions present there. If we does not change the deterministic reactions present there. If we
measure a path and the arrival characteristics at the reactive host/ measure a path, the arrival characteristics at the reactive host/link
link depend on both the sending characteristics and the transfer are determined by the sending characteristics and the transfer
characteristics of intervening hosts and links, then the reaction characteristics of intervening hosts and links. Identical traffic
will appear less deterministic owing to the noise in the pattern at patterns at the sending host might generate distinct patterns at the
the reactive host/link. reactive host's/link's input due to impairments in the intermediate
subpath. The reactive host/link is expected to provide deterministic
response on identical input patterns.
Other than the size of the payload at the layer of interest and the Other than the size of the payload at the layer of interest and the
header itself, packet content does not influence the measurement. header itself, packet content does not influence the measurement.
Reactive behavior at the IP layer is not influenced by the TCP ports Reactive behavior at the IP layer is not influenced by the TCP ports
in use, for example. Therefore, the indication of reactive behavior in use, for example. Therefore, the indication of reactive behavior
must include the layer at which measurements are instituted. must include the layer at which measurements are instituted.
Examples include links with Active/In-active state detectors, and Examples include links with Active/In-active state detectors, and
hosts or links that revise their traffic serving and forwarding rates hosts or links that revise their traffic serving and forwarding rates
(up or down) based on packet arrival history. (up or down) based on packet arrival history.
skipping to change at page 4, line 38 skipping to change at page 4, line 36
Although difficult to handle from a measurement point of view, Although difficult to handle from a measurement point of view,
reactive paths entities are usually designed to improve overall reactive paths entities are usually designed to improve overall
network performance and user experience, for example by making network performance and user experience, for example by making
capacity available to an active user. Reactive behavior may be an capacity available to an active user. Reactive behavior may be an
artifact of solutions to allocate scarce resources according to the artifact of solutions to allocate scarce resources according to the
demands of users, thus it is an important problem to solve for demands of users, thus it is an important problem to solve for
measurement and other disciplines, such as application design. measurement and other disciplines, such as application design.
2. Scope 2. Scope
The scope of this memo is to describe useful stream parameters in The purpose of this memo is to foster repeatable measurement results
addition to the information in Section 11.1 of [RFC2330] and in modern networks by highlighting the key aspects of test streams
described in [RFC3432] for periodic streams. The purpose is to and packets and make them part of the IPPM performance metric
foster repeatable measurement results in modern networks by framework.
highlighting the key aspects of test streams and packets and make
them part of the IPPM performance metric framework. The scope is to update key sections of [RFC2330], adding
considerations that will aid the development of new measurement
methodologies intended for today's IP networks. Specifically, this
memo describes useful stream parameters in addition to the
information in Section 11.1 of [RFC2330] and described in [RFC3432]
for periodic streams.
The memo also provides new considerations to update the criteria for
metrics in section 4 of [RFC2330], the measurement methodology in
section 6.2 of [RFC2330], and other topics related to the quality of
metrics and methods (see section 4).
Other topics in [RFC2330] which might be updated or augmented are
deferred to future work. This includes the topics of passive and
various forms of of hybrid active/passive measurements.
3. New or Revised Stream Parameters 3. New or Revised Stream Parameters
There are several areas where measurement methodology definition and There are several areas where measurement methodology definition and
test result interpretation will benefit from an increased test result interpretation will benefit from an increased
understanding of the stream characteristics and the (possibly understanding of the stream characteristics and the (possibly
unknown) network condition that influence the measured metrics. unknown) network condition that influence the measured metrics.
1. Network treatment depends on the fullest extent on the "packet of 1. Network treatment depends on the fullest extent on the "packet of
Type-P" definition in [RFC2330], and has for some time. Type-P" definition in [RFC2330], and has for some time.
skipping to change at page 6, line 30 skipping to change at page 6, line 41
Many instances of network characterization using IPPM metrics have Many instances of network characterization using IPPM metrics have
relied on a single test packet length. When testing to assess relied on a single test packet length. When testing to assess
application performance or an aggregate of traffic, benchmarking application performance or an aggregate of traffic, benchmarking
methods have used a range of fixed lengths and frequently augmented methods have used a range of fixed lengths and frequently augmented
fixed size tests with a mixture of sizes, or IMIX as described in fixed size tests with a mixture of sizes, or IMIX as described in
[RFC6985]. [RFC6985].
Test packet length influences delay measurements, in that the IPPM Test packet length influences delay measurements, in that the IPPM
one-way delay metric [RFC2679] includes serialization time in its one-way delay metric [RFC2679] includes serialization time in its
first-bit to last bit time stamping requirements. However, different first-bit to last bit time stamping requirements. However, different
sizes can have a larger effect on link delay and link delay variation sizes can have a larger influence on link delay and link delay
than serialization would explain alone. This effect can be non- variation than serialization would explain alone. This effect can be
linear and change the instantaneous network performance when a non-linear and change the instantaneous network performance when a
different size is used, or the performance of packets following the different size is used, or the performance of packets following the
size change. size change.
Repeatability is a main measurement methodology goal as stated in Repeatability is a main measurement methodology goal as stated in
section 6.2 of [RFC2330]. To eliminate packet length as a potential section 6.2 of [RFC2330]. To eliminate packet length as a potential
measurement uncertainty factor, successive measurements must use measurement uncertainty factor, successive measurements must use
identical traffic patterns. In practice a combination of random identical traffic patterns. In practice a combination of random
payload and random start time can yield representative results as payload and random start time can yield representative results as
illustrated in [IRR]. illustrated in [IRR].
3.1.2. Test Packet Payload Content Optimization 3.1.2. Test Packet Payload Content Optimization
The aim for efficient network resource use has resulted in deployment The aim for efficient network resource use has resulted in deployment
of server-only or client-server lossless or lossy payload compression of server-only or client-server lossless or lossy payload compression
techniques on some links or paths. These optimizers attempt to techniques on some links or paths. These optimizers attempt to
compress high-volume traffic in order to reduce network load. Files compress high-volume traffic in order to reduce network load. Files
are analyzed by application-layer parsers and parts (like comments) are analyzed by application-layer parsers, and parts (like comments)
might be dropped. Although typically acting on HTTP or JPEG files, might be dropped. Although typically acting on HTTP or JPEG files,
compression might affect measurement packets, too. In particular compression might affect measurement packets, too. In particular,
measurement packets are qualified for efficient compression when they measurement packets are qualified for efficient compression when they
use standard plain-text payload. use standard plain-text payload.
IPPM-conforming measurements should add packet payload content as a IPPM-conforming measurements should add packet payload content as a
Type-P parameter which can help to improve measurement determinism. Type-P parameter which can help to improve measurement determinism.
Some packet payloads are more susceptible to compression than others, Some packet payloads are more susceptible to compression than others,
but optimizers in the measurement path can be out ruled by using but optimizers in the measurement path can be out ruled by using
incompressible packet payload. This payload content could be either incompressible packet payload. This payload content could be either
generated by a random device or by using part of a compressed file generated by a random device or by using part of a compressed file
(e.g., a part of a ZIP compressed archive). (e.g., a part of a ZIP compressed archive).
3.2. Packet History 3.2. Packet History
Recent packet history and instantaneous data rate influence Recent packet history and instantaneous data rate influence
measurement results for reactive links supporting on-demand capacity measurement results for reactive links supporting on-demand capacity
allocation. Measurement uncertainty may be reduced by knowledge of allocation. Measurement uncertainty may be reduced by knowledge of
measurement packet history and total host load. Additionally, small measurement packet history and total host load. Additionally, small
changes in history, e.g., because of lost packets along the path, can changes in history, e.g., because of lost packets along the path, can
be the cause of large performance variations. be the cause of large performance variations.
For instance delay in reactive 3G networks like High Speed Packet For instance, delay in reactive 3G networks like High Speed Packet
Access (HSPA) depends to a large extent on the test traffic data Access (HSPA) depends to a large extent on the test traffic data
rate. The reactive resource allocation strategy in these networks rate. The reactive resource allocation strategy in these networks
affects the uplink direction in particular. Small changes in data affects the uplink direction in particular. Small changes in data
rate can be the reason of more than 200% increase in delay, depending rate can be the reason of more than 200% increase in delay, depending
on the specific packet size. on the specific packet size.
3.3. Access Technology Change 3.3. Access Technology Change
[RFC2330] discussed the scenario of multi-homed hosts. If hosts [RFC2330] discussed the scenario of multi-homed hosts. If hosts
become aware of access technology changes (e.g., because of IP become aware of access technology changes (e.g., because of IP
address changes or lower layer information) and make this information address changes or lower layer information) and make this information
available, measurement methodologies can use this information to available, measurement methodologies can use this information to
improve measurement representativeness and relevance. improve measurement representativeness and relevance.
However, today's various access network technologies can present the However, today's various access network technologies can present the
same physical interface to the host. A host may or may not become same physical interface to the host. A host may or may not become
aware when its access technology changes on such an interface. aware when its access technology changes on such an interface.
Measurements for paths which support on-demand capacity allocation Measurements for paths which support on-demand capacity allocation
are therefore challenging in that it is difficult to differentiate are therefore challenging, in that it is difficult to differentiate
between access technology changes (e.g., because of mobility) and between access technology changes (e.g., because of mobility) and
reactive path behavior (e.g., because of data rate change). reactive path behavior (e.g., because of data rate change).
3.4. Time-Slotted Randomness Cancellation 3.4. Time-Slotted Randomness Cancellation
Time-Slotted operation of path entities - interfaces, routers or Time-Slotted operation of path entities - interfaces, routers or
links - in a network path is a particular challenge for measurements, links - in a network path is a particular challenge for measurements,
especially if the time slot period is substantial. The central especially if the time slot period is substantial. The central
observation as an extension to Poisson stream sampling in [RFC2330] observation as an extension to Poisson stream sampling in [RFC2330]
is that the first such time-slotted component cancels unbiased is that the first such time-slotted component cancels unbiased
skipping to change at page 10, line 4 skipping to change at page 10, line 13
tests are hyper-sensitive to differences in the mean of tests are hyper-sensitive to differences in the mean of
distributions), and recognize the original findings of [RFC2330] distributions), and recognize the original findings of [RFC2330]
regarding excess sample sizes. regarding excess sample sizes.
One way to view the reliance on identical conditions is to view it as One way to view the reliance on identical conditions is to view it as
a challenge: how few parameters and path conditions need to be a challenge: how few parameters and path conditions need to be
controlled and still produce repeatable methods/measurements? controlled and still produce repeatable methods/measurements?
Although the [RFC6808] test plan documented numerical criteria for Although the [RFC6808] test plan documented numerical criteria for
equivalence, we cannot specify the exact numerical criteria for equivalence, we cannot specify the exact numerical criteria for
repeatability *in general*. The process in the BCP [RFC6576] and repeatability *in general*. The process in the BCP [RFC6576] and
statistics in [RFC6808] have been used successfully, and the statistics in [RFC6808] have been used successfully, and the
numerical criteria to declare a metric repeatable should be agreed by numerical criteria to declare a metric repeatable should be agreed by
all interested parties prior to measurement. all interested parties prior to measurement.
We revise the definition slightly, as follows: We revise the definition slightly, as follows:
"A methodology for a metric should have the property that it is "A methodology for a metric should have the property that it is
repeatable: if the methodology is used multiple times under identical repeatable: if the methodology is used multiple times under identical
conditions, the methods should produce equivalent measurement conditions, the methods should produce equivalent measurement
results." results."
skipping to change at page 12, line 43 skipping to change at page 13, line 4
methodologies is highly challenging and sometimes impossible in methodologies is highly challenging and sometimes impossible in
reactive paths. Measurements in paths with demand-driven allocation reactive paths. Measurements in paths with demand-driven allocation
strategies must use a prototypical application packet stream to infer strategies must use a prototypical application packet stream to infer
a specific application's performance. Measurement repetition with a specific application's performance. Measurement repetition with
unbiased network and flow states (e.g., by rebooting measurement unbiased network and flow states (e.g., by rebooting measurement
hosts) can help to avoid interference with periodic network behavior, hosts) can help to avoid interference with periodic network behavior,
randomness being a mandatory feature for avoiding correlation with randomness being a mandatory feature for avoiding correlation with
network timing. Inferring the path performance between one network timing. Inferring the path performance between one
measurement session or packet stream and other streams with alternate measurement session or packet stream and other streams with alternate
characteristics is generally discouraged with reactive paths because characteristics is generally discouraged with reactive paths because
of the huge set of global parameters which have influence of the huge set of global parameters which have influence on
instantaneous path performance. instantaneous path performance.
6. Security Considerations 6. Security Considerations
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].
7. IANA Considerations 7. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
8. Acknowledgements 8. Acknowledgements
The authors thank Rudiger Geib, Matt Mathis and Konstantinos The authors thank Rudiger Geib, Matt Mathis and Konstantinos
Pentikousis for their helpful comments on this draft. Pentikousis for their helpful comments on this memo, and Ann Cerveny
for her editorial review and comments that helped to improve
readability overall.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330, May
May 1998. 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
skipping to change at page 14, line 22 skipping to change at page 14, line 32
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012. RFC 6703, August 2012.
9.2. Informative References 9.2. Informative References
[IBD] Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner, [IBD] Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner,
"The Illusion of Being Deterministic - Application-Level "The Illusion of Being Deterministic - Application-Level
Considerations on Delay in 3G HSPA Networks", Lecture Considerations on Delay in 3G HSPA Networks", Lecture
Notes in Computer Science, Springer, Volume 5550, 2009, Notes in Computer Science, Springer, Volume 5550, 2009, pp
pp 301-312 , May 2009. 301-312 , May 2009.
[IRR] Fabini, J., Wallentin, L., and P. Reichl, "The Importance [IRR] Fabini, J., Wallentin, L., and P. Reichl, "The Importance
of Being Really Random: Methodological Aspects of IP-Layer of Being Really Random: Methodological Aspects of IP-Layer
2G and 3G Network Delay Assessment", ICC'09 Proceedings of 2G and 3G Network Delay Assessment", ICC'09 Proceedings of
the 2009 IEEE International Conference on the 2009 IEEE International Conference on Communications,
Communications, doi: 10.1109/ICC.2009.5199514, June 2009. doi: 10.1109/ICC.2009.5199514, June 2009.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
July 2001. 2001.
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results Supporting Advancement of RFC 2679 on the Plan and Results Supporting Advancement of RFC 2679 on the
Standards Track", RFC 6808, December 2012. Standards Track", RFC 6808, December 2012.
[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet [RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet
Sizes for Additional Testing", RFC 6985, July 2013. Sizes for Additional Testing", RFC 6985, July 2013.
[TSRC] Fabini, J. and M. Abmayer, "Delay Measurement Methodology [TSRC] Fabini, J. and M. Abmayer, "Delay Measurement Methodology
Revisited: Time-slotted Randomness Cancellation", IEEE Revisited: Time-slotted Randomness Cancellation", IEEE
Transactions on Instrumentation and Measurement doi: Transactions on Instrumentation and Measurement
10.1109/TIM.2013.2263914, October 2013. doi:10.1109/TIM.2013.2263914, October 2013.
Authors' Addresses Authors' Addresses
Joachim Fabini Joachim Fabini
Vienna University of Technology Vienna University of Technology
Gusshausstrasse 25/E389 Gusshausstrasse 25/E389
Vienna, 1040 Vienna 1040
Austria Austria
Phone: +43 1 58801 38813 Phone: +43 1 58801 38813
Fax: +43 1 58801 38898 Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
 End of changes. 22 change blocks. 
64 lines changed or deleted 82 lines changed or added

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