Subject: RE: [ipfix-arch] counter wrapping

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

|-----Original Message-----
|From: Calato, Paul 
|Sent: Thursday, February 21, 2002 3:28 PM
|To: Norseth, KC
|Cc: [email-masked]; [email-masked]
|Subject: Re: [ipfix-arch] counter wrapping
|
|
|"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.

Yes.

K.C.

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