RE: RAQMON Trap PDU size and report transmission time

At 06:01 AM 1/18/2005, Siddiqui, Anwar A \(Anwar\) wrote:
>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

no it's not -- it's the best-case transmission rate for SNMP Traps

>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.

no -- I think it's reasonable to expect the first (or at least one)
report will contain all the mandatory parameters.  The question
is whether the Basic Report fits in a single SNMP PDU, or is
report fragmentation required sometimes.  If it is, (sure looks
that way) then that's at least 3 traps per report (1 per 6 min!), 
making SNMP traps even less workable. 

The PDU lengths assumed all along have been wrong because the
OBJECTS clause contains only 1 object.  Even the minimum length
for IPv4 is > 484.  The SNMP approach is more complicated than
the TCP method to implement because RAQMON reports have to
be fragmented into multiple Trap or Inform PDUs by the application.
application deal with the fragmentation of reports than TCP.

I favored the SNMP approach when we were trying to save time
and avoid creating a new protocol.  The SNMP-based transport 
made more sense when the only other choice was RTCP, but
now that we've gone to the trouble of creating a new protocol,
we should use it.


>b. "ALL" dynamic parameters are reported as well which is bit unusual
>since NOT all APPLICATION will use all parameters to describe their
>sessions.

The issue is really the coding complexity hit because the SNMP-based
RDS code has to deal with report fragmentation, and process Inform 
replies or report buffering for several minutes for Traps.


>So if you do NOT compute the static parameters, the scenario over SNMP
>is not that scary!
>
>Thanks
>Anwar

Andy



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