Measuring and Understanding IPTV Networks

(1)

Measuring and Understanding

IPTV Networks

Colin Perkins

http://csperkins.org/

Martin Ellis

http://www.dcs.gla.ac.uk/~ellis/

(2)

Talk Outline

•

Research goals

•

Measuring and monitoring IPTV systems

• Measurement architecture and initial data

• Implications for IPTV systems

(3)

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.

(4)

IPTV System Model – Interdomain

Monitoring – end-to-end and at domain borders Repair – at edges of content distributor network Feedback Aggregation – inter- and intra-domain Transit Provider B

Content Distributor B Content Provider

Transit Provider A Content Distributor A

S

R

Expected future evolution; deployed IPTV systems a restricted subset – need to understand the end-to-end performance to evolve system

(5)

•

Expect largely tree-structured access network, more well-connected in the core

•

Much access/edge network

topology is hidden below the IP layer, but will influence its performance

•

Long term goal: infer the

edge topology using network tomography, understand and locate problems

IPTV System Model – Intradomain

S S Core Network R R R R R R R R R R R R R R R R Access Networks Home Networks D D FT FT

(6)

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

(7)

Interdomain Measurement Architecture

• Server well-connected

on public Internet

• Clients on residential

connections

• Inter-domain path from

server to client

•

~15 hops to UK ISPs;

choke-point at Telehouse in London

•

Simulates interdomain IPTV

scenario Server (curtis.dcs.gla.ac.uk)

JANET

ISP1

ISP2

ADSL _Client Client Client ADSL Cable

(8)

Measurement Architecture – Limitations

• 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

• Difficult to separate effect of edge

from problems in the core

• Will measurements to other

well-connected hosts let us infer home

network performance?

Server (curtis.dcs.gla.ac.uk)

JANET

ISP1

ISP2

ADSL _Client Client Client ADSL Cable

(9)

Measurement Platform

• Deploy into home networks

•

ADSL - generally 8Mbps downstream

•

Cable modem

• Expect a mix of users

•

Technical - own Linux/Unix system at

home, can run measurement tool

•

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

(10)

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

(11)

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

(12)

Initial Measurements

ADSL

IPTV CBR 1Mbps Hourly at :50 1min

IPTV CBR 2Mbps 03:15 10:15 15:15 20:15 10 mins

VoIP CBR 64kbps Hourly at :10 1 min

Cable Modem

IPTV CBR 1Mbps Hourly at :30 1 min

IPTV CBR 4Mbps (not supported by access link) 10 mins

Initial trace duration: 1-7 November 2008 ~16 million packets

(13)

Packet Loss – Loss Rates

10 20 30 40 50 60 70 80

Packet Loss Rate (percent)

ADSL 4Mbps 0 2 4 6 8 10 0 20 40 60 80 100 120 140 160 180

Time (hours) ADSL 1Mbps Cable 1Mbps 0 2 4 6 8 10 0 5 10 15 20 25 30

Time

ADSL 2Mbps

Non-negligible packet loss on ADSL network, unaffected by data rate below some threshold

(14)

Packet Loss – Loss Run Lengths

10 100 1000 10000 100000 1e+06 Frequency ADSL 1Mbps ADSL 2Mbps ADSL 4Mbps Cable 1Mbps Cable 2Mbps

No clear distinction between ADSL and cable 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?

(15)

Packet Loss – Good Run Lengths

1 10 100 1000 10000 100000 Frequency ADSL 1Mbps ADSL 2Mbps ADSL 4Mbps Cable 1Mbps Cable 2Mbps

Most packets are in long good runs, but most good runs are short

(16)

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

(17)

ADSL Inter-arrival Times

0 500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency

Binned interarrival times (milliseconds)

4 Nov 2008 06:50 0 500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency

4 Nov 2008 13:50

• Traffic dispersion pattern not unexpected

• Highly dependent on time-of-day

(18)

ADSL Inter-arrival Times (24 Hour Trace)

0 500 1000 1500 2000 2500 3000 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/04 11/05 6 8 10 12 14

(19)

ADSL Inter-arrival Times (1 Week Trace)

0 500 1000 1500 2000 2500 3000 11/01

00:00 11/0200:00 11/0300:00 11/0400:00_{Date and Time}11/0500:00 11/0600:00 11/0700:00 11/0800:00 6

8 10 12 14

(20)

0 500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency

4 Nov 2008 04:30

• Slightly worse dispersion than ADSL at busy times,

much better at quiet times

Cable Inter-arrival Times

0 500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency

(21)

Cable Inter-arrival Times (24 Hour Trace)

0 500 1000 1500 2000 2500 3000 11/04

00:00 11/0402:00 11/0404:00 11/0406:00 11/0408:00 11/0410:00_{Date and Time}12:0011/04 14:0011/04 11/0416:00 11/0418:00 11/0420:00 11/0422:00 11/0500:00 6

8 10 12 14

Binned Interarrival Time (milliseconds) Temporal profile differs from ADSL: sharper distinction between unloaded and busy times; more residential users?

(22)

Cable Inter-arrival Times (1 Week Trace)

0 500 1000 1500 2000 2500 3000 11/01 11/02 11/03 11/04 11/05 11/06 11/07 11/08 6 8 10 12 14

(23)

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

(24)

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

(25)

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

(26)

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

(27)