Subject: FW: [ipfix-req] does raqmon-pdu compete with ipfix?

From: "Carter Bullard" <[email-masked]>
Date: Thu, 23 Jan 2003 00:05:22 -0500

Hey Jeff,
   I'm glad to see that you also recognize RAQMon-PDU
as an IP flow information transport protocol.

   RAQMon is a new component of the RMON Architecture
that introduces a completely new philosophy in
RMON data generation/collection.  It is exactly what
the IPFIX concept envisions and is designed to support;
remote probes generating flow information to enable
various applications.  Obviously, the RMON WG is saying
that when it wants to use IP flow information as a data
source in its new strategy, it doesn't need the minimum features and
functions of IPFIX.  The chairs and Ads are supporting this position,
either out of ignorance or as a hedge.  This is the essence of the
problem.

   I believe that RAQMon-PDU is an IPFIX killer not
because it can meet the requirements of IPFIX, but
rather because RMON, a targeted IPFIX customer doesn't
need the functions and features of the protocol.  If
the IESG accepts that position, then what are IPFIX's
chances?

   I am not aware that the list "routers, probes,
middleboxes" excludes end systems.

Carter

> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]]
> Sent: Friday, January 17, 2003 7:57 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix?
> 
> 
> Hi,
> 
>   Further examining RAQMon, it looks like an interesting
> approach to address the collection of a certain limited set of flow 
> information from end devices (vs. IPFIX which is more 
> targeted at routers, probes, middleboxes).
> 
>   It is based on an essentially fixed data model containing 28 
> different attributes.  Several of these attributes are particularly 
> focused on QoS aspects of various streaming protocols, other 
> attributes provide system level statistics such as CPU utilization.  
> The attribute set is incomplete compared to that defined in IPFIX 
> requirements.
> 
>   It also only specifies mappings onto non-congestion aware
> protocols today.  Although one could picture mapping it to 
> something like BEEP (RFC 3080).
> 
>   It clearly states that loss of information is a property
> of the current spec (framework sec. 2.4 bullet #6).
> 
> 
>   Although it claims an extension framework, this basically
> consists of specifying a different header, which indicates 
> the subsequent encoding of the payload is "interpreted by the 
> application and not by RRC itself."  (Hmmm not a lot of 
> guidance there).  [see PDU sec. 4.3]
> 
> 
>   Given their design center, which appears to be device
> centric QoS reporting, with a focus on streaming, this UDP based, 
> fixed set of information may address a need different than 
> IPFIX, i.e. a dirt simple UDP packet that an app can blast 
> at a collector, when it has some info to share.
> 
> 
>   However, RAQMon clearly is incomplete in addressing IPFIX.
> 
> 
> Regards,
> 
>   Jeff Meyer
> 
> 
> > -----Original Message-----
> > From: Carter Bullard [mailto:[email-masked]]
> > Sent: Thursday, January 16, 2003 5:51 AM
> > To: [email-masked]
> > Subject: [ipfix-req] does raqmon-pdu compete with ipfix?
> > 
> > 
> > Gentle People,
> >    I believe that raqmon-pdu is indeed a direct
> > competitor to IPFIX.  Why not realize that raqmon
> > is a form of flow data and have it use IPFIX?
> > 
> > Carter
> > 
> > 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On Behalf
> > Of [email-masked]
> > Sent: Thursday, January 16, 2003 8:08 AM
> > To: IETF-Announce:
> > Cc: [email-masked]
> > Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Remote Network 
> > Monitoring Working Group of the IETF.
> > 
> > 	Title		: Real-time Application Quality of Service
> > Monitoring 
> >                          (RAQMON) Protocol Data Unit (PDU)
> > 	Author(s)	: A. Siddiqui et al.
> > 	Filename	: draft-ietf-rmonmib-raqmon-pdu-00.txt
> > 	Pages		: 26
> > 	Date		: 2003-1-15
> > 	
> > This memo defines a common protocol data unit (PDU) used between 
> > RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report

> > a QOS statistics using RTCP and SNMP as Transport Protocol. The 
> > original RAQMON draft [SIDDIQUI3] was split into 3 parts to identify
> the RAQMON
> > Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined
> RAQMON QOS
> > Protocol Data Unit (PDU). This memo also outlines mechanisms
> > to use Real
> > Time Transport Control Protocol
> > (RTCP) and Simple Network Management Protocol (SNMP) to 
> > transport these
> > PDUs between RAQMON Data Source (RDS) and RAQMON Report 
> > Collector (RRC)
> > as outlined in RAQMON Charter of the RMON Workgroup. The memo
> > [SIDDIQUI2] defines a Real-Time Application QOS Monitoring
> > (RAQMON) Framework that extends the RMON Framework to allow 
> Real-time
> > Application QoS information as outlined by RAQMON Charter
> of the RMON
> > Workgroup. The memo [SIDDIQUI1] defines a portion of the Management 
> > Information Base (MIB) for use with network management protocols in 
> > the Internet community. The document proposes an extension to the 
> > Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution.
> > Distribution of
> > this memo is unlimited.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-
> pdu-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-rmonmib-raqmon-pdu-00.txt".
> 
> A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
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: Nevil Brownlee <[email-masked]>
Date: Fri, 24 Jan 2003 08:38:15 +1300

> either out of ignorance or as a hedge.  This is the essence of the

I think you're taking too simple a view.  RAQMon is aimed at providing
a simple means for QoS monitor boxes to gather information **about
what's happening at the application layer** on small probes implemented
in other boxes.  The idea - at least the way I thought I understood it -
is to provide monitoring of response times for transactions in a wide
variety of systems.  Although one could use flow information to derive
QoS, that seems to be pushing the edges of RAQMon in terms of the amount
of data an RAQ monitor box would need to retrieve from its probes.

Differences between IPFIX and RAQmon:
 * RAQMon defines both ends of the data channel, IPFIX only defines the
   exporting end.
 * RAQMon seems to be aiming at carrying sets of metric values, probably
   using a TLV list to encode it.  IPFIX is tailored to the exporting
   of large sets of flow data, minimising the encoding overhead by using
   templates.  
 * RAQMon is targeted at making measurements at the application layer.
   IPFIX works with flows, i.e. at the transport layer.
 * Others ???

Having said all that, I agree with one thing you said - we (the IPFIX WG)
need to get moving and make some real progress on the IPFIX documents 
soon!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/