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