1

Realtime Application QOS Monitoring (RAQMON) Framework

56th IETF Session – San FranciscoRMON Work Group

Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky

<draft-ietf-rmonmib-raqmon-framework-01.txt>

2

RAQMON Framework Draft – Progress Status

RAQMON I-D accepted as RMON WG draft during IETF 55 @ Atlanta

draft-ietf-rmonmib-raqmon-framework-00.txt issued on 01/15/2003

draft-ietf-rmonmib-raqmon-framework-01.txt issued on 03/03/2003

WG last call deadline APRIL’ 2003

3

Changes/Updates/Modification in framework–01.txt

– Editorial Changes & clean up (work continues!)– Re-arrangements of sections as suggested in the mailing list and various IETF

Sessions– Better Architectural Definitions upfront in the document– Better Definitions of parameters – Guidance on selecting appropriate measurement methodologies based on

application text (e.g. End-to-End Delay)

– Clear text on “extensibility” of the PDU Types in the framework

– Incorporation of One Way End-to-End Delay in BASIC PDU

– Removed 8 bit vendor specific information from BASIC PDU

4

Item # 1: Extensibility of RAQMON PDUs

BASIC PDU defines a pre-listed set of parameters– Currently allows 28 pre-listed parameters

Use RAQMON APP PDUs to add additional parameters– Vendor specific information

– Application specific information/profile (e.g. echo cancellation type, echo length etc. )

5

Item # 2: Extensibility of Transport protocol

RAQMON PDUs are carried over– RTCP

– SNMP

Do we allow more transport protocols to carry RAQMON PDUs?

If Yes: Do we need to address that issue in the Framework Document?

6

Item # 3: Mandatory Support of Transport Protocol

RRC MAY support either RTCP OR SNMP as Transport Protocol

Note: If one implements the RAQMON MIB, SNMP support is almost given!

ADVANTAGES:

– Simple RRC Design

DISADVANTAGES:

– RDS/RRC Pair needs to know about each others transport protocol type

RRC MUST support RTCP AND SNMP as Transport Protocol for compliance

ADVANTAGES:

– Flexible Operation

DISADVANTAGES:

– Adds complexity in RRC implementation

Option A Option B

RRC Conformance!RRC Conformance!

7

Item # 4: Lossy vs. Lossless

Being lossless is not a RAQMON Requirement for the – RAQMON PDUs COULD be “lossy”

– RAQMON PDUs do not guarantee delivery nor does it assume that the underlying network is reliable!

RDS/RRC Sessions could be engineered to be lossless– RAQMON PDUs itself does not provide any mechanism to ensure timely

delivery but relies on lower-layer services to do so.

– Option A: RAQMON PDU over RTCP/TCP/IP– Option B: RAQMON PDU over SNMP/TCP/IP

(deployment ??)

Will add clarifications on this in the Framework Doc

8

Item # 5: Coping with lossy transport

RDSs never re-transmits– RDS design is simple/stateless

RRCs does not try to recover lost packets– RAQMON not be used for mission critical applications (e.g. billing)

RRCs may handle open “reporting” sessions with Case A: RTCP/UDP/IP

i. Rely on RTCP BYE Packetii. RRCs can time out for in active RDSs

Case B: SNMP/UDP/IPi. RRCs can time out for in active RDSs

Realtime information needs to be stored for historical purpose!

9

Item # 6: One Way vs. Roundtrip End-to-End Delay

One Way End to End Delay is explicit in the Framework– End-to-End Delay in Previous drafts Roundtrip End-to-

End Delay in current draft– One Way End-to-End Delay is also reflected in

aggregation process– Need to reflect in the MIB!

Applications/end devices can select either End to End Delay parameter to report as felt appropriate by selecting appropriate RPPF bit (RAQMON Parameter Presence Flags)

10

Item # 7: A Suggestive list of Provisioning parameters

Clarifying text on a list of parameters that RDSs may need be provisioned with before reporting to RRC.

– RRC IP Address– RRC Port– Type of Transport Protocol supported by RRC– Rate of Transmitting PDUs/Time Interval

Please comment if something is missing!

11

Item # 8: Mandatory Security Requirements

RDS/RRC MUST support some sort of Authentication for compliance (or not!)– RDS/RRCs must support some authentication!

Should RRC Police rate an RDS at RRC level to avoid DOS attack?

Could use security reviews/help!

12

RAQMON Protocol Data Unit (PDU)

56th IETF Session – San FranciscoRMON Work Group

Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky

<draft-ietf-rmonmib-raqmon-pdu-01.txt>

13

RAQMON PDU Draft – Progress Status

RAQMON PDU I-D accepted as RMON WG draft during IETF 55 @ Atlanta

draft-ietf-rmonmib-raqmon-pdu-00.txt issued on 01/15/2003

draft-ietf-rmonmib-raqmon-pdu-01.txt issued on 03/03/2003

WG last call deadline MAY’ 2003

14

Changes/Updates/Modification in last draft

– Editorial Changes & clean up (work continues!)– Better Definitions of parameters units (ms, Sec, %, second etc)

– Incorporation of One Way End-to-End Delay in BASIC PDU

– Removed 8 bit vendor specific information from BASIC PDU– All vendor specific/special application specific values goes to APP PDU

15

Item # 1: Rate of Reporting

Option A: Rate Controlled Approach: Algorithms that MAY be used as to calculate rate of reporting

given a target Bandwidth allocated for reporting!– Recommendation on no more than 10% bandwidth be wasted for Reporting

as a guideline!

Option B: Pre-Provision Approach: Guidelines on “pre-provisioning” RDSs with specific Transmission

Rate is included (section 2.1.1 of the Framework Draft)

Both Approaches are supported and documented!

16

Item # 2: Congestion Avoidance

Recommend usage of TCP as transport for congestion control

– Option A: RAQMON PDU over RTCP/TCP/IP– Option B: RAQMON PDU over SNMP/TCP/IP (any deployment issue)

Recommendation on no more than 10% aggregate bandwidth be wasted for Reporting as a design guideline guideline!

– Reference Algorithms that MAY be used as to calculate rate of reporting given a target Bandwidth allocated for reporting!

– Guidelines on “pre-provisioning” RDSs with specific Transmission Rate (e.g. 1 PDU every 5 seconds)

– section 2.1.1 of the Framework Draft

17

Item #3: RAQMON PDU Level Compliance

Clarifying text on BASIC RAQMON PDU– Every BASIC PDU MUST include RPPF bits (RAQMON Parameter Presence

Flags) – BASIC PDU without any parameter will be considered as VALID (RPPF = 0)– RRCs would have the option to drop such PDUs with RPPF = 0– BASIC PDU MUST be used while reporting any parameter pre-listed in BASIC

PDU set

APP PDU– Can be extended to add new parameters not spelled out in BASIC PDU– Its not Mandatory to send a BASIC PDU before sending an APP PDU – Vendors should not use APP PDUs to carry the same parameters pre-

identified in BASIC PDU (Will ensure better Interoperability)

Re-issue the PDU draft with above mentioned level of compliance!

18

Item # 4: Handling Compound Application Sessions

Compound application sessions can be reported in one BASIC PDU

Clarifying text is needed to explainA. When to report multiple application session within the same DSRC of a BASIC PDU

B. When to report multiple application session in different DSRC

C. Do we need to keep the RC_n unchanged when the RDSs have started a session

RDS 1 RDS 2AUDIO

TEXT

RRC

•Same DSRC in BASIC PDU

• One RAQMON BASIC PDU from RDS RRC

RDS 2AUDIOTEXT

RRC

• Different DSRC in BASIC PDU

• Different RAQMON BASIC PDU from RDS RRC

RDS 3 RDS 1

19

Item # 5: IANA Registration

IANA Port for RAQMON PDUs over RTCP

IANA Port for RAQMON PDUs over SNMP

RAQMON PDU

Name=RAQMON (ascii)

SSRC/CSRC

LengthPT=204Version & subtype

RAQMON specific and

IANA

Registered

RTCP APP Packet

20

RAQMON MIB

56th IETF Session – San FranciscoRMON Work Group

Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky

<draft-ietf-rmonmib-raqmon-mib-00.txt>

21

RAQMON MIB Draft – Progress Status

RAQMON MIB I-D accepted as RMON WG draft during IETF 55 @ Atlanta

draft-ietf-rmonmib-raqmon-mib-00.txt issued on 01/15/2003

WG last call deadline MAY’ 2003

22

MIB Drafts Will be updated in next version

One Way End-to-End Delay will be added in the next version

Aggregation (i.e. Avg, Min, Max) for One Way End-to-End Delay

Configuration Issues!

23

Backgrounder

24

RAQMON Context Setting

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

PDAMG

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

25

- 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 - Round Trip End-to-End Delay - One Way 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 (in %)- 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 (in %)- Memory utilization in Fraction (in %)

- Application Name/version

Item # 1: Extensibility of RAQMON PDUs (cont.)

Framework Accommodates addition of new parameters to the list …..

26

RAQMON Network Configuration

Telephone

Laptop computer

Telephone

IP Network

Video/IP/IM/Voice

Voice over IP

Router

Media GatewayFax

Wireless Gateway

Regional Report Collector (Periodic Packets to populate MIB)

LAN/VPN INTRANET

Laptop computer

Corporate Network

Application Administrator

Monitoring Applications via

SNMP

PDANetwork /

Application Service Provider

SNMP

SNMP

SNMP

SNMP

Statistics Reported

Telephone

PDABluetooth

27

Framework Definition

RRC

Out of Scope of Charter Protocol used to communicate between APPs

Measurement Methodology Used Measurement Accuracy

Scope of the Framework Existing Transport Protocol to carry RAQMON PDU

RAQMON SNMP MIB

SNMP

RAQMON MIB

RDS RDS

X End DeviceEnd Device

UNDERLYING TRANSPORT

(e.g. RTCP, SNMP)

Common RAQMON PDU format

28

RAQMON Architecture (Functional )

Communication NetworkIP

PSTNCellularOptical

RAQMON Report Collector

(RRC) # 1RAQMON 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 list Updated using RAQMON PDU

                        

 

SNMP

Management Application

IP End Device

RAQMON Data Source (RDS)

APPLICATION

Transport Protocol Agnostic

29

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

30

RAQMON PDU over RTCP

RAQMON PDUs inside RTCP APP Packets

Different Ports will be IANA registered for RAQMON PDUs over RTCP

RAQMON PDU

Name=RAQMON (ascii)

SSRC/CSRC

LengthPT=204Version & subtype

RAQMON specific and

IANA

Registered

RTCP APP Packet

31

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

– Use MIB object to encapsulate the RAQMON PDU payload

32

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.

33

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