RE: RAQMON Trap PDU size and report transmission time

At 09:28 AM 1/18/2005, Romascanu, Dan \(Dan\) wrote:
>> 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. 

I think the metric instrumentation and report collection is
the same either way.  The SNMP PDU encoding is going to be
bigger and slower than the TCP approach.  The biggest code hit
is that the SNMP approach requires the RAQMON code to be
aware of MTUs and avoid 'tooBig' errors by splitting the
OBJECTS list over 2 or more PDUs.

I would be much less concerned if the SNMP transport
was optional in the RRC.

Here is my last argument:
 - Multiple options should only be done in a standard when
   there are multiple use cases with different functional
   requirements that require different protocols (e.g., NETCONF)
 - The RAQMON authors (and WG) have done a very good job
   defining a RAQMON over TCP transport, with an efficient 
   and extensible binary report encoding.  It's so much 
   easier to implement, and has so much better performance and
   congestion behavior, that I think it should
   be the one and only mandatory RAQMON PDU transport.


>Regards,
>
>Dan

Andy







>>