RE: Begin WG Last Call: draft-ietf-rmonmib-raqmon-pdu-09

At 08:17 AM 1/17/2005, Romascanu, Dan \(Dan\) wrote:
>Andy,

I don't see why we need two transports for RAQMON reports.  

If I'm a developer looking to put RAQMON report generation 
code into an RDS platform, the probability that I would 
have UDP/SNMP but not have TCP in my stack is very close to zero.  
The probability that I would rather implement SNMP Informs than 
TCP for "reliability" are even lower.  I would probably want TCP 
to handle the send rate, rather than adhere to the super-restrictive
(1 PDU per 2 min?) throttling rate defined in RAQMON.  And finally, 
if I cared about code size, memory, and CPU utilization because 
the RDS is a small user device, I would be forced to choose TCP over SNMP.

Let's look at the problem from the perspective of an RFC reader
choosing between two options.  I'm sorry that the path the WG
took to get here has been so much work.  We tried to use existing
protocols for RAQMON transport before creating a new one.

Andy



>I will throw just one more argument, and then shut up and let indeed the non-authors speak their voice. I hope that they will do it to help us get an indication about were the potential users of the protocol stand. 
>
>The argument is not necessarily only technical I am afraid. This standard provides a solution for QoS performance monitoring of large networks. The hierarchical architecture RDS <>RRC<>NMS derives from a scalability problem that we try to overcome. The better chances are for this solution to catch in the application space if we look at what the RDSs are. For some of them SNMP agent implementation seems to be a big deal, and they would like to see a dedicated and more compact protocol for RDS<>RRC interaction. In other cases SNMP is already there in RDSs, and probably in RRCs as well if we look at the current RMON probes market. The application space is segmented and this is why we need two options for RDSs, while RRCs must support both. 
>
>I would also observe that the observations that you refer were not Last Call comments. The WG seemed to accept the SNMP solution for the last two years without any objection. Actually for people who do not follow Mreview, this discussion in the last two days may be a little obscure. The discussions were around a MIB Review criteria nit which seems to contradict the way the RDS MIB module uses  MAX-ACCESS in its reporting objects table. Even that discussion seems to settle now into relaxing this rule. I am asking again, are we not over-suspicious and block by ourselves a legitimate use of SNMP in performance monitoring that is needed in the market / application space? 
>
>The defense rests its case :-)
>
>Regards,
>
>Dan
>
>
>
>> -----Original Message-----
>> From: Andy Bierman [mailto:[email protected]]
>> Sent: 17 January, 2005 5:52 PM
>> To: Romascanu, Dan (Dan)
>> Cc: [email protected]
>> Subject: RE: [RMONMIB] Begin WG Last Call: 
>> draft-ietf-rmonmib-raqmon-pdu-09
>> 
>> 
>> At 09:20 AM 1/16/2005, Romascanu, Dan \(Dan\) wrote:
>> >Andy,
>> 
>> Dan,
>> 
>> If others besides the authors feel this strongly about it,
>> then that would be different.
>> 
>> I want to hear the technical reasons why somebody is going
>> to pick the SNMP transport over the TCP transport for RAQMON.
>> "We'll implement it because it's in the standard" is not a reason.
>> 
>> Defining multiple options for the same task is going to get
>> some IESG scrutiny.  We need reasonable technical advantages
>> (or use cases) to justify this.  So what are they? 
>> 
>> I'm bringing this up now because objections have been raised
>> during WG Last Call about it.  I think it is fair to make
>> sure the WG (not just the RAQMON authors) wants this feature.
>> 
>> 
>> >See in-line. 
>> >
>> >Regards, 
>> >
>> >Dan
>> 
>> Andy
>> 
>> 
>> 
>> >> I'm not asking for firm commitments.
>> >...
>> >> I want to avoid a scenario where people dismiss RAQMON (in favor
>> >> of proprietary or other approaches) because it has so much extra 
>> >> baggage they don't need and don't want to implement.  Do you
>> >> really think vendors are going to implement SNMP-transport in
>> >> their collector if none of their own (or foreseeable) products
>> >> plan to use it? What RDSs are they even going to test against?
>> >
>> >My company is doing both RDSs and collectors. I believe that 
>> we will implement the full RAQMON specification, whatever it 
>> ends being. 
>> >
>> >> 
>> >> > 
>> >> >> 
>> >> >> There are significant valid concerns that have been raised
>> >> >> regarding the use of SNMP, SNMP notification sender only (w/o 
>> >> >> a command responder), and UDP, for RDS to RRC communication.
>> >> >> 
>> >> >
>> >> >We do not propose to implement an SNMP notification sender 
>> >> only. We are talking about a full SNMP implementation 
>> >> ('agent'), we just propose that the reporting objects are 
>> >> only 'accessible-for-notify' in order to allow keeping the 
>> >> state in the RDSs beyond the emission of the notifications. 
>> >> 
>> >> This is a notification sender.  It is not a full agent.
>> >> See the thread on event driven polling as well. 
>> >
>> >No, it is a full agent. It may have whatever number of 
>> objects with read-only and/or read-write MAX-ACCESS. Only the 
>> RDS-MIB objects in this table would be accessible-for-notify.  
>> >
>> >> 
>> >> 
>> >> 
>> >> 
>> >> >> It seems that the SNMP transport mapping is inferior to the 
>> >> >> TCP transport mapping in every possible way:
>> >> >>   - code size
>> >> >>   - encoding size
>> >> >>   - complexity
>> >> >>   - congestion control
>> >> >>   - proper use of the (transport) protocol
>> >> >> 
>> >> >> If nobody plans to develop an SNMP-based RDS, then we don't
>> >> >> need to standardize it.  If you want to keep the SNMP 
>> Notification
>> >> >> transport, then speak up during this WG Last Call.  
>> >> >
>> >> >Are we bending because of a CLR over CLR discussion? Even 
>> >> this discussion seems to converge towards relaxing the text 
>> >> in the MIB Review Guidelines by replacing the famous 'i.e.' 
>> >> by a 'e.g.' - this being where this whole thread started. 
>> >> 
>> >> No.  See Juergen's objections to this transport.  
>> >> I have heard several times from at least one RAQMON author
>> >> that nobody will implement the SNMP-transport in the RDS and we
>> >> were only doing it to make the "SNMP people" feel happy.
>> >> Look at the list above.  Are you dismissing these technical 
>> >> arguments?  
>> >> Do you believe the SNMP transport is viable and will be 
>> used instead 
>> >> of the TCP transport?  If so, why?
>> >
>> >All the arguments above are valid arguments for any 
>> implementation and deployment of SNMP agents. But if a RDS 
>> device has already implemented the SNMP agent, and if it is 
>> deployed in an environment where the level of loss because of 
>> the UDP transport is acceptable, why should we impose another 
>> transport? 
>> >
>> >> I know the history.  The SNMP transport was an optimization
>> >> to get around the development of a new protocol, under the 
>> assumption
>> >> that it will be easier and faster to get to RFC 
>> publication this way.
>> >> Well, now we have a bloated, inefficient, sub-optimal standard
>> >> because of it.  We didn't save any time either, so let's just
>> >> decide on the technical merits.  
>> >> 
>> >
>> >I am certainly with you on deciding based on technical 
>> merits, but I do not believe that the SNMP solution was just 
>> an opportunistic proposal but a rather a realistic one. To me 
>> the arguments being brought in this discussion are too much 
>> on the line of defending the purity of the SNMP framework, 
>> and accepting them would prevent because of 'academic' 
>> reasons a very simple and straight-forward application of 
>> SNMP for devices that already have implemented SNMP. However, 
>> as I already said, I will accept the consensus of the WG. 
>> >
>> >> 
>> >> The TCP PDU parameters and SNMP Notification parameters are not the
>> >> same and it is not explained well how they exactly correlate.
>> >> 
>> >
>> >I wish you were more specific. Both TCP PDU fields and the 
>> objects in the SNMP Notifications refer the framework 
>> document. The MIB module definition uses the REFERENCE 
>> clauses. Where are the differences? 
>> >
>> >> 
>> >
>> >_______________________________________________
>> >RMONMIB mailing list
>> >[email protected]
>> >https://www1.ietf.org/mailman/listinfo/rmonmib 
>>