Subject: Re: [ipfix] CUrrent issues, Draft deadlines

From: Benoit Claise <[email-masked]>
Date: Sat, 08 Nov 2003 03:23:19 +0100

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

>Maurizio,
>
>  I agree with your sentiments around requiring both.  I disagree
>with your statement that counters benefit charging.  Again, most
>flows are single export records which you either receive or you
>don't.  State management for counters, make them most useful if
>you have a relatively constrained space (i.e. it may be OK for
>exporter based aggregation schemes such as NFv8), but in the situation
>where each flow has a unique src/dstIP and src/dstPort we're talking
>about millions of possible counters to maintain.
>
Exactly. Running counters per flow are not practical!

Regards, Benoit.

>
>  Integers are how deployed Netflow works today, and I would
>not recommend changing something which works.
>
>Regards,
>
>  Jeff Meyer
>
>  
>
>>-----Original Message-----
>>From: majordomo listserver 
>>[mailto:[email-masked]]On Behalf
>>Of Maurizio Molina
>>Sent: Friday, October 17, 2003 10:59 AM
>>To: [email-masked]
>>Cc: 'Nevil Brownlee'; [email-masked]
>>Subject: Re: [ipfix] CUrrent issues, Draft deadlines
>>
>>
>>Nevil, Carter,
>>my position would be to support both Counters and Integers in the 
>>information model, and to NOT make any default choice, but rather 
>>request with a MUST that the IPFIX devices support both.
>>
>>In fact, on the  ML we had arguments pro/against Integers and 
>>arguments 
>>pro/against Counters, and all of them are probably  correct given the 
>>application that had in mind who wrote them.
>>But that's exacly the point: in theory ANY application receiving flow 
>>records and making something out of them could work both with 
>>Integers 
>>and Counters (provided it knows what it is receiving...). Of course 
>>there are applications that care most about variations (e.g. load 
>>monitoring) and therefore are happy with Integers, but can also work 
>>with Counters (they just need more processing). 
>>Simmetrically, there are 
>>applications that need the total amount of traffic of a flow (e.g. 
>>Charging) and therefore are happy with Counters, but can also 
>>work with 
>>Integers (they just need more processing).
>>But I can envisage that there can be "poor" or legacy 
>>applications that 
>>can only work with either Integers
>>or Counters (not both), and if the probe cannot support the 
>>data in the 
>>format they need they cannot work at all.
>>
>>Of  course, making a default choice  gives more chance for market 
>>differentiation ("good" probes will support both...) but 
>>opens the door 
>>to interoperability problems.
>>
>>Maurizio
>>
>>Carter Bullard wrote:
>>
>>    
>>
>>>Hey Nevil,
>>>  With regard to counters vs integers.  I would suggest that
>>>the better default choice would be integers.  Counters
>>>would require that originators of IPFIX always support the
>>>largest data type possible, where an integers strategy can
>>>be used by a probe to limit the size of the reported metrics.
>>>This would provide the opportunity to control the
>>>memory demands of a probe, and minimize the amount of
>>>data on the wire.
>>>
>>>  Because counters have roll-over behaviors, regardless
>>>of the size of the counters you support, the counter strategy
>>>is fundamentally the same as integers, except that with
>>>counters you throw away some intermediate records and keep
>>>others.  This introduces possible uncertainty.  The reader is
>>>throwing away data, did it throw away the right data?  I
>>>would rather like to avoid having any IPFIX component
>>>throw away data as a part of its basic function.
>>>
>>>Carter
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>IM-1: Counters vs Integers
>>>>  We seem to acknowledge that counters (running totals) 
>>>>        
>>>>
>>and Integers
>>    
>>
>>>>  (reset to zero when the exporter sends out data about a flow) can
>>>>  both be useful, so the Information Model needs to have 
>>>>        
>>>>
>>both Counter
>>    
>>
>>>>  and Integer types.
>>>>
>>>>  My experience with RTFM is that counters have the advantage that
>>>>  it doesn't matter if you loose a few intermediate counts for any
>>>>  reason.  If that happens you loose some time granularity, but you
>>>>  still have most, or at least some, of the packet and byte counts
>>>>  for the flow.
>>>>
>>>>  I'm not sure that - at least for packet and byte counts - we need
>>>>  both.  <wg chair hat off> could we agree to only have counters?
>>>>  </wg chair hat off>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>--
>>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/
>  
>