Transcript Slide 1

On the Enhancement of QoE for IPTV Services
through Knowledge Plane Development
Bart De Vleeschauwer
Wim Van de Meerssche
Pieter Simoens
Filip De Turck
Bart Dhoedt
Piet Demeester
ist-muse.org
Edith Gilon
Kris Struyve
Tom Van Caenegem
Overview
> Access
network challenges
> Monitoring
Plane & Knowledge Plane
> Monitoring
in the home network
BB Europe 14.12.2006 — 2
ist-muse.org
Access Network Overview
Access Network
Service
Providers
BB Europe 14.12.2006 — 3
Home Network
Access
Node
Service
Edge
ist-muse.org
Residential
Gateway
End User
Device
Services & Challenge
>
Classic best-effort internet services:
•
>
Web Surfing, E-mail, File Transfer, …
New services:
•
•
VOIP, Broadcast IPTV, Video on Demand, Gaming
Higher Requirements:
–
>
Interactivity, Media quality, Zapping Time, Setup Time, Synced Sound,
Artifact-free Video
Need for guaranteed Quality of Experience
= how the user experiences the service
• Influenced by network jitter, delay and loss
How can we detect & automatically solve QoE degradation?
BB Europe 14.12.2006 — 4
ist-muse.org
Overview
> Access
network challenges
> Monitoring
Plane & Knowledge Plane
> Monitoring
in the home network
BB Europe 14.12.2006 — 5
ist-muse.org
MP/KP: Architecture
Knowledge Plane
root cause analysis
QoE decrease detected
Monitor Plane
Monitoring data sources
BB Europe 14.12.2006 — 6
ist-muse.org
restorative action
Monitor Plane
•Logical layer containing all monitoring tools:
•SNMP:
• Read & write device parameters
• Set traps
• IPFIX (or netflow):
• Flow statistics
• TR-069
• Residential gateway configuration & monitoring
•…
BB Europe 14.12.2006 — 7
ist-muse.org
Knowledge plane Overview
Additional info might be needed
for accurate fault recovery
Initialize new
anomaly detection
modules
Knowledge Plane
Diagnosis and Solution
Additional
Initiate new
queries
monitor
over
probes
available data
Anomaly is detected Anomaly Detection
Solution Execution
Solve Problem
Continuous monitoring
Monitoring Plane
e.g. FEC, interleaving, local
retransmission, device
reconfiguration, warn end-user
or network management, …
Data Reduction
Active: e.g. generate additional ICMP ping requests
Passive: e.g. additional threshold in RMON MIB
BB Europe 14.12.2006 — 8
ist-muse.org
MP/KP: Example
Knowledge Plane
root cause analysis
QoE decrease detected
restorative action
Cause known: ADSL-line loss
Monitor Plane
Loss
Loss
in
Detected
Home
Network
BB Europe 14.12.2006 — 9
ist-muse.org
ADSL-line
Add FEC to stream
Statistics:
loss detected
Overview
> Access
network challenges
> Monitoring
Plane & Knowledge Plane
> Monitoring
in the home network
BB Europe 14.12.2006 — 10
ist-muse.org
Home Network Monitoring
Loss, RTT and
Jitter monitoring
?
From the Access Node
How to monitor?
•
Limited or no knowledge & control of end-devices
>
Active monitoring
>
Passive monitoring
BB Europe 14.12.2006 — 11
ist-muse.org
Active Monitoring
>
Dedicated software
•
>
Assumes control of end-devices and end-device software by
access network
ICMP-based
•
•
•
Each IP device should support “ping”
Can measure RTT, jitter and loss
Problem:
–
Firewall
– Might be handled differently than other traffic
– Large Loss detection overhead!
– To detect a packet loss ratio p, you need 10/p packets
>
Active monitoring isn’t very useful
BB Europe 14.12.2006 — 12
ist-muse.org
Passive Monitoring
>
From in the access network, monitor packets from and to the
home network
>
Use service specific algorithms to derive home network
parameters
>
Use cases:
•
•
Broadcast TV using RTP/RTCP
VoD using TCP
BB Europe 14.12.2006 — 13
ist-muse.org
RTP/RTCP monitoring
RTP
>
Overview:
•
•
•
RTCP Sender Reports
RTP/RTCP basics
Jitter Monitoring
Loss Monitoring
BB Europe 14.12.2006 — 14
RTCP Receiver Reports
ist-muse.org
RTP/RTCP
>
RFC 3550: RTP: A Transport Protocol for Real-Time
Applications
>
Two protocols
•
•
>
RTP packets contain data
•
•
>
RTP protocol for data packets
RTCP protocol for control traffic
Sequence number
Timestamps (Sampling instant of first octet in the RTP data
packet)
RTCP packets contain control & feedback information
BB Europe 14.12.2006 — 15
ist-muse.org
RTCP Messages
>
SDES, source description items
>
BYE, end of participation
>
APP, application specific
>
SR, Sender Report
>
RR, Receiver Report
Report Block
BB Europe 14.12.2006 — 16
ist-muse.org
RTP/RTCP loss estimation
>
Receiver report:
Fraction lost since last RR
# Expected - # Received
Loss
>
Same calculations can be done on AN,
by looking at RTP stream
BB Europe 14.12.2006 — 17
ist-muse.org
Access node home network loss detection
Access Network
Home Network
Receiver Reports (loss=A)
RTP Monitoring on AN
(loss=B)
BB Europe 14.12.2006 — 18
ist-muse.org
Calculate: A - B
RTP/RTCP interarrival Jitter estimation
>
Interarrival jitter: variance in interarrival time
Server
Sj
Si
Access Node (AN)
End-Device
Sk
Aj
Ai
Ri
Ak
Rj
Rk
time
>
End-to-end jitter is reported in RR
>
Do analogous calculations on RTP at AN to determine Server – AN jitter
>
Compare end-to-end jitter (RR) and Server-AN jitter
BB Europe 14.12.2006 — 19
ist-muse.org
TCP monitoring
>
TCP
Overview:
•
•
•
•
TCP basics
RTT & Jitter Monitoring
Loss Monitoring
Our algorithm: ANTMA
BB Europe 14.12.2006 — 20
ist-muse.org
TCP: Basics
Monitoring Point
Receiver
Sender
DP 1
ACK 1
1 A1
BB Europe 14.12.2006 — 21
ist-muse.org
TCP: Loss
Monitoring Point
Receiver
Sender
DP 1
ACK 1
Time-out!
1 1 A1
BB Europe 14.12.2006 — 22
ist-muse.org
TCP: Flights
Monitoring Point
Receiver
Sender
1
DP 2
ACK 2
1
1 2 A1 A2
BB Europe 14.12.2006 — 23
ist-muse.org
TCP Middle Monitoring: RTT & Jitter in home network
>
RTT is time between seeing a data packet,
and seeing its matching ACK
>
“RTT Jitter” can be derived from RTT
>
Finding matching ACK is hard when loss & jitter
occur:
DP 1
ACK 1
1 2 3 4 A1 A1 2 3 4 A1 A4 A4 A4
 Need smart matching for jitter detection!
BB Europe 14.12.2006 — 24
ist-muse.org
TCP Middle Monitoring: Loss in Home Network
>
Counting retransmissions
•
Unreliable, as jitter can cause retransmissions
• Tests on the internet show difference with loss
can be very high
>
“Smart” counting retransmissions
•
Assume multiple losses in row are jitter, and
ignore them
• Bursty loss is seen as jitter!
BB Europe 14.12.2006 — 25
ist-muse.org
TCP Middle Monitoring: ANTMA
>
ANTMA = “Access Network TCP Monitoring Algorithm”
>
What?
• Loss, RTT & Jitter estimations
• Measure each TCP connection separately
• Monitor only home network part of connection
>
How?
• Passive monitoring of packets on AN (or RGW)
• History is evaluated by various rules
• Packets are matched with their ACK
BB Europe 14.12.2006 — 26
ist-muse.org
TCP Middle Monitoring: ANTMA Example
DP 6
1
2
3
4
5
MP
ACK 3
1
2
1 2 3 A1 A2 A3 4 5 6 A3 A3
LOST
History: 1 2 3 A1 A2 A3 4 5 6 A3 A3
Can match:
BB Europe 14.12.2006 — 27
1,3
2 3
ist-muse.org
5,6 6
Conclusion
>
Monitoring Plane
•
•
Monitoring in Acces Network
Monitoring in Home Network
–
–
>
RTP/RTCP
TCP
Knowledge Plane
•
Detect & Solve QoE degradations
BB Europe 14.12.2006 — 28
ist-muse.org
Questions?
BB Europe 14.12.2006 — 29
ist-muse.org