Presentation on theme: "Ist-muse.org On the Enhancement of QoE for IPTV Services through Knowledge Plane Development Bart De Vleeschauwer Wim Van de Meerssche Pieter Simoens Filip."— Presentation transcript:
ist-muse.org 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 Edith Gilon Kris Struyve Tom Van Caenegem
BB Europe — 2 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network
BB Europe — 3 ist-muse.org Access Network Overview Service Providers Service Edge Access Node Residential Gateway End Device User Access NetworkHome Network
BB Europe — 4 ist-muse.org Services & Challenge > Classic best-effort internet services: Web Surfing, , 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 — 5 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network
BB Europe — 6 ist-muse.org Monitor Plane MP/KP: Architecture Knowledge Plane QoE decrease detectedroot cause analysis Monitoring data sources restorative action
BB Europe — 8 ist-muse.org Knowledge Plane Solution Execution Monitoring Plane Data Reduction Knowledge plane Overview 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 e.g. FEC, interleaving, local retransmission, device reconfiguration, warn end-user or network management, … Solve Problem Continuous monitoring
BB Europe — 9 ist-muse.org Monitor Plane MP/KP: Example Knowledge Plane QoE decrease detectedroot cause analysisrestorative action Loss Detected ADSL-line Statistics: loss detected Loss in Home Network Add FEC to stream Cause known: ADSL-line loss
BB Europe — 10 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network
BB Europe — 11 ist-muse.org Home Network Monitoring How to monitor? Limited or no knowledge & control of end-devices > Active monitoring > Passive monitoring Loss, RTT and Jitter monitoring From the Access Node ?
BB Europe — 12 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 — 13 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 — 15 ist-muse.org 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
BB Europe — 16 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 — 17 ist-muse.org RTP/RTCP loss estimation > Receiver report: > Same calculations can be done on AN, by looking at RTP stream # Expected - # Received Fraction lost since last RR Loss
BB Europe — 18 ist-muse.org Access node home network loss detection Receiver Reports (loss=A) RTP Monitoring on AN (loss=B) Calculate: A - B Access NetworkHome Network
BB Europe — 19 ist-muse.org RTP/RTCP interarrival Jitter estimation > Interarrival jitter: variance in interarrival time Server Access Node (AN) SjSj 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 SkSk AjAj AkAk End-Device RjRj RkRk SiSi AiAi RiRi
BB Europe — 24 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: A A1 A4 A4 A4 ACK 1 DP 1 Need smart matching for jitter detection!
BB Europe — 25 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 — 26 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 — 27 ist-muse.org TCP Middle Monitoring: ANTMA Example MP ACK 1DP 1DP 2DP 3DP 4DP 5DP 6ACK 2ACK 3 123A1A2A3456 ACK 3 History: 123A1 Can match:1,3 A2A ,66 LOST
BB Europe — 28 ist-muse.org Conclusion > Monitoring Plane Monitoring in Acces Network Monitoring in Home Network – RTP/RTCP – TCP > Knowledge Plane Detect & Solve QoE degradations