RE: RAQMON Trap PDU size and report transmission time

So why not make it an OPTIONAL interface in RRC as well and not make it
mandatory for compliance. Let the industry decide the direction!

Anwar

-----Original Message-----
From: Andy Bierman [mailto:[email protected]] 
Sent: Tuesday, January 18, 2005 2:30 PM
To: Romascanu, Dan (Dan)
Cc: [email protected]; Siddiqui, Anwar A (Anwar); Wijnen, Bert (Bert)
Subject: RE: [RMONMIB] RAQMON Trap PDU size and report transmission time

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

I could too.

I am very concerned about such a big mandatory collector
implementation requirement scaring off potential vendors
because they want to be able to say that they comply with 
the RAQMON standard, but would have to take a big development hit 
for something they don't need to comply.


>Regards,
>
>Dan

Andy




>> -----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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> >> 
>> 
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib