[ARGUS] PAPER: Building a Better Netflow

[Carter Bullard]

Ok, well my last response was a little harsh, but I have to say
again, in a nicer way, that I'm disappointed in a few things.

There are two concepts in the paper that are, I think, the
core concepts of the authors.

The first is adaptive behavior during high load times.  This
is a good idea, but I of course do not believe packet sampling
is a requirement at all.  It causes all sorts of statistical
problems, and it degrades the utility of the data.  I take
HUGE exception to statements like that made in 1.3 Related
work.  "... it is impossible to measure traffic in flows
without bias", which of course only applies to techniques
that use sampling.  BUT, if you have to sample, and some
strategies have to/want to, then having some form of adaptive
sampling seems pretty obvious.

So the paper is just modifying the random sampling of incoming
packets, and playing games with buffer management.  This is
not something to write home about.

The second concept is the proposal of the slotted probe,
(their notion of bins).  In order to apply their technique,
they propose creating measurement bins, epochs of observation.
The interesting thing is the introduction of the slotted
probe changes the semantic of the flow meter to the extent
that the resulting flow data doesn't have flow start and
stop timestamps any longer. You can't measure flow duration
any longer, not good.  So I'm very unhappy that the proposal
doesn't preserve the semantics of the flow monitor.

So without being tooooooo critical (my wife thinks I'm toooooo
critical), this is not a good solution, not a good approach,
not a good idea.  In section 1.3, Related work, the claim
is made; "There are solutions for counting the number of
flows at line speeds [14], but these count the total number
of flows, and one cannot later recover the number of flows
associated with specific aggregates of traffic out of the
overall mix".  Argus, of course does this every day, at up
to OC-192 speeds (well argus variants do this every day).

I have to respectfully disagree with the authors statements.


Carter


> From: eric <eric at catastrophe.net>
> Organization: Catastrophe.Net <http://www.catastrophe.net/>
> Date: Wed, 4 Aug 2004 14:08:42 -0500
> To: <argus-info at lists.andrew.cmu.edu>
> Subject: [ARGUS] PAPER: Building a Better Netflow
> 
> Some of you might be interested in reading this:
> 
> ``Network operators need to determine the composition of the traffic
> mix on links when looking for dominant applications, users, or
> estimating traffic matrices. Cisco's NetFlow has evolved into a
> solution that satisfies this need by reporting flow records that
> summarize a sample of the traffic traversing the link. But sampled
> NetFlow has shortcomings that hinder the collection and analysis of
> traffic data. First, during flooding attacks router memory and
> network bandwidth consumed by flow records can increase beyond what
> is available; second, selecting the right static sampling rate is
> difficult because no single rate gives the right tradeoff of memory
> use versus accuracy for all traffic mixes; third, the heuristics
> routers use to decide when a flow is reported are a poor match to
> most applications that work with time bins; finally, it is
> impossible to estimate without bias the number of active flows for
> aggregates with non-TCP traffic.''
> 
> <http://www.caida.org/outreach/papers/2004/tr-2004-03/tr-2004-03.pdf>
> 
>