RFC 4710

Real-time Application Quality-of-Service Monitoring (RAQMON) Framework

๐Ÿ“… published October 2006, from ietf

RFC 4710: Real-time Application Quality-of-Service Monitoring (RAQMON) Framework ๐ŸŽ€

okay bestie, let's start with the title block so you know who's behind this. ๐Ÿ’… It's RFC 4710, and the full title is "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework" โœจ. It's from the Network Working Group, and the authors are A. Siddiqui and D. Romascanu (both at Avaya) plus E. Golovinsky (at Alert Logic) ๐Ÿงš. It's on the Standards Track ๐Ÿ‘‘, dated October 2006 ๐Ÿ“. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ๐Ÿ™ˆ.

Status of This Memo ๐Ÿ“

ok so this is the bit that says what kind of doc this is. It's an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements ๐Ÿซถ. If you want the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) ๐Ÿ”ฅ. And distribution of this memo is unlimited, so share it with everyone ๐ŸŒธ.

Copyright (C) The Internet Society (2006). Legal stuff, but it's giving "we own this one" ๐Ÿ’œ.

Abstract ๐Ÿฆ‹

ok this is the TL;DR. There's a need to monitor end-devices like IP phones, pagers, Instant Messaging clients, mobile phones, and other handheld computing devices ๐Ÿ“ฑ. This memo extends the remote network monitoring (RMON) family of specifications so you can do real-time quality-of-service (QoS) monitoring of the apps running on those devices โœจ. Then you can integrate that info into the RMON family using the Simple Network Management Protocol (SNMP) ๐Ÿงš. The memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications ๐Ÿ’–. Literally the whole plan in one paragraph, iconic ๐Ÿ‘‘.

Table of Contents ๐Ÿ—‚๏ธ

   1. Introduction ....................................................2
   2. RAQMON Functional Architecture ..................................4
   3. RAQMON Operation in Congestion-Safe Mode .......................11
   4. Measurement Methodology ........................................14
   5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU .......14
   6. Report Aggregation and Statistical Data processing .............28
   7. Keeping Historical Data and Storage ............................29
   8. Security Considerations ........................................30
   9. Acknowledgements ...............................................32
   10. Normative References ..........................................33
   11. Informative References ........................................34

1. Introduction โœจ

okay so the internet keeps growing, and smart IP devices are basically everywhere now ๐Ÿ“ฑ๐ŸŒˆ. Think IP phones, pagers, instant message clients, mobile phones, wireless handhelds, and a bunch of other computing devices ๐Ÿ’…. Enterprise operators, IT managers, application service providers, network service providers, and so on all need to keep an eye on these apps and devices ๐Ÿ‘€. The goal is to make sure end users actually get the quality-of-service (QoS) they're supposed to get ๐Ÿ”ฅ. This memo describes a monitoring solution for these environments, and it extends the remote network monitoring (RMON) family of specifications [RFC2819] ๐Ÿฆ‹. These extensions support real-time QoS monitoring of typical apps on the end-devices I just mentioned, and they let you fold that info into the familiar RMON family via SNMP [RFC3416] ๐Ÿซถ.

The Real-time Application QoS Monitoring Framework (RAQMON) lets end-devices and applications report QoS statistics in real time โฑ๏ธโœจ. Lots of real-time apps (and non-real-time apps managed within the RMON family) can report application-level QoS statistics in real time using the RAQMON Framework in this memo ๐Ÿ’œ. Some scenarios include Voice over IP, Fax over IP, Video over IP, Instant Messaging (IM), Email, software download apps, e-business style transactions, web access from handheld computing devices, and so on ๐Ÿ“.

The experience a user has with an app on an IP end-device depends on what app they're running and what resources that app has around it ๐ŸŽ€. The end-to-end app QoS experience is a compound effect of various application-level transactions plus the available network and host resources ๐Ÿงš. Like, for a Voice over IP (VoIP) call, the user experience depends on how long it takes to set up the call just as much as on media-related performance stuff like end-to-end network delay, jitter, packet loss, and the type of codec used in the call ๐Ÿ“ž. A VoIP call is also affected by protocols like the Reservation Protocol (RSVP), by explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE 802.1 [IEEE802.1D], and by host resources like device CPU or memory that other apps are using while the call is going ๐Ÿ’€.

The end-to-end app QoS experience is also app context sensitive ๐Ÿ’…. For example, the parameters an IP telephony app reports might not really be needed for something like Instant Messaging ๐Ÿ’ฌ. So RAQMON offers a way to report the end-to-end QoS experience that fits a specific app context, by letting you report a subset of metrics from a pre-defined list ๐ŸŒธ.

To get a complete end-to-end view, RAQMON correlates statistics that involve:

i. "User, Application, Session"-specific parameters (e.g., session setup time, session duration parameters based on application context).

ii. "IP end-device"-specific parameters during a session (e.g., CPU usage, memory usage).

iii. "Transport network"-specific parameters during a session (e.g., end-to-end delay, one-way delay, jitter, packet loss etc).

At any given point, the apps on these devices can correlate all that diverse data and report end-to-end performance ๐Ÿ”ฅ. The RAQMON Framework in this memo gives you a way to report that end-to-end QoS view and bring it into the RMON family ๐Ÿ’–. Specifically, the RAQMON Framework specifies the following:

a. A set of basic metrics sent as reports between the RAQMON entities using for transport existing Internet Protocols such as TCP or SNMP.

b. Requirements to be met by the underlying transport protocols that carry the RAQMON reports.

c. A portion of the Management Information Base (MIB) as an extension of the RMON MIB Modules for use with network management protocols in the Internet community.

This memo gives you the RAQMON functional architecture, RAQMON entity definitions and requirements, requirements for the transport protocols, a set of metrics, and an information model for the RAQMON reports ๐Ÿฆ‹โœจ.

Supplementary memos will describe how the basic RAQMON metrics map onto different transport protocols ๐Ÿงš. For example, the RAQMON PDU [RFC4712] memo defines the syntactical PDU structure and use case scenarios for sending these PDUs over the Transmission Control Protocol (TCP) and the Simple Network Management Protocol (SNMP) ๐Ÿซถ.

The RAQMON MIB [RFC4711] memo describes the Management Information Base (MIB) for use with SNMP ๐ŸŒˆ. It proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solutions ๐Ÿ’œ.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] โš ๏ธ. These are the official BCP 14 key words, so read them carefully, bestie ๐Ÿ™ˆ.

2. RAQMON Functional Architecture ๐Ÿ—๏ธ

ok so the RAQMON Framework extends the architecture from the RMON MIB [RFC2819] by adding application performance info as experienced by end-users ๐Ÿ’–. The RAQMON architecture is based on three functional components:

  • RAQMON Data Source (RDS)
  • RAQMON Report Collector (RRC)
  • RAQMON MIB Structure

A RAQMON Data Source (RDS) is a functional component that acts as a source of data for monitoring purposes ๐Ÿงš. End-devices like IP phones, cell phones, and pagers, plus app clients like instant messaging clients and soft phones on PCs, are all envisioned to act as RDSs in the RAQMON Framework ๐Ÿ“ฑโœจ.

Here's the diagram, look at all the little arrows ๐Ÿ˜ญ:

   +----------------------+        +---------------------------+
   |    IP End-Device     |        |    IP End-Device   >----+ |
   |+--------------------+|        |+--------------------+   | |
   || APPLICATION        ||        || APPLICATION        |   | |
   ||  -Voice over IP   <----(1)----> -Voice over IP    >- + | |
   ||  -Instant Messaging||        ||  -Instant Messaging| | 3 |
   ||  -Email            ||        ||  -Email            | 2 | |
   |+--------------------+|        |+--------------------+ | | |
   |                      |        |                       | | |
   |                      |        | +------------------+  | | |
   +----------------------+        | |RAQMON Data Source|<-+ | |
                                   | |    (RDS)         |<---+ |
                                   | +------------------+      |
                                   +-----------|---------------+
                                               |
                                 (4) RAQMON PDU transported
                               over TCP or SNMP Notifications
                                               |
                  +----------------------------+
                  |                            |
                  |/                           |/
     +------------------+      +------------------+       +------------+
     |RAQMON Report     |  ..  |RAQMON Report     |       | Management |
     |Collector (RRC) #n|      |Collector (RRC) #1|<--5-->| Application|
     +------------------+      +------------------+       +------------+


                       Figure 1 - RAQMON Framework.

And here's what the numbers mean ๐Ÿ”ข:

(1) Communication Session between real-time applications

(2) Context-Sensitive Metrics

(3) Device State Specific Metrics

(4) Reporting session - RAQMON metrics transmitted over specified interfaces (Specific Protocol Interface, IP Address, port)

(5) Management Application - RRC interaction using the RAQMON MIB

A RAQMON Report Collector (RRC) collects statistics from multiple RDSs, analyzes them, and stores that info appropriately ๐Ÿ—„๏ธ. RRC is envisioned to be a network server serving an administrative domain defined by the network administrator ๐Ÿ‘‘. The RRC component is envisioned to be computationally resourceful ๐Ÿ’ช. Only RRCs should implement the RAQMON MIB module ๐Ÿ”’.

The RAQMON Management Information Base (RAQMON MIB) extends the Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework, and it exposes End-to-End Application QoS information to Network Management Applications ๐Ÿฆ‹โœจ.

2.1. RAQMON Data Source (RDS) ๐ŸŒธ

2.1.1. RAQMON Data Source (RDS) Functional Architecture ๐ŸŽ€

okay so an RAQMON Data Source (RDS) is basically any source of data for monitoring ๐Ÿ“Š and the monitoring happens in real time while the communication session is actually going on โœจ. RDS entities capture the QoS attributes of those sessions and report them inside a RAQMON "reporting session" ๐Ÿ’–

an RDS is mainly the thing that represents IP end-devices and applications inside the RAQMON architecture ๐Ÿฆ‹ it collects the parameters for one particular communication session and forwards them to the right RAQMON Report Collector (RRC). since the RDS is meant to run as firmware or software on potentially small, low-powered end-devices, it was designed with that in mind ๐ŸŒธ and just like routing and management protocol implementations, an RDS running on an end-device will typically run in the background, not in the data-forwarding path ๐Ÿซถ

RDSs use a PUSH mechanism to report QoS parameters ๐Ÿ”ฅ the applications on the RDS get to decide what goes in the PDU for their context, and then the RDS asynchronously sends reports out to the RRC ๐Ÿ’…

the rate at which PDUs leave RDSs and head to RRCs is controlled by the application's administrative domain policy ๐ŸŒˆ this gives IT managers and system administrators the flexibility to gather a detailed end-to-end experience, BUT certain steps should be followed to run RAQMON in a congestion-safe manner ๐Ÿ˜ญ Section 3 covers the steps required for congestion-safe operation, so go check that out ๐Ÿ‘‘

an RDS reports QoS statistics for simplex flows โœจ at any given instance, a report from an RDS is logically seen as a collection of QoS parameters tied to a communication session, as perceived by the reporting RDS ๐Ÿงš for example, say two IP phone users, Alice and John, are on a call ๐Ÿ“ž the end-to-end delay Alice's IP phone experiences could be different from the delay John's IP phone experiences, for all kinds of reasons ๐Ÿ™ˆ so a report from Alice's IP phone shows the QoS performance of that call as perceived by the RDS living in Alice's IP phone ๐Ÿ’œ

2.1.2. RAQMON Data Source (RDS) Requirements ๐Ÿ’…

  1. RAQMON Data Sources SHALL gather reports from multiple applications residing in that device and SHALL send out compound QoS reports associated with multiple communication sessions at a given moment ๐Ÿ”ฅ

examples include a conference bridge hosting several different conference calls, or a two-party video call made up of audio/video sessions ๐ŸŽ€ in each case, an RDS could send out one single RAQMON report made up of multiple sub-reports, either for the audio and video sessions or for each conference call ๐Ÿ“

  1. RAQMON Data Sources MUST implement the TCP transport and MAY implement the SNMP transport ๐Ÿซถ

2.1.3. Configuring RAQMON Data Sources โญ

in order to report statistics to RAQMON Report Collectors, RDSs will need to be configured with the following parameters ๐ŸŒธ

  1. The time interval between RAQMON PDUs. This parameter MUST be configured such that overflow of any RAQMON parameter within a PDU between consecutive transmissions is avoided ๐Ÿ˜ญ
  2. The IP address and port of the target RRC ๐Ÿ’–

an RDS may use manual configuration for its RDS configuration parameters, using a command line interface (CLI), a Telephone User Interface (TUI), etc. ๐Ÿฆ‹

one of the following mechanisms to get access to configuration parameters can also be considered ๐Ÿ‘€

  • RDS acts as a trivial file transfer protocol (TFTP) client and downloads text scripts to read the parameters.
  • RDS acts as a Dynamic Host Configuration Protocol (DHCP) client and gets RRC addressing information as a DHCP option.
  • RDS acts as a DNS client and gets target collector information from a DNS Server.
  • RDS acts as an LDAP client and uses directory look-ups.

identifying the DHCP option and structure to use, defining the structure of the configuration information in DNS, or defining an LDAP schema could be explored as items of future work ๐Ÿ”ฎ

compliance to the RAQMON specification does not require using any of the specific configuration mechanisms mentioned above ๐Ÿ™Œ it's left up to implementers to choose the appropriate provisioning mechanisms for their system ๐Ÿ’…

2.2. RAQMON Report Collector (RRC) โœจ

2.2.1. RAQMON Report Collector (RRC) Functional Architecture ๐Ÿงš

a RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple RDSs, then analyzes and stores the information in the RAQMON MIB ๐Ÿ“š the RRC is meant to be computationally resourceful, acting as a storage and aggregation point for a set of RDSs ๐Ÿ’ช

since RDSs can belong to separate administrative domains, the RAQMON Framework lets RDSs report QoS parameters to separate RRCs ๐ŸŒˆ vendors can develop a management application that correlates information sitting in different RRCs across multiple administrative domains, so it represents one communication session ๐Ÿฆ‹ however, that kind of application-level specification is beyond the scope of this memo ๐Ÿ™ƒ

2.2.2. RAQMON Report Collector (RRC) Requirements ๐Ÿ“‹

  1. RAQMON Report Collectors MUST support the mandatory mapping over TCP of the RAQMON information model defined in [RFC4712] for the purpose of receiving RAQMON reports from RAQMON Data Sources (RDS) ๐ŸŽ€
  2. RAQMON Report Collectors MAY support the optional mapping over SNMP notifications of the RAQMON information model defined in [RFC4712] ๐ŸŒธ
  3. RAQMON Report Collectors MUST implement session timeout mechanisms to assume the end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such timeout parameters SHOULD be configurable in vendor implementations, as programmable parameters at deployment โฑ๏ธ
  4. RAQMON Report Collectors MUST support the RAQMON-MIB module and meet the compliance requirements of the raqmonCompliance MODULE-COMPLIANCE definition as described in [RFC4711]. the population of the RAQMON MIB with performance monitoring information is independent of the transport protocol, or protocols, used to carry the information between RDSs and RRCs ๐Ÿซถ

2.3. Information Model and RAQMON Protocol Data Unit (PDU) ๐Ÿงฉ

2.3.1. RAQMON Information Model ๐Ÿ’œ

RAQMON defines a set of basic metrics that characterize the QoS of applications, as reported by RAQMON Data Sources ๐Ÿ“Š this basic set is defined in Section 5 of this memo ๐Ÿ‘€ there is no minimal requirement for a mandatory set of metrics to be supported by an RDS ๐Ÿคทโ€โ™€๏ธ

specific applications, new types of network appliances, or new methods to measure and characterize the QoS of applications mean the information model has to be extensible ๐Ÿ”ฅ to cover that, the information model is designed so vendors can extend it by adding new metrics ๐ŸŒˆ

although NOT REQUIRED for RAQMON conformance, extensions of the information model can offer useful information for specific applications ๐Ÿ’… an example of metrics that can extend the basic RAQMON information model is the detailed metrics for VoIP media monitoring and call quality included in the VoIP Metrics Report Block defined in [RFC3611] ๐ŸŽง

the RAQMON information model is expressed by defining a conceptual RAQMON Protocol Data Unit (PDU) โœจ

2.3.2. RAQMON Protocol Data Unit ๐Ÿฆ‹

a RAQMON Protocol Data Unit (PDU) is a common data format understood by RDSs and RRCs ๐Ÿค a RAQMON PDU does not transport application data; instead, it takes the place of a payload specification at the application layer of the protocol stack ๐Ÿง  different transport mappings may be used to carry RAQMON PDUs between RDSs and RRCs ๐Ÿšš transport protocol requirements are being defined in Section 2.4 of this memo ๐Ÿ“

even though it's architected conceptually as a single PDU, the RAQMON PDU is functionally divided into two different parts ๐Ÿ’– they are the BASIC part, and the Application-Specific Extensions, which are required for application-, vendor-, and device-specific extensions ๐Ÿง

The BASIC part of the RAQMON PDU:

the BASIC part of the RAQMON PDU follows the SMI Network Management Private Enterprise Code 0, which indicates an IETF standard construct ๐Ÿ›๏ธ it offers an entry-type from a pre-defined list of QoS parameters defined in Section 5, and lets applications fill in appropriate values for those parameters ๐ŸŽฏ application developers also have the flexibility to make an RDS report built from only a subset of the parameters listed in Section 5 ๐ŸŒธ there is no need to carry all metrics in every PDU ๐Ÿ™…โ€โ™€๏ธ moreover, it is RECOMMENDED that static or pseudo-static metrics, the ones that don't change or seldom change for a given session or application, are sent only when the session or application is initiated, and then at large time intervals ๐Ÿ•ฐ๏ธ

The Application part of RAQMON PDU:

since it is difficult to structure a BASIC part that meets the needs of all applications, RAQMON provides extension capabilities to convey application-, vendor-, and device-specific parameters for future use ๐ŸŒˆ additional parameters can be defined within the payload of the APP part of the PDU by application developers or vendors ๐Ÿ› ๏ธ the owner of the definition of the application part of the RAQMON PDU is indicated by a vendor's SMI Network Management Private Enterprise Code, which is defined in http://www.iana.org/assignments/enterprise-numbers ๐Ÿ”— such application-specific extensions should be maintained and published by the application vendor ๐Ÿ“ข

though RDSs and RRCs are designed to be stateless for an entire reporting session, the framework requires an indication for the end of the reporting ๐Ÿ for this purpose, an RDS MUST send a RAQMON NULL PDU ๐Ÿซง a NULL PDU is a RAQMON PDU containing ALL NULL values (i.e., nothing to report) ๐Ÿ’€

2.4. RDS/RRC Network Transport Protocol Requirements ๐Ÿššโœจ

okay bestie, so RAQMON PDUs totally rely on whatever underlying protocol(s) they ride on to handle the transport stuff ๐Ÿ’… like transport reliability, retransmission, error correction, length indication, congestion safety, fragmentation/defragmentation, etc. ๐ŸŽ€ and the max length of a RAQMON data packet is only limited by those underlying protocols, so RAQMON isn't adding its own cap ๐ŸŒธ

these requirements MUST be met by the transport protocols, no cap ๐Ÿซถ

  1. The transport protocol SHOULD allow for RDS lightweight implementations. RDSs will be implemented on low-powered embedded devices with limited device resources ๐Ÿ”‹
  2. Scalability ๐Ÿ“ˆ Since RRCs need to interact with a very large number (many tens, many hundreds, or more) of RDSs, scalability of the transport protocol is REQUIRED. big main character energy ๐Ÿ‘‘
  3. Congestion safety ๐Ÿšฆ as per [RFC2914]. See also Section 3.
  4. Security ๐Ÿ” Since RAQMON statistics may carry sensitive system information requiring protection from unauthorized disclosure and modification in transit, a transport protocol that provides strong secure modes or allows for data encryption and integrity to be applied is REQUIRED. ๐Ÿ˜ญ this one is lowkey the most serious, bestie
  5. NAT-Friendly ๐Ÿฆ‹ The transport protocol SHOULD comply with [RFC3235], so that an RDS could communicate with an RRC through a Firewall/Network Address Translation device.
  6. The transport protocol MAY implement session timeout mechanisms to assume end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such timeout parameters SHOULD be configurable in vendor implementations, programmable at deployment โฐ
  7. Reliability ๐Ÿ’œ The RAQMON Framework expects PDUs to operate in lossy networks. However, retransmission is not included in the RAQMON framework, in order to keep the design simple. If retransmission is a necessity, RAQMON MAY operate over transport protocols, such as TCP.

In the future, if RAQMON PDUs are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation for the RAQMON packets must be defined to provide a framing mechanism. Framing is also needed if the underlying protocol contains padding so that the extent of the RAQMON payload cannot be determined. No framing mechanism is defined in this document. Carrying several RAQMON packets in one network or transport packet reduces header overhead ๐Ÿงš

Further memos like [RFC4712] describe how the PDU is transported over existing protocols like the Transmission Control Protocol (TCP) or the Simple Network Management Protocol (SNMP) ๐Ÿ“ฌ

3. RAQMON Operation in Congestion-Safe Mode ๐Ÿ›ก๏ธ

okay so RAQMON PDUs can be sent over multiple transport protocols ๐Ÿš€ The RAQMON Framework will be congestion safe if a RAQMON PDU is transported over TCP, full stop ๐Ÿ’–

one solution to the congestion awareness problem could have been to discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs can be transported over TCP, some transports like SNMP over TCP are not commonly practiced in practical deployments ๐Ÿคทโ€โ™€๏ธ

the use of UDP inherently increases the risks of network congestion problems, since UDP itself doesn't define congestion prevention, avoidance, detection, or correction mechanisms ๐Ÿ˜ฌ the fundamental problem with UDP is that it provides no feedback mechanism to let a sender pace its transmissions against the real performance of the network. While this tends to have no significant effect on extremely low-volume sender-receiver pairs, the impact of high-volume relationships on the network can be severe ๐Ÿ’€ this problem could be further aggravated by large RAQMON PDUs fragmented at the UDP level. Transport protocols such as DCCP can also be used as underlying RAQMON PDU transport, which gives you the flexibility of UDP-style datagram transmission with congestion control โœจ

it's worth noting that the congestion problem isn't just between RDS and RRC pairs. Whenever there's a high fan-in ratio, congestion could happen (e.g., many RDSs reporting to an RRC) ๐ŸŒŠ within the RAQMON Framework using UDP as a transport, congestion safety can be achieved in the following ways:

  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. The configured rate needs to be related to the expected peak number of devices. 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 RDSs, and the timers for the constant rate need to be randomly jittered ๐ŸŽฒ
  2. Single outstanding requests ๐Ÿ“ 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 reliability and efficiency reasons, this technique must include backed-off retransmissions. For example, if RAQMON PDUs are transported using SNMP INFORM PDUs over UDP, an SNMP response from the RRC SHOULD be processed by the RDS to implement this mechanism. [RFC4712] specifies that if the SNMP notifications transport mapping mechanism is implemented, it is RECOMMENDED to use INFORM PDUs, and it is NOT RECOMMENDED to use Trap PDUs.

This pacing or serialization approach has the side-effect of significantly reducing the maximum throughput, since transmission only happens in one direction at a time and there's at least a 2xRTT (round-trip time) delay between transmissions. More sophisticated algorithms (such as those in TCP and Stream Control Transmission Protocol (SCTP)) have been developed to address this, and it would be inappropriate to duplicate that work at the application level. So if greater efficiency is required than this simple approach provides, implementers SHOULD use TCP, SCTP, or another such protocol. But if one absolutely must use UDP, this approach works. It has also been used in other application scenarios, like SIP over UDP ๐Ÿ™Œ

  1. By restricting transmission to a maximum transmission unit (MTU) size ๐Ÿ“ฆ An RDS may be faced with a request to deliver a large message using UDP as a transport. Fragmentation of such messages is problematic in several ways. Loss of any fragment requires a time-out and retransmission of the message. The fragments are commonly transmitted out of the interface at local interface (usually LAN) rates, without awareness of the intervening network conditions. For these reasons, it is generally considered bad practice to send large PDUs over UDP. If the MTU size is known, as an implementation, an RDS should not allow an application to send more information by limiting the size of transmissions over UDP to reduce the effects of fragmentation. As an alternative, an RDS MAY also send parameters to the RRC over multiple RAQMON PDUs but identify them as part of the same RAQMON reporting session with exactly the same Network Time Protocol (NTP) [RFC1305] time stamp.

While the actual MTU of a link may not be known, common practice seems to indicate that the RDS local interface MTU is likely to be a reasonable "approximation". Where the actual path MTU is known, that value SHOULD be used instead ๐Ÿ“

  1. Irrespective of choice of transport protocol, it is also RECOMMENDED that no more than 10% network bandwidth be used for RDS/RRC reporting. More frequent reports from an RDS to an RRC would imply requirements for higher network bandwidth usage ๐Ÿ“‰

4. Measurement Methodology ๐Ÿ“

it's not the intent of this document to recommend a methodology for measuring any of the QoS parameters defined in Section 5 ๐Ÿ™ˆ measurement algorithms are left to the implementers and equipment vendors to choose. There are many different measurement methodologies out there for measuring application performance, including probe-based, client-based, synthetic-transaction, and other approaches ๐Ÿ“ this specification doesn't mandate a particular methodology and is open to any methodology that meets the minimum requirements. For conformance to this specification, it is REQUIRED that the collected data match the semantics described herein. However, it is RECOMMENDED that vendors use IETF-defined and International Telecommunication Union (ITU)-specified methodologies to measure parameters when possible ๐Ÿ’…

5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU ๐Ÿ“Š

okay so the BASIC part of the RAQMON PDU gives you a list of pre-defined parameters that applications use all the time to characterize end-to-end application Quality of Service ๐ŸŒˆ this section defines a set of simple metrics to be contained in the BASIC part of the RAQMON PDU, by referring to existing IETF, ITU, and other standards organizations' documents. Appropriate IETF or ITU references are included in the metrics definitions ๐Ÿ“š

as mentioned earlier, the RAQMON PDU also has an application-specific part, where application- and vendor-specific information not included in the BASIC part can be added as <Name, Value> pairs, or as a variable binding list. These extensions, managed independently by vendors or other organizations, should be published for wider interoperability ๐Ÿงฉ

applications aren't required to report all the parameters in this section, but should have the flexibility to report a subset that fits their context ๐Ÿ’– the memo further identifies the parameters that RDSs are required to include in all PDUs for compliance, as well as optional parameters that RDSs may report as needed. The definitions here are meant to guide implementers, and IETF metric definition references are provided for each metric. Application developers should choose the metrics that fit their app's needs ๐Ÿซถ syntactical representations of the parameters identified here are provided in the [RFC4712] specification โœจ

5.1. Data Source Address (DA) ๐Ÿ’–

Okay so the Data Source Address (DA) is just the address of the data source ๐Ÿซถ It can be either a globally unique IPv4 or IPv6 address, or a privately allocated IPv4 address as defined in [RFC1918].

The DA is expected to stay the same for the whole communication session ๐Ÿฆ‹ So RDSs SHOULD avoid sending it in RAQMON reports too often, which keeps network resources efficient โœจ

5.2. Receiver Address (RA) ๐ŸŽ€

The Receiver Address (RA) is basically the DA's bestie ๐Ÿ‘ฏโ€โ™€๏ธ It has the same form, but it represents the Receiver's address instead. In a session, the reporting RDSs SHOULD fill in the other party's address as the RA. Like the DA, it can be a globally unique IPv4 or IPv6 address, or a privately allocated IPv4 address as defined in [RFC1918].

The RA is also expected to stay constant for the session, so RDSs SHOULD avoid sending it in RAQMON reports too often, to keep network resources efficient ๐Ÿ’…

5.3. Data Source Name (DN) ๐ŸŒธ

The Data Source Name (DN) can look different depending on what the application needs ๐Ÿงš Some of the forms it can take include, but aren't limited to, the following:

  • user@host, or just host if there's no user name (like on single-user systems). For both of these formats, host is the fully qualified domain name of the host the payload comes from, formatted according to the rules in [RFC1034], [RFC1035], and Section 2.1 of [RFC1123]. Example names are big-guy@example.com or big-guy@192.0.2.178 for a multi-user system. On a system with no user name, an example would be ip-phone4630.example.com. It is RECOMMENDED that the standard host's numeric address not be reported via the DN parameter, because the DA parameter is already used for that purpose ๐Ÿ™ˆ
  • Another DN could be a valid E.164 phone number, a SIP URI, or any other form of telephone or pager number ๐Ÿ“ž The phone number SHOULD be formatted with a plus sign replacing the international access code. For example, +44-116-496-0348 is a number in the UK ๐Ÿ‡ฌ๐Ÿ‡ง

The DN is expected to stay the same for the whole session ๐Ÿ”ฅ So RDSs SHOULD avoid sending it in RAQMON reports too often, for efficient use of network resources.

5.4. Receiver Name (RN) ๐Ÿ’œ

The Receiver Name (RN) has the same form as the DN, but it's the name of the receiver instead ๐Ÿฅฐ In a session, an application SHOULD supply as the RN the name of the other party it's talking to.

The RN is expected to stay constant for the session too, so RDSs SHOULD avoid sending it in RAQMON reports too often, to keep network resources efficient โœจ

5.5. Data Source Device Port Used ๐Ÿ“

This parameter tells you which source port the application used for a particular session or sub-session ๐Ÿ‘€ Examples of ports include TCP Ports or UDP Ports, as used by application protocols like Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), H.323, RTP, HyperText Transport Protocol (HTTP), and so on.

This parameter MUST be sent in the first RAQMON PDU. No exceptions, bestie ๐Ÿซก

5.6. Receiver Device Port Used ๐Ÿฆ‹

This one is the receiver's port for a particular session or sub-session ๐Ÿ’… Examples are TCP Ports or UDP Ports used by application protocols such as SIP, SIMPLE, H.323, RTP, HTTP, and so on.

This parameter MUST be sent in the first RAQMON PDU. Iconic behavior ๐Ÿ‘‘

5.7. Session Setup Date/Time โญ

This parameter gives the time when the setup was initiated, if the application has a setup phase. If there's no setup phase, it gives the time the session was started instead โฐ The time is represented using the timestamp format of the Network Time Protocol (NTP), which counts seconds relative to 0h UTC (Coordinated Universal Time) on 1 January 1900 [RFC1305]. Yes, 1900. The vintage is real ๐Ÿ˜ญ

This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.

5.8. Session Setup Delay ๐ŸŒˆ

The Session Setup Delay metric tells you how long it took from an origination request being started by a host or endpoint until the media path was established (or until a session progress indication came back from the remote host or endpoint). It's measured in milliseconds โšก For example, in VoIP systems, the setup time can be measured from the last DTMF (dual-tone multi-frequency) button pushed to the first ring-back tone, which tells you the far end is ringing ๐Ÿ“ฑ Another example is the Session Setup Delay of a SIP call, which is the elapsed time between when an INVITE is generated by a User Agent and when the 200 OK is received ๐ŸŽถ

This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.

5.9. Session Duration ๐Ÿ•ฐ๏ธ

The Session Duration metric reports how long a session or a sub-session lasted โณ It's very application context sensitive, so it depends on what you're doing. For example, a VoIP Call Session Duration can be measured as the elapsed time between call pickup and call termination, and that includes the session setup time too ๐Ÿ“ž

This parameter SHOULD be sent only in the first RAQMON PDU, after the session is terminated. Gone but not forgotten ๐Ÿ‘‹

5.10. Session Setup Status ๐Ÿšฆ

The Session Setup Status metric is meant to report the communication status of a session ๐Ÿ’ฌ Its values name the session states, like Call Progressing, Call Established successfully, "trying", "ringing", "re-trying", "RSVP reservation failed", and so on.

Session setup status only makes sense in the context of an application, which is why applications SHOULD use this metric together with the application/name metrics defined in Section 5.32 ๐Ÿง 

This info can be used by network management systems to calculate things like call success rate and call failure rate ๐Ÿ“Š It can also be used by a debugging tool that captures the status of a call's setup phase as soon as the call is established ๐Ÿ”

This parameter SHOULD be sent after each change in the session status. Keep the tea flowing โ˜•

5.11. Round-Trip End-to-End Network Delay ๐Ÿ”

The Round-Trip End-to-End Network Delay is defined in [RFC3550] for applications running over RTP, and in [RFC2681] for all other IP applications. It is a key metric for Application QoS Monitoring ๐Ÿ‘‘ Some applications don't perform well (or at all) if the end-to-end delay between hosts is large compared to some threshold value. Erratic variation in delay values makes it hard (or impossible) to support many real-time applications, like Voice over IP, Video over IP, Fax over IP, and so on ๐Ÿ˜ฉ

The round-trip delay of the underlying transport network is measured using the methodologies described in [RFC3550] for RTP, and in [RFC2681] for other IP applications ๐Ÿ“

Heads up: the packets used for measurement in some methodologies may be a different type from the ones used for media (for example, ICMP instead of RTP). That means they may differ in terms of route and queue priority. So the measured delays might not match what the media path actually experiences ๐Ÿ™ƒ For this metric to be conformant, actual application packets, or packets of the same application type, must be used.

Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications, or by including the string RTP at the beginning of the Application Name (Section 5.32) ๐Ÿ”Ž

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐Ÿ’–

5.12. One-Way End-to-End Network Delay ๐Ÿ›ค๏ธ

The One-Way End-to-End Network Delay metric [RFC2679] reports the one-way end-to-end delay that traffic experiences from the source to the destination network interface ๐Ÿš€ One-Way Delay measurements identified by the IP Performance Metrics (IPPM) Working Group [RFC2679] are used to measure one-way end-to-end network delay.

Why do we even need this? Because the path from a source to a destination can be different from the path back from the destination to the source ("asymmetric paths"). Different sequences of routers can be used for the forward and reverse paths ๐Ÿ™ƒ So round-trip measurements are actually measuring two distinct paths together, which is a bit of a mess ๐ŸŒ€

Measuring each path on its own shows the performance difference between the two. Those paths might go through different Internet service providers, or even totally different types of networks (for example, research versus commodity networks, or ATM (Asynchronous Transfer Mode) versus Packet-over-SONET (Synchronous Optical) transport networks) ๐ŸŒ

Even when the two paths are symmetric, they can have very different performance because of asymmetric queuing ๐Ÿงฉ An application's performance may depend mostly on one direction. For example, a file transfer using TCP may depend more on the direction data flows than on the direction acknowledgements travel ๐Ÿ“

In QoS-enabled networks, provisioning in one direction can be totally different from provisioning in the reverse direction, so the QoS guarantees can differ too ๐ŸŽฏ Measuring the paths independently lets you verify both guarantees โœ…

Don't cheat, bestie: RAQMON SHOULD NOT derive One-Way End-to-End Network Delay by assuming Internet paths are symmetric (that is, by dividing Round-Trip Delay by two) ๐Ÿšซ

Same heads up as before: the packets used for measurement in some methodologies may be a different type from the ones used for media (for example, ICMP instead of RTP). That means they may differ in terms of route and queue priority, so the measured delays might not match what the media path experiences ๐Ÿซ  For this metric to be conformant, actual application packets, or packets of the same application type, must be used.

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐ŸŒŸ

5.13. Application Delay โœจ

okay so the network delay versions in 5.11 and 5.12 don't count the time your device spends buffering, playing stuff out, putting packets back in order, or coding and decoding ๐Ÿ’…. Application Delay is the metric that's meant to catch all of that, so you get one total application endpoint delay ๐ŸŽ€

Application delay can be expressed as the time delay introduced between the network interface and the application-level presentation. Since it's basically impossible to picture every app out there, the spec gives implementers some guidance for measuring it:

  • The sending end contribution to application delay is defined as the sum of sample sequencing, accumulation, and encoding delay.
  • The receiving end contribution to application delay is calculated as the sum of delays associated with buffering, play-out, packet-sequencing, and decoding associated with the receiving direction, if relevant.

The endpoint application delay is the sum of the receiving and sending contributions, measured or estimated within the endpoint that's generating the report ๐Ÿงš

It's totally possible for two apps on the same IP device to have the same network delay but different application delay values ๐Ÿฆ‹ So the user experience can vary between apps even when the network delay stays the same for both.

Once you have both network delay and application delay measurements, a management application can show the delay the end user feels at the application level, as the sum of network delay and the application delays reported from the endpoints. BUT the spec for that management application is outside the scope of the RAQMON specification, so that's a different story ๐Ÿ™ˆ

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.14. Inter-Arrival Jitter ๐ŸŒธ

The Inter-Arrival Jitter metric gives you a short-term measure of network congestion [RFC3550]. Jitter can be a heads-up for congestion before it turns into packet loss, which is iconic behaviour ๐Ÿ‘‘

The inter-arrival jitter field is only a snapshot of the jitter at the moment a RAQMON PDU is generated. It's NOT meant to be read quantitatively, as [RFC3550] explains. It's really for comparing inter-arrival jitter from one receiver over time. This info is super useful for understanding apps like Voice over IP and Video over IP, and it's also used to size play-out buffers for apps that need packets delivered regularly, like voice or video play-out ๐ŸŽ€

In [RFC3550], the selection function is implicitly applied to consecutive packet pairs, and the "jitter estimate" is computed by applying an exponential filter with parameter 1/16 to generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new) โœจ

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.15. IP Packet Delay Variation ๐Ÿ’œ

[RFC3393] gives guidance on several absolute jitter parameters. RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation (ipdv) for packets inside a stream of packets ๐Ÿฆ‹

This metric helps figure out the dynamics of queues inside a network (or router). Changes in delay variation can be linked to changes in queue length processes at a given link or a combo of links. So it gives you visibility into the IP network and helps you understand app-level performance problems that come from IP network performance. Main character energy ๐Ÿ‘‘

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.16. Total Number of Application Packets Received ๐Ÿ“ฆ

This metric reports the number of application payload packets the RDS has received as part of this session, counting from the last RAQMON PDU that was sent up until the moment this RAQMON PDU was generated.

It's a super simple incremental counter that counts the "application" packets an RDS has received. Application packets MAY include signaling packets. Since this count is a snapshot in time, it also changes depending on the application state. So an RDS in an app session will report the aggregated number of application packets sent out during signaling setup, media packets received, session termination, and so on ๐Ÿ“

For example, during Voice over IP or Video over IP session setup, this counter covers the signaling-session-related packets received. Those come from the relevant application signaling protocol stack, like SIP or H.323, SIMPLE, and other signaling protocols the app uses to set up the communication session.

BUT when media is set up between the communicating entities, this counter shows the number of RTP Frames sent out to the communicating party since the last PDU went out. The methodology in the RTCP SR/RR reports [RFC3550] for counting RTP frames gets applied wherever apps use RTP โœจ Because this is a cumulative counter, apps need to think about the possibility of it overflowing and restarting from zero ๐Ÿ’€

You can tell if RTP is supported either by the RTP MIB [RFC2959] being supported on the hosts running the apps, or by the string 'RTP' showing up at the beginning of the Application Name (Section 5.32) ๐Ÿซถ

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.17. Total Number of Application Packets Sent ๐Ÿš€

This metric reports the number of signaling and payload packets the RDS has sent as part of this session, counting from the last RAQMON PDU sent until this RAQMON PDU was generated. Applications packets MAY include signaling packets ๐ŸŒˆ

It's similar to the Total Number of Application Packets Received parameter in Section 5.16, so this count is also a snapshot in time. Depending on the app type, the counter also changes with the app states, including packet counts for signaling setup, media establishment, session termination, and so on. It's a cumulative counter too, so apps need to think about the possibility of it overflowing and restarting from zero ๐Ÿ”ฅ

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.18. Total Number of Application Octets Received ๐Ÿ“

This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session, since the last RAQMON PDU was sent and up until the moment this RAQMON packet was generated. Applications octets MAY include signaling octets ๐Ÿง

The methodology described by [RFC3550] gets applied wherever apps use RTP. It's a cumulative counter, so apps need to think about overflowing and restarting from zero, same as always ๐Ÿ’…

You can tell if RTP is supported either by the RTP MIB [RFC2959] being supported on the hosts running the apps, or by the string 'RTP' at the beginning of the Application Name (Section 5.32) ๐ŸŽ€

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.19. Total Number of Application Octets Sent ๐ŸŒท

This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session, since the last RAQMON PDU was sent and up until the moment this RAQMON packet was generated. Yes, it says "received" there, and yes, that's how the spec words it ๐Ÿ™ˆ It's similar to the Total Number of Application Octets Received metric. Applications octets MAY include signaling octets.

The methodology described by [RFC3550] gets applied wherever apps use RTP. It's a cumulative counter, so apps need to think about overflowing and restarting from zero โœจ

You can tell if RTP is supported either by the RTP MIB [RFC2959] being supported on the hosts running the apps, or by the string 'RTP' at the beginning of the Application Name (Section 5.32) ๐Ÿฆ‹

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.20. Cumulative Packet Loss ๐Ÿ’€

The cumulative packet loss metric shows the loss associated with the network as well as local device losses over time. It's counted as the total number of application packets from the source that have been lost since the start of the session. This number is the number of packets expected minus the number of packets actually received, where the packets received includes the count of packets that are late or duplicates. If a packet gets discarded because it arrived late, then it MUST be counted as either lost or discarded, but it MUST NOT be counted as both. Not double-counting, bestie ๐Ÿ˜ค

Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is the extended last sequence number received, as defined next, minus the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550] ๐Ÿ“Š

Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is the extended last sequence number received, as defined next, minus the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550] ๐Ÿ”

You can tell if RTP is supported either by the RTP MIB [RFC2959] being supported on the hosts running the apps, or by the string 'RTP' at the beginning of the Application Name (Section 5.32) ๐ŸŒธ

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.21. Packet Loss in Fraction ๐Ÿฐ

The Packet Loss in Fraction metric is the packet loss we just talked about in the section above, but expressed as a fraction of the total traffic over time. Same loss, just dressed up as a ratio ๐Ÿ’–

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.

5.22. Cumulative Application Packet Discards ๐Ÿ—‘๏ธ

okay bestie so RAQMON lets apps tell apart the packets the network lost ๐ŸŒ from the ones the app tossed itself because of jitter or other app-level stuff ๐Ÿ’…. Both hurt quality the exact same way, fr fr, but having two separate counts helps you figure out where the glitch is actually coming from ๐Ÿ”โœจ

The packet discard metric tracks packets the device discarded locally over time. Basically it's the total number of application-level packets from the source that got thrown out since reception began, because they arrived late or early, the jitter buffer ran under or overflowed, or for any other application-specific reason ๐Ÿซง.

If the RDS can't tell discards apart from lost packets, then it MUST report only lost packets and MUST NOT report discards ๐Ÿ™…โ€โ™€๏ธ. no mixing them up bestie!

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐Ÿ’–.

5.23. Packet Discards in Fraction ๐Ÿฐ

this one is giving the discards-over-time vibe but as a fraction ๐Ÿงฎ. It represents packets from the source that have been discarded since the beginning of reception, expressed as a fraction of the total traffic over time. Main character math energy ๐Ÿ‘‘.

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐Ÿซถ.

5.24. Source Payload Type ๐ŸŽต

The source payload type reports the payload formats (like media encoding) as sent by the data source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. ๐ŸŽง This memo follows the definition of Payload Type (PT) in [RFC3551]. For example, to say the source payload type for a session is PCMA (pulse-code modulation with A-law scaling), the value of the source payload field for that session will be 8 ๐ŸŒธ.

The source payload type value is expected to stay constant for the whole session, except for stuff like dynamic codec changes ๐Ÿ”„. RDSs SHOULD avoid sending these parameters within RAQMON reports more often than necessary (e.g., at dynamic codec changes), so the network resources stay efficient ๐ŸŒฟ.

If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the source payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes ๐Ÿฆ‹. And if the RDS does send reports noting dynamic codec changes, this extension parameter might only show up before or after the codec change, since the source payload can hop between dynamic and static types ๐Ÿ™ˆ.

5.25. Receiver Payload Type ๐ŸŽ™๏ธ

The receiver payload type reports payload formats (like media encodings) as sent by the other communicating party back to the source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. ๐Ÿ’œ This document follows the definition of payload type (PT) in [RFC3551].

For example, to say the destination payload type used for a session is PCMA, the destination payload type field for that session will be 8 โœจ.

The destination payload type value is expected to stay constant for the duration of a session, except for events like dynamic codec changes ๐ŸŒˆ. RDSs SHOULD avoid sending these parameters within RAQMON reports more often than necessary (e.g., at dynamic codec changes), to keep network resources efficient ๐Ÿ’….

If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the destination payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes ๐ŸŽ€. Same deal as before: if the RDS does send reports noting dynamic codec changes, the extension might only be used before or after the change, because the destination payload can shift between dynamic and static types ๐Ÿซ .

5.26. Source Layer 2 Priority ๐Ÿšฆ

Lots of devices use Layer 2 technologies to prioritize certain types of traffic in the Local Area Network environment ๐Ÿ . For example, the 1998 Edition of IEEE 802.1D [IEEE802.1D], "Media Access Control Bridges", has expedited traffic capabilities to support time-critical information โฐ. Lots of devices use that standard to mark Ethernet frames according to IEEE P802.1p standard. Details can be found in [IEEE802.1D], which incorporates P802.1p ๐Ÿ“š.

The Source Layer 2 Priority RAQMON field tells you what Layer 2 values the host running the RDS used to prioritize these packets in the Local Area Network environment ๐Ÿซง.

The Source Layer 2 Priority value is expected to stay constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often, so the network resources stay efficient ๐ŸŒธ.

5.27. Source TOS/DSCP Value ๐ŸŒท

Various Layer 3 technologies are in place to prioritize traffic on the Internet ๐ŸŒ. For example, there's the traditional IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or newer stuff like Differentiated Services [RFC2474] [RFC2475], which use the TOS octet in IPv4. Meanwhile, the traffic class octet is used to prioritize traffic in IPv6 ๐Ÿ’ซ. The Source Layer TOS/DCP RAQMON field reports the appropriate Layer 3 values the Data Source used to prioritize these packets ๐Ÿงš.

The Source TOS/DSCP value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often, to ensure efficient usage of network resources ๐Ÿ“.

5.28. Destination Layer 2 Priority ๐Ÿ“ฌ

The Destination Layer 2 Priority reports the Layer 2 value the communication receiver used to prioritize packets while sending traffic back to the data source in the Local Area Networks environment ๐Ÿก. Like Source Layer 2 Priority, it could indicate whether the destination has used Layer 2 technologies like IEEE P802.1p for priority queuing ๐Ÿ”ฅ.

The Destination Layer 2 Priority value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often, to ensure efficient usage of network resources ๐Ÿ’–.

5.29. Destination TOS/DSCP Value ๐ŸŽฏ

The Destination TOS/DSCP RAQMON field reports the values the Data Receiver used to prioritize these packets received by the source ๐Ÿซถ. Similar to Source Layer 3 Priority, Destination Layer 3 Priority indicates whether the destination has used any Layer 3 technologies, like IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or newer ones like Differentiated Service [RFC2474] [RFC2475] ๐ŸŒˆ.

The Destination TOS/DSCP value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often, to ensure an efficient usage of network resources ๐Ÿ’….

5.30. CPU Utilization in Fraction ๐Ÿง 

This parameter captures the CPU usage of the hosts running the RDSs, which can be super critical for the QoS of an end-device ๐Ÿšจ. It's computed as an average since the last reporting interval, and corresponds to the percentage of that time the CPU was busy โฑ๏ธ.

In the case of multiple CPU hosts, the maximum utilization among the different CPUs MUST be reported ๐Ÿ‘‘.

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐Ÿ’œ.

5.31. Memory Utilization in Fraction ๐Ÿงฉ

This parameter captures the memory usage of the hosts running the RDSs, which can also be very critical for the QoS of an end-device ๐Ÿ’€. It's computed as an average since the last reporting interval, and corresponds to the average percentage of the total memory space that's critical for the applications in use during that interval (e.g., primary CPU RAM, buffers) ๐Ÿงบ.

In the case of multiple CPU hosts, the maximum memory utilization among the different CPUs MUST be reported ๐Ÿซ .

This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application ๐Ÿฆ‹.

5.32. Application Name/Version ๐Ÿท๏ธ

The Application Name/Version parameter gives the name and, optionally, the version of the application linked to that session or sub-session, e.g., "XYZ VoIP Agent 1.2" ๐ŸŽค. This is super useful when the end-device is running multiple applications with different priorities, and it's very handy for debugging too ๐Ÿ› ๏ธ.

If the application is using RTP [RFC3550], the Application Name SHOULD begin with the string 'RTP' ๐ŸŽถ.

This parameter MUST be sent in the first RAQMON PDU ๐Ÿฅน.

6. Report Aggregation and Statistical Data processing โœจ

okay so within the RAQMON Framework, RRCs are expected to have way more computational resources than RDSs ๐Ÿ–ฅ๏ธ. That means the RRCs do the aggregation functions, while RDSs don't have to be burdened with statistical data processing like minima, maxima, averages, standard deviations, etc. ๐Ÿซถ

The RAQMON MIB provides minimal aggregation of the RAQMON parameters defined above ๐ŸŒธ. It is not designed to offer extensive aggregation like the Application Performance Measurement (APM) MIB [RFC3729] or the Transport Performance Metrics (TPM) MIB [RFC4150]. one should use the APM and TPM MIBs to aggregate parameters based on protocols (e.g., performance of HTTP, RTP) or applications (e.g., performance of VoIP, Video Applications) ๐Ÿ“š.

In the RAQMON MIB, aggregation can only be performed on specific RAQMON metric parameters. Aggregation always results in statistical Mean/Min/Max values, according to these definitions ๐Ÿงฎ:

  • Mean: Mean is defined as the statistical average of a metric over the duration of a communication session. For example, if an RDS reported End-to-End delay metric N times within a communication session, then the Mean End-to-End Delay can be computed by summing of these N reported values, and then dividing by N ๐Ÿ’–.
  • Min: Min is defined as the statistical minimum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Min end-to-end delay is the smallest of the N end-to-end delay metric values reported ๐Ÿงš.
  • Max: Max is defined as the statistical maximum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Max End-to-End Delay is the largest of the N End-to-End Delay metric values reported ๐Ÿ‘‘.

7. Keeping Historical Data and Storage โœจ

okay so it's super obvious from this doc that the RAQMON MIB data needs to be managed so it doesn't eat all your storage ๐Ÿ’… one communication session can gather a LOT of data, so the move is to store only aggregated RAQMON metrics for history, and only if you actually need history ๐ŸŽ€

here are some ways to optimize that storage space:

  1. Make data available through the MIB only at the end of a communication session, i.e., upon receipt of a NULL PDU. The aggregated data could be made available using the RAQMON MIB as Mean, Max, or Min entries and saved for historical purposes. ๐ŸŒธ
  2. Use a time-based algorithm that aggregates data over a specific period of time within a communication session, so you need fewer entries and less storage ๐Ÿฆ‹ for example, if an RDS sends data out every 10 seconds and the RRC updates the RAQMON MIB once every minute, then for every 6 data points there would be one MIB entry. the math is literally so clean ๐Ÿงš
  3. Periodically delete historical data in accordance with an administrative policy. an example of such a policy would be to delete historical data older than 60 days. the implementation of such policies is left to the application developer's discretion, and their use is an operational concern. ๐Ÿ“

8. Security Considerations ๐Ÿ”

bestie, this part is serious, so read it carefully ๐Ÿซถ the security stuff tied to the RAQMON Framework is covered below, and it gets dug into way more in other RAQMON memos where that makes sense ๐Ÿ’œ

8.1. The RAQMON Threat Model ๐Ÿ˜ˆ

so the vulnerabilities in the RAQMON Framework are a mix of the ones from the underlying layers up to the transport layer, plus possible exploits of the RAQMON payload itself ๐Ÿ’€ the payload exploits fall into these classes:

  1. Unauthorized examination of sensitive information in the payload in transit. ๐Ÿ‘€
  2. Unauthorized modification of payload contents in transit, leading to:

a. Mis-identification of information from one RAQMON reporting session as belonging to another destined to the same RRC;

b. Mismapping of RAQMON sessions;

c. Various forms of session-level denial-of-service (DoS) attacks;

d. DoS through modification of RAQMON parameter values and statistics;

e. Invalid timestamps, leading to false interpretation of the monitored data, affecting call records information, and making difficult to place monitoring events in their appropriate temporal context. โฐ

  1. Malformed payloads, permitting the exploitation of potential implementation weaknesses to compromise an RRC. ๐Ÿšจ
  2. Unauthorized disclosure of sensitive data carried by application PDUs, leading to a breach of confidentiality. ๐Ÿ™ˆ

so yeah, threats based on unauthorized disclosure or modification of payloads or headers will have to be assumed. no skipping that one ๐Ÿ’…

8.2. The RAQMON Security Requirements and Assumptions ๐Ÿ›ก๏ธ

to keep the RAQMON PDU's integrity safe from all of these threats, the RAQMON model must provide for cryptographically strong security services. ๐Ÿ”ฅ

so the RAQMON framework must be able to provide for the following protections:

  1. Authentication - the RRC should be able to verify that a RAQMON PDU was in fact originated by the RDS that claims to have sent it. ๐Ÿชช
  2. Privacy - since RAQMON information includes identification of the parties participating in a communication session, the RAQMON framework should be able to provide for protection from eavesdropping, to prevent an unauthorized third party from gathering potentially sensitive information. this can be achieved by using various payload encryption technologies, such as Data Encryption Standard (DES), 3-DES, Advanced Encryption Standard (AES), etc. ๐Ÿ”’
  3. Protection from DoS attacks directed at the RRC - RDSs send RAQMON reports as a side effect of an external event (for example, a phone call is being received). an attacker can try to overwhelm the RRC (or the network) by initiating a large number of events (i.e., calls) for the purpose of swamping the RRC with too many RAQMON PDUs. ๐Ÿ“ž

to prevent DoS attacks against RRC, the RDS will send the first report for a session only after the session has been in progress for the five-second reporting interval. sessions shorter than that should be stored in the RDS and will be reported only after that interval has expired. โณ

warning, this is the kind of attack that can really swamp things, so don't skip the five-second rule ๐Ÿšฉ

8.3. RAQMON Security Model ๐Ÿ”

the RAQMON architecture permits the use of multiple transport protocols, and most of them support a secure mode of operation ๐ŸŒˆ there are real advantages to relying on the security provided at the transport protocol layer:

  1. Transport-protocol-level security can generally protect the payload with end-to-end authentication, confidentiality, message integrity, and replay protection services. ๐Ÿงฑ
  2. A good cryptographic security protocol always has an associated key management protocol. use of transport protocol security relies on its key management and does not require development of another mechanism. ๐Ÿ—๏ธ
  3. When transport protocol security is already enabled between the RDS and RRC, additional encryption and message authentication at the application level is avoided. โœจ

but there are also shortcomings to note in relying on transport protocol security, bestie ๐Ÿฅฒ

  1. When session-level isolation of the different RAQMON sessions of an RDS-RRC pair is required, it will be necessary to open separate transport protocol instances. such cases, however, may be rare. ๐Ÿงฉ
  2. Since security services are not provided by the RAQMON framework, the absence of transport or lower protocol security implies the absence of RAQMON security. ๐Ÿ’”

9. Acknowledgements ๐Ÿ’œ

the authors want to thank Andy Bierman, Alan Clark, Mahalingam Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai Zilbershtein for the precious advices and real contributions brought to this document ๐Ÿซถ they also want to give special thanks to Randy Presuhn, who reviewed this document for spelling and formatting, and who gave a deep review of the technical content ๐Ÿ‘‘ and a huge thank you to Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions ๐ŸŒธ

10. Normative References ๐Ÿ“š

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. ๐ŸŒ

[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. ๐Ÿ›ฃ๏ธ

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ๐Ÿ”‘

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. ๐Ÿท๏ธ

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. ๐Ÿ—๏ธ

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. โฑ๏ธ

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. ๐Ÿ“‰

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. ๐Ÿ”

[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. ๐Ÿ“Š

[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, October 2000. ๐ŸŽ™๏ธ

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. ใ€ฐ๏ธ

[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. ๐Ÿ› ๏ธ

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. ๐Ÿ“ก

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. ๐ŸŽง

11. Informative References ๐Ÿ’ก

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. ๐Ÿ—บ๏ธ

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. ๐Ÿงพ

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. ๐Ÿ–ฅ๏ธ

[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. ๐Ÿ•ฐ๏ธ

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. ๐Ÿ 

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. ๐Ÿšฆ

[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. ๐Ÿ”€

[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. ๐Ÿ“ˆ

[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. ๐Ÿงช

[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005. ๐Ÿš€

[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006. ๐Ÿ“˜

[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006. ๐Ÿ“ฆ

[IEEE802.1D] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common Specification a - Media access control (MAC) bridges:15802-3: 1998 (ISO/IEC). Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE Std 802.1D, 1998 Edition] ๐ŸŒ‰

Authors' Addresses ๐ŸŽ€

Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA

Phone: +1 732 852-3200
EMail: anwars@avaya.com


Dan Romascanu
Avaya
Atidim Technology Park, Building #3
Tel Aviv, 61131
Israel

Phone: +972-3-645-8414
EMail: dromasca@avaya.com


Eugene Golovinsky

EMail: gene@alertlogic.net

Okay bestie, let's get the legal stuff out of the way first ๐ŸŽ€ The Internet Society owns the copyright here (2006), and this document is subject to the rights, licenses and restrictions in BCP 78. Other than what BCP 78 says, the authors keep all their rights ๐Ÿ’…

The document and the info in it are handed over "AS IS" ๐Ÿซถ The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That covers no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose. Lowkey a lot of lawyer energy ๐Ÿ’€

Intellectual Property ๐Ÿฆ‹

The IETF takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid, or how far they reach, or whether a license would even be available ๐ŸŒธ It also doesn't say it has done any independent work to find those rights. If you want the rules about rights in RFC documents, check BCP 78 and BCP 79 ๐Ÿ“š

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr ๐Ÿ”ฅ

The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org ๐Ÿ’œ

Acknowledgement ๐ŸŒˆ

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) โญ

๐Ÿ“ฆ where this page comes from