Realtime Application QOS Monitoring RAQMON Framework 55th IETF Session Atlanta RMON Work Group

1
Realtime Application QOS Monitoring (RAQMON)
Framework55th IETF Session AtlantaRMON Work
Group
Anwar Siddiqui, Dan Romascanu, Eugene
Golovinsky ltdraft-siddiqui-rmonmib-raqmon-framewo
rk-00.txtgt
2
Context Setting for the proposal
MG
Application level priority (e.g. RSVP for S1, but
no RSVP for S2)
Applications
Applications
Streaming Media, Transaction, Bulk data transfer
etc
RTP / FTP/ HTTP
RTP / FTP/ HTTP
Various packet level priority ( TOS, DiffServ
etc.)
TCP/UDP
TCP/UDP
IP
IP
IP
IP
IP Network
MAC 802.3
MAC 802.3
MAC IEEE 802.3
MAC IEEE 802.3
PHYSICAL
PHYSICAL
PHYSICAL
PHYSICAL
Router
Router
IP End Points
IP End Points
Domain 2 .
Domain N
Domain 1
Domain N1
Multiple Equipment vendors, Multiple geographic
locations, Multiple xSPs Control multiple
Administrative and Provisioning domain
3
RAQMON Network Configuration
Monitoring Applications via SNMP

Video/IP/IM/Voice
Corporate Network Application Administrator
SNMP
LAN/VPN INTRANET
Statistics Reported
Voice over IP
SNMP
SNMP
Regional Report Collector (Periodic Packets to
populate MIB)
IP Network
Media Gateway
SNMP
Wireless Gateway
Network / Application Service Provider
RAQMON MIB
Bluetooth
4
Scope of the Framework
Out of Scope of Framework Protocol used to
communicate Measurement Methodology Measurement
Accuracy
RAQMON PDU over RTCP or SNMP
X
End Device
End Device
SNMP
RDS
RDS
RRC
RAQMON MIB
Scope of the Framework
Existing Internet
Protocol used to carry RAQMON PDU RAQMON SNMP MIB

5
RAQMON Architecture (Functional )
                                               
 
IP End Device
?
APPLICATION

Communication Network IP PSTN Cellular Optical
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)
?
RAQMON Data Source (RDS)
Network Alarm Manager
Variable Metrics Parameters Updated using RAQMON
PDU
?
(IP Address, port)
Transport Protocol Agnostic
SNMP
SNMP
RAQMON Report Collector (RRC) 1
RAQMON MIB
Management Application
6
Metrics pushed by the RDS to RRC

• 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 ..
Framework Accommodates addition of new parameters
to the list ..
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
Overall RAQMON I-D Status

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

9
RAQMON Protocol Data Unit (PDU)55th IETF
Session AtlantaRMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene
Golovinsky ltdraft-siddiqui-rmonmib-raqmon-pdu-00.
txtgt
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
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
RAQMON PDU over RTCP

• RAQMON PDUs inside RTCP APP Packets
• Different Ports will be IANA registered for
  RAQMON PDUs over RTCP

RTCP APP Packet
RAQMON specific and IANA
Registered
13
RTCP Pros and Cons
PROS
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

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
SNMP Pros Cons
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.

16
Backgrounder
17
Relationship to current work in various WGs

• Rapmon Framework correlates per transactions
  statistics to performance of a particular
  transaction (e.g. call setup ? calls media
  stream performance)
• Proposed Rapmon Framework conforms to APM and TPM
  completely.
• Rapmon work is complementary to the work thats
  going on in ippm WG.
• This proposal conforms to ippm WGs
  recommendations fully.
• Proposed Rapmon Framework is complimentary to
  current work that is going on in the areas of
  synthetic source.