RE: RAQMON Trap PDU size and report transmission time
"David B Harrington" <[email protected]>
| Newsgroups | gmane.ietf.rmonmib |
|---|---|
| Message-ID | <[email protected]> |
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 >