Real-time Application Quality-of-Service Monitoring (RAQMON) Framework
Extracted elements (23)
Aggregation functions (Mean, Min, Max) are performed at the RRC rather than the RDS because RRCs have significantly greater computational resources, deliberately offloading statistical processing from constrained end-devices to the collector infrastructure.
RDSs use a PUSH (asynchronous) mechanism rather than a poll/response model because RDS firmware runs on low-powered embedded devices not in the data-forwarding path; the application determines PDU content appropriate for its context and sends reports to RRCs without solicitation.
Static or pseudo-static metrics that do not change during a session (e.g., DA, RA, DN, payload type) are RECOMMENDED to be sent only at session initiation and then at large intervals, rather than in every PDU, to minimize bandwidth consumption on constrained devices.
When UDP is used instead of TCP, congestion safety can be achieved by: (1) a constant transmission rate policy with jittered timers (e.g., at most one PDU every two minutes), (2) single-outstanding-request ping-pong serialization with backed-off retransmissions, or (3) restricting PDU size to local interface MTU to avoid fragmentation.
RTP support in an end-device can be detected by presence of the RTP MIB (RFC 2959) or by the Application Name (Section 5.32) beginning with the string 'RTP'; this detection governs which measurement methodology (RFC 3550 vs. RFC 2679/2680/2681) applies to delay, jitter, and packet loss metrics.
An RDS MUST send a RAQMON NULL PDU (containing ALL NULL values) to signal the end of a reporting session, since RDSs and RRCs are otherwise stateless across the entire reporting session.
Data Source Device Port Used (Section 5.5), Receiver Device Port Used (Section 5.6), and Application Name/Version (Section 5.32) MUST each be included in the first RAQMON PDU of a session.
For multi-CPU hosts, the maximum CPU utilization among all CPUs MUST be reported (Section 5.30), and similarly the maximum memory utilization MUST be reported (Section 5.31), rather than an average across CPUs.
If a late-arriving packet is discarded, it MUST be counted as either lost or discarded but MUST NOT be counted as both. If an RDS cannot distinguish discards from lost packets, it MUST report only lost packets and MUST NOT report discards.
Irrespective of the choice of transport protocol, it is RECOMMENDED that no more than 10% of network bandwidth be used for RDS-to-RRC reporting traffic.
RAQMON Data Sources MUST implement the TCP transport and MAY implement the SNMP transport for sending RAQMON PDUs to RRCs.
RAQMON Report Collectors MUST implement session timeout mechanisms to assume end of reporting for RDSs that have been silent for a reasonable duration; such timeout parameters SHOULD be configurable in vendor implementations as programmable parameters at deployment.
RAQMON Report Collectors MUST support the mandatory TCP mapping of the RAQMON information model as defined in RFC 4712 for receiving reports from RDSs, and MAY support the optional SNMP notifications mapping.
RAQMON Report Collectors MUST support the RAQMON-MIB module and meet the compliance requirements of the raqmonCompliance MODULE-COMPLIANCE definition described in RFC 4711; MIB population is independent of the transport protocol used between RDSs and RRCs.
RAQMON SHOULD NOT derive One-Way End-to-End Network Delay by assuming Internet paths are symmetric (i.e., by dividing Round-Trip Delay by two); actual one-way measurements per RFC 2679 must be used.
Transport protocols carrying RAQMON PDUs MUST meet scalability (handling many tens or hundreds of RDSs), congestion safety per RFC 2914, and security requirements providing strong secure modes or data encryption and integrity; NAT-friendliness per RFC 3235 is SHOULD.
A RAQMON PDU is divided into a BASIC part using SMI Enterprise Code 0 (IETF standard construct) containing pre-defined QoS metrics, and an Application-Specific Extensions part identified by vendor SMI Enterprise Codes for vendor-, device-, and application-specific parameters expressed as <Name, Value> pairs.
RAQMON defines three functional components: the RAQMON Data Source (RDS) on end-devices (IP phones, IM clients, etc.), the RAQMON Report Collector (RRC) as a computationally resourceful network server aggregation point, and the RAQMON MIB extending the RMON MIB for management application access via SNMP.
Session Setup Date/Time (Section 5.7) is encoded using the NTP timestamp format in seconds relative to 0h UTC on 1 January 1900 per RFC 1305; this parameter SHOULD be sent only in the first RAQMON PDU after session setup completes.
The BASIC part of the RAQMON PDU defines up to 32 pre-defined parameters covering session identifiers (DA, RA, DN, RN), session timing (setup time, setup delay, duration, status), network performance (round-trip delay, one-way delay, application delay, inter-arrival jitter, IPDV), packet counters (sent, received, lost, discarded, as counts and fractions), QoS markings (L2 priority, TOS/DSCP for source and destination), device resources (CPU and memory utilization), and application identification (name/version, payload type).
RAQMON relies entirely on transport-layer security (end-to-end authentication, confidentiality, integrity, replay protection) rather than defining application-level security mechanisms; absence of transport security implies absence of all RAQMON security, requiring deployments to ensure their transport choice supports secure operation.
RAQMON requires cryptographically strong security providing: (1) authentication so the RRC can verify PDU origin; (2) privacy via payload encryption (DES, 3-DES, AES) to prevent eavesdropping on session participants; and (3) DoS protection by having RDSs delay the first report until a session has been active for five seconds, preventing flooding the RRC with spurious short-lived sessions.
RAQMON threat classes include: unauthorized examination of sensitive session-participant information in transit; unauthorized modification causing session mismapping, DoS via parameter falsification, or invalid timestamps; malformed PDUs exploiting RRC implementation weaknesses; and unauthorized disclosure of communicating parties' identities.