RE: RAQMON Trap PDU size and report transmission time

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

I am not in violent disagreement, although I consider that the complexity hit is not that terrible, and that processing inform replies should be in any case implemented by an agent. Also, I cannot argue with numbers, even if their impact would show up only in extreme cases. My question is whether these concerns are strong enough and lead us to the decision to drop completely the SNMP option as a transport for RDSs that already have an SNMP agent. Do you believe that the incremental complexity in the agent is higher than the complexity of supporting the new protocol? 

This is again for RDSs that already have SNMP. 

Regards,

Dan





>