Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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