Service QoE Monitoring in the Access Network Bart De Vleeschauwer Ghent University – IBBT-IMEC...

22
Service QoE Monitoring in the Access Network Bart De Vleeschauwer Ghent University – IBBT-IMEC Department of Information Technology [email protected]

Transcript of Service QoE Monitoring in the Access Network Bart De Vleeschauwer Ghent University – IBBT-IMEC...

Service QoE Monitoring in the Access Network

Bart De VleeschauwerGhent University – IBBT-IMECDepartment of Information [email protected]

03.10.2006 — 2

Muse Project

> MUlti Service access Everywhere

> “The overall objective of MUSE is the research and development of a future, low cost, multi-service access network. The access network should provide secure connectivity between end-user terminals and edge nodes in a multi-provider environment. It should be suited for the ubiquitous delivery of broadband services to every European citizen.”http://www.ist-muse.org

> Service QoE is of prime importance

> Goal of our contribution to MUSE: a knowledge plane in the access network that is responsible for autonomous QoE management.

03.10.2006 — 3

Outline

> Access network overview

> Access network services

> Knowledge plane• Motivation• A two layered architecture

> Access node monitoring and actions• RTP/RTCP monitoring• QoE restorative actions

> Conclusion

03.10.2006 — 4

Access Network Overview

Service Providers

Service Edge

Aggregation Network

Access Node

Residential

Gateway

End Device

User

Home Network

03.10.2006 — 5

Motivation

> Access network services:• VOIP• Video on demand• IPTV• High Speed Internet

> For all these services, QoE is essential

> Packet loss, delay, jitter have huge impact

> Goal:• Autonomous access network QoE management• Monitor the QoE• Enable QoE restorative action• Proactive and reactive QoE monitoring and restoration

03.10.2006 — 6

A Knowledge plane in the access network

Monitoring Plane

Knowledge Plane

03.10.2006 — 7

State of the art> Monitoring the access network

• SNMP (Simple Network Management Protocol)• RMON MIBs• Raqmon• DSLForum

– Protocol described in TR-69– Object models in various working texts

• IPFIX/Netflow• Active monitoring

> Monitor data analysis• “Sketch-based change detection: methods, evaluation, and applications”, Krishnamurthy,

B., Sen, S., Zhang, Y., Chen, Y., 2003• “What’s new: finding significant differences in network data streams”, Cormode, G.,

Muthukrishnan, S., 2005• Database sliding window techniques

> Knowledge plane actions• Retransmissions• Forward error correction• Interleaving

03.10.2006 — 8

Monitoring Plane

MP/KP Responsibilities

Data Reduction

Monitored Data

Sampling Sliding Window Sketch

Knowledge Plane

Reduce data to manageable size

Anomaly Detection

Sketch Test 2Threshold Sketch Test 1

Diagnosis and Solution

Alert diagnosis component

Detect problem root cause and find solution

Analyze data

03.10.2006 — 9

A distributed Knowledge Plane

Monitoring Plane

Knowledge Plane

Knowledge Plane

Monitoring Plane

03.10.2006 — 10

Monitoring Plane

Data Reduction

Knowledge plane – Monitoring plane interaction

Knowledge Plane

Active: e.g. generate additional ICMP ping requests

Passive: e.g. additional threshold in RMON MIB

Anomaly Detection

Diagnosis and Solution

Additional queries over available data

Initialize new anomaly detection modules

Additional info might be needed for accurate fault recovery

Initiate new monitor probes

Anomaly is detected

03.10.2006 — 11

Central role of the access node

> Access node:• Under control of access network provider• Crossing point between aggregation network and last mile + home

network• All data of the same user passes this point

> Ideal place for user/service monitoring and restorative action

> Dedicated protocol monitoring

Knowledge Plane

Monitoring Plane

03.10.2006 — 12

Streaming video services

Streaming video service

RTP

RTCP

03.10.2006 — 13

RTP/RTCP

> RFC 3550: RTP: A Transport Protocol for Real-Time Applications

> Two protocols• RTP protocol for data packets• RTCP protocol for control traffic

> RTP packets contain data• Sequence number• Timestamps (Sampling instant of first octet in the RTP data

packet)

> RTCP packets contain control & feedback information

03.10.2006 — 14

RTCP Messages

> SDES, source description items

> BYE, end of participation

> APP, application specific

> SR, Sender Report

> RR, Receiver Report

Report Block

03.10.2006 — 15

Monitor Plane

Streaming Video Services

Goal:• Determine end-to-end QoE• Determine Access-node end-device QoE

RTPSR

RR

Track Sequence NumbersTrack SR timesInspect RRs

03.10.2006 — 16

RTP/RTCP loss estimation

> Receiver calculates the number of packets it expects and the number it has received in an interval

> Fraction lost between two report blocks is reported together with cumulative number of lost packets

> Cumulative number lost = # expected - # received

> Fraction lost = fraction lost since last RR

03.10.2006 — 17

Access node home network loss detection

•Access node keeps track of packets that were sent to end-device

•Access node keeps track of highest sequence numbers in RR

•Access node keeps track of reported fraction lost / number lost packets

Access node can estimate how many packets were lost between access node and end-device

03.10.2006 — 18

RTP/RTCP interarrival Jitter estimation

> Interarrival jitter: variance in interarrival timeServer

End-Device

Sl

time

> End-to-end interarrival jitter is calculated:• Calculate interarrival time between two packets

• D(k,l) = (Rk – Rl) - (Sk – Sl) = (Rk – Sk)- (Rl – Sl)• Jitter estimation• J(k)=J(k-1)+(|D(k,k-1)|- J(k-1) )/16

> Jitter is reported in RR

> Do analogous calculations to determine Server – AN jitter

> Compare end-to-end jitter (RR) and Server-AN jitter

Sk

Rl Rk

03.10.2006 — 19

RTP/RTCP RTT estimation

> RTCP Report block contains fields for• LSR: Last SR timestamp• DLSR: Delay Since last SR

> This allows us to estimate the RTT whenever a RR is received

> Time when SR passes access node: t1

> Time when RR passes access node : t2

> RTT est. = t2-t1-DLSRSender

Access Node

End Device

DLSR

t1 t2

SR

RR

03.10.2006 — 20

Access Node QoE Restorative Action

> Trigger application specific actions when packet loss is detected

• Forward error correction• Interleaving• Intercept retransmission requests at the access node and send

retransmissions– Faster retransmission– Less network load

> Inform higher layers of QoE decrease

> Adapt stream to better suite client specifications

> Dynamic content proxying according to an observed demand pattern

03.10.2006 — 21

Conclusion

> There is a clear need for access network QoE management

> Three goals• QoE monitoring• QoE problem detection• Problem solution

> A two layered solution• Monitor plane• Knowledge plane

> A distributed architecture is able to locate/solve QoE decreases at the appropriate location

> The access node plays a central role in the distributed knowledge plane

03.10.2006 — 22

Thank you for you attention !

Any Questions?