Re: 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
>  
>

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