Subject: RE: [ipfix-arch] counter wrapping

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 25 Feb 2002 13:55:10 -0800

Hello Paul, 

Could we just have the two counters as proposed by Ganesh (absolute and
delta)? An implementation would use one or the other as it sees fit.

regards,

Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, February 25, 2002 7:07 AM
>To: Benoit Claise
>Cc: [email-masked]; Penno, Reinaldo [SC9:T327:EXCH];
>[email-masked]
>Subject: Re: [ipfix-arch] counter wrapping
>
>
>
>Thought I would reply direct.
>
>I would check on that. Since the hardware
>is the one that increments the counter as
>packets are going through, the only way to 
>read the count and then set it to zero as
>one operation would be to stop the hardware
>from updating the counter while the read-set-to-zero
>operation is happening. 
>
>So either the netflow hardware really supports that
>operation or a tradeoff was made to leave the issue
>as is.
>
>It would be good to know as it affects how to best
>accomplish intermediate updates should we go that way.
>
>Paul
>
>Benoit Claise wrote:
>> 
>> Paul,
>> 
>> [email-masked] wrote:
>> 
>> > Benoit Claise wrote:
>> > >
>> > > Nevil,
>> > >
>> > > [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.
>> > > >
>> > > > 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.
>> > > > 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.
>> > >
>> > > Why?
>> > > For long run flows, you can just export the flow records 
>with the acconting
>> > > information seen during that interval.
>> > > If you must export the flow records because:
>> > >  - you faced the long aging time timeout (for example: 
>30 minutes)
>> > >  - the counters is about to wrap.
>> > > then you consider the flow to be ended (expired) and 
>export the accounting data
>> > > for that period.
>> > > Now a new flow with the same characterics will be 
>directly created. Not a problem.
>> > > And you start the accounting from 0 for that "new" flow.
>> >
>> >         Most hardware can't do a get and set in one
>> >         operation. So in between reading the count
>> >         and setting it to zero you may loose some
>> >         of the count.
>> 
>> I'm not too sure about the details of most hardware, but 
>this is the way it works with
>> netflow.
>> 
>> Regards, Benoit
>> 
>> >
>> >
>> > > The collector won't be confused at all and don't need to 
>remember any values.
>> > >
>> > > Regards, Benoit
>> > >
>> > > >
>> > > > That would mean that successive exports of the same 
>flow would have
>> > > > increasing counter values, 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: "Kevin Zhang" <[email-masked]>
Date: Mon, 25 Feb 2002 22:28:55 -0500

RE: [ipfix-arch] counter wrappingHi Paul and Reinaldo,

The data model draft should focus on the definition of various attributes or
IEs, so that information collected is correctly exported and processed by
downstream systems.  How the informaiton is collected is out side our scope,
as long as it conforms to the definition.  I felt nother prevent us to
introduce both counters (absolute and delta) in or document.

Thanks,

Kevin
  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Reinaldo Penno
  Sent: Monday, February 25, 2002 4:55 PM
  To: [email-masked]; Benoit Claise
  Cc: [email-masked]; [email-masked]
  Subject: RE: [ipfix-arch] counter wrapping

  Hello Paul,

  regards,

  Reinaldo

---

From: [email-masked]
Date: Wed, 27 Feb 2002 13:56:40 -0500

Reinaldo Penno wrote:
> 
> Hello Paul,
> 
> Could we just have the two counters as proposed by Ganesh (absolute
> and delta)? An implementation would use one or the other as it sees
> fit.
> 

	Yes. I just wanted to point out the issue with deltas.
	It should be there as an option though.

	Paul

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