[PPT] - Measuring and Understanding IPTV Networks Colin Perkins PowerPoint Presentation

SLIDE 1

Measuring and Understanding IPTV Networks

Colin Perkins

http://csperkins.org/

Martin Ellis

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

SLIDE 2

Talk Outline

Research goals
Measuring and monitoring IPTV systems
Measurement architecture and initial data
Implications for IPTV systems
Future directions

2

SLIDE 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.
Consider network tomography for management

3

[Joint with Jörg Ott’s group @ TKK]

SLIDE 4

IPTV System Model – Interdomain

4

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 R R

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

SLIDE 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

5

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

SLIDE 6

Understanding System Performance

Only limited IPTV measurements available
Most studies either between well-connected sites
r 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

SLIDE 7

Interdomain Measurement Architecture

Server well-connected
n 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

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

JANET ISP1 ISP2

ADSL

Client Client Client

ADSL Cable

SLIDE 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?

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

JANET ISP1 ISP2

ADSL

Client Client Client

ADSL Cable

SLIDE 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

<10W, silent, size of a book

9

SLIDE 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
ver time
Input to simulation of repair mechanisms

and topology inference

10

SLIDE 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
Starting phase 2

11

SLIDE 12

Initial Measurements

12

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 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 Initial trace duration: 1-7 November 2008 ~16 million packets

SLIDE 13

Packet Loss – Loss Rates

13

10 20 30 40 50 60 70 80 5 10 15 20 25 30 Packet Loss Rate (percent) Time ADSL 4Mbps

2 4 6 8 10 20 40 60 80 100 120 140 160 180 Packet Loss Rate (percent) Time (hours) ADSL 1Mbps Cable 1Mbps

2 4 6 8 10 5 10 15 20 25 30 Packet Loss Rate (percent) Time ADSL 2Mbps

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

SLIDE 14

Packet Loss – Loss Run Lengths

14

1 10 100 1000 10000 100000 1e+06 1 2 3 4 5 6 7 8 9 Frequency Loss burst duration (packets) 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?

SLIDE 15

Packet Loss – Good Run Lengths

15

1 10 100 1000 10000 100000 1 10 100 1000 10000 Frequency Good run duration (packets) ADSL 1Mbps ADSL 2Mbps ADSL 4Mbps Cable 1Mbps Cable 2Mbps

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

SLIDE 16

Packet Reordering

16

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

SLIDE 17

ADSL Inter-arrival Times

17

500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency Binned interarrival times (milliseconds) 4 Nov 2008 06:50 500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency Binned interarrival times (milliseconds) 4 Nov 2008 13:50

Traffic dispersion pattern not unexpected
Highly dependent on time-of-day

1 Mbps CBR flows

SLIDE 18

ADSL Inter-arrival Times (24 Hour Trace)

18

500 1000 1500 2000 2500 3000 11/04 00:00 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 00:00 Date and Time 6 8 10 12 14 Binned Interarrival Time (milliseconds)

SLIDE 19

ADSL Inter-arrival Times (1 Week Trace)

19

500 1000 1500 2000 2500 3000 11/01 00:00 11/02 00:00 11/03 00:00 11/04 00:00 11/05 00:00 11/06 00:00 11/07 00:00 11/08 00:00 Date and Time 6 8 10 12 14 Binned Interarrival Time (milliseconds)

SLIDE 20

500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency Binned interarrival times (milliseconds) 4 Nov 2008 04:30

Slightly worse dispersion than ADSL at busy times,

much better at quiet times

Cable Inter-arrival Times

20

500 1000 1500 2000 2500 3000 6 8 10 12 14 Frequency Binned interarrival times (milliseconds) 4 Nov 2008 20:50

SLIDE 21

Cable Inter-arrival Times (24 Hour Trace)

21

500 1000 1500 2000 2500 3000 11/04 00:00 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 00:00 Date and Time 6 8 10 12 14 Binned Interarrival Time (milliseconds)

Temporal profile differs from ADSL: sharper distinction between unloaded and busy times; more residential users?

SLIDE 22

Cable Inter-arrival Times (1 Week Trace)

22

500 1000 1500 2000 2500 3000 11/01 00:00 11/02 00:00 11/03 00:00 11/04 00:00 11/05 00:00 11/06 00:00 11/07 00:00 11/08 00:00 Date and Time 6 8 10 12 14 Binned Interarrival Time (milliseconds)

SLIDE 23

Summary of Measurements

23

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

SLIDE 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
f FEC to protect against these; reactive repair
Need more data, from flows reflecting real IPTV

traffic, to confirm repair effectiveness

24

SLIDE 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

proxy for full packet traces, if available

25

SLIDE 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
Application to repair and tomography tasks

26

SLIDE 27