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