RE: RAQMON Trap PDU size and report transmission time

Is this a call for consensus to make the RAQMON over TCP the only mandatory transport for RAQMON and SNMP notifications transport optional in RRCs? 

I can live with this. 

Regards,

Dan



> -----Original Message-----
> From: Andy Bierman [mailto:[email protected]]
> Sent: 18 January, 2005 7:54 PM
> To: Romascanu, Dan (Dan)
> Cc: Siddiqui, Anwar A (Anwar); [email protected]; Wijnen, Bert (Bert)
> Subject: RE: [RMONMIB] 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
> 
> 
> 
> 
> 
> 
> 
> >> 
>