Subject: RE: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00

From: "Norseth, KC" <[email-masked]>
Date: Wed, 13 Feb 2002 15:41:44 -0500

Depending on what you are trying to mine from the data.  The load process
may be different.  If you start mixing 2 different types of data in a data
mart, the wrong query  could yield devastating results.  A lot of
applications leave it up to the user to generate their reports. They clone a
report that was written and modify it.  The data store to is going to be
simple in rules, but rich in data.  They would have to build an
intuitiveness that they could pass on to the user.  This could be missed as
they build reports.  Most users would miss this where the data is stored in
the same area, but has different meaning.

The issue of reporting data does get complex already when they are tracking
a single flow across the whole network.  The data collected is valid and
same data, just a different viewpoint. Each router the data is reported on
has valuable information, so it would be duplicated in the database.  A rule
specifying a next hop to be the same as the destination for example, would
be a way of determining that this is the last edge of the lan.  Rules like
this need to be defined in the application.

|-----Original Message-----
|From: Robert Lowe [mailto:[email-masked]] 
|Sent: Wednesday, February 13, 2002 1:27 PM
|To: K.C. Norseth
|Cc: [email-masked]
|Subject: Re: [ipfix] Questions regarding 
|draft-gsadasiv-ipfix-proposal-00
|
|
|"K.C. Norseth" wrote:
|
|Hi K.C.!
|
|> ----- Original Message -----
|> From: Robert Lowe <[email-masked]>
|> To: Norseth, KC <[email-masked]>
|> Cc: <[email-masked]>
|> Sent: Tuesday, February 12, 2002 12:22 PM
|> Subject: Re: [ipfix] Questions regarding 
|> draft-gsadasiv-ipfix-proposal-00
|> 
|> | > "Norseth, KC" wrote:
|> |
|> | Hi KC!
|> |
|> | > |A few more comments regarding templates, although ones which 
|> | > |probably fall within the realm of operational vs. protocol 
|> | > |issues...
|> | > |
|> | > |Early on there was some discussion regarding the impact 
|of IPFIX 
|> | > |on the network itself, and if/how the exporter or collector 
|> | > |should react to overload conditions.  As I recall, Peter Phaal 
|> | > |indicated that from an analysis point of view, it would not be 
|> | > |good to change the sample rate. However, when faced with an 
|> | > |overload condition:
|> | > |
|> | > |1) On the exporter, should it:
|> | > |       a. continue as is, and drop packets when it has to, or
|> | > |        b. fall-back to a user pre-defined sampling 
|rate, compromising
|> | > |           IPFIX data to avoid dropping packets ??
|> | > |
|> | > |2) On the collector, should it:
|> | > |        a. continue, and lose flow data because it 
|cannot process 
|> | > |it all, or
|> | > |        b. signal a fall-back to a different sampling 
|rate via a 
|> | > |new template?
|> | > |
|> | > |If the solution uses the verb "buy", don't mention it!  ;-)  I 
|> | > |can accept a good argument that these are operational issues.
|> | >
|> | > This is very dangerous to have the exporter switch to sampling
|> automatically.  This
|> | > could really confuse the information being gathered.  You could 
|> | > get the
|> message from the
|> | > reports that volume has dropped down during a period of 
|time, but 
|> | > in
|> reality, it is
|> | > dnagerously high.
|> |
|> | No, I was assuming that the new template would somehow be 
|recorded, 
|> | or
|> available
|> | during analysis, so that it would be recognized that the sampling 
|> | rate
|> changed
|> | and could be properly reflected in a report.  I agree that not 
|> | having this
|> change
|> | record available during analysis makes the analysis pretty useless.
|> |
|> | But this is a kind of in-band config that would add more 
|complexity 
|> | than
|> would
|> | seem to outweigh its benefit.  I think I need to re-read a few 
|> | things to
|> better
|> | understand the use of templates in general too.
|> 
|> This could be a SHOULD if people want it to be. I think it could be 
|> dangerous, but you are right, a template could inform the collector 
|> that this is sampled data.  The collector would have to be smart 
|> enough to explain this to the readers of the reports when it changes 
|> though.  It would also have to be smart to switch back and 
|once again 
|> the collector would have to be smart enough to report this to the 
|> users.  I don't think the collectors/applications out there now are 
|> smart enough for this.
|
|Won't they have to become smarter?  Besides a changing sample 
|rate from one exporter, how will they aggregate flow data from 
|multiple exporters, 
|each potentially using a different sample rate?  Or do all exporters 
|within a "domain" have to use the sample rate?
|
|-Robert
|
|--
|Help        mailto:[email-masked] and say "help" 
|in message body
|Unsubscribe mailto:[email-masked] and say 
|"unsubscribe ipfix" in message body
|Archive     http://ipfix.doit.wisc.edu/archive/
|