draft-ietf-ippm-rt-loss-00.txt   draft-ietf-ippm-rt-loss-01.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track February 14, 2011 Intended status: Standards Track July 8, 2011
Expires: August 18, 2011 Expires: January 9, 2012
Round-trip Loss Metrics Round-trip Loss Metrics
draft-ietf-ippm-rt-loss-00 draft-ietf-ippm-rt-loss-01
Abstract Abstract
Many user applications (and the transport protocols that make them Many user applications (and the transport protocols that make them
possible) require two-way communications. To assess this capability, possible) require two-way communications. To assess this capability,
and to achieve test system simplicity, round-trip loss measurements and to achieve test system simplicity, round-trip loss measurements
are frequently conducted in practice. The Two-Way Active Measurement are frequently conducted in practice. The Two-Way Active Measurement
Protocol specified in RFC 5357 establishes a round-trip loss Protocol specified in RFC 5357 establishes a round-trip loss
measurement capability for the Internet. However, there is currently measurement capability for the Internet. However, there is currently
no metric specified according to the RFC 2330 framework. no metric specified according to the RFC 2330 framework.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 18, 2011. This Internet-Draft will expire on January 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 5 4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 5
4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 5 4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 5
4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6
4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6 4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6
4.4. Discussion and other details . . . . . . . . . . . . . . . 7 4.4. Discussion and other details . . . . . . . . . . . . . . . 7
5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7 5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream . . . . . . . 7 5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream . . . . . . . 7
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7
5.3. Definition and Metric Units . . . . . . . . . . . . . . . 7 5.3. Definition and Metric Units . . . . . . . . . . . . . . . 7
5.4. Discussion and other details . . . . . . . . . . . . . . . 8 5.4. Discussion and other details . . . . . . . . . . . . . . . 8
6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 8 6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio . . . . . . . . . . 9 6.1. Type-P-Round-trip-Loss-<Sample>-Ratio . . . . . . . . . . 9
7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9 7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Measurement Considerations and Calibration . . . . . . . . . . 10
8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 10 9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10
8.3. Interference with the metrics . . . . . . . . . . . . . . 10 9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9.3. Interference with the metrics . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This memo defines a metric for round-trip loss on Internet paths. It This memo defines a metric for round-trip loss on Internet paths. It
builds on the notions and conventions introduced in the IP builds on the notions and conventions introduced in the IP
Performance Metrics (IPPM) framework [RFC2330]. Also, the Performance Metrics (IPPM) framework [RFC2330]. Also, the
specifications of the One-way Loss metric [RFC2680] and the Round- specifications of the One-way Loss metric [RFC2680] and the Round-
trip Delay metric [RFC2681] are frequently referenced and modified to trip Delay metric [RFC2681] are frequently referenced and modified to
match the round-trip circumstances addressed here. However, this match the round-trip circumstances addressed here. However, this
memo assumes that the reader is familiar with the references, and memo assumes that the reader is familiar with the references, and
skipping to change at page 3, line 32 skipping to change at page 3, line 32
<-SYN-ACK, ACK-> three-way handshake attempted billions of times each <-SYN-ACK, ACK-> three-way handshake attempted billions of times each
day cannot be completed without two-way connectivity in a near- day cannot be completed without two-way connectivity in a near-
simultaneous time interval. Thus, measurements of Internet round- simultaneous time interval. Thus, measurements of Internet round-
trip loss performance provide a basis to infer application trip loss performance provide a basis to infer application
performance more easily. performance more easily.
Measurement system designers have also recognized advantages of Measurement system designers have also recognized advantages of
system simplicity when one host simply echoes or reflects test system simplicity when one host simply echoes or reflects test
packets to the sender. Round-trip loss measurements are frequently packets to the sender. Round-trip loss measurements are frequently
conducted and reported in practice. The Two-Way Active Measurement conducted and reported in practice. The Two-Way Active Measurement
Protocol specified in [RFC5357] establishes a round-trip loss Protocol (TWAMP) specified in [RFC5357] establishes a round-trip loss
measurement capability for the Internet. However, there is currently measurement capability for the Internet. However, there is currently
no round-trip loss metric specified according to the [RFC2330] no round-trip loss metric specified according to the [RFC2330]
framework. framework.
[RFC2681] indicates that round-trip measurements may sometimes [RFC2681] indicates that round-trip measurements may sometimes
encounter "asymmetric" paths. When loss is observed using a round- encounter "asymmetric" paths. When loss is observed using a round-
trip measurement, there is often a desire to ascertain which of the trip measurement, there is often a desire to ascertain which of the
two directional paths "lost" the packet. Under some circumstances, two directional paths "lost" the packet. Under some circumstances,
it is possible to make this inference. The round-trip measurement it is possible to make this inference. The round-trip measurement
method raises a few complications when interpreting the embedded one- method raises a few complications when interpreting the embedded one-
way results, and the user should be aware of them. way results, and the user should be aware of them.
[RFC2681] also points out that loss measurement conducted [RFC2681] also points out that loss measurement conducted
sequentially in both directions of a path and reported as a round- sequentially in both directions of a path and reported as a round-
trip result may be exactly the desired metric. On the other hand, it trip result may be exactly the desired metric. On the other hand, it
may be difficult to derive the state of round-trip loss from one-way may be difficult to derive the state of round-trip loss from one-way
measurements conducted in each direction unless a method to match the measurements conducted in each direction unless a method to match the
appropriate one-way measurements has pre-arranged. appropriate one-way measurements has been pre-arranged.
Finally, many measurement systems report statistics on a conditional Finally, many measurement systems report statistics on a conditional
delay distribution, where the condition is packet arrival at the delay distribution, where the condition is packet arrival at the
destination. This condition is encouraged in [RFC3393], [RFC5481], destination. This condition is encouraged in [RFC3393], [RFC5481],
and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets
need to be reported separately, according to a standardized metric. need to be reported separately, according to a standardized metric.
This memo defines such a metric. This memo defines such a metric.
See Section 1.1 of[RFC2680] for additional motivation of the packet See Section 1.1 of[RFC2680] for additional motivation of the packet
loss metric. loss metric.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Type-P-Round-trip-Loss SHALL be represented by the binary logical Type-P-Round-trip-Loss SHALL be represented by the binary logical
values (or their equivalents) when the following conditions are met: values (or their equivalents) when the following conditions are met:
Type-P-Round-trip-Loss = 0: Type-P-Round-trip-Loss = 0:
o Src sent the first bit of a Type-P packet to Dst at wire-time o Src sent the first bit of a Type-P packet to Dst at wire-time
TstampSrc, TstampSrc,
o that Dst received that packet, o that Dst received that packet,
o the Dst immediately sent a Type-P packet back to the Src, and o the Dst sent a Type-P packet back to the Src as immediately as
possible, and
o that Src received the last bit of the reflected packet at wire- o that Src received the last bit of the reflected packet prior to
time TstampSrc + Tmax. wire-time TstampSrc + Tmax.
Type-P-Round-trip-Loss = 1: Type-P-Round-trip-Loss = 1:
o Src sent the first bit of a Type-P packet to Dst at wire-time o Src sent the first bit of a Type-P packet to Dst at wire-time
TstampSrc, TstampSrc,
o that Src did not receive the last bit of the reflected packet o that Src did not receive the last bit of the reflected packet
before the waiting time lapsed at TstampSrc + Tmax before the waiting time lapsed at TstampSrc + Tmax.
o (possibly because that Dst did not receive that packet, Possible causes for the Loss = 1 outcome are:
o the Dst did not immediately sent a Type-P packet back to the Src, o the Dst did not receive that packet,
or
o the Dst did not send a Type-P packet back to the Src, or
o the Src did not receive a reflected Type-P packet sent from the o the Src did not receive a reflected Type-P packet sent from the
Dst). Dst.
Following the precedent of[RFC2681], we make the simplifying Following the precedent of[RFC2681], we make the simplifying
assertion: assertion:
Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src) Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src)
(and agree with the rationale presented, that the ambiguity (and agree with the rationale presented there, that the ambiguity
introduced is a small price to pay for measurement efficiency). introduced is a small price to pay for measurement efficiency).
Therefore, each singleton can be represented by pairs of elements as Therefore, each singleton can be represented by pairs of elements as
follows: follows:
o TstampSrc, the wire time of the packet at the Src (beginning the o TstampSrc, the wire time of the packet at the Src (beginning the
round-trip journey). round-trip journey).
o L, either zero or one (or some logical equivalent), where L=1 o L, either zero or one (or some logical equivalent), where L=1
indicates loss and L=0 indicates successful round-trip arrival indicates loss and L=0 indicates successful round-trip arrival
skipping to change at page 8, line 45 skipping to change at page 8, line 46
for packets, and avoid prematurely declaring round-trip loss when for packets, and avoid prematurely declaring round-trip loss when
a sequence gap or error is observed. a sequence gap or error is observed.
2. The time distribution of the singletons in the sample has been 2. The time distribution of the singletons in the sample has been
significantly changed. significantly changed.
3. Either the original packet stream or the reflected packet stream 3. Either the original packet stream or the reflected packet stream
experienced path instability, and the original conditions may no experienced path instability, and the original conditions may no
longer be present. longer be present.
Measurement implementations SHOULD address the possibility for packet Measurement implementations MUST address the possibility for packet
reordering and avoid related errors in their processes. reordering and avoid related errors in their processes.
6. Round-trip Loss Statistic 6. Round-trip Loss Statistic
This section gives the primary and overall statistic for loss This section gives the primary and overall statistic for loss
performance. Additional statistics and metrics originally prepared performance. Additional statistics and metrics originally prepared
for One-way loss MAY also be applicable. for One-way loss MAY also be applicable.
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio 6.1. Type-P-Round-trip-Loss-<Sample>-Ratio
Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of all Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of all
the logical values, L, in the Stream is the Type-P-Round-trip-Loss- the logical values, L, in the Stream is the Type-P-Round-trip-Loss-
<Sample>-Ratio. This ratio is in units of lost packets per round- <Sample>-Ratio. This ratio is in units of lost packets per round-
trip transmissions attempted. trip transmissions actually attempted.
In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined
if the sample is empty. if the sample is empty.
7. Round-trip Testing and One-way Reporting 7. Round-trip Testing and One-way Reporting
This section raises considerations for results collected using a This section raises considerations for results collected using a
round-trip measurement architecture, such as in TWAMP [RFC5357]. round-trip measurement architecture, such as in TWAMP [RFC5357].
The sampling process for the return path (Dst->Src) is a conditional The sampling process for the reverse path (Dst->Src) is a conditional
process that depends on successful packet arrival at the Dst and process that depends on successful packet arrival at the Dst and
correct operation at the Dst to generate the reflected packet. correct operation at the Dst to generate the reflected packet.
Therefore, the sampling process for the return path will be Therefore, the sampling process for the reverse path will be
significantly affected when appreciable loss occurs on the Src->Dst significantly affected when appreciable loss occurs on the Src->Dst
path, making an attempt to assess the return path performance invalid path, making an attempt to assess the reverse path performance
(for loss or possibly any metric). invalid (for loss or possibly any metric).
Further, the sampling times for the return path (Dst->Src) are a Further, the sampling times for the reverse path (Dst->Src) are a
random process that depends on the original sample times (TstampSrc), random process that depends on the original sample times (TstampSrc),
the one-way-delay for successful packet arrival at the Dst, and time the one-way-delay for successful packet arrival at the Dst, and time
taken at the Dst to generate the reflected packet. Therefore, the taken at the Dst to generate the reflected packet. Therefore, the
sampling process for the return path will be significantly affected sampling process for the reverse path will be significantly affected
when appreciable delay variation occurs on the Src->Dst path, making when appreciable delay variation occurs on the Src->Dst path, making
an attempt to assess the return path performance invalid (for loss or an attempt to assess the reverse path performance invalid (for loss
possibly any metric). or possibly any metric).
As discussed above, packet reordering is always a possibility. In As discussed above, packet reordering is always a possibility. In
addition to the severe delay variation that usually accompanies it, addition to the severe delay variation that usually accompanies it,
reordering on the Src->Dst path will cause a mis-alignment of reordering on the Src->Dst path will cause a mis-alignment of
sequence numbers applied at the reflector when compared to the sender sequence numbers applied at the reflector when compared to the sender
numbers. Measurement implementations SHOULD address this possible numbers. Measurement implementations SHOULD address this possible
outcome. outcome.
8. Security Considerations 8. Measurement Considerations and Calibration
8.1. Denial of Service Attacks
Prior to conducting this measurement, the participating hosts MUST be
configured to send and receive test packets of the chosen Type-P.
Standard measurement protocols are capable of this task [RFC5357],
but any reliable method is sufficient.
Two key features of the host that receives test packets and returns
them to the originating host is described in section 4.2 of [RFC5357]
. Every received test packet MUST result in a responding packet, and
the response MUST be generated as immediately as possible. This
implies that interface buffers will be serviced promptly, and that
buffer discards will be extremely rare. These features of the
measurement equipment MUST be calibrated according to Section 3.7.3
of [RFC2679], when operating under a representative measurement load
(as defined by the user). Both unexpected test packet discards and
the systematic and random errors and uncertainties MUST be recorded.
We note that Section 4.2.1 of [RFC5357] specifies a method to collect
all four significant time-stamps needed to describe a packet's round-
trip delay [RFC2681] and remove the processing time incurred at the
responding host. This information supports the measurement of the
corresponding One-way Delays encountered on the round-trip path,
which can identify path asymmetry or unexpected processing time at
the responding host.
9. Security Considerations
9.1. Denial of Service Attacks
This metric requires a stream of packets sent from one host (source) This metric requires a stream of packets sent from one host (source)
to another host (destination) through intervening networks, and back. to another host (destination) through intervening networks, and back.
This method could be abused for denial of service attacks directed at This method could be abused for denial of service attacks directed at
the destination and/or the intervening network(s). the destination and/or the intervening network(s).
Administrators of source, destination, and the intervening network(s) Administrators of source, destination, and the intervening network(s)
should establish bilateral or multi-lateral agreements regarding the should establish bilateral or multi-lateral agreements regarding the
timing, size, and frequency of collection of sample metrics. Use of timing, size, and frequency of collection of sample metrics. Use of
this method in excess of the terms agreed between the participants this method in excess of the terms agreed between the participants
may be cause for immediate rejection or discard of packets or other may be cause for immediate rejection or discard of packets or other
escalation procedures defined between the affected parties. escalation procedures defined between the affected parties.
8.2. User Data Confidentiality 9.2. User Data Confidentiality
Active use of this method generates packets for a sample, rather than Active use of this method generates packets for a sample, rather than
taking samples based on user data, and does not threaten user data taking samples based on user data, and does not threaten user data
confidentiality. Passive measurement must restrict attention to the confidentiality. Passive measurement must restrict attention to the
headers of interest. Since user payloads may be temporarily stored headers of interest. Since user payloads may be temporarily stored
for length analysis, suitable precautions MUST be taken to keep this for length analysis, suitable precautions MUST be taken to keep this
information safe and confidential. In most cases, a hashing function information safe and confidential. In most cases, a hashing function
will produce a value suitable for payload comparisons. will produce a value suitable for payload comparisons.
8.3. Interference with the metrics 9.3. Interference with the metrics
It may be possible to identify that a certain packet or stream of It may be possible to identify that a certain packet or stream of
packets is part of a sample. With that knowledge at the destination packets is part of a sample. With that knowledge at the destination
and/or the intervening networks, it is possible to change the and/or the intervening networks, it is possible to change the
processing of the packets (e.g. increasing or decreasing delay) that processing of the packets (e.g. increasing or decreasing delay) that
may distort the measured performance. It may also be possible to may distort the measured performance. It may also be possible to
generate additional packets that appear to be part of the sample generate additional packets that appear to be part of the sample
metric. These additional packets are likely to perturb the results metric. These additional packets are likely to perturb the results
of the sample measurement. of the sample measurement.
To discourage the kind of interference mentioned above, packet To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used. interference checks, such as cryptographic hash, may be used.
9. IANA Considerations 10. IANA Considerations
Metrics defined in IETF are typically registered in the IANA IPPM Metrics defined in IETF are typically registered in the IANA IPPM
METRICS REGISTRY as described in initial version of the registry METRICS REGISTRY as described in initial version of the registry
[RFC4148]. However, areas for improvement of this registry have been [RFC4148]. However, areas for improvement of this registry have been
identified, and the registry structure has to be revisited when there identified, and the registry structure has to be revisited when there
is consensus to do so. is consensus to do so.
Therefore, the metrics in this draft may be considered for Therefore, the metrics in this draft may be considered for
registration in the future, and no IANA Action is requested at this registration in the future, and no IANA Action is requested at this
time. time.
10. Acknowledgements 11. Acknowledgements
11. References The author thanks Tiziano Ionta for his careful review of this memo,
primarily resulting in the development of measurement considerations
using TWAMP [RFC5357] as an example method.
11.1. Normative References 12. References
12.1. Normative References
[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.
[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.
skipping to change at page 12, line 5 skipping to change at page 12, line 38
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010. Composition", RFC 5835, April 2010.
11.2. Informative References 12.2. Informative References
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009. Selection and Reporting", RFC 5474, March 2009.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009. Applicability Statement", RFC 5481, March 2009.
[Stats] McGraw-Hill NY NY, "Introduction to the Theory of [Stats] McGraw-Hill NY NY, "Introduction to the Theory of
Statistics, 3rd Edition,", 1974. Statistics, 3rd Edition,", 1974.
 End of changes. 30 change blocks. 
45 lines changed or deleted 79 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/