draft-ietf-ippm-btc-framework-02.txt   draft-ietf-ippm-btc-framework-03.txt 
INTERNET-DRAFT Expires Apr. 2000 INTERNET-DRAFT INTERNET-DRAFT Expires May 2001 INTERNET-DRAFT
Network Working Group Matt Mathis Network Working Group Matt Mathis
INTERNET-DRAFT Pittsburgh Supercomputing Center INTERNET-DRAFT Pittsburgh Supercomputing Center
Expiration Date: Apr. 2000 Mark Allman Expiration Date: May 2001 Mark Allman
NASA Glenn/BBN NASA Glenn/BBN
October, 1999 November, 2000
Empirical Bulk Transfer Capacity Empirical Bulk Transfer Capacity
< draft-ietf-ippm-btc-framework-02.txt > < draft-ietf-ippm-btc-framework-03.txt >
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 58 skipping to change at line 58
formal tests for being a metric. formal tests for being a metric.
This document defines a framework for standardizing multiple BTC This document defines a framework for standardizing multiple BTC
metrics that parallel the permitted transport diversity. Two metrics that parallel the permitted transport diversity. Two
approaches are used. First, each BTC metric must be much more approaches are used. First, each BTC metric must be much more
tightly specified than the typical IETF protocol. Pseudo-code or tightly specified than the typical IETF protocol. Pseudo-code or
reference implementations are expected to be the norm. Second, each reference implementations are expected to be the norm. Second, each
BTC methodology is expected to collect some ancillary metrics which BTC methodology is expected to collect some ancillary metrics which
are potentially useful to support analytical models of BTC. are potentially useful to support analytical models of BTC.
1. Introduction 1 Introduction
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 [RFC2119]. Although document are to be interpreted as described in [RFC2119]. Although
[RFC2119] was written with protocols in mind, the key words are used [RFC2119] was written with protocols in mind, the key words are used
in this document for similar reasons. They are used to ensure that in this document for similar reasons. They are used to ensure that
each BTC methodology defined contains specific pieces of each BTC methodology defined contains specific pieces of
information. information.
Bulk Transport Capacity (BTC) is a measure of a network's ability to Bulk Transport Capacity (BTC) is a measure of a network's ability to
transfer significant quantities of data with a single transfer significant quantities of data with a single
congestion-aware transport connection (e.g., TCP). For many congestion-aware transport connection (e.g., TCP). For many
applications the BTC of the underlying network dominates the overall applications the BTC of the underlying network dominates the overall
elapsed time for the application to run and thus dominates the elapsed time for the application to run and thus dominates the
performance as perceived by a user. Examples of such applications performance as perceived by a user. Examples of such applications
include FTP, and the world wide web when delivering large images or include FTP, and the world wide web when delivering large images or
documents. The intuitive definition of BTC is the expected long documents. The intuitive definition of BTC is the expected long
term average data rate (bits per second) of a single ideal TCP term average data rate (bits per second) of a single ideal TCP
implementation over the path in question. implementation over the path in question. The specific definition
of the bulk transfer capacity that MUST be reported by a BTC tool is:
BTC = data_sent / elapsed_time
where ``data_sent'' represents the unique ``data'' bytes transfered
(i.e., not including header bytes or emulated header bytes). Also
note that the amount of data sent should only include the unique
number of bytes transmitted (i.e., if a particular packet is
retransmitted the data it contains should be counted only once).
Central to the notion of bulk transport capacity is the idea that Central to the notion of bulk transport capacity is the idea that
all transport protocols should have similar responses to congestion all transport protocols should have similar responses to congestion
in the Internet. Indeed the only form of equity significantly in the Internet. Indeed the only form of equity significantly
deployed in the Internet today is that the vast majority of all deployed in the Internet today is that the vast majority of all
traffic is carried by TCP implementations sharing common congestion traffic is carried by TCP implementations sharing common congestion
control algorithms largely due to a shared developmental heritage. control algorithms largely due to a shared developmental heritage.
[RFC2581] specifies the standard congestion control algorithms used [RFC2581] specifies the standard congestion control algorithms used
by TCP implementations. Even though this document is a (proposed) by TCP implementations. Even though this document is a (proposed)
skipping to change at line 113 skipping to change at line 122
We believe that such non-linearity reflects weakness in our current We believe that such non-linearity reflects weakness in our current
understanding of congestion control and is present to some extent in understanding of congestion control and is present to some extent in
all TCP implementations and BTC metrics. Note that such all TCP implementations and BTC metrics. Note that such
non-linearity (in either TCP or a BTC metric) is potentially non-linearity (in either TCP or a BTC metric) is potentially
problematic in the market because investment in capacity might problematic in the market because investment in capacity might
actually reduce the perceived quality of the network. Ongoing actually reduce the perceived quality of the network. Ongoing
research in congestion dynamics has some hope of mitigating or research in congestion dynamics has some hope of mitigating or
modeling the these non-linearities. modeling the these non-linearities.
Furthermore related areas, including Integrated services Related areas, including Integrated services
[RFC1633,RFC2216], differentiated services [RFC2475] and Internet [RFC1633,RFC2216], differentiated services [RFC2475] and Internet
traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently
receiving significant attention from the research community. It is receiving significant attention from the research community. It is
likely that we will see new experimental congestion control likely that we will see new experimental congestion control
algorithms in the near future. In addition, Explicit Congestion algorithms in the near future. In addition, Explicit Congestion
Notification (ECN) [RFC2481] is being tested for Internet Notification (ECN) [RFC2481] is being tested for Internet
deployment. We do not yet know how any of these developments might deployment. We do not yet know how any of these developments might
affect BTC metrics. affect BTC metrics, and thus the BTC framework and metrics may need
to be revisited in the future.
This document defines a framework for standardizing multiple BTC This document defines a framework for standardizing multiple BTC
metrics that parallel the permitted transport diversity. Two metrics that parallel the permitted transport diversity. Two
approaches are used. First, each BTC metric must be much more approaches are used. First, each BTC metric must be much more
tightly specified than the typical IETF transport protocol. tightly specified than the typical IETF transport protocol.
Pseudo-code or reference implementations are expected to be the Pseudo-code or reference implementations are expected to be the
norm. Second, each BTC methodology is expected to collect some norm. Second, each BTC methodology is expected to collect some
ancillary metrics which are potentially useful to support analytical ancillary metrics which are potentially useful to support analytical
models of BTC. If a BTC methodology does not collect these models of BTC. If a BTC methodology does not collect these
ancillary metrics, it should collect enough information such that ancillary metrics, it should collect enough information such that
skipping to change at line 162 skipping to change at line 172
These are difficult or impossible to measure at low rates and unsafe These are difficult or impossible to measure at low rates and unsafe
to measure at rates higher than the bulk transport capacity of the to measure at rates higher than the bulk transport capacity of the
path. path.
It is expected that at some point in the future there will exist an It is expected that at some point in the future there will exist an
A-frame [RFC2330] which will unify all simple path metrics (e.g., A-frame [RFC2330] which will unify all simple path metrics (e.g.,
segment loss rates, round trip time) and BTC ancillary metrics segment loss rates, round trip time) and BTC ancillary metrics
(e.g., queue size and packet reordering) with different versions of (e.g., queue size and packet reordering) with different versions of
BTC metrics (e.g., that parallel Reno or SACK TCP). BTC metrics (e.g., that parallel Reno or SACK TCP).
2. Congestion Control Algorithms 2 Congestion Control Algorithms
Nearly all TCP implementations in use today utilize the congestion Nearly all TCP implementations in use today utilize the congestion
control algorithms published in [Jac88] and further refined in control algorithms published in [Jac88] and further refined in
[RFC2581]. In addition to using the basic notion of using an ACK [RFC2581]. In addition to using the basic notion of using an ACK
clock, TCP (and therefore BTC) implements five standard congestion clock, TCP (and therefore BTC) implements five standard congestion
control algorithms: Congestion Avoidance, Retransmission timeouts, control algorithms: Congestion Avoidance, Retransmission timeouts,
Slow-start, Fast Retransmit and Fast Recovery. All BTC Slow-start, Fast Retransmit and Fast Recovery. All BTC
implementations MUST implement slow start and congestion avoidance, implementations MUST implement slow start and congestion avoidance,
as specified in [RFC2581] (with extra details also specified, as as specified in [RFC2581] (with extra details also specified, as
outlined below). All BTC methodologies SHOULD implement fast outlined below). All BTC methodologies SHOULD implement fast
skipping to change at line 200 skipping to change at line 210
* [RFC2581] allows TCPs to use advanced loss recovery mechanism * [RFC2581] allows TCPs to use advanced loss recovery mechanism
such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms
[FF96,MM96a,MM96b]. If used in a BTC implementation, such an [FF96,MM96a,MM96b]. If used in a BTC implementation, such an
algorithm MUST be fully defined. algorithm MUST be fully defined.
* The actual segment size, or method of choosing a segment size * The actual segment size, or method of choosing a segment size
(e.g., path MTU discovery [RFC1191]) and the number of header (e.g., path MTU discovery [RFC1191]) and the number of header
bytes assumed to be prepended to each segment MUST be specified. bytes assumed to be prepended to each segment MUST be specified.
In addition, if the segment size is artificially limited to less In addition, if the segment size is artificially limited to less
than the path MTU this MUST be indicated (if known). than the path MTU this MUST be indicated.
* TCP includes a retransmission timeout (RTO) to trigger * TCP includes a retransmission timeout (RTO) to trigger
retransmissions of segments that have not been acknowledged retransmissions of segments that have not been acknowledged
within an appropriate amount of time and have not been within an appropriate amount of time and have not been
retransmitted via some more advanced loss recovery algorithm. A retransmitted via some more advanced loss recovery algorithm. A
BTC implementation MUST include a retransmission timer. BTC implementation MUST include a retransmission timer.
Calculating the RTO is subject to a number of details that MUST Calculating the RTO is subject to a number of details that MUST
be defined for each BTC metric. In addition, a BTC metric MUST be defined for each BTC metric. In addition, a BTC metric MUST
define when the clock is set and the granularity of the clock. define when the clock is set and the granularity of the clock.
Note [WS95] outlines a popular implementation of the [RFC2988] specifies the behavior of the retransmission timer.
retransmission timer. Also, a specification for the behavior of However, there are several details left to the implementer which
the retransmission timer is currently being written for TCP MUST be specified for each BTC metric defined.
[PA99]. If adopted this specification would apply to BTC
implementation, as well. ## Likewise, I envision [ABF00] making it to RFC before or around the
## time this is published as an RFC.
##
Note that as new congestion control algorithms are placed on the
standards track they may be incorporated into BTC metrics (e.g., the
Limited Transmit algorithm [ABF00]). However, any implementation
decisions provided by the relevant RFCs should be fully specified in
the particular BTC metric.
3 Ancillary Metrics 3 Ancillary Metrics
The following ancillary metrics can provide additional information The following ancillary metrics can provide additional information
about the network and the behavior of the implemented congestion about the network and the behavior of the implemented congestion
control algorithms in response to the behavior of the network path. control algorithms in response to the behavior of the network path.
It is RECOMMENDED that these metrics be built into each BTC It is RECOMMENDED that these metrics be built into each BTC
methodology. Alternatively, it is RECOMMENDED that the BTC methodology. Alternatively, it is RECOMMENDED that the BTC
implementation provide enough information such that the ancillary implementation provide enough information such that the ancillary
metrics can be derived via post-processing (e.g., by providing a metrics can be derived via post-processing (e.g., by providing a
skipping to change at line 243 skipping to change at line 260
Retransmission Timeout and Slow-Start algorithms are not invoked. Retransmission Timeout and Slow-Start algorithms are not invoked.
The CAC metric is defined to have no meaning across Retransmission The CAC metric is defined to have no meaning across Retransmission
Timeouts or Slow-Start periods (except the single segment Slow-Start Timeouts or Slow-Start periods (except the single segment Slow-Start
that is permitted to follow recovery, as discussed in section 2.3). that is permitted to follow recovery, as discussed in section 2.3).
In principle a CAC metric would be an ideal BTC metric, as it In principle a CAC metric would be an ideal BTC metric, as it
captures what should be TCP's steady state behavior. But, there is captures what should be TCP's steady state behavior. But, there is
a rather substantial difficulty with using it as such. The a rather substantial difficulty with using it as such. The
Self-Clocking of the Congestion Avoidance algorithm can be very Self-Clocking of the Congestion Avoidance algorithm can be very
fragile, depending on the specific details of the Fast Retransmit, fragile, depending on the specific details of the Fast Retransmit,
Fast Recovery or advanced recovery algorithms above. It has been Fast Recovery or advanced recovery algorithms chosen. It has been
found that timeouts and periods of slow start loss recovery are found that timeouts and periods of slow start loss recovery are
prevalent in traffic on the Internet [LK98] and therefore these prevalent in traffic on the Internet [LK98,BPS+97] and therefore these
should be captured by the BTC metric. should be captured by the BTC metric.
When TCP loses Self-Clock it is re-established through a When TCP loses Self-Clock it is re-established through a
retransmission timeout and Slow-Start. These algorithms nearly retransmission timeout and Slow-Start. These algorithms nearly
always require more time than Congestion Avoidance would have taken. always require more time than Congestion Avoidance would have taken.
It is easily observed that unless the network loses an entire window It is easily observed that unless the network loses an entire window
of data (which would clearly require a retransmit timeout) TCP of data (which would clearly require a retransmit timeout) TCP
missed some opportunity to safely transmit data. That is, if TCP likely missed some opportunity to safely transmit data. That is, if TCP
experiences a timeout after losing a partial window of data, it must experiences a timeout after losing a partial window of data, it must
have received at least one ACK that was generated after some of the have received at least one ACK that was generated after some of the
partial data was delivered, but did not trigger the transmission of partial data was delivered, but did not trigger the transmission of
new data. Recent research in congestion control (e.g., FACK new data. Recent research in congestion control (e.g., FACK
[MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be
characterized as making TCP's Self-Clock more tenacious, while characterized as making TCP's Self-Clock more tenacious, while
preserving fairness under adverse conditions. This work is preserving fairness under adverse conditions. This work is
motivated by how poorly current TCP implementations perform under motivated by how poorly current TCP implementations perform under
some conditions, often due to repeated clock loss. Since this is an some conditions, often due to repeated clock loss. Since this is an
active research area, different TCP implementations have rather active research area, different TCP implementations have rather
skipping to change at line 341 skipping to change at line 358
of RTT duration outages, these can be impossible to diagnose at low of RTT duration outages, these can be impossible to diagnose at low
rates (less than 1 packet per RTT) and inappropriate to test at rates (less than 1 packet per RTT) and inappropriate to test at
rates above the BTC of the network path. rates above the BTC of the network path.
All BTC metrics SHOULD instrument packet reordering. The frequency All BTC metrics SHOULD instrument packet reordering. The frequency
and distance out-of-sequence SHOULD be instrumented for all and distance out-of-sequence SHOULD be instrumented for all
out-of-order packets. The severity of the reordering can be out-of-order packets. The severity of the reordering can be
classified as one of three different cases, each of which SHOULD be classified as one of three different cases, each of which SHOULD be
reported. reported.
Packets that are only slightly out-of-order should not trigger Segments that are only slightly out-of-order should not trigger
the fast retransmit algorithm, but they may affect the window the fast retransmit algorithm, but they may affect the window
calculation. BTC metrics SHOULD document how slightly calculation. BTC metrics SHOULD document how slightly
out-of-order packets affect the congestion window calculation. out-of-order segments affect the congestion window calculation.
If packets are sufficiently out-of-order, the Fast Retransmit If segments are sufficiently out-of-order, the Fast Retransmit
algorithm will be invoked in advance of the delayed packet's algorithm will be invoked in advance of the delayed packet's
late arrival. These events SHOULD be instrumented. Even though late arrival. These events SHOULD be instrumented. Even though
the the late arriving packet will complete recovery, the the the the late arriving packet will complete recovery, the the
window will still be reduced by half. window will still be reduced by half.
Under some rare conditions packets have been observed that are Under some rare conditions segments have been observed that are
far out of order - sometimes many seconds late [Pax97b]. These far out of order - sometimes many seconds late [Pax97b]. These
SHOULD always be instrumented. SHOULD always be instrumented.
BTC implementations SHOULD instrument the maximum cwnd observed BTC implementations SHOULD instrument the maximum cwnd observed
during congestion avoidance and slow start. A TCP running over the during congestion avoidance and slow start. A TCP running over the
same path as the BTC metric must have sufficient sender buffer space same path as the BTC metric must have sufficient sender buffer space
and receiver window (and window shift [RFC1323]) to cover this cwnd and receiver window (and window shift [RFC1323]) to cover this cwnd
in order to expect the same performance. in order to expect the same performance.
There are several other path properties that one might measure There are several other path properties that one might measure
skipping to change at line 398 skipping to change at line 415
3.6 Validate Reverse Path Load 3.6 Validate Reverse Path Load
To the extent possible, the BTC metric SHOULD distinguish between To the extent possible, the BTC metric SHOULD distinguish between
the properties of the forward and reverse paths. the properties of the forward and reverse paths.
BTC methodologies which rely on non-cooperating receivers may only BTC methodologies which rely on non-cooperating receivers may only
be able to measure round trip path properties and may not be able to be able to measure round trip path properties and may not be able to
independently differentiate between the properties of the forward independently differentiate between the properties of the forward
and reverse paths. In this case the load on the reverse path and reverse paths. In this case the load on the reverse path
contributed by the BTC metric SHOULD be instrumented (or computed) contributed by the BTC metric SHOULD be instrumented (or computed)
to permit other means of gage the proportion of the round trip path to permit other means of gauge the proportion of the round trip path
properties attributed to the the forward and reverse paths. properties attributed to the the forward and reverse paths.
To the extent possible, BTC methodologies that rely on cooperating To the extent possible, BTC methodologies that rely on cooperating
receivers SHOULD support separate ancillary metrics for the forward receivers SHOULD support separate ancillary metrics for the forward
and reverse paths. and reverse paths.
4 Acknowledgments 4 Security Considerations
The framework for specifying BTC metrics outlined in this document
does not pose any threat to Internet security. The BTC metrics
defined based on this specification will be as ``network friendly''
as current TCP connections.
5 Acknowledgments
Thanks to Jeff Semke for numerous clarifications. Thanks to Jeff Semke for numerous clarifications.
5 References 6 References
[ABF00] Mark Allman, Hari Balakrishnan, Sally Floyd. Enhancing
TCP's Loss Recovery Using Limited Transmit, August
2000. Internet-Draft draft-ietf-tsvwg-limited-xmit-00.txt (work
in progress).
[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan,
Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server:
Analysis and Improvements. Technical Report UCB/CSD-97-966,
August 1997. Available from
http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in
Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.)
[FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe,
Reno and SACK TCP". Computer Communication Review, July 1996. Reno and SACK TCP". Computer Communication Review, July 1996.
ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[Flo95] Floyd, S., "TCP and successive fast retransmits", March [Flo95] Floyd, S., "TCP and successive fast retransmits", March
1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Hoe96] Hoe, J., "Improving the start-up behavior of a congestion [Hoe96] Hoe, J., "Improving the start-up behavior of a congestion
control scheme for TCP, Proceedings of ACM SIGCOMM '96, August control scheme for TCP, Proceedings of ACM SIGCOMM '96, August
skipping to change at line 474 skipping to change at line 510
[OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary
Behavior of Ideal TCP Congestion Avoidance", In progress, August Behavior of Ideal TCP Congestion Avoidance", In progress, August
1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to
ftp.bellcore.com ftp.bellcore.com
[OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior
in TCP/IP with Constant Loss Probability", DIMACS Special Year in TCP/IP with Constant Loss Probability", DIMACS Special Year
on Networks, Workshop on Performance of Real-Time Applications on Networks, Workshop on Performance of Real-Time Applications
on the Internet, Nov 1996. on the Internet, Nov 1996.
[PA99] Paxson, V., Allman, M., "Computing TCP's Retransmission
Timer", October 1999. Internet-Draft draft-paxson-tcp-rto-00.txt
(work in progress).
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP
Implementations", Proceedings of ACM SIGCOMM '97, August 1997. Implementations", Proceedings of ACM SIGCOMM '97, August 1997.
[Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics,"
Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP
Throughput: A Simple Model and its Empirical Validation", Throughput: A Simple Model and its Empirical Validation",
Proceedings of ACM SIGCOMM '98, August 1998. Proceedings of ACM SIGCOMM '98, August 1998.
skipping to change at line 540 skipping to change at line 572
Implementation Problems", 1999, Obtain via: Implementation Problems", 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2525.txt ftp://ds.internic.net/rfc/rfc2525.txt
[RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion
Control"., 1999, Obtain via: Control"., 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2581.txt ftp://ds.internic.net/rfc/rfc2581.txt
[RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to
TCP's Fast Recovery Algorithm", 1999, Obtain via: TCP's Fast Recovery Algorithm", 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2582.txt ftp://ds.internic.net/rfc/rfc2582.txt
[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission
Timer", November 2000, Obtain via:
ftp://ds.internic.net/rfc/rfc2988.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, 1994. Addison-Wesley, 1994.
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The
Implementation", Addison-Wesley, 1995. Implementation", Addison-Wesley, 1995.
Author's Addresses Author's Addresses
Matt Mathis Matt Mathis
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/