draft-ietf-rtfm-new-traffic-flow-00.txt   draft-ietf-rtfm-new-traffic-flow-01.txt 
Real Time Flow Measurement Working Group S.W. Handelman Real Time Flow Measurement Working Group S.W. Handelman
Internet-draft IBM Internet-draft IBM
Expire in six months Hawthorne, NY USA Hawthorne, NY USA
N. Brownlee N. Brownlee
U of Auckland, NZ U of Auckland, NZ
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Waltham, MA USA Waltham, MA USA
November, 1996 March 25, 1997
expires
September 25, 1997
Real Time Flow Measurement Working Group - New Attributes for Real Time Flow Measurement Working Group - New Attributes for
Traffic Flow Measurement Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-00.txt> draft-ietf-rtfm-new-traffic-flow-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents months, and may be updated, replaced, or obsoleted by other documents
skipping to change at page 1, line 46 skipping to change at page 2, line 8
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of does not specify an Internet standard of any kind. Distribution of
this memo is unlimited. this memo is unlimited.
2.1 Introduction 2.1 Introduction
The Real-time Traffic Flow Measurement (RTFM) working group has The Real-time Traffic Flow Measurement (RTFM) working group has
developed a rudimentary system for measuring and reporting developed a system for measuring and reporting information about
information about traffic flows in the Internet. This document traffic flows in the Internet. This document explores the definition
explores the definition of extensions to the concepts of flow of extensions to the flow measurements as currently defined in [1]
measurements as currently defined in RFC 1272 and [1]. and [5]. The new attributes described in this document will be
useful for monitoring network performance and expand the scope of
RTFM beyond traffic measurement. Performance attributes typically
deal with throughput, packet loss, and delays. We will explore the
methods in which RTFM can extract values from flows which measure
these attributes. We will also look at capturing information on
jitter and congestion control.
The RTFM Working Group has defined the concept of a standardized The RTFM Working Group has defined the concept of a standardized
meter which records flows from a traffic stream according to a Rule meter which records flows from a traffic stream according to Rule
Set that is active in the meter[1]. Implementations of this meter Sets which are active in the meter[1].
have been done by Nevil Brownlee in the University of Auckland, NZ, Implementations of this meter have been done by Nevil Brownlee in
and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA. the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
The meter implementations measure flows by marking them with time at IBM in Hawthorne, NY, USA. The RTFM WG has also discussed the
stamps, recording total traffic in bytes and packets. In general one Meter Reader Program whose job is to fetch the completed group of
may say that the meter finds the existence of flows, and records the flows active in the Meter.
traffic in each flow. The RTFM WG has also discussed the Collector
Program whose job is to fetch the completed group of flows active in
the Meter.
2.1 RTFM's Definition of Flows 2.1.1 RTFM's Definition of Flows
The RTFM Meter architecture views a flow as a set of packets between The RTFM Meter architecture views a flow as a set of packets between
two end-points (as defined by their source and destination attribute two end-points (as defined by their source and destination attribute
values), and as BI-DIRECTIONAL (i.e. the meter effectively monitors values), and as BI-DIRECTIONAL (i.e. the meter effectively monitors
two sub-flows, one in each direction). two sub-flows, one in each direction).
Reasons why RTFM flows are bi-directional: Reasons why RTFM flows are bi-directional:
- We are interested in understanding the behavior of sessions between - We are interested in understanding the behavior of sessions between
end-points. end-points.
- We want to perform as much data reduction as possible, so as to - We want to perform as much data reduction as possible, so as to
reduce the amount of data to be retrieved from a remote meter. reduce the amount of data to be retrieved from a remote meter.
- The end-point attribute values (the "Address" and "Type" ones) are - The endpoint attribute values (the "Address" and "Type" ones) are
the same for both directions; storing them in bi-directional flows the same for both directions; storing them in bi-directional flows
reduces the meter's memory demands. reduces the meter's memory demands.
2.2 RTFM's Current Definition of Network Flows and their Attributes 2.2 RTFM's Current Definition of Flows and their Attributes
Flows, as described in the "Architecture" I-D have the following Flows, as described in the "Architecture" I-D have the following
properties: properties:
a. They occur between two end-points, specified as sets of attribute a. They occur between two endpoints, specified as sets of attribute
values in the meter's current rule set. A flow is completely values in the meter's current rule set. A flow is completely
identified by its set of end-point attribute values. identified by its set of endpoint attribute values.
b. Each flow may also have values for "computed" attributes (Class b. Each flow may also have values for "computed" attributes (Class
and Kind). These are directly derived from the end-point attribute and Kind). These are directly derived from the endpoint attribute
values. values.
c. A new flow comes into being when the a packet is seen which is not c. A new flow comes into being when the a packet is seen which is not
classified by the Rule Set into an existing flow. The meter records classified by the Rule Set into an existing flow. The meter records
the time when this new flow is created. the time when this new flow is created.
d. Attribute values in (a), (b) and (c) are set when the meter sees d. Attribute values in (a), (b) and (c) are set when the meter sees
the first packet for the flow, and are never changed. the first packet for the flow, and are never changed.
e. Each flow has a "LastTime" attribute, which indicates the time the e. Each flow has a "LastTime" attribute, which indicates the time the
skipping to change at page 3, line 43 skipping to change at page 4, line 5
At the June, 1996 meeting of the RTFM WG, in Montreal, Canada, a At the June, 1996 meeting of the RTFM WG, in Montreal, Canada, a
proposal was put forth to extend the work of the group to produce an proposal was put forth to extend the work of the group to produce an
Internet Draft "New Attributes for Traffic Flow Measurement". That Internet Draft "New Attributes for Traffic Flow Measurement". That
proposal has brought forth this document. The goal of this work is to proposal has brought forth this document. The goal of this work is to
produce a simple set of abstractions, which can be easily implemented produce a simple set of abstractions, which can be easily implemented
and at the same time enhance the value of RTFM meters. This document and at the same time enhance the value of RTFM meters. This document
also defines a method for organizing the flow abstractions to also defines a method for organizing the flow abstractions to
preserve the existing RTFM flow table. preserve the existing RTFM flow table.
At the December, 1996 meeting of the RTFM WG and at a joint meeting
of the RTFM and IPPM working groups the concepts of this document
were discussed. The suggestions given at these discussions are
included in this document.
An addition to the main architecture document of RTFM is the use of An addition to the main architecture document of RTFM is the use of
High Watermarks, to set up Alerts when the value of a flow record High Watermarks, to set up Alerts when the value of a flow record
variable exceeds a watermark, e.g. the total byte count exceeds a variable exceeds a watermark, e.g. the total byte count exceeds a
preset amount, such as no user should send more than 2,000,000 preset amount, such as no user should send more than 2,000,000
packets over a certain time period. This is a generalization of the packets. This is a generalization of the concept defined in RTFM to
concept defined in RTFM to send Traps when a the Meter finds an send Traps when a Meter finds an exception condition in its own
exception condition in its own processing (The Architecture Document processing (The Architecture Document refers to running out of buffer
refers to running out of buffer space). space).
2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows
The concept of flows has been studied in various different contexts. The concept of flows has been studied in various different contexts.
For the purpose of extending RTFM, a starting point is the work of For the purpose of extending RTFM, a starting point is the work of
the Integrated Services WG. We will measure quantities that are often the Integrated Services WG. We will measure quantities that are often
set by Integrated Services and configuration programs. We will look set by Integrated Services and configuration programs. We will look
at the work of the Benchmarking - Internet Provider Performance at the work of the Benchmarking - Internet Provider Performance
Metrics Working Group, and also look at the work of Claffy, Braun and Metrics Working Group, and also look at the work of Claffy, Braun and
Polyzos. Polyzos. We will demonstrate how RTFM can compute throughput, packet
loss, and delays from flows.
An example of the use of capacity and performance information is An example of the use of capacity and performance information is
found in "The Use of RSVP with IETF Integrated Services". [2]. found in "The Use of RSVP with IETF Integrated Services". [2].
RSVP's use of Integrated Services revolves around Token Bucket Rate, RSVP's use of Integrated Services revolves around Token Bucket Rate,
Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum
Packet Size, and the Slack term. These are set by TSpec, ADspec and Packet Size, and the Slack term. These are set by TSpec, ADspec and
FLowspec (Integrated Services Keywords), and are used in FLowspec (Integrated Services Keywords), and are used in
configuration and operation of Integrated Services. RTFM could configuration and operation of Integrated Services. RTFM could
monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum monitor explicitly Peak Data Rate,
Packet Size, and the Slack term. RTFM could infer details of the Minimum Policed Unit, Maximum Packet Size, and the Slack term. RTFM
Token Bucket. We will develop measures to work with these service could infer details of the Token Bucket. We will develop measures to
metrics. work with these service metrics.
RTFM will work with several traffic measurements identified by IPPM RTFM will work with several traffic measurements identified by IPPM
[3]. There are two broad areas in which RTFM is useful for IPPM. [3]. There are three broad areas in which RTFM is useful for IPPM.
1) RTFM could act as a passive device that can gather traffic and 1) RTFM could act as a passive device that can gather traffic and
performance statistics at appropriate places in TCP/IP networks performance statistics at appropriate places in TCP/IP networks
(servers or client locations). (servers or client locations).
2) RTFM could give detailed analyses of IPPM test flows that pass 2) RTFM could give detailed analyses of IPPM test flows that pass
through the Network segment that RTFM is monitoring. through the Network segment that RTFM is monitoring.
RTFM will also incorporate work from Claffy, Braun and Polyzos [4]. 3) RTFM could be used to identify most used paths in a network mesh,
We can measure flow time-outs, traffic aggregation and metrics on the such that detailed IPPM work could be applied to the most used paths.
application layer using methods similar to theirs.
3. Flow Abstractions 3. Flow Abstractions
Extensions to the current RTFM flow attributes may be divided into Performance attributes include throughput, packet loss, delays,
jitter, and congestion analysis. RTFM will calculate these attributes
in the form of extensions to the RTFM flow attributes according to
three general classes: three general classes:
o packet traces - collections of individual packets in a flow or a o 'packet traces' - collections of individual packets in a flow or a
segment of a flow segment of a flow
o 'aggregates' - statistics derived from the flow taken as a whole o 'aggregates' - statistics derived from the flow taken as a whole
(e.g. mean rate, max packet size). (e.g. mean rate, max packet size).
o 'series'- sequences of attributes that depend on more than one o 'series'- sequences of attributes that depend on more than one
packet (e.g. inter- arrival times) packet (e.g. inter- arrival times)
The following sections suggest implementations for each of these The following sections suggest implementations for each of these
classes of extensions. classes of extensions.
skipping to change at page 5, line 23 skipping to change at page 5, line 39
Meter Reader that is tied to the meter with instantaneous response, Meter Reader that is tied to the meter with instantaneous response,
and very high bandwidth. If the Meter Reader and Meter can be and very high bandwidth. If the Meter Reader and Meter can be
arranged in such a way, RTFM could collect Packet Traces with time arranged in such a way, RTFM could collect Packet Traces with time
stamps, and provide them to the Meter Reader for processing by the stamps, and provide them to the Meter Reader for processing by the
Meter Reader. Meter Reader.
A more useful alternative is to have the meter calculate some flow A more useful alternative is to have the meter calculate some flow
statistics locally. This allows a looser coupling between the meter statistics locally. This allows a looser coupling between the meter
and Meter Reader. RTFM will create an 'extended attribute' depending and Meter Reader. RTFM will create an 'extended attribute' depending
upon settings in the Rules table of RTFM. By default, RTFM will not upon settings in the Rules table of RTFM. By default, RTFM will not
create any extensions without explicit instructions in the Rules create any extensions without explicit instructions in the Rule
table. table.
RTFM's traditional flows can be analyzed at two levels. The first is RTFM's traditional flows can be analyzed at two levels. The first is
to analyze the Network traffic in terms of time, e.g. traffic load of to analyze the Network traffic in terms of time, e.g. traffic load of
a particular flow, to be called Network Flows. These flows can be a particular flow, to be called Network Flows. These flows can be
looked at as an extension of the "old-style" flow attributes. The looked at as an extension of the "old-style" flow attributes. The
second, is to derive a value from the flow, e.g. analyzing packet second, is to derive a value from the flow, e.g. analyzing packet
sequence numbers and ACKS and estimating delay. This second type sequence numbers and ACKS and estimating delay. This second type
will be called Derived Attributes. will be called Derived Attributes.
skipping to change at page 6, line 14 skipping to change at page 6, line 29
To use this, one would write a rule set which selected out a small To use this, one would write a rule set which selected out a small
number of flows of interest, and PushPkted PacketTrace for each of number of flows of interest, and PushPkted PacketTrace for each of
them. A MaxTraceRows default value of 2000 would be enough to allow them. A MaxTraceRows default value of 2000 would be enough to allow
a Meter Reader to read 1-second ping traces every 10 minutes or so. a Meter Reader to read 1-second ping traces every 10 minutes or so.
More realistically, a MaxTraceRows of 500 would be enough for one- More realistically, a MaxTraceRows of 500 would be enough for one-
minute pings, read once each hour. minute pings, read once each hour.
3.2. Aggregate Attributes 3.2. Aggregate Attributes
Performance aspects of flows are useful in the case of a flow between Performance aspects of flows are interesting in the case of a flow
a server and client. RTFM could find the same data in TCP/IP and UDP between a server and client. RTFM could find the same data in TCP/IP
flows, and can find additional data in TCP flows. The performance and UDP flows, and can find additional data in TCP flows. The
data found by this method define the flow capacity used by the performance data found by this method define the flow capacity used
individual flow, as experienced in the locale of the RTFM meter. The by the individual flow, as experienced in the locale of the RTFM
data found in this method would help Operations Support determine meter.
the performance of delivery in the network being measured.
For both TCP/IP and UDP, RTFM's "old-style" flow attributes count the For both TCP/IP and UDP, RTFM's "old-style" flow attributes count the
bytes/packets for packets which match the rule set for an individual bytes/packets for packets which match the rule set for an individual
flow. In addition to these totals, RTFM could calculate Packet size flow. In addition to these totals, RTFM could calculate Packet size
and Bit rate statistics. and Bit rate statistics. Bit rate statistics point to the throughput
of performance metrics.
Packet size - RTFM's packet flows can be examined to determine the Packet size - RTFM's packet flows can be examined to determine the
maximum packet size found in a flow. This will give the Network maximum packet size found in a flow. This will give the Network
Operator an indication of the MTU being used in a flow. It will also Operator an indication of the MTU being used in a flow. It will also
give an indication of the sensitivity to loss of a flow, for losing give an indication of the sensitivity to loss of a flow, for losing
large packets causes more data to be repeated. large packets causes more data to be repeated.
Bit rate - The data could also be recorded as the maximum and Bit rate - The data could also be recorded as the maximum and
minimum data rate of the flow, found over specific time periods minimum data rate of the flow, found over specific time periods
during the lifetime of a flow. This measure could be used to compare during the lifetime of a flow. Bit rate could be used to define the
the bandwidth used by the flow with the total capacity of the media he throughput of a flow, and if the RTFM flow is defined to be the
and guarantees set for flows. sum of all traffic in a network, one can find the throughput of the
network.
Note that aggregate attributes are a simple extension of the their
values are never reset. For example, an array of counters could hold
a 'total bits observed' distribution. The counters continue to
increase, a meter reader will collect their values at regular
intervals, and an analysis application will compute and display
distributions of the data rate for each interval. In this situation,
the interval will be specified by the manager which controls the
meter and meter reader.
3.3 Series Attributes 3.3 Series Attributes
The notion of series attributes, is to keep simple statistics that The notion of series attributes, is to keep simple statistics that
involve more than one packet. Methods to derive simple percentiles, involve more than one packet. Methods to derive simple percentiles,
means, and other statistics can be developed for each flow. The means, and other statistics can be developed for each flow. The
notation to construct such an attribute would be a command in the notation to construct such an attribute would be a command in the
rule set, instructing the meter to compute the attribute. This is rule set, instructing the meter to compute the attribute. This is
similar to the definition above of creating an aggregate attribute. similar to the definition above of creating an aggregate attribute.
Whereas aggregate attributes (see above) only require the meter to
increment counters, series attributes require the meter to compute
attribute values. For example, if we want to produce a distribution
of '10-second' forward data rates, the meter might compute this for
each flow of interest as follows: - maintain an array of counters to
hold the flow's 10-second data rate distribution.
- every 10 seconds, compute the 10-second octet count, and save a
copy of the flow's forward octet counter. To achieve this, the meter
will have to keep a list of aggregate flows and the intervals at
which they require processing. It will require careful programming
to achieve this, but provided the meter is not asked to do this for
very large numbers of flows, it should not be too difficult!
TCP and UDP TCP and UDP
Inter-arrival statistics - TCP and UDP. RTFM knows the time that it Inter-arrival statistics - TCP and UDP. RTFM knows the time that it
encounters each individual packet. Statistics can be kept to record encounters each individual packet. Statistics can be kept to record
the inter-arrival times of the packets, which would give an the inter-arrival times of the packets, which would give an
indication of the jitter found in the Flow. indication of the jitter found in the Flow.
TCP Only - Data Loss - This is an area for further study. TCP packets TCP Only - Packet loss - RTFM can calculate packet loss performance
have byte sequence numbers and SYNS, FINS, and ACK's associated with metrics. This is an area for further study. TCP packets have byte
them. RTFM could track the sequence numbers in the flows, and sequence numbers and SYNS, FINS, and ACK's associated with them. RTFM
calculate the packet loss occurring in a flow, and thus we can could track the sequence numbers in the flows, and calculate the
develop a metric of lost packets and useful traffic. packet loss occurring in a flow, and thus we can develop a metric of
lost packets and useful traffic.
Delay analysis - TCP flows also could be examined for the timing Delay analysis - TCP flows could be examined for the timing between
between Transmissions and ACKS and thus we can get some measure of Transmissions and ACKS and thus we can get some measure of delay of
delay. This assumes the forward and reverse packets are both visible performance metrics . This assumes the forward and reverse packets
to the meter. are both visible to the meter. In the case of asymmetric flows, RTFM
can be run on multiple paths, and with precise timing create packet
traces, which can be compared at later times.
Subflow analysis - TCP flows, e.g. a Web server's httpd flows Subflow analysis - TCP flows, e.g. a Web server's httpd flows
actually contain many individual sub flows. Given, a well known Web actually contain many individual sub flows. Given, a well known Web
Server WW, and a client CC, RTFM would normally pick up an Server WW, and a client CC, RTFM would normally pick up an
aggregation of all the flows of text, graphics, Java programs, etc. aggregation of all the flows of text, graphics, Java programs, etc.
that are sent between WW and CC. By analyzing the Sequence numbers, that are sent between WW and CC. By analyzing the Sequence numbers,
RTFM could estimate when each subflow occurs, and thus maintain RTFM could estimate when each subflow occurs, and thus maintain
statistics about the subflows on a network. statistics about the subflows on a network.
Congestion Analysis - In a TCP/IP flow we have information on the
negotiation of Window sizes which are used by TCP/IP to control
congestion. Well behaved flows honor these requests and in the vast
majority of cases the sender will slow down and thus decrease its
rate of injecting packets into the congested network. We will look
for cases where flows do not honor these congestion control and are
not slowing down. We will also look for flows which have the
"precedence" fields turned on and thus are aggressively competing for
network resources.
3.4 Action on Exceptions 3.4 Action on Exceptions
The user of RTFM will have the ability to define Network and Derived The user of RTFM will have the ability to define Network and Derived
flows, as having High Watermarks. The existence of abnormal service flows, as having High Watermarks. The existence of abnormal service
conditions, such as non-ending flow, a flow that exceeds a given conditions, such as non-ending flow, a flow that exceeds a given
limit in traffic (e.g. a flow that is exhausting the capacity of the limit in traffic (e.g. a flow that is exhausting the capacity of the
line that carries it) causes an ALERT to be sent to the Collector for line that carries it) causes an ALERT to be sent to the Meter Reader
forwarding to the Manager. Operations Support may define service for forwarding to the Manager. Operations Support may define service
situations in many different environments. This is an area for situations in many different environments. This is an area for
further discussion on Alert and Trap handling. further discussion on Alert and Trap handling.
4. Packet Flow Table 4. Packet Flow Table
The architecture of RTFM has defined the structure of flows, and this The architecture of RTFM has defined the structure of flows, and this
draft does not change that structure. The flow table could have draft does not change that structure. The flow table could have
ancillary tables called "Packet Flow Tables", which would contain ancillary tables called "Packet Flow Tables", which would contain
rows of values and or actions as defined under packet traces, rows of values and or actions as defined under packet traces,
aggregate attributes and series attributes. Each Packet Flow table aggregate attributes and series attributes. Each Packet Flow table
skipping to change at page 8, line 25 skipping to change at page 9, line 30
future by the work of the RMONMIB Bulk Data Transfer. future by the work of the RMONMIB Bulk Data Transfer.
5. Extensions to the Rules Table 5. Extensions to the Rules Table
The Rules Table of "old-style" attributes will be extended for the The Rules Table of "old-style" attributes will be extended for the
new flow types. A list of actions, and Keywords, such as "BitRate"- new flow types. A list of actions, and Keywords, such as "BitRate"-
for Bit Rate, "MaxPack", for Max Packet size will be developed and for Bit Rate, "MaxPack", for Max Packet size will be developed and
used to inform RTFM to collect a set of extended values for a used to inform RTFM to collect a set of extended values for a
particular flow (or set of flows). particular flow (or set of flows).
6. Security Considerations 6. Acknowledgments
We thank Stephen Stibler of IBM for his comments on this draft.
7. Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
7. Author's Address: 8. Author's Address:
Sig Handelman Sig Handelman
IBM Research Division IBM Research Division
Hawthorne, NY Hawthorne, NY
Phone: 1-914-784-7626 Phone: 1-914-784-7626
E-mail: handel@watson.ibm.com E-mail: handel@watson.ibm.com
Nevil Brownlee Nevil Brownlee
The University of Auckland The University of Auckland
New Zealand New Zealand
skipping to change at page 8, line 42 skipping to change at page 10, line 4
IBM Research Division IBM Research Division
Hawthorne, NY Hawthorne, NY
Phone: 1-914-784-7626 Phone: 1-914-784-7626
E-mail: handel@watson.ibm.com E-mail: handel@watson.ibm.com
Nevil Brownlee Nevil Brownlee
The University of Auckland The University of Auckland
New Zealand New Zealand
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Greg Ruth Greg Ruth
GTE Laboratories GTE Laboratories
Waltham, MA Waltham, MA
Phone: 1 617 466 2448 Phone: 1 617 466 2448
E-mail: grr1@gte,com E-mail: grr1@gte,com
8. References: 9. References:
[1] Brownlee, N, Mills, C., Ruth, G.: "Traffic Flow Measurement: [1] Brownlee, N, Mills, C., Ruth, G.: "Traffic Flow Measurement:
Architecture", Internet Draft, April, 1996 Architecture", RFC 2063, 1997
[2] Wroclawski, J., : "The Use of RSVP with IETF Integrated Services [2] Wroclawski, J., : "The Use of RSVP with IETF Integrated Services
Internet" Draft, October, 1996 Internet" Draft, October, 1996
[3] Almes, G. et al: "Framework for IP Provider Metrics" Internet [3] Almes, G. et al: "Framework for IP Provider Metrics" Internet
[4] Claffy, K., Braun, H-W, Polyzos, G. "A Parameterizable [4] Claffy, K., Braun, H-W, Polyzos, G. "A Parameterizable
Methodology for Internet Traffic Flow Profiling," IEEE Journal on Methodology for Internet Traffic Flow Profiling," IEEE Journal on
Selected Areas in Communications, Vol. 13, No. 8, October 1995. Selected Areas in Communications, Vol. 13, No. 8, October 1995.
[5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272,
1992
 End of changes. 34 change blocks. 
66 lines changed or deleted 119 lines changed or added

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