1. 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

2. BB Europe 14.12.2006 — 2 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

3. BB Europe 14.12.2006 — 3 ist-muse.org Access Network Overview Service Providers Service Edge Access Node Residential Gateway End Device User Access NetworkHome Network

4. BB Europe 14.12.2006 — 4 ist-muse.org 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?

5. BB Europe 14.12.2006 — 5 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

6. BB Europe 14.12.2006 — 6 ist-muse.org Monitor Plane MP/KP: Architecture Knowledge Plane QoE decrease detectedroot cause analysis Monitoring data sources restorative action

7. BB Europe 14.12.2006 — 7 ist-muse.org 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 …

8. BB Europe 14.12.2006 — 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

9. BB Europe 14.12.2006 — 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

10. BB Europe 14.12.2006 — 10 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

11. BB Europe 14.12.2006 — 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 ?

12. BB Europe 14.12.2006 — 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

13. BB Europe 14.12.2006 — 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

14. BB Europe 14.12.2006 — 14 ist-muse.org RTP/RTCP monitoring > Overview: RTP/RTCP basics Jitter Monitoring Loss Monitoring RTP RTCP Sender Reports RTCP Receiver Reports

15. BB Europe 14.12.2006 — 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

16. BB Europe 14.12.2006 — 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

17. BB Europe 14.12.2006 — 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

18. BB Europe 14.12.2006 — 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

19. BB Europe 14.12.2006 — 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

20. BB Europe 14.12.2006 — 20 ist-muse.org TCP monitoring > Overview: TCP basics RTT & Jitter Monitoring Loss Monitoring Our algorithm: ANTMA TCP

21. BB Europe 14.12.2006 — 21 ist-muse.org TCP: Basics DP 1 Sender Receiver Monitoring Point 1 A1 ACK 1

22. BB Europe 14.12.2006 — 22 ist-muse.org TCP: Loss DP 1 Time-out! Sender Receiver Monitoring Point 1 A1 1 ACK 1

23. BB Europe 14.12.2006 — 23 ist-muse.org 1 TCP: Flights DP 1DP 2ACK 1 Sender Receiver Monitoring Point A1 2 ACK 2 A2

24. BB Europe 14.12.2006 — 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: 1 2 3 4A1 2 3 4A1 A4 A4 A4 ACK 1 DP 1  Need smart matching for jitter detection!

25. BB Europe 14.12.2006 — 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!

26. BB Europe 14.12.2006 — 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

27. BB Europe 14.12.2006 — 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 A2A3 23 456 5,66 LOST

28. BB Europe 14.12.2006 — 28 ist-muse.org Conclusion > Monitoring Plane Monitoring in Acces Network Monitoring in Home Network – RTP/RTCP – TCP > Knowledge Plane Detect & Solve QoE degradations

29. BB Europe 14.12.2006 — 29 ist-muse.org Questions?