RE: RAQMON Trap PDU size and report transmission time

"Romascanu, Dan \(Dan\)" <[email protected]>
Newsgroups gmane.ietf.rmonmib
Message-ID <AAB4B3D3CF0F454F98272CBE187FDE2F038AA00D@is0004avexu1.global.avaya.com> 
There is something very fundamental in the RAQMON philosophy that we seem to miss in this discussion. A RAQMON Data Source will never have any reason to send all the parameters. No object is mandatory in the notification because for each application a few metrics (objects) are being picked from the total list and sent according to the application needs. A well written agent (or a agent written by somebody who read carefully the RAQMON documents) will send only once the static parameters in a given session, and then send periodically only the dynamic counters relevant for the application - thus there is no need to define separate notifications. 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of David B Harrington
> Sent: 18 January, 2005 4:19 PM
> To: Siddiqui, Anwar A (Anwar); 'Andy Bierman'; 'Wijnen, Bert (Bert)'
> Cc: [email protected]
> Subject: RE: [RMONMIB] RAQMON Trap PDU size and report 
> transmission time
> 
> 
> So would this have been better written as two separate notifications,
> one for static info, and a second for dynamic?
> 
> dbh 
> 
> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]] On Behalf Of Siddiqui, 
> > Anwar A (Anwar)
> > Sent: Tuesday, January 18, 2005 9:02 AM
> > To: Andy Bierman; Wijnen, Bert (Bert)
> > Cc: [email protected]
> > Subject: RE: [RMONMIB] RAQMON Trap PDU size and report 
> > transmission time
> > 
> > This represents a "worst case" analysis. There is no doubt we need
> to
> > accommodate for the "worst case" but thought I would point out that
> > 
> > a. In your analysis you assumed static parameters such as name and
> > address etc. are reported in every PDU which will be simply a bad
> > implementation and there is text that says one should avoid exactly
> > that.
> > 
> > b. "ALL" dynamic parameters are reported as well which is bit
> unusual
> > since NOT all APPLICATION will use all parameters to describe their
> > sessions.
> > 
> > So if you do NOT compute the static parameters, the scenario over
> SNMP
> > is not that scary!
> > 
> > Thanks
> > Anwar
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of Andy Bierman
> > Sent: Monday, January 17, 2005 8:49 PM
> > To: Wijnen, Bert (Bert)
> > Cc: [email protected]
> > Subject: RE: [RMONMIB] RAQMON Trap PDU size and report 
> > transmission time
> > 
> > At 12:35 PM 1/17/2005, Wijnen, Bert (Bert) wrote:
> > 
> > Here are my results (I used smidump 0.4.2).
> > 
> > For the test, I modified the RAQMON-RDS-MIB so the 
> > InetAddress was (SIZE(4)), then again with (SIZE(16)) for IPv6.  
> > I modified the raqmonDsNotification so the OBJECTS clause contains
> > the entire list of accessible-for-notify report parameters,
> > instead of just one object.
> > 
> > For IPv4: [770..1569]
> > For IPv6: [1106..2241]
> > 
> > Note also that the SNMP Transport requires that a separate
> > raqmonDsByeNotification be sent to indicate the RAQMON reporting for
> 
> > that session is over.  That means a maximum of 1 report per 4
> minutes.
> > 
> > Andy
> > 
> > -----------------------------------
> > smidump -fsizes output
> > 
> > For IPv4:
> > 
> > # size of notification PDUs:
> > 
> > raqmonDsNotification {
> >   sysUpTime                             [15..19]
> >   snmpTrapOID                           [25..25]
> >   raqmonAppName                         [23..287]
> >   raqmonDataSourceDevicePort            [26..36]
> >   raqmonReceiverDevicePort              [26..36]
> >   raqmonSessionSetupDateTime            [31..42]
> >   raqmonSessionSetupDelay               [26..38]
> >   raqmonSessionDuration                 [26..38]
> >   raqmonSessionSetupStatus              [23..287]
> >   raqmonRoundTripEndToEndNetDelay       [26..38]
> >   raqmonOneWayEndToEndNetDelay          [26..38]
> >   raqmonApplicationDelay                [26..38]
> >   raqmonInterArrivalJitter              [26..38]
> >   raqmonIPPacketDelayVariation          [26..38]
> >   raqmonTotalPacketsReceived            [26..38]
> >   raqmonTotalPacketsSent                [26..38]
> >   raqmonTotalOctetsReceived             [26..38]
> >   raqmonTotalOctetsSent                 [26..38]
> >   raqmonCumulativePacketLoss            [26..38]
> >   raqmonPacketLossFraction              [26..34]
> >   raqmonCumulativeDiscards              [26..38]
> >   raqmonDiscardsFraction                [26..34]
> >   raqmonSourcePayloadType               [26..34]
> >   raqmonReceiverPayloadType             [26..34]
> >   raqmonSourceLayer2Priority            [26..34]
> >   raqmonSourceDscp                      [26..34]
> >   raqmonDestinationLayer2Priority       [26..34]
> >   raqmonDestinationDscp                 [26..34]
> >   raqmonCpuUtilization                  [26..34]
> >   raqmonMemoryUtilization               [26..34]
> > } [770..1569]
> > 
> > raqmonDsByeNotification {
> >   sysUpTime                             [15..19]
> >   snmpTrapOID                           [25..25]
> >   raqmonAppName                         [23..287]
> > } [65..334]
> > 
> > 
> > For IPv6:
> > 
> > raqmonDsNotification {
> >   sysUpTime                             [15..19]
> >   snmpTrapOID                           [25..25]
> >   raqmonAppName                         [35..311]
> >   raqmonDataSourceDevicePort            [38..60]
> >   raqmonReceiverDevicePort              [38..60]
> >   raqmonSessionSetupDateTime            [43..66]
> >   raqmonSessionSetupDelay               [38..62]
> >   raqmonSessionDuration                 [38..62]
> >   raqmonSessionSetupStatus              [35..311]
> >   raqmonRoundTripEndToEndNetDelay       [38..62]
> >   raqmonOneWayEndToEndNetDelay          [38..62]
> >   raqmonApplicationDelay                [38..62]
> >   raqmonInterArrivalJitter              [38..62]
> >   raqmonIPPacketDelayVariation          [38..62]
> >   raqmonTotalPacketsReceived            [38..62]
> >   raqmonTotalPacketsSent                [38..62]
> >   raqmonTotalOctetsReceived             [38..62]
> >   raqmonTotalOctetsSent                 [38..62]
> >   raqmonCumulativePacketLoss            [38..62]
> >   raqmonPacketLossFraction              [38..58]
> >   raqmonCumulativeDiscards              [38..62]
> >   raqmonDiscardsFraction                [38..58]
> >   raqmonSourcePayloadType               [38..58]
> >   raqmonReceiverPayloadType             [38..58]
> >   raqmonSourceLayer2Priority            [38..58]
> >   raqmonSourceDscp                      [38..58]
> >   raqmonDestinationLayer2Priority       [38..58]
> >   raqmonDestinationDscp                 [38..58]
> >   raqmonCpuUtilization                  [38..58]
> >   raqmonMemoryUtilization               [38..58]
> > } [1106..2241]
> > 
> > raqmonDsByeNotification {
> >   sysUpTime                             [15..19]
> >   snmpTrapOID                           [25..25]
> >   raqmonAppName                         [35..311]
> > } [77..358]
> > 
> > 
> > >C:\smi\mibs\work>smidump -fsizes ./RAQMON-RDS-MIB
> > ># RAQMON-RDS-MIB module PDU sizes (generated by smidump 0.4.3)
> > >
> > >
> > ># size of PDUs for groups and rows:
> > >
> > >RAQMON-RDS-MIB          raqmonDsNotificationEntry       16
> > [13..16]
> > >
> > ># size of one-shot row creation PDUs including columns with default
> > values:
> > >
> > >
> > ># size of one-shot row creation PDUs excluding columns with default
> > values:
> > >
> > >
> > ># size of notification PDUs:
> > >
> > >RAQMON-RDS-MIB          raqmonDsNotification            214
> > [72..566]
> > >RAQMON-RDS-MIB          raqmonDsByeNotification         214
> > [72..566]
> > >
> > >> -----Original Message-----
> > >> From: [email protected]
> [mailto:[email protected]]On
> > >> Behalf Of Andy Bierman
> > >> Sent: Monday, January 17, 2005 20:42
> > >> To: [email protected]
> > >> Subject: [RMONMIB] RAQMON Trap PDU size and report 
> > transmission time
> > >> 
> > >> 
> > >> Hi,
> > >> 
> > >> Does anyone know how many RAQMON-RDS-MIB varbinds can fit in 
> > >> an unfragmented SNMP Trap PDU?  (IPv4 as well as IPv6).
> > >> 
> > >> It seems to me that all of the Basic report parameters should be 
> > >> reported at least once per session, otherwise they shouldn't be 
> > >> in the common parameter list.  If the Basic report needs to be 
> > >> fragmented into multiple Trap PDUs, then RDS complexity is 
> > >> increased, and the likelihood goes up that a maximum transmission
> 
> > >> rate of 1 Trap PDU every 2 minutes becomes a bottleneck on the
> RDS.
> > >> 
> > >> Andy
> > >> 
> > >> _______________________________________________
> > >> RMONMIB mailing list
> > >> [email protected]
> > >> https://www1.ietf.org/mailman/listinfo/rmonmib
> > >> 
> > 
> > _______________________________________________
> > RMONMIB mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rmonmib
> > 
> > 
> > _______________________________________________
> > RMONMIB mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rmonmib
> > 
> 
> 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.