1. 1 Realtime Application QOS Monitoring (RAQMON) Framework 55 th IETF Session – Atlanta RMON Work Group Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky

2. 2 Context Setting for the proposal IP Network Applications RTP / FTP/ HTTP TCP/UDP MAC IEEE 802.3 PHYSICAL IP MAC 802.3 IP IP End Points Router PHYSICAL MAC 802.3 IP Router PHYSICAL Applications RTP / FTP/ HTTP TCP/UDP MAC IEEE 802.3 PHYSICAL IP IP End Points MG Streaming Media, Transaction, Bulk data transfer etc Application level priority (e.g. RSVP for S1, but no RSVP for S2) Various packet level priority ( TOS, DiffServ etc.) Domain 1 Domain 2 ……. Domain N+1 Multiple Equipment vendors, Multiple geographic locations, Multiple xSPs Control multiple Administrative and Provisioning domain Domain N

3. 3 RAQMON Network Configuration IP Network Video/IP/IM/Voice Voice over IP Media Gateway Wireless Gateway Regional Report Collector ( Periodic Packets to populate MIB ) LAN/VPN INTRANET Corporate Network Application Administrator Monitoring Applications via SNMP Network / Application Service Provider SNMP Statistics Reported Bluetooth

4. 4 Scope of the Framework RRC Out of Scope of Framework Protocol used to communicate Measurement Methodology Measurement Accuracy Scope of the Framework Existing Internet Protocol used to carry RAQMON PDU RAQMON SNMP MIB RAQMON PDU over RTCP or SNMP SNMP RAQMON MIB RDS X End Device

5. 5 RAQMON Architecture (Functional ) Communication Network IP PSTN Cellular Optical RAQMON Report Collector (RRC) # 1 SNMP RAQMON MIB (IP Address, port) Network Alarm Manager   Context-sensitive Metrics (e.g.VoIP vs. Instant Messaging) Transport Network Condition Specific Metrics (e.g. Jitter) Network Policy Specific ( e.g. RSVP Failed, Diffsrv = EF) Device Sate Specific Metrics (e.g. CPU Usage)  Variable Metrics Parameters Updated using RAQMON PDU SNMP Management Application IP End Device RAQMON Data Source (RDS) APPLICATION Transport Protocol Agnostic

6. 6 -Data Source Name (DN) -Receiver Name (RN) -Data Source Address (DA) -Receiver Address (RA) -Data Source Device Port used -Receiver Device Port used -Session Setup Date/Time -Session Setup delay -Session duration -Session Setup Status -End-to-End Delay -Inter Arrival Jitter -Total number of Packets Received -Total number of Packets Sent -Total number of Octets Received -Total number of Octets Sent -Cumulative Packet Loss -Packet Loss in Fraction -Source Payload Type -Receiver Payload Type -Source Layer 2 Priority -Destination Layer 2 Priority -Source Layer 3 Priority -Destination Layer 3 Priority -CPU utilization in Fraction -Memory utilization in Fraction -Application Name/version This is a suggested matrix ….. Metrics “pushed” by the RDS to RRC Framework Accommodates addition of new parameters to the list …..

7. 7 What is not proposed in RAQMON Framework!  Creation/Extension/Modification of any existing protocol in order to support RAQMON PDU is out of scope of the RAQMON charter proposal  Methodology to measure any of the QOS parameters defined in the RAQMON Framework is out of scope for this proposal. –Measurement algorithms are left upon the implementers and equipment vendors to choose. –Consistent with other RMON WG work items like APM, TPM etc.

8. 8 Overall RAQMON I-D Status  RAQMON idea was first presented at 51 st IETF session in RMON WG –There seemed interest in 51 st IETF session by the RMON community  RAQMON I-D was made available for 52 nd IETF –draft-siddiqui-rmonmib-raqmon-mib-00.txt  Discussions around RAQMON I-D have happened –within the RMON mailing list during 52 nd and 53 rd IETF –out of band interest/comments from various vendors for participation  Official RAQMON charter went out after 54 th IETF –3 drafts were called out in the charter –RAQMON Framework, RAQMON PDU and RAQMON MIB

9. 9 RAQMON Protocol Data Unit (PDU) 55 th IETF Session – Atlanta RMON Work Group Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky

10. 10 RAQMON PDU Overview  A set of RAQMON Application level PDUs to have “common formats” for reporting statistics –Between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC).  RAQMON PDUs will be transported over existing protocols –RTCP (using RTCP APP Packets) –SNMP (using SNMP INFORM)  RDS and RRC are Peer-to-Peer entities –RDS reports what “IT” feels to be appropriate for the “application context” –RRC consumes what “IT” feels to be appropriate for the “application context”  RDS  RRC communication should be stateless –Minimal (preferably No) setup transaction to tell the collector which metrics the data source will be sending later on.  RAQMON PDUs can be lossy –Complementary to IPFIX charter  RAQMON PDUs should be extensible for future –To add additional matrices

11. 11 RAQMON PDU Types  BASIC PDU –Basic PDUs are TLV pair –Draft provides a list of initial matrix ( i.e. not meant to be exhaustive ) –Matrix parameters are selected by the apps –Compound sessions can be reported as multiple sub-sessions –End devices control the rate of reporting  APP PDU –Can be extended to add new parameters not spelled out in initial draft

12. 12 RAQMON PDU over RTCP  RAQMON PDUs inside RTCP APP Packets  Different Ports will be IANA registered for RAQMON PDUs over RTCP Version & subtype PT=204Length SSRC/CSRC Name= RAQMON (ascii) RAQMON PDU RAQMON specific and IANA Registered RTCP APP Packet

13. 13 RTCP Pros and Cons  Using a well-known protocol.  Very light weight  Privacy and authentication are covered by RTP/RTCP  No acknowledgement required  RRC is burdened by RTCP  RRC have to be RTCP sink! –Need to understand atleast RTCP APP Packets PROS CONS

14. 14 RAQMON PDU over SNMP  RDSs will not be required to respond to SNMP requests –Keep the RDS design simple.  The RDS “MAY” ignore the SNMP Inform Responses, or, if better –Requires retransmission Inform PDU  RAQMON information is mapped to an SNMP Inform PDU in 2 ways. –Mapping RAQMON data items to MIB variables (i.e. uses NOTIFICATION-TYPE macro) –Encoding RAQMON PDU format within a small set of MIB items.

15. 15 SNMP Pros & Cons  Using a well-known protocol.  Easy integration with RMON Framework  Privacy and authentication are covered by SNMPv3  RRC can use an SNMP manager implementation to process Informs.  Overhead SNMP puts on low-powered RDSs! –BER encoding on a PDA or a pager or in an IP Phone Proposed Solution: To alleviate this, possibility of encoding INFORM PDUs using UTF-8 should be studied further. However this would require –a RAQMON PDU specific code in the RRC, and –a new IANA UDP port  Acknowledgements from RRCs to RDSs can create bottleneck  Session centric RDS design  Sending ACKs also wastes network bandwidth. PROS CONS

16. 16 Backgrounder

17. 17  Rapmon Framework correlates “per transactions statistics” to “performance of a particular transaction” (e.g. call setup  call’s media stream performance )  Proposed Rapmon Framework conforms to APM and TPM completely.  Rapmon work is complementary to the work that’s going on in ippm WG.  This proposal conforms to ippm WG’s recommendations fully.  Proposed Rapmon Framework is complimentary to current work that is going on in the areas of synthetic source. Relationship to current work in various WGs