Subject: RE: [ipfix-arch] counter wrapping

From: "Norseth, KC" <[email-masked]>
Date: Thu, 21 Feb 2002 17:13:45 -0500

Although a DELTA counter helps, if the interval between checking the flow
causes a wrap (or 2 wraps), it can cause grief.  This is an issue when the
hardware cannot handle the larger number.  The ability to send a flow record
at any interval due to a counter rollover needs to be a selection criteria.

K.C.

|-----Original Message-----
|From: Calato, Paul 
|Sent: Thursday, February 21, 2002 3:00 PM
|To: [email-masked]
|Cc: [email-masked]; [email-masked]
|Subject: Re: [ipfix-arch] counter wrapping
|
|
[email-masked] wrote:
|> 
|> Hi Reinaldo:
|> 
|> > b. avoid counter wrapping."
|> >
|> > This activity SHOULD be configurable. Btw, can someone 
|elaborate on 
|> > the counter wrapping stuff?
|> >
|> > It is very simple to send so much data though the line on a flow 
|> > that the byte counter rolls over.  This is very typical in 
|1 gig and 
|> > 10g  ports. counter 32 is not large enough field size for this.
|> >
|> > yes, that's what I tought. So the solution is just to augment th 
|> > efield to a 64 counter. It seems that the peirodic reporting is 
|> > completely orthogonal to this specific issue.
|
|	We need to be careful here. Some of us need to get counters
|	directly from the hardware so just changing the size is
|	not an option. Doing it in software can be an issue too
|	because that means extra memory is needed for each flow.
|
|> 
|> You've covered the 'counter wrapping' problem - a flow information 
|> meter (whatever that turns out to be) needs counters wide enough not 
|> to wrap too often, and that becomes more of a problem at high link 
|> speeds.
|
|	Not only the link speed but the aggregation level too.
|	The higher level aggregations tend to get more bytes/packets
|	per second. 
|
|> In RTFM, all counts are kept in 64-bit unsigned counters so 
|that they 
|> don't wrap too often.
|> 
|> Of more interest, I don't remember seeing any IPFIX discussion 
|> concerning just how information about long-running flows is to be 
|> exported.  In particular, I believe that counters should never be 
|> reset.
|
|	One more thing to keep in mind here is that most hardware
|	does not provide a way to do an atomic get and set operation.
|	So if you do reset it, you'll likely loose some information.
|
|> That would mean that successive exports of the same flow would have 
|> increasing counter values,
|
|	The other way is the box keeps track of the last reported
|	in counter in software and still provide deltas. The 
|problem with
|	cumulative counts is on failover the collector will not
|	have the last count. I'd like to keep collector to collector
|	requirements to a minimum or none if possible.
|
|> a collector would need to remember the
|> previous value and subtract it.  Furthermore, provided unsigned 
|> arithmetic is used, the difference is correct even if the 
|counter has 
|> wrapped.  Provided, of course that the counter has only wrapped once!
|> 
|> Cheers, Nevil
|> 
|> 
|-----------------------------------------------------------------------
|>    Nevil Brownlee                   Director, Technology Development
|>    Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
|>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
|> 
|> --
|> 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/
|
|--
|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/
|

---

From: [email-masked]
Date: Thu, 21 Feb 2002 17:28:10 -0500

"Norseth, KC" wrote:
> 
> Although a DELTA counter helps, if the interval between checking the
> flow causes a wrap (or 2 wraps), it can cause grief.  This is an issue
> when the hardware cannot handle the larger number.  The ability to
> send a flow record at any interval due to a counter rollover needs to
> be a selection criteria.

	I don't have a problem with intermediate updates but
	I think your last statement is key "...due to a counter rollover".
	If we can select only those flows that are in danger of
	rollover we can help keep from overwhelming the exporter
	with the number of updates to be sent out. The flows moving at
	a slower pace can send updates in a more leisurely manner.

--
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/