RAQMON congestion-safe requirements

Andy Bierman <[email protected]>
Newsgroups gmane.ietf.rmonmib
Message-ID <[email protected]>
Hi,

I think there is a problem with the RAQMON congestion-safe 
requirements text.  The framework document and PDU document
do not align well on this subject.  There are no MUST requirements
for maximum transmission rate of SNMP traps (not informs).
The WG agreed that an RDS MUST NOT send more than 1 trap PDU 
every 2 minutes.

Section 3 of the framework is too vague on the subject:

3. RAQMON Operation in Congestion-Safe Mode 

   ... the RAQMON Framework using UDP as a transport, congestion 
   safety can be achieved in following ways: 

[s/can/MUST/]

     1. Constant Transmission Rate: In a well-managed network a
         constant transmission rate policy (e.g. 1 RAQMON PDU per device
         every N seconds) will ensure congestion safety as devices are
         introduced into the network in a controlled manner.  For
         example, in an enterprise network, IP Phones are added in a
         controlled manner and a constant transmission rate policy can
         be sufficient to ensure congestion safe operation.  As a worst-
         case scenario, if the RDSs enforce an administrative policy
         where the maximum PDU transmission rate is no more than one
         RAQMON PDU every two minutes, a UDP based implementation can be
         as congestion safe as a TCP based implementation.  Such
         policies can be enforced while configuring an RDS.

[s/if the RDSs enforce/the RDS MUST enforce/]

      2. Retransmission timers with back offs: This approach requires
         that a request be sent at the application level, then there is
         a wait for some sort of response indicating that the request
         was received before sending anything else.  This produces an
         effect described by some as "ping-ponging" - traffic bounces
         back and forth between two nodes like a ping-pong ball in a
         match.  Since there's only one ball in play between any two
         players at any given time, most of the potential for congestion
         cascades is eliminated.  For example if RAQMON PDUs are
         transported using SNMP INFORM PDUs over UDP, a SNMP response
         from the RRC SHOULD be processed by the RDS to implement this
         mechanism.

[s/SHOULD be processed/MUST be processed/
 The WG already agreed that if Informs are used, they must be
 used correctly.  This is correct in the PDU spec, see below]

>From the PDU I-D, sec. 2.2:

      +  In order to meet congestion safety requirements, SNMP INFORM
         PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST
         process the SNMP INFORM responses from RRCs, and MAY serialize
         the PDU transmission rate, i.e. limit the number of PDUS sent
         in a specific time interval.

[This section is inconsistent with [framework, 3.3]. The Inform text
is correct (unlike the framework), but there needs to be explicit text 
about adhering to the [framework, 3.3] requirements if Trap PDUs
are used instead of Inform.]


Andy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.