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

From: "Carter Bullard" <[email-masked]>
Date: Thu, 16 Jan 2003 08:51:19 -0500

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.
ENCODING mime
FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 16 Jan 2003 13:11:38 -0500

Carter,

  From the synopsis, it certainly sounds like Raqmon could
simply use IPFIX.  However, who is your question directed to?

  Have you had any dialog w/ A. Siddiqui et al.?

Regards,

  Jeff Meyer

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

Send a message to:
	[email-masked].
In the body type:

--
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: "Carter Bullard" <[email-masked]>
Date: Thu, 16 Jan 2003 13:54:12 -0500

Hey Jeff,
   The question was to the whole IPFIX group, of
course with the intention of trying to motivate
someone to point it out to an AD, who is suppose
to be paying attention to what's going on in 
their family of WG's to prevent duplicate efforts.

   Because RAQMON-PDU is in the RMON charter, 
its not just a, "here's an interesting draft,
why not come on over to IPFIX and lets work
together" kind of problem.  If, of course,
anyone ever recognizes it as a problem.  IMHO
this is definitely IPFIX killer technology.

   What I find interesting is that RAMON-PDU
transport has no congestion awareness.
   
Carter

> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]] 
> Sent: Thursday, January 16, 2003 1:12 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix?
> 
> 
> Carter,
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 17 Jan 2003 19:57:04 -0500

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

Send a message to:
	[email-masked].
In the body type: