Subject: [ipfix] ipfix vs. RMON

From: <[email-masked]>
Date: Thu, 4 Apr 2002 11:17:11 -0500

Hi,

I was asked about what the differences between IPFIX and RMON (also defined at IETF) are. In particular, what IPFIX can do that RMON cannot do? 

My two cents are that IPFIX runs on top of reliable TCP, hence allows exporting large chunk of data. Whereas RMON runs on top of UDP, not efficient for large amount of data transporting. I may have missed the main points. So any comments are appreciated.

Best regards
Man Li

--
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, 04 Apr 2002 09:34:15 -0800 (PST)

On Thu, 04 April 2002, "Christopher R. Cook" wrote
> 
> RMON / RMON2 and SNMP in general were never designed to handle the 
> incredible data volumes that will need to be transferred. IPFIX rides on to 
> of TCP, more reliable however less efficient that UDP, but reliability is 
> the key. The efficiencies (I hope) are being build in to IPFIX 
> implementation...  as both ( reliability & efficiency )   are required...

TCP is not 100 percent, SCTP is a contendor for transmission protocol. The
transmission protocol needs to be congestion aware.

IPFIX is to select from existing protocols.  So far, in each of the 3 main
contenders, they have their own way for efffecient transfer. It will also be
important to see how they handle overloading (network, exporting device,
collector).

K.C.

> Thoughts ?
> 
> Cheers..
> .
> At 11:17 AM 4/4/2002 -0500, [email-masked] wrote:
> >Hi,
> >
> >I was asked about what the differences between IPFIX and RMON (also 
> >defined at IETF) are. In particular, what IPFIX can do that RMON cannot do?
> >
> >My two cents are that IPFIX runs on top of reliable TCP, hence allows 
> >exporting large chunk of data. Whereas RMON runs on top of UDP, not 
> >efficient for large amount of data transporting. I may have missed the 
> >main points. So any comments are appreciated.
> >
> >Best regards
> >Man Li
> >
> >
> Christopher R. Cook
> Director of Product Management			Voice (781) 359-5055
> Quarry Technologies			
> 8 New England Executive Park
> Burlington MA, 01803
> 
> 
> --

---

From: [email-masked]
Date: Thu, 04 Apr 2002 09:34:15 -0800 (PST)

K.C.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 14:26:59 -0500

[email-masked] wrote:
> 
> Hi,
> 
> See my comments below starting with [man]. I am not defending any of the technologies. But I have a hard time to convince myself the differences between the two, let along to explain to others.

	I understand. If we can't articulate the differences 
	well, we should!

	See comments below.
> 
> Man
> 
> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: April 05, 2002 01:49 PM
> To: Li Man.M (NRC/Boston)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ipfix] ipfix vs. RMON
> 
> That is part of it. Some other items are bulk transfer,
> implementation with minimal resource needs on the client
> side in terms of memory and CPU
> 
> [man] This seems to be an implementation issue rather than IPFIX advantage.

	Don't underestimate implementation details. That is where
	success or failure often lays.

	Design and specification set the boundaries for implementation.
	So it is an IPFIX advantage because it is being designed so
	implementation can meet high capacity needs.

	When I first started doing LFAP on the RS router, I questioned
	why not RMON as well, but the answer I got for the engineers who
	knew it best was that it was fine in simple situations but
	not real world. It would run out of memory, eat up all the CPU,
	miss information if not polled quickly enough, etc...

> 
> much more flexible
> definition of flow in terms of aggregation,
> 
> [man] The RMON packet filter is quite flexible -- one can define the bytes to match in a packet

	What about deriving data from packet information? the simple
	one is translating IP address to an AS number. But there are
	many others. Are those functions standardized? Can you
	take RMON flows and aggregate them together or can a packet
	be counted in more than one bucket. What does and RMON do if the
	box is also doing NAT, can you get/use the before and after fields?

	Of course there is the reliable transport of data issue along
	with issues such as failover that come along with that.

	I'm sure there is more, but at this point I'll let other comment
	further.

> 
> IPFIX encompasses the RMON work so that RMON, I think,
> could be made to look like an IPFIX device. But we are going
> beyond what is defined for RMON.
> 
> [man] So the flow monitoring part of RMON is a subset of IPFIX?

	I would say yes.

> 
> [email-masked] wrote:
> >
> > Hi,
> >
> > Regarding the following two points listed by KC,.
> >
> > RMON - Device statistics and alarms
> > IPFIX - Flow information (IP Flow Information Export)
> >
> > RMON - Health of the device
> > IPFIX - health of the network
> >
> > It seems that RMON2 is also able to collect flow information. For
> > example, with RFC2819 one can define packet filters for capturing flow
> > info.  Is the main difference then that IPFIX can reliably export
> > large amount of data whereas RMON being running over SNMP is not able
> > to handle the volume of data expected?
> >
> >
> >
> > Man