RE: RAQMON Trap PDU size and report transmission time
Andy Bierman <[email protected]>
| Newsgroups | gmane.ietf.rmonmib |
|---|---|
| Message-ID | <[email protected]> |
At 12:40 AM 1/18/2005, Romascanu, Dan \(Dan\) wrote:
>Andy,
>
>Your computation simulates a complete PDU with the full set of static and dynamic metrics. Static metrics need not be transmitted more than once per session, or if there are changes during the session. Notifications that would include only the full set of dynamic metrics would result in:
So you are saying that the SNMP Transport approach cannot be coded
so that a RDS can send a full report without fragmentation? T
Why would developers choose to reinvent TCP (badly) in the SNMP agent code,
rather than use the TCP that they already have? I really don't understand
the use cases for the SNMP Notification transport. IMO, the Trap approach
is totally unworkable and the Inform approach is between 3X and 5X more
work (and code) than using TCP. With worse performance and congestion
awareness as a result.
Andy
>For IPv4:
>
># size of notification PDUs:
>
>raqmonDsNotification {
> sysUpTime [15..19]
> snmpTrapOID [25..25]
> raqmonAppName [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]
> raqmonCpuUtilization [26..34]
> raqmonMemoryUtilization [26..34]
>} [453..901]
>
>For IPv6:
>
>raqmonDsNotification {
> sysUpTime [15..19]
> snmpTrapOID [25..25]
> raqmonAppName [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]
> raqmonCpuUtilization [38..58]
> raqmonMemoryUtilization [38..58]
>} [625...1269]
>
>It looks like picking raqmonAppName to be the mandatory object in each notification was a poor choice on my part. It is both static, and brings a permanent overhead that is not justified. Being wiser now I would rather change the mandatory object to be one of the coounters, say raqmonTotalPacketsReceived. The figures that would result if we do this change would be:
>
>For IPv4 [430..614]
>For IPv6 [590..958]
>
>Regards,
>
>Dan
>
>
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]]On Behalf Of Andy Bierman
>> Sent: 18 January, 2005 3:49 AM
>> 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
>>