draft-ietf-ippm-testplan-rfc2679-02.txt   draft-ietf-ippm-testplan-rfc2679-03.txt 
Network Working Group L. Ciavattone Network Working Group L. Ciavattone
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational R. Geib Intended status: Informational R. Geib
Expires: December 26, 2012 Deutsche Telekom Expires: March 10, 2013 Deutsche Telekom
A. Morton A. Morton
AT&T Labs AT&T Labs
M. Wieser M. Wieser
Technical University Darmstadt Technical University Darmstadt
June 24, 2012 September 6, 2012
Test Plan and Results for Advancing RFC 2679 on the Standards Track Test Plan and Results Supporting Advancement of RFC 2679 on the
draft-ietf-ippm-testplan-rfc2679-02 Standards Track
draft-ietf-ippm-testplan-rfc2679-03
Abstract Abstract
This memo proposes to advance a performance metric RFC along the This memo provides the supporting test plan and results to advance
standards track, specifically RFC 2679 on One-way Delay Metrics. RFC 2679 on One-way Delay Metrics along the standards track,
Observing that the metric definitions themselves should be the following the process in RFC 6576. Observing that the metric
primary focus rather than the implementations of metrics, this memo definitions themselves should be the primary focus rather than the
describes the test procedures to evaluate specific metric requirement implementations of metrics, this memo describes the test procedures
clauses to determine if the requirement has been interpreted and to evaluate specific metric requirement clauses to determine if the
implemented as intended. Two completely independent implementations requirement has been interpreted and implemented as intended. Two
have been tested against the key specifications of RFC 2679. completely independent implementations have been tested against the
key specifications of RFC 2679. This memo also provides direct input
for development of RFC 2679bis.
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
skipping to change at page 1, line 47 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 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 March 10, 2013.
This Internet-Draft will expire on December 26, 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 34 skipping to change at page 3, line 34
6.2.2. Perfas+ Results for Loss Threshold . . . . . . . . . . 22 6.2.2. Perfas+ Results for Loss Threshold . . . . . . . . . . 22
6.2.3. Conclusions for Loss Threshold . . . . . . . . . . . . 22 6.2.3. Conclusions for Loss Threshold . . . . . . . . . . . . 22
6.3. One-way Delay, First-bit to Last bit, RFC 2679 . . . . . . 22 6.3. One-way Delay, First-bit to Last bit, RFC 2679 . . . . . . 22
6.3.1. NetProbe and Perfas+ Results for Serialization . . . . 23 6.3.1. NetProbe and Perfas+ Results for Serialization . . . . 23
6.3.2. Conclusions for Serialization . . . . . . . . . . . . 24 6.3.2. Conclusions for Serialization . . . . . . . . . . . . 24
6.4. One-way Delay, Difference Sample Metric (Lab) . . . . . . 25 6.4. One-way Delay, Difference Sample Metric (Lab) . . . . . . 25
6.4.1. NetProbe results for Differential Delay . . . . . . . 25 6.4.1. NetProbe results for Differential Delay . . . . . . . 25
6.4.2. Perfas+ results for Differential Delay . . . . . . . . 26 6.4.2. Perfas+ results for Differential Delay . . . . . . . . 26
6.4.3. Conclusions for Differential Delay . . . . . . . . . . 26 6.4.3. Conclusions for Differential Delay . . . . . . . . . . 26
6.5. Implementation of Statistics for One-way Delay . . . . . . 26 6.5. Implementation of Statistics for One-way Delay . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Conclusions and RFC 2679 Errata . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has considered The IETF IP Performance Metrics (IPPM) working group has considered
how to advance their metrics along the standards track since 2001, how to advance their metrics along the standards track since 2001,
with the initial publication of Bradner/Paxson/Mankin's memo with the initial publication of Bradner/Paxson/Mankin's memo
[I-D.bradner-metricstest]. The original proposal was to compare the [I-D.bradner-metricstest]. The original proposal was to compare the
results of implementations of the metrics, because the usual performance of metric implementations. This was similar to the usual
procedures for advancing protocols did not appear to apply. It was procedures for advancing protocols, which did not directly apply. It
found to be difficult to achieve consensus on exactly how to compare was found to be difficult to achieve consensus on exactly how to
implementations, since there were many legitimate sources of compare implementations, since there were many legitimate sources of
variation that would emerge in the results despite the best attempts variation that would emerge in the results despite the best attempts
to keep the network paths equal, and because considerable variation to keep the network paths equal, and because considerable variation
was allowed in the parameters (and therefore implementation) of each was allowed in the parameters (and therefore implementation) of each
metric. Flexibility in metric definitions, essential for metric. Flexibility in metric definitions, essential for
customization and broad appeal, made the comparison task quite customization and broad appeal, made the comparison task quite
difficult. difficult.
A renewed work effort sought to investigate ways in which the A renewed work effort investigated ways in which the measurement
measurement variability could be reduced and thereby simplify the variability could be reduced and thereby simplify the problem of
problem of comparison for equivalence. comparison for equivalence.
There is consensus represented in [RFC6576] that the metric The consensus process documented in [RFC6576] is that metric
definitions should be the primary focus of evaluation rather than the definitions should be the primary focus of evaluation rather than the
implementations of metrics, and equivalent results are deemed to be implementations of metrics. Equivalent test results are deemed to be
evidence that the metric specifications are clear and unambiguous. evidence that the metric specifications are clear and unambiguous.
This is the metric specification equivalent of protocol This is now the metric specification equivalent of protocol
interoperability. The advancement process either produces confidence interoperability. The [RFC6576] advancement process either produces
that the metric definitions and supporting material are clearly confidence that the metric definitions and supporting material are
worded and unambiguous, OR, identifies ways in which the metric clearly worded and unambiguous, OR, identifies ways in which the
definitions should be revised to achieve clarity. metric definitions should be revised to achieve clarity.
The process should also permit identification of options that were
not implemented, so that they can be removed from the advancing
specification (this is an aspect more typical of protocol advancement
along the standards track).
This memo's purpose is to implement the current approach for The metric RFC advancement process requires documentation of the
[RFC2679]. It was prepared to help progress discussions on the topic testing and results. [RFC6576] retains the testing requirement of
of metric advancement, both through e-mail and at the upcoming IPPM the original standards track advancement process described in
meeting at IETF. [RFC2026] and [RFC5657], because widespread deployment is
insufficient to determine whether RFCs that define performance
metrics result in consistent implementations.
In particular, consensus is sought on the extent of tolerable errors The process also permits identification of options that were not
when assessing equivalence in the results. In discussions, the IPPM implemented, so that they can be removed from the advancing
working group agreed that test plan and procedures should include the specification (this is a similar aspect to protocol advancement along
threshold for determining equivalence, and this information should be the standards track). All errata must also be considered.
available in advance of cross-implementation comparisons. This memo
includes procedures for same-implementation comparisons to help set
the equivalence threshold.
Another aspect of the metric RFC advancement process is the This memo's purpose is to implement the advancement process of
requirement to document the work and results. The procedures of [RFC6576] for [RFC2679]. It supplies the documentation that
[RFC2026] are expanded in [RFC5657], including sample implementation accompanies the protocol action request submitted to the Area
and interoperability reports. This memo expands on these RFCs and
the examples in Appendix A of [RFC6576] for the procedure and report
that accompanies the protocol action request submitted to the Area
Director, including description of the test set-up, results for each Director, including description of the test set-up, results for each
implementation, and conclusions. implementation, evaluation of each metric specification, and
conclusions.
In particular, this memo documents the consensus on the extent of
tolerable errors when assessing equivalence in the results. The IPPM
working group agreed that the test plan and procedures should include
the threshold for determining equivalence, and that this aspect
should be decided in advance of cross-implementation comparisons.
This memo includes procedures for same-implementation comparisons
that may influence the equivalence threshold.
Although the conclusion reached through testing is that [RFC2679]
should be advanced on the Standards Track with modifications, the
revised text of RFC 2679bis is not yet ready for review. Therefore,
this memo documents the information to support [RFC2679] advancement,
and the approval of RFC2769bis is left for future action.
2. A Definition-centric metric advancement process 2. A Definition-centric metric advancement process
The process described in Section 3.5 of [RFC6576] takes as a first The process described in Section 3.5 of [RFC6576] takes as a first
principle that the metric definitions, embodied in the text of the principle that the metric definitions, embodied in the text of the
RFCs, are the objects that require evaluation and possible revision RFCs, are the objects that require evaluation and possible revision
in order to advance to the next step on the standards track. This in order to advance to the next step on the standards track. This
memo follows that process. memo follows that process.
3. Test configuration 3. Test configuration
One metric implementation used was NetProbe version 5.8.5, (an One metric implementation used was NetProbe version 5.8.5, (an
earlier version is used in the AT&T's IP network performance earlier version is used in the AT&T's IP network performance
measurement system and deployed world-wide [WIPM]). NetProbe uses measurement system and deployed world-wide [WIPM]). NetProbe uses
UDP packets of variable size, and can produce test streams with UDP packets of variable size, and can produce test streams with
Periodic [RFC3432] or Poisson [RFC2330] sample distributions. Periodic [RFC3432] or Poisson [RFC2330] sample distributions.
The other metric implementation used was Perfas+ version 3.1, The other metric implementation used was Perfas+ version 3.1,
developed by Deutsche Telekom. Perfas+ uses UDP unicast packets of developed by Deutsche Telekom [Perfas]. Perfas+ uses UDP unicast
variable size (but supports also TCP and multicast). Test streams packets of variable size (but supports also TCP and multicast). Test
with Periodic, Poisson or uniform sample distributions may be used. streams with Periodic, Poisson or uniform sample distributions may be
used.
Figure 2 shows a view of the test path as each Implementation's test Figure 2 shows a view of the test path as each Implementation's test
flows pass through the Internet and the L2TPv3 tunnel IDs (1 and 2), flows pass through the Internet and the L2TPv3 tunnel IDs (1 and 2),
based on Figures 2 and 3 of [RFC6576]. based on Figures 2 and 3 of [RFC6576].
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
|Imp1| |Imp1| ,---. |Imp2| |Imp2| |Imp1| |Imp1| ,---. |Imp2| |Imp2|
+----+ +----+ / \ +-------+ +----+ +----+ +----+ +----+ / \ +-------+ +----+ +----+
| V100 | V200 / \ | Tunnel| | V300 | V400 | V100 | V200 / \ | Tunnel| | V300 | V400
| | ( ) | Head | | | | | ( ) | Head | | |
skipping to change at page 15, line 19 skipping to change at page 15, line 19
7. Compare the cross-implementation ADK performance with the 7. Compare the cross-implementation ADK performance with the
equivalence threshold determined in step 5 to determine if equivalence threshold determined in step 5 to determine if
equivalence can be declared. equivalence can be declared.
The common parameters used for tests in this section are: The common parameters used for tests in this section are:
o IP header + payload = 64 octets o IP header + payload = 64 octets
o Periodic sampling at 1 packet per second o Periodic sampling at 1 packet per second
o Test duration = 300 seconds (March 29) o Test duration = 300 seconds (March 29, 2011)
The netem emulator was set for 100ms average delay, with uniform The netem emulator was set for 100ms average delay, with uniform
delay variation of +/-50ms. In this experiment, the netem emulator delay variation of +/-50ms. In this experiment, the netem emulator
was configured to operate independently on each VLAN and thus the was configured to operate independently on each VLAN and thus the
emulator itself is a potential source of error when comparing streams emulator itself is a potential source of error when comparing streams
that traverse the test path in different directions. that traverse the test path in different directions.
In the result analysis of this section: In the result analysis of this section:
o All comparisons used 1 microsecond resolution. o All comparisons used 1 microsecond resolution.
skipping to change at page 22, line 9 skipping to change at page 22, line 9
with 2 sec additional delay to be declared lost, and that all with 2 sec additional delay to be declared lost, and that all
packets that arrive successfully in step 3 are assigned a valid packets that arrive successfully in step 3 are assigned a valid
one-way delay. one-way delay.
The common parameters used for tests in this section are: The common parameters used for tests in this section are:
o IP header + payload = 64 octets o IP header + payload = 64 octets
o Poisson sampling at lambda = 1 packet per second o Poisson sampling at lambda = 1 packet per second
o Test duration = 900 seconds total (March 21) o Test duration = 900 seconds total (March 21, 2011)
The netem emulator was set to add constant delays as specified in the The netem emulator was set to add constant delays as specified in the
procedure above. procedure above.
6.2.1. NetProbe results for Loss Threshold 6.2.1. NetProbe results for Loss Threshold
In NetProbe, the Loss Threshold is implemented uniformly over all In NetProbe, the Loss Threshold is implemented uniformly over all
packets as a post-processing routine. With the Loss Threshold set at packets as a post-processing routine. With the Loss Threshold set at
3 seconds, all packets with one-way delay >3 seconds are marked 3 seconds, all packets with one-way delay >3 seconds are marked
"Lost" and included in the Lost Packet list with their transmission "Lost" and included in the Lost Packet list with their transmission
skipping to change at page 25, line 38 skipping to change at page 25, line 38
each system should cancel, if they are stationary. each system should cancel, if they are stationary.
In this test, X=1000ms and Y=1000ms. In this test, X=1000ms and Y=1000ms.
The common parameters used for tests in this section are: The common parameters used for tests in this section are:
o IP header + payload = 64 octets o IP header + payload = 64 octets
o Poisson sampling at lambda = 1 packet per second o Poisson sampling at lambda = 1 packet per second
o Test duration = 900 seconds total (March 21) o Test duration = 900 seconds total (March 21, 2011)
The netem emulator was set to add constant delays as specified in the The netem emulator was set to add constant delays as specified in the
procedure above. procedure above.
6.4.1. NetProbe results for Differential Delay 6.4.1. NetProbe results for Differential Delay
Average pre-increase delay, microseconds 1089868.0 Average pre-increase delay, microseconds 1089868.0
Average post 1s additional, microseconds 2089686.0 Average post 1s additional, microseconds 2089686.0
Difference (should be ~= Y = 1s) 999818.0 Difference (should be ~= Y = 1s) 999818.0
Average delays before/after 1 second increase Average delays before/after 1 second increase
The NetProbe implementation observed a 1 second increase with a 182 The NetProbe implementation observed a 1 second increase with a 182
microsecond error (assuming that the netem emulated delay difference microsecond error (assuming that the netem emulated delay difference
is exact). is exact).
We note that this differential delay test has been run under lab We note that this differential delay test has been run under lab
conditions and published in prior work [ref to "advance metrics" conditions and published in prior work
draft]. The error was 6 microseconds. [I-D.morton-ippm-advance-metrics]. The error was 6 microseconds.
6.4.2. Perfas+ results for Differential Delay 6.4.2. Perfas+ results for Differential Delay
Average pre-increase delay, microseconds 1089794.0 Average pre-increase delay, microseconds 1089794.0
Average post 1s additional, microseconds 2089801.0 Average post 1s additional, microseconds 2089801.0
Difference (should be ~= Y = 1s) 1000007.0 Difference (should be ~= Y = 1s) 1000007.0
Average delays before/after 1 second increase Average delays before/after 1 second increase
The Perfas+ implementation observed a 1 second increase with a 7 The Perfas+ implementation observed a 1 second increase with a 7
skipping to change at page 27, line 18 skipping to change at page 27, line 18
5.2. Type-P-One-way-Delay-Median yes no 5.2. Type-P-One-way-Delay-Median yes no
5.3. Type-P-One-way-Delay-Minimum yes yes 5.3. Type-P-One-way-Delay-Minimum yes yes
5.4. Type-P-One-way-Delay-Inverse-Percentile no no 5.4. Type-P-One-way-Delay-Inverse-Percentile no no
Implementation of Section 5 Statistics Implementation of Section 5 Statistics
Only the Type-P-One-way-Delay-Inverse-Percentile has been ignored in Only the Type-P-One-way-Delay-Inverse-Percentile has been ignored in
both implementations, so it is a candidate for removal in RFC2679bis. both implementations, so it is a candidate for removal or deprecation
in RFC2679bis (this small discrepancy does not affect candidacy for
advancement).
7. Security Considerations 7. Conclusions and RFC 2679 Errata
The conclusions throughout Section 6 support the advancement of
[RFC2679] to the next step of the standards track, because its
requirements are deemed to be clear and unambiguous based on
evaluation of the test results for two implementations. The results
indicate that these implementations produced statistically equivalent
results under network conditions that were configured to be as close
to identical as possible.
Sections 6.2.3 and 6.5 indicate areas where minor revisions are
warranted in RFC2679bis. The IETF has reached consensus on guidance
for reporting metrics in [RFC6703], and this memo should be
referenced in RFC2679bis to incorporate recent experience where
appropriate.
We note that there is currently one erratum with status "Held for
document update" for [RFC2679], and it appears this minor revision
and additional text should be incorporated in RFC2679bis.
8. Security Considerations
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and live networks are relevant here as well. See [RFC4656] and
[RFC5357]. [RFC5357].
8. IANA Considerations 9. IANA Considerations
This memo makes no requests of IANA, and hopes that IANA will welcome This memo makes no requests of IANA, and hopes that IANA will welcome
our new computer overlords as willingly as the authors. our new computer overlords as willingly as the authors.
9. Acknowledgements 10. Acknowledgements
The authors thank Lars Eggert for his continued encouragement to The authors thank Lars Eggert for his continued encouragement to
advance the IPPM metrics during his tenure as AD Advisor. advance the IPPM metrics during his tenure as AD Advisor.
Nicole Kowalski supplied the needed CPE router for the NetProbe side Nicole Kowalski supplied the needed CPE router for the NetProbe side
of the test set-up, and graciously managed her testing in spite of of the test set-up, and graciously managed her testing in spite of
issues caused by dual-use of the router. Thanks Nicole! issues caused by dual-use of the router. Thanks Nicole!
The "NetProbe Team" also acknowledges many useful discussions with The "NetProbe Team" also acknowledges many useful discussions with
Ganga Maguluri. Ganga Maguluri.
10. References 11. References
10.1. Normative References
11.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 1998. May 1998.
skipping to change at page 28, line 42 skipping to change at page 29, line 16
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation [RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, September 2009. Standard", BCP 9, RFC 5657, September 2009.
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
Performance Metrics (IPPM) Standard Advancement Testing", Performance Metrics (IPPM) Standard Advancement Testing",
BCP 176, RFC 6576, March 2012. BCP 176, RFC 6576, March 2012.
10.2. Informative References [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012.
11.2. Informative References
[ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling [ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling
Tests of fit, for continuous and discrete cases", Tests of fit, for continuous and discrete cases",
University of Washington, Technical Report No. 81, University of Washington, Technical Report No. 81,
May 1986. May 1986.
[Fedora14] [Fedora14]
"Fedora Project Home Page", http://fedoraproject.org/, "Fedora Project Home Page", http://fedoraproject.org/,
2012. 2012.
skipping to change at page 29, line 16 skipping to change at page 29, line 42
Bradner, S. and V. Paxson, "Advancement of metrics Bradner, S. and V. Paxson, "Advancement of metrics
specifications on the IETF Standards Track", specifications on the IETF Standards Track",
draft-bradner-metricstest-03 (work in progress), draft-bradner-metricstest-03 (work in progress),
August 2007. August 2007.
[I-D.morton-ippm-advance-metrics] [I-D.morton-ippm-advance-metrics]
Morton, A., "Lab Test Results for Advancing Metrics on the Morton, A., "Lab Test Results for Advancing Metrics on the
Standards Track", draft-morton-ippm-advance-metrics-02 Standards Track", draft-morton-ippm-advance-metrics-02
(work in progress), October 2010. (work in progress), October 2010.
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren",
published by ITG Fachgruppe, 2nd meeting 5.2.3 (NGN) http:
//www.itg523.de/oeffentlich/01nov/
Heidemann_QOS_Messverfahren.pdf , November 2001.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and [Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and
Combinations of Such Tests. R package version 1.0.", , Combinations of Such Tests. R package version 1.0.", ,
2008. 2008.
[Rtool] R Development Core Team, "R: A language and environment [Rtool] R Development Core Team, "R: A language and environment
for statistical computing. R Foundation for Statistical for statistical computing. R Foundation for Statistical
Computing, Vienna, Austria. ISBN 3-900051-07-0, URL Computing, Vienna, Austria. ISBN 3-900051-07-0, URL
 End of changes. 27 change blocks. 
73 lines changed or deleted 115 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/