Measuring and Understanding IPTV Networks Colin Perkins http://csperkins.org/ Martin Ellis http://www.dcs.gla.ac.uk/~ellis/
Talk Outline Research goals Measuring and monitoring IPTV systems Measurement architecture and initial data Implications for IPTV systems Future directions 2
Research Goals Measure and understand the impairments affecting IPTV network traffic Packet loss/timing; media aware if possible Intra- and inter-domain flows Improve techniques for on-line error repair and off-line network troubleshooting Inform choice of FEC, retransmission, etc. Consider network tomography for management [Joint with Jörg Ott s group @ TKK] 3
IPTV System Model Interdomain Transit Provider A Content Distributor A R Content Provider S Transit Provider B Expected future evolution; deployed IPTV systems a restricted subset need to understand the end-to-end performance to evolve system Content Distributor B R R Monitoring end-to-end and at domain borders Repair at edges of content distributor network Feedback Aggregation inter- and intra-domain 4
IPTV System Model Intradomain S S Core Network D FT FT D Expect largely tree-structured access network, more wellconnected in the core Much access/edge network topology is hidden below the IP layer, but will influence its performance Access Networks Home Networks R R R R R R R R R R R R R R Long term goal: infer the edge topology using network tomography, understand and locate problems R R 5
Understanding System Performance Only limited IPTV measurements available Most studies either between well-connected sites or using TCP for media transport Little data on UDP-based IPTV performance Interdomain from well-connected servers to residential hosts, to understand end-to-end path Intradomain to understand behaviour of edge networks, evaluate effectiveness of network tomography to diagnose edge problems Beginning to collect data early interdomain results today 6
Interdomain Measurement Architecture ISP1 Server (curtis.dcs.gla.ac.uk) JANET ISP2 Server well-connected on public Internet Clients on residential connections Inter-domain path from server to client Client ADSL ADSL Client Cable Client ~15 hops to UK ISPs; chokepoint at Telehouse in London Simulates interdomain IPTV scenario 7
Measurement Architecture Limitations ISP1 Server (curtis.dcs.gla.ac.uk) JANET ISP2 Server on the public network Conceptually acts as a STUN server for NAT traversal Will likely need to implement ICE for peer-to-peer scenarios Uncontrolled interdomain path ADSL Cable Difficult to separate effect of edge from problems in the core Client ADSL Client Client Will measurements to other wellconnected hosts let us infer home network performance? 8
Measurement Platform Deploy into home networks ADSL - generally 8Mbps downstream Technical - own Linux/Unix system at home, can run measurement tool Cable modem Expect a mix of users But uncontrolled measurement environment; undesirable variation Non-technical - require unobtrusive, low-maintenance, measurement box Soekris net5501 single-board computer with 120GB disk, running FreeBSD 7 <10W, silent, size of a book 9
Measurement Using Test Streams Aim: generate test traffic to (roughly) match IPTV flows Measure loss/jitter characteristics Looking to move to real-world streaming IPTV over time Input to simulation of repair mechanisms and topology inference 10
Measurement Plan Three phases: 1. Initial experiment: CBR flows, manually triggered 2. Simulated VoIP and IPTV traffic, manual control 3. Simulated VoIP and IPTV traffic, automated tool Starting phase 2 11
Initial Measurements ADSL IPTV CBR 1Mbps Hourly at :50 1min IPTV CBR 2Mbps 03:15 10:15 15:15 20:15 10 mins IPTV CBR 4Mbps 03:35 10:35 15:35 20:35 10 mins VoIP CBR 64kbps Hourly at :10 1 min Cable Modem Initial trace duration: 1-7 November 2008 ~16 million packets IPTV CBR 1Mbps Hourly at :30 1 min IPTV CBR 2Mbps 04:15 11:15 16:15 21:15 10 mins IPTV CBR 4Mbps (not supported by access link) 10 mins VoIP CBR 64kbps Hourly at :55 1 min 12
Packet Loss Loss Rates 10 ADSL 1Mbps Cable 1Mbps 10 8 ADSL 2Mbps Packet Loss Rate (percent) 8 6 4 2 Packet Loss Rate (percent) 6 4 2 0 80 0 5 10 15 20 25 30 Time ADSL 4Mbps 70 0 0 20 40 60 80 100 120 140 160 180 Time (hours) Non-negligible packet loss on ADSL network, unaffected by data rate below some threshold Packet Loss Rate (percent) 60 50 40 30 20 10 0 0 5 10 15 20 25 30 Time 13
Packet Loss Loss Run Lengths Frequency 1e+06 100000 10000 1000 100 ADSL 1Mbps ADSL 2Mbps ADSL 4Mbps Cable 1Mbps Cable 2Mbps High rate flows: linear plot geometric distribution Lower rate flows show some evidence of longer tail Hypothesis: uniform loss probability dependent on data rate with background rate-independent bursty loss? No clear distinction between ADSL and cable 10 1 1 2 3 4 5 6 7 8 9 Loss burst duration (packets) 14
Packet Loss Good Run Lengths Frequency 100000 10000 1000 100 ADSL 1Mbps ADSL 2Mbps ADSL 4Mbps Cable 1Mbps Cable 2Mbps Most packets are in long good runs, but most good runs are short 10 1 1 10 100 1000 10000 Good run duration (packets) 15
Packet Reordering Packet reordering infrequent 4 packets reordered out of ~16 million sent Worst was out-of-sequence (delayed) by 4 packets 2 flows affected Matches expectations: reordering due to route change or misbehaving load balancing at high rates 16
ADSL Inter-arrival Times 3000 4 Nov 2008 06:50 3000 4 Nov 2008 13:50 2500 2500 2000 2000 Frequency 1500 Frequency 1500 1000 1000 500 500 0 6 8 10 12 14 0 6 8 10 12 14 Binned interarrival times (milliseconds) Binned interarrival times (milliseconds) 1 Mbps CBR flows Traffic dispersion pattern not unexpected Highly dependent on time-of-day 17
ADSL Inter-arrival Times (24 Hour Trace) 3000 Binned Interarrival Time (milliseconds) 14 12 10 8 6 11/04 11/04 02:00 11/04 04:00 11/04 06:00 11/04 08:00 11/04 10:00 11/04 12:00 11/04 14:00 11/04 16:00 11/04 18:00 11/04 20:00 11/04 22:00 11/05 Date and Time 2500 2000 1500 1000 500 0 18
ADSL Inter-arrival Times (1 Week Trace) 3000 Binned Interarrival Time (milliseconds) 14 12 10 8 6 2500 2000 1500 1000 500 11/01 11/02 11/03 11/04 11/05 Date and Time 11/06 11/07 11/08 0 19
Cable Inter-arrival Times 3000 4 Nov 2008 04:30 3000 4 Nov 2008 20:50 2500 2500 2000 2000 Frequency 1500 Frequency 1500 1000 1000 500 500 0 6 8 10 12 14 0 6 8 10 12 14 Binned interarrival times (milliseconds) Binned interarrival times (milliseconds) Slightly worse dispersion than ADSL at busy times, much better at quiet times 20
Cable Inter-arrival Times (24 Hour Trace) 3000 14 Binned Interarrival Time (milliseconds) 12 10 8 6 Temporal profile differs from ADSL: sharper distinction between unloaded and busy times; more residential users? 2500 2000 1500 1000 500 11/04 11/04 02:00 11/04 04:00 11/04 06:00 11/04 08:00 11/04 10:00 11/04 12:00 11/04 14:00 11/04 16:00 11/04 18:00 11/04 20:00 11/04 22:00 11/05 Date and Time 0 21
Cable Inter-arrival Times (1 Week Trace) 3000 Binned Interarrival Time (milliseconds) 14 12 10 8 6 2500 2000 1500 1000 500 11/01 11/02 11/03 11/04 11/05 Date and Time 11/06 11/07 11/08 0 22
Summary of Measurements Despite uncontrolled inter-domain path, see clear distinctions between edge networks Analysis just starting... Very early results: planning to conduct more measurements Range of different ISPs Multiple users in the same ISP 23
Implications for Error Concealment If these results are typical Most loss bursts short (2-3 packets), but many short good runs small amounts of FEC, but not on adjacent packets Longer bursts infrequent not worth overhead of FEC to protect against these; reactive repair Need more data, from flows reflecting real IPTV traffic, to confirm repair effectiveness 24
Implications for Network Trouble Shooting Eventual aim: network tomography to locate problem areas in access network Collecting more data, to understand correlation between receivers in single ISP Expect to be able to trace 2 or 3 receivers in deployed networks without ISP cooperation Not enough to confirm use of tomography, but hopefully sufficient to direct future measurements RTCP XR summary reports would be a good proxy for full packet traces, if available 25
Future Work Debugging and deploying measurement tool across a range of ISPs Interest and potential collaboration with other groups for wider data collection Will make traces available once infrastructure stabilises Analysis and understanding performance Application to repair and tomography tasks 26