IPFIX Working Group L. Peluso
Internet-Draft University of Napoli/Fraunhofer
Intended status: Standards Track Institute FOKUS
Expires: May 21, 2008 T. Zseby
Fraunhofer Institute FOKUS
S. D'Antonio
CINI Consortium/ITeM Laboratory
M. Molina
DANTE
November 18, 2007
Flow selection Techniques
draft-peluso-flowselection-tech-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Flow selection is the process in charge of electing a limited number
of flows from all of those observed at an observation point to be
Peluso, et al. Expires May 21, 2008 [Page 1]
Internet-Draft Flow selection Techniques November 2007
considered into the measurement process chain. The flow selection
process can be enabled at different stages of the monitoring
reference model. It can be performed at metering time once the
packet classification has been executed, i.e. flow state dependent
packet sampling, or at recording/exporting time by limiting the
number of flows to be stored and/or exported to the collector
applications. This document illustrates the motivations which might
lead flow selection to be performed and presents a classification of
the related techniques. The document furthermore provides the basis
for the definition of information models for configuring flow
selection techniques and discusses what information about the flow
selection process is beneficial to be exported by adopting a suitable
information model.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Peluso, et al. Expires May 21, 2008 [Page 2]
Internet-Draft Flow selection Techniques November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Selection process related terminology . . . . . . . . . . 4
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Flow selection techniques . . . . . . . . . . . . . . . . . . 6
5.1. Flow selection on flow record content . . . . . . . . . . 8
5.2. Flow selection on flow record arrival time . . . . . . . . 8
5.3. Flow selection on external events . . . . . . . . . . . . 8
6. Flow selection causes and relevant exportable information . . 9
6.1. Flow selection in the metering process . . . . . . . . . . 9
6.2. Flow selection in the flow recording process . . . . . . . 9
6.3. Flow selection in the exporting process . . . . . . . . . 11
6.4. Information model for flow selection information
exporting . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.1. Meter process related . . . . . . . . . . . . . . . . 12
6.4.2. Flow recording process related . . . . . . . . . . . . 13
6.4.3. Flow exporting process related . . . . . . . . . . . . 14
6.5. Requirements put on implementations . . . . . . . . . . . 15
7. Information model for flow selection configuration . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Peluso, et al. Expires May 21, 2008 [Page 3]
Internet-Draft Flow selection Techniques November 2007
1. Introduction
<Text for this section>
2. Scope
The main aim of this document is to present flow selection techniques
that can be performed by an IPFIX device and to define additional
information that can be reported to keep under control/complement the
flow selection process. This document does not intend to deal with
the flow selection that might result from the sampling of packets in
the metering process before that the classification process is
performed. Although that approach leads to a natural selection of
the flows that are generated once the classification process has been
performed, packet sampling techniques are widely analysed in
[PSAMP-TECH] and, therefore, outside the scope of this document.
Instead, it describes those selection techniques that might be
considered in order to enable flow selection by directly acting on
traffic flows during the metering phase and/or the exporting phase.
3. Terminology
The terminology used here is fully consistent with all terms listed
in [IPFIX-ARCH] and [PSAMP-TECH] and includes additional terms
required for the description of flow selection techniques.
3.1. Selection process related terminology
In this section, some additional terms are presented which extend the
terminology introduced in [PSAMP-TECH].
* Flow Selection Process
A Flow Selection Process takes the set of the accounted Flow
Records as its input and selects a subset of that set as its
output.
* Flow Selection State
A Flow Selection Process may maintain state information for use by
the Flow Selection Process. At a given time, the Flow Selection
State may depend on flows observed at and before that time, and
other variables. Examples include:
Peluso, et al. Expires May 21, 2008 [Page 4]
Internet-Draft Flow selection Techniques November 2007
(i) number of accounted flow records;
(ii) memory space available for flow recording;
(iii) state of the pseudorandom number generators;
(iv) hash values calculated during selection.
* Flow Selector
A Flow Selector defines the action of a Flow Selection Process on
a single flow of its input. The Flow Selector can make use of the
following information in determining whether a flow is selected:
(i) the content of the flow record;
(ii) any information state related to the flow recording;
(iii) any selection state that may be maintained by the Flow
Selection Process.
4. Motivation
As stated in [PSAMP-TECH], packet selection is in charge of electing
a representative subset of packets that allow accurate estimates of
properties of the unsampled traffic to be formed. Its main
application consists in performing some forms of data reduction on
observed Internet traffic in order to limit the processing overhead
at measurement devices. Despite its proven ability in achieving this
objective, the mechanism responsible for steering the selection
process is generally driven by a packet-based decision strategy. It
means that, the element on which this selection mechanism is
performed is a packet and the decision of which packets are suitable
to be sampled depends on packets only. As a consequence, depending
on the specific adopted selection strategy, packet selection may not
take in consideration potential effects of its actions on subsequent
measurement tasks, such as flow recording and exporting processes,
which are instead considering flows rather than packets. In this
perspective, flow selection differs from packet selection in that the
basis elements on which the selection process is applied is not a
packet but a flow. In the IPFIX architecture the object of the
selection process would be the so-colled flow records. It has been
observed that the distribution of the number of packets per flow or
the number of bytes per flow are heavy-tailed. That means, most
flows consist only of a small number of packets and only few flows
have a large number of packets. The few large flows contribute to
the majority of the overall traffic volume [DuLT01a], [DuLT01b].
Peluso, et al. Expires May 21, 2008 [Page 5]
Internet-Draft Flow selection Techniques November 2007
This observation on the flow size distributions in Internet traffic
is also referred to as "Quasi-Zipf-Law" [KuXW04] or as "elephant and
mice phenomenon". The large flows are referred to as elephant flows
or heavy hitters. Obviously, distributions characterizing the flow
size strictly depends on the flow definition in use and can change
with regard to the profile of future applications. For several
applications it makes sense to select only the flows of interest.
5. Flow selection techniques
Figure 1 shows the IPFIX reference model as defined in [IPFIX-ARCH],
and extends it by introducing the functional components where flow
selection can take place. As previously mentioned, traffic flows can
be selected at different stages of the measurement chain. The first
possibility is to perform flow selection by analysing flow packets
during the metering process. The second option is to act directly on
the traffic flows during the flow recording process and/or the flow
exporting process.
Peluso, et al. Expires May 21, 2008 [Page 6]
Internet-Draft Flow selection Techniques November 2007
Packet(s) coming in to Observation Point(s)
| |
v v
+----------------+---------------------------+ +-----+-------+
| Metering Process on an | | |
| Observation Point | | |
| | | |
| packet header capturing | | |
| | |...| Metering |
| timestamping | | Process N |
| | | | |
| packet selection | | |
| | | | |
| classification | | |
| | | | |
| flow state dependent packet sampling (*) | | |
| | | | |
| aggregation | | |
| | | | |
| flow recording (*) | | |
| | | | |
| | Timing out Flows | | |
| | Handle resource overloads | | |
+--------|-----------------------------------+ +-----|-------+
| |
Flow Records (selected by Observation Domain) Flow Records
| |
+----------------------+----------------------+
|
+----------------------|---------------+
| Exporting Process v |
| +---------------+-----------+ |
| | flow export (*) | |
| +---------------+-----------+ |
| | |
+----------------------+---------------+
|
v
IPFIX export packet to Collector
(*) indicates where flow selection can take place.
Figure 1
In case the flow selection is performed during the metering process,
then it consists in accounting only a subset of all the incoming
packets which are collected at the observation point. However,
unlike the selection process executed before the packet
Peluso, et al. Expires May 21, 2008 [Page 7]
Internet-Draft Flow selection Techniques November 2007
classification is performed, the flow selection applies to only the
incoming packets which somehow satisfy certain conditions regarding
flows state information available from the flow recording process.
This kind of selection is considered as a packet sampling technique,
in accordance with [PSAMP-TECH] where such technique is referred to
as flow state dependent sampling. The state of the stored flow
records is thus taken into account while performing packet selection,
so that the process responsible for generating or updating flow
records might be influenced by the selective collection of packets
which feed it. Under this perspective, unlike the flow selection
performed at the flow recording and exporting processes, this flow
selection technique operates at a very early stage of the flow
monitoring process, as it acts at packet level. The adoption of such
technique allows to prevent that some observed/observable packets
might enforce the flow recording process to account, for instance,
not representative or not expected flow records. The flow selection
that might be provided is executed during the flow recording and/or
exporting processes, it is done at flow level, once packets are
classified and assigned to the correspondent flows. More exactly,
the flow selection process can be carried out by storing new flow
records only in those cases whem enough resources are available at
the monitoring device or by discarding already accounted records
which, under certain circumstances and at a certain point in time,
are not anymore significant. Finally, at the flow exporting time it
might be required that not all of the stored flow records are
actually exported to the collectors.
We can distinguish the following selection techniques:
1. based on flow record content (i.e. all reported flow
characteristics);
2. based on flow record arrival time;
3. based on external events like the exhaustion of local resources.
5.1. Flow selection on flow record content
<Text for this section>
5.2. Flow selection on flow record arrival time
<Text for this section>
5.3. Flow selection on external events
<Text for this section>
Peluso, et al. Expires May 21, 2008 [Page 8]
Internet-Draft Flow selection Techniques November 2007
6. Flow selection causes and relevant exportable information
In this section we identify and describe in more detail some possible
causes of flow selection, along with the information that can be
beneficial to make available to applications about it.
6.1. Flow selection in the metering process
The main reason for applying in the metering process a flow state
dependent sampling is that the flow recording process may not have,
at a certain point in time, enough positions to record all observable
flows. Another reason may be that there may not be enough processing
resources to create and manage a new flow record. To overcome with
these limitations, a number of possible policies can be applied, the
simplest one being not to consider for measurement the new packets
that do not belong to already existing flow records (i.e. that would
require the creation of a new one). More refined policies are
however possible, mainly aimed at the so called elephant flow
detection, i.e. to give priority in the flow recording process to
flows carrying more traffic. For instance, [EsVa01] proposes
criteria to define a packet eligible to create a new flow record
(sample and hold, multistage filters). Independently of the specific
algorithms, we are concerned here about defining what information it
makes sense to keep about the flow state dependent packet sampling
and make available to applications (by exporting it out of an IPFIX
device). It is certainly possible to keep a cumulative counter of
the total number of packets and bytes that were not considered for
measurement because of flow state dependent sampling. Also, it is
possible to keep a timestamp for the first and last of these non
measured packets. This means, in practice, to aggregate all these
packets in a macro flow, and keep track of its volume and duration.
Imagining keeping more detailed information about packets not
measured because of flow state dependent sampling would contradict
the fact that the sampling is done because of lack of memory and/or
processing resources.
6.2. Flow selection in the flow recording process
This block is optional in the IPFIX framework architecture. However,
we address here the case where it is present. We already described
in the previous section that because of lack of memory positions in
the flow recording process some incoming packets may be discarded if
they lead to the opening of a new flow record. However, under
certain circumstances, it may be advantageous to discard an existing
flow record in the flow recording process to make room for the new
record opened by an arriving packet. For example, an algorithm for
taking the decision whether to discard the new arriving packet or an
existing flow record is described in [Moli03]. In this section we
Peluso, et al. Expires May 21, 2008 [Page 9]
Internet-Draft Flow selection Techniques November 2007
are not concerned about the algorithm details but about what
information to store about this record removal. For the same reasons
expressed before, we argue that it does not make sense to store
separate information for each discarded flow record, as it would
contradict the motivation itself for which the discarding is done
(i.e. lack of memory resources). The information that is certainly
possible to keep with a limited effort is a cumulative counter of the
total number of not yet exported packets and bytes belonging to flow
records that were eliminated from the flow recording process.
Ideally, we would also like to keep a timestamp for the first (T_fd)
and last (T_ld) not yet exported packets belonging to all these
discarded flow records. This would mean, in practice, to aggregate
all these packets in a macro flow, and keep track of its volume and
duration. To do so precisely, we would need to keep in each flow
record a timestamp for the first and last non-exported packets, and
whenever a record is discarded look at these timestamps to see if
they are smaller or larger (respectively) of T_fd and T_ld and if yes
update them. Another information that can be easily kept is the
number of these discarding events, along with a timestamp of the
first and last of them. This information should not be used by
applications to re- normalize their received per flow statistics
(because a flow may be discarded and re-created multiple times) but
rather to keep under control the good functioning of the implemented
policy. Note that we consider a discarding event only when the
discarded flow record contains some not exported traffic. Otherwise,
the removal of a record whose traffic was fully exported (after a
timeout or after the arrival of specific packets, e.g. TCP FIN or
RST) is part of the normal functioning of an IPFIX flow metering
system. Note also that we consider only the case when an elimination
of a flow record from the flow recording process leads to the
complete loss of all the information contained in the flow record.
If on the contrary another policy is implemented, like immediate
exporting of the flow record before elimination, or freezing of the
flow record and moving it in an area of memory different from which
is considered the flow recording process for later exporting, this is
not considered an elimination and therefore is out of the scope of
this document. In parallel to the information about the number of
discarded flow records and associated packets and bytes, it is useful
to keep cumulative information about the number of flow records
containing not yet exported traffic that exist in the flow recording
process, along with the cumulative number of not exported packets and
bytes contained in them. This information is useful also for
exporting process related reasons, as clarified in the following
paragraph.
Peluso, et al. Expires May 21, 2008 [Page 10]
Internet-Draft Flow selection Techniques November 2007
6.3. Flow selection in the exporting process
The exporting process may implement policies for not exporting the
whole set of flow records of the flow recording process. In case of
absence of the flow recording process, when the metering process
directly feeds the exporting process (i.e. directly put the exported
packets in the IPFIX format), the following reasoning does not apply.
The motivations for not exporting some flow records (containing non
exported traffic) can be two: there are explicit configured policies
or the exporting process faces resource limitation. An example of
explicit policy can be not to export the flows whose accounted
traffic is below a certain threshold, or a more complex mechanism
such as the one described in [DuLT01a] or [DuLT01b]. An example of
resource limitation is that the exporting process has an assigned,
limited time slot to operate or a limited predefined number of export
packets that it can send. There can also be hybrid cases where there
are resource limitations and policies are applied in order to
optimize the exported information (e.g. given that we want to export
only N flow records, select a subset so that the overall number of
reported packets and bytes belonging to the subset is maximized).
Coming to the issue of which information it makes sense to keep about
this flow selection, there are two cases to consider. If a flow is
not exported and because of this decision is deleted from the flow
recording process, we are in the same case described before (where
the deletion was triggered by the need to make room for another
record). The information to keep is then naturally the same as
described before (cumulative packets and bytes for all the flows not
exported, timestamps of the first and last packets belonging to non
exported flow records, counter of dropping events and timestamp of
first and last dropping event). Only the reason for this removal is
different. If on the contrary a record eligible for exporting is not
exported but it remains in the flow recording process it has always a
chance to be exported in the future. For an application, however, it
would be beneficial to know what it is not currently being exported
because of exporting process policies/resource limitations, in terms
of flow records, packets and bytes. This, not to re-normalize its
estimates (it would be dangerous and error prone because the
exporting of these records may be simply delayed), but rather to keep
under control what is happening: for example, understand if there are
pathologic situations where a large number of flow records and/or
associated traffic are never exported, or if the number of flow
records in the flow recording process is growing, etc. When it comes
to understanding if this information can be easily available,
however, we recognize that there is the problem that in order to be
aware that it has not exported a flow record, an exporting process
should at least have browsed through it. In other words, we would
have to assume that there is always a full scanning of the flow
recording process associated to the exporting process selection
Peluso, et al. Expires May 21, 2008 [Page 11]
Internet-Draft Flow selection Techniques November 2007
decision. However, there may be more efficient implementations where
this does not happen. Therefore, even if we provide support in the
information model for this information, defining it as mandatory in
the protocol definition would put a constraint on the exporting
process implementation, which is undesirable.
6.4. Information model for flow selection information exporting
We formally define the elements to contain the information described
in the previous section. Some elements have an associated couple of
timestamps, which we reference for brevity (when it is not ambiguous)
as Tfirst and Tlast (instead of element_nameTfirst,
element_nameTlast). Note that all the following information elements
are aimed at describing macro flows (e.g. the total number of packets
and bytes contained in all dropped or not created flow records).
Some of these macro flows are additive only, in the sense that they
only add contributions to them, but never subtract. E.g. the macro
flow of the packets contained in flow records that are discarded from
the flow reporting process receives a contribution when a flow record
is discarded, and this contribution can never be subtracted. On the
contrary, some of the macro flows can dynamically receive and loose
contributions. E.g. the macro flows of packets not yet exported
receives a contribution when a new packets arrives, and looses some
contribution when there is an exporting event. Associating a
timestamp for the oldest and most recent contributions to additive
only flow is easy, while for the others is not (would require to
maintain full state) and that is why we did not define timestamps for
these information elements.
6.4.1. Meter process related
6.4.1.1. FsMeter_UnmeasPacketCount
Contains the count of packets that were not measured because of flow
state dependent sampling, in terms of:
TsFirst: timestamp of the first packet not measured because of flow
state dependent sampling (Type: dateTime)
TsLast: timestamp of the last packet not measured because of flow
state dependent sampling (Type: dataTime)
6.4.1.2. FsMeter_UnmeasBytesCount
Contains the count of bytes that were not measured because of flow
state dependent sampling
Type: unsignedInt
Peluso, et al. Expires May 21, 2008 [Page 12]
Internet-Draft Flow selection Techniques November 2007
6.4.2. Flow recording process related
6.4.2.1. FsFrec_PacketInDroppedRecsCount
Contains the count of non exported packets that were contained in
flow records eliminated from the flow recording process because of
resource limitations/policies in the flow recording process. It is
defined in terms of:
TsFirst: timestamp of the first non-exported packet belonging to a
eliminated flow record (Type: dateTime)
TsLast: timestamp of the last non-exported packet belonging to a
eliminated flow record (Type: dateTime)
6.4.2.2. FsFrec_ByteInDroppedRecsCount
Contains the count of non exported bytes that were contained in flow
records eliminated from the flow recording process because of
resource limitations/policies in the flow recording process.
Type: unsignedInt
6.4.2.3. FsFrec_FrecDroppedCount
Contains the count of flow records containing non exported packets
eliminated from the flow recording process because of resources
limitations/policies in the flow recording process. It is defined in
terms of:
TsFirst: timestamp of the first flow record elimination event from
the flow recording process (Type: dateTime)
TsLast: timestamp of the last flow record elimination event from the
flow recording process (Type: dateTime)
6.4.2.4. FsFrec_UnexportedFrecCount
Contains the count of the flow records currently existing in the flow
recording process containing at least one non exported packet
Type: unsignedInt
6.4.2.5. FsFrec_UnexportedPacketInFrecCount
Contains the count of non exported packets contained in flow records
of the flow recording process.
Peluso, et al. Expires May 21, 2008 [Page 13]
Internet-Draft Flow selection Techniques November 2007
Type: unsignedInt
6.4.2.6. FsFrec_UnexportedBytesInFrecCount
Contains the count of non exported bytes contained in flow records of
the flow recording process.
Type: unsignedInt
6.4.3. Flow exporting process related
6.4.3.1. FsExp_PacketInDroppedRecsCount
Contains the count of non exported packets that were contained in
flow records eliminated from the flow recording process because of
resource limitations/policies in the exporting process. It is
defined in terms of:
TsFirst: timestamp of the first non exported packet belonging to a
eliminated flow record (Type: dateTime)
TsLast: timestamp of the last non exported packet belonging to a
eliminated flow record (Type: dateTime)
6.4.3.2. FsExp_ByteInDroppedRecsCount
Contains the count of non exported bytes that were contained in flow
records eliminated from the flow recording process because of
resource limitations/policies in the exporting process.
Type: unsignedInt
6.4.3.3. FsExp_FrecDroppedCount
Contains the count of flow records containing non exported packets
eliminated from the flow recording process because of resource
limitations/policies in the exporting process. It is defined in
terms of:
TsFirst: timestamp of the first flow record elimination event from
the flow recording process (Type: dateTime)
TsLast: timestamp of the last flow record elimination event from the
flow recording process (Type: dateTime)
Peluso, et al. Expires May 21, 2008 [Page 14]
Internet-Draft Flow selection Techniques November 2007
6.4.3.4. FsExp_UnexportedCount
Contains the count of the flow records currently existing in the flow
recording process containing non-exported traffic and not being
exported because of exporting process resource lmitations/policies.
Type: unsignedInt
6.4.3.5. FsExp_UnexportedPacketCount
Contains the count of non exported packets contained in flow records
of the flow recording process not being exported because of exporting
process resource limitations/policies.
Type: unsignedInt
6.4.3.6. FsFrec_UnexportedByteInFrecCount
Contains the count of non exported bytes contained in flow records of
the flow recording process not being exported because of exporting
process resource limitations/policies.
Type: unsignedInt
6.5. Requirements put on implementations
To support the described information model an implementation must
keep, in the flow records, counts for non-exported packets and bytes.
Sometimes these are referred as delta counts. An implementation may
also keep absolute counts for scopes not specified in this
information model (it appears that both delta and absolute counters
can be exported in the IPFIX information model, see [IPFIX-INFO]).
In addition, to fully support this information model, it would be
required to keep in a flow record a timestamp for the first and last
non-exported packets. An implementation may need to keep timestamps
for the first and last exported packets as well for scopes not
specified in this information model, or to join the two timers for
the last exported and first exported packets (which is of course an
approximation) or to approximate them with the time of the exporting
event.
7. Information model for flow selection configuration
This section aims at describing the representative parameters of the
above presented flow selection techniques. To this regard, this
section provides the basis for an information model to adopt in order
to configure the flow selection process at an IPFIX device.
Peluso, et al. Expires May 21, 2008 [Page 15]
Internet-Draft Flow selection Techniques November 2007
8. IANA Considerations
This document makes no request of IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[DuLT01a] Duffield, N., Lund, C., and M. Thorup, "Charging from
Sampled Network Usage", ACM Internet Measurement Workshop
IMW 2001, San Francisco, USA, November 2001.
[DuLT01b] Duffield, N., Lund, C., and M. Thorup, "Properties and
Prediction of Flow Statistics from Sampled Packet
Streams", ACM SIGCOMM Internet Measurement Workshop 2002,
November 2002.
[DuLT01c] Duffield, N., Lund, C., and M. Thorup, "Learn More, sample
less: control of volume and variance in network
measurement", IEEE Transactions on Information Theory,
May 2005.
[DuLT01d] Duffield, N., Lund, C., and M. Thorup, "Flow Sampling
under Hard Resource Constraints", ACM IFIP Conference on
Measurement and Modeling of Computer Systems SIGMETRICS,
June 2004.
[EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic
Measurement and Accounting: Focusing on the Elephants,
Ignoring the Mice", ACM SIGCOMM Internet Measurement
Workshop 2001, San Francisco (CA), November 2001.
[FeGL98] Feldmann, A., Rexford, J., and R. Caceres, "Efficient
Policies for Carrying Web Traffic over Flow-Switched
Networks", IEEE/ACM Transaction on Networking,
December 1998.
[IPFIX-ARCH]
Sadasivan, G., Bownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", Internet
Draft draft-ietf-ipfix-architecture-12.txt, work in
progress, September 2006.
Peluso, et al. Expires May 21, 2008 [Page 16]
Internet-Draft Flow selection Techniques November 2007
[IPFIX-INFO]
Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
Internet Draft draft-ietf-ipfix-info-15.txt, work in
progress, February 2007.
[KuXW04] Kumar, K., Xu, J., Wang, J., Spatschek, O., and L. Li,
"Space-code bloom filter for efficient per-flow traffic
measurement", INFOCOM 2004 Twenty-third AnnualJoint
Conference of the IEEE Computer and Communications
Societies, March 2004.
[Moli03] Molina, M., "A scalable and efficient methodology for flow
monitoring in the Internet", International Teletraffic
Congress (ITC-18), Berlin, September 2003.
[PSAMP-TECH]
Zseby, T., Molina, M., Raspall, F., Duffield, N., and S.
Niccolini, "Sampling and Filtering techniques for IP
Packet Selection", Internet
Draft draft-ietf-psamp-sample-tech-10.txt, work in
progress, June 2007.
Authors' Addresses
Lorenzo Peluso
University of Napoli/Fraunhofer Institute FOKUS
Via Claudio 21
Napoli 80125
Italy
Phone: +39 081 7683821
Email: lorenzo.peluso@unina.it, lorenzo.peluso@fokus.fraunhofer.de
Tanja Zseby
Fraunhofer Institute FOKUS
Kaiserin-Augusta-Allee 31
Berlin 10589
Germany
Phone: +49 30 3463 7153
Email: zseby@fokus.fraunhofer.de
Peluso, et al. Expires May 21, 2008 [Page 17]
Internet-Draft Flow selection Techniques November 2007
Salvatore D'Antonio
CINI Consortium/ITeM Laboratory
Monte S.Angelo, Via Cinthia
Napoli 80126
Italy
Phone: +39 081 679944
Email: saldanto@unina.it
Maurizio Molina
DANTE
Hills Road 126-130
Cambridge CB2 1PQ
United Kingdom
Phone: +44 1223 371300
Email: maurizio.molina@dante.org.uk
Peluso, et al. Expires May 21, 2008 [Page 18]
Internet-Draft Flow selection Techniques November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Peluso, et al. Expires May 21, 2008 [Page 19]