Subject: Re: [IPFIX] about Collecting Process MIB objects

From: Hitoshi Irino <[email-masked]>
Date: Thu, 02 Apr 2009 10:28:56 +0900

Hello Benoit,

> - Furthermore, the proposed mechanism, i.e. compare the
> packets/bytes/messages from one table to the sum of the transport
> sessionS stats for whatever Template Records/Flow Records are written
> into a File is not intuitive. If we want to do something, I'm in favor
> of a very simple flag expressing: "I can't deal with all the Flow
> Records". Then it's up to the sys admin to investigate the causes.

I agree, the flag you proposed is enough to just inform to administrator about
unusual state of collector(s). It is easier and simpler than my proposed 
mechanism.
On the other hand, I think that packets/bytes/messages counters for writing 
can be useful information for investigating the causes.

regards,
Hitoshi IRINO

(2009/03/30 20:03), Benoit Claise wrote:
> Hitoshi-san,
> 
> What you trying to achieve is basically a way to have the 
> application-level acknowledgements, i.e. knowing when the transport 
> protocol is able to transmit the data, while the collector is not able 
> to write them down.
> 
> A few points:
> - We discussed that capability a long time ago in the WG, and my 
> recollection is that it was deemed unnecessary to overload the IPFIX 
> protocol with that mechanism.
> - If the Collector can detect that, it might be interesting to flag that
> - However, I guess that we don't want to postpone the MIB anymore, as it 
> was mentioned. So if the group wants to do something, this might be in 
> the configuration data model (even there is nothing to configure in this 
> case)
> - Furthermore, the proposed mechanism, i.e. compare the 
> packets/bytes/messages from one table to the sum of the transport 
> sessionS stats for whatever Template Records/Flow Records are written 
> into a File is not intuitive. If we want to do something, I'm in favor 
> of a very simple flag expressing: "I can't deal with all the Flow 
> Records". Then it's up to the sys admin to investigate the causes.
> 
> Regards, Benoit.
> 
> 
>> Dear IPFIX-MIB authors and all,
>>
>> I'd like to propose to add MIB objects about collecting process, if 
>> you agree and if you can. (I am sorry for my very late opinion, I hit 
>> on this recently.)
>>
>> Collected information will be passed to another process (e.g., File 
>> Writer, Metering Process in Mediators and/or any applications for 
>> analyzing and/or displaying graphical view in Collectors) from 
>> collecting process generally, I think.
>>
>> If the number of processed packets, bytes, and messages in Collecting 
>> Process (which I call them as 
>> ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail 
>> temporarily) can be got, I think these objects are useful to detect 
>> failure in Collectors (or Mediators) by comparing 
>> ipfixTransportSessionPackets/Bytes/Messages and these objects. 
>> Therefore I'd like to add 
>> ipfixCollectingProcessProcessedPackets/Bytes/Messages.
>>
>> An example situation: If a Collector's disk is full filled and File 
>> Writer will fail in writing, 
>> ipfixTransportSessionPackets/Bytes/Messages will be increased but 
>> ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be 
>> increased when a Collecting Process receives new IPFIX Message.
>>
>> regards,
>> Hitoshi IRINO
>>
> 

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549