RE: RAQMON PDU Notification Objects - Table or Scalar?

Hi,
 
I concur that, if tracking  multiple subsessions is required, using
scalars won't suffice.

Separating the initiation phase from the reporting phase makes sense
to me.
 
One notification could indicates the start (or end) of a subsession
and report the subsession identifier.
If the table of subsessions used an integer identifier for the
session, then all subsequent messages could use the integer rather
than the DSRC, RCN, and address to identify the session. this would
significantly reduce the size of subsequent subsession-specific
notifications.

Once the subsession-start inform has been acknowledged by the
receiver, the static parameters related to the subsession could be
reported, and subsession-specific statistics could follow, until the
end of the session was reported.

The correlation of the static parameters with the statistics could be
handled by the collector, reducing the processing that needs to be
done at the reporting device.
 
This still strikes me as being better done using protoocls other than
SNMP, ones designed for session handling and streaming data reports.
 
David Harrington
[email protected]

________________________________

	From: [email protected]
[mailto:[email protected]] On Behalf Of Mark Ellison
	Sent: Monday, January 24, 2005 12:44 PM
	To: Romascanu, Dan (Dan)
	Cc: [email protected]; Mark Ellison
	Subject: Re: [RMONMIB] RAQMON PDU Notification Objects - Table
or Scalar?
	
	
	Hi Dan,
	
	I do not think that using scalar object definitions instead of
table object definitions is part of the optimal solution.
	
	As I understand raqmon, the auxiliary objects (raqmonDSRC,
raqmonRCN, raqmonPeerAddrType, raqmonPeerAddr) serve to identify the
(sub)session reporting the statistic.  Further, I believe raqmon
wishes to commingle statistics from different (sub)sessions in a
single report notification.  To accommodate situations where two
different subsessions rely on the same object definition for reporting
a statistic, and they both wish to report such statistic in the same
notification (piggybacking), then the unique instance quality is lost
by using scalar object definitions.  Note, it is not a good idea to
report multiples of the same varbindname in a single notification.
	
	With scalar object definitions, if raqmon wants to piggyback
reports from multiple subsessions, then no scalar object definition
could be relied upon by more than one subsession.  The alternative,
not piggybacking statistic notifications would only serve to double,
then triple, etc. the amount of traffic due to RDS originated
notifications. This would  break the 2min quiet rule, as well. 
	
	In consideration of the MTU issues, and in consideration of
the 2min quiet period between reports, I would suggest the WG study
the definition of notification-types that support the initiation of an
RDS subsession.  For MTU concerns, the initiation report may need to
be broken into a short (2 or 3) series of notification definitions.
Of course, the 2min quiet period would need to be modified so as not
to apply to subsession initiation reports.
	
	I believe that once the RDS subsession state is past
initiation and operational, the devised system in the rds notification
table should work quite nicely.  Possibly the WG could create some
additional text  that shows some examples of multiple subsession
behavior in this regard.  Also, consider the creation of a (series) of
initiation notification-types to assuage the MTU issue.  Finally,
study the adjustment of the 2min quiet rule to apply only to the rds
in progress reports.  I think this approach is more likely to yield an
optimal solution.
	
	Regards,
	
	Mark
	
	
	
	Romascanu, Dan (Dan) wrote:
	

		I would like to query the WG on another issue that
surfaced visibly during the latest round of discussions. One of the
more visible problems of the SNMP Notifications transport is the need
of fragmentation if the number of objects in one notification leads to
the maximum PDU size being exceeded. To reduce this probability, a
more compact notifications format would help. Currently the
notification objects are organized in raqmonDsNotificationTable which
is indexed by the objects that characterize a session and subsession
(raqmonDSRC, raqmonRCN, raqmonPeerAddrType, raqmonPeerAddr). This is
not too efficient, and if a maximum PDU or close to a maximum PDU
needs to be set, the limit may be exceeded, especially for ipv6
addresses in the peer. In the past I supported the table format
because the indices characterize the session in a unique manner and
because possible extensions can be written in the future simply like
extensions of this table by later RAQMON users.  Right now it looks
like avoiding fragmentation became a bigger concern. The proposal I
would like the WG to consider is to replace the
raqmonDsNotificationTable with a group of scalars, and make the
present four index objects the mandatory objects in the notifications.


		Opinions?      

		Regards, 

		Dan 

	
________________________________


		_______________________________________________
		RMONMIB mailing list
		[email protected]
		https://www1.ietf.org/mailman/listinfo/rmonmib