1 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Continuous Scheduling for Data-Driven Peer-to-Peer Streaming Jyrki Akkanen Peer-to-peer team, Internet Laboratory Nokia Research Center, Helsinki, Finland

2 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Agenda Data-driven (pull-based mesh) P2P streaming Continuous data-driven P2P streaming Early experience results

3 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Our original motivation Desired practical P2P streaming solution For Symbian/S60 mobile phones No “perfect” solution exists yet Desired to improve joining time On-going work, results are preliminary

4 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Peer-to-peer streaming: two basic questions How to manage the overlay topology? Centralized tracker Random topology, 4-8 neighbors How to disseminate data? Data-driven / pull-based mesh Well-known, much used in practice

5 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Data-driven (pull-based) stream delivery Mesh topology Each node has a small set of partners Stream split in pieces Nodes collect pieces in buffer Window of interest / Request window in the front Playing from the back Notify – Request – Response pattern Buffer content advertised to partners Scheduling: what to fetch, when and where Requests sent to partners Partners return pieces one by one Periodic operation 1-2 second scheduling/request period NotifyRequestSend source Window of Interest Jitter Window

6 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Challenges of periodic operation Buffer lag Advertising+scheduling delay 1-2 sec Receiving node lags sending partner Partners who lag cannot contribute Low reacton time, slow re-transmit Wait for the next scheduling round Consequences Long end-to-end delay Long window of interest (30 sec or more) Hard to find partners that don’t lag and have enough capacity Low delivery ratio Can we run it faster? Better gain, shorter delay Increases overhead Same timing, exchange few pieces Different timing, unidirectional traffic

7 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Continuous Data-driven Streaming Protocol Speed up the basic data-driven protocol Up to point where it no more operates periodically Small piece size 1250 Bytes = single IP packet Narrow window of interest 256 packets = 8.5 sec at 200 kbps Send incremental notifications continuously As soon as possible after you get a piece Scheduler runs continuously Notifications fed in one by one whenever they arrive Maintains plan to fetch pieces from partners Requests sent continuously One by one at “last possible” moment Requests are waiting in the scheduler Scheduler

8 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Communication over UDP Rare selection: TCP is usually preferred Better timing, improved reaction speed Control on re-transmission AIMD-based rate control; could also use TFRC May lead to difficulties with firewalls etc.

9 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Fighting against overhead Need to send lots of small amounts of control data all the time Piggybacking Control data piggybacked to stream data whenever possible Ability to mutually exchange data also helps Less need to send “control” packets without stream data In practice Rate control regularly allows transmission opportunities to each link On each opportunity, assemble a packet from what you need to send Incremental notifications sent in small groups (1-10)

10 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Source fan-out policy Mandatory process to create initial packet distribution at first hop peers Selective advertising Simple fan-out policy Decreased density of packets Randomly selected packets Advertised Window of Interest

11 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Simple scheduler Packet is scheduled or re-scheduled whenever notification is received request is lost Maintain a request queue per each partner holds assigned requests in randomized order sorted by seqno + X where X is uniformly random insert request in shortest queue Pick requests from the queues when needed window-based flow control minimize the number of outstanding requests Scheduling policy concerns bandwidth constrained peers only others have always almost empty queues prefers rare and urgent packets virtual time sorting increases diversity randomize order select shortest queue pick request re-notified lost

12 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Implementation status A portable C++ implementation Simulation in Linux Demonstration with Linux PCs Demonstration with Symbian phones

13 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Simulations in Linux PC Simple network simulator centralized router with tail drop queues 500 kbps links with 50 ms latency Artificial media stream 200 kbps, 20 packets/sec Simple dynamic scenario random overlay topology, 4 partners / node initially 100 nodes after 120 seconds drop half of the nodes remaining peers re-connect so that all have 4 partners again

14 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk End-to-end delay, simulated No frames are lost 50% of peers lost at 120 sec

15 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Recent simulation results (not in paper) Dynamic scenarios with Poisson join/leave process Exponentially distributed random dwelling time 50 or 100 sec Each newcomer joined to 6 randomly selected peers

16 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Live video streaming Live network of 4 Nokia N93i smart phones Ad-hoc WLAN network Video from phone camera H.263 profile 0 level x 288 pixels, 16M colors, 15 fps variable data rate 64 – 315 kbps Other three phones viewed the video Player learned optimal playback point End-to-end latency was 10 sec No frames lost Full mesh overlay topology

17 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Video rate at source, live

18 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Window of interest and player jitter Window of Interest Jitter Window

19 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Network overhead, live Due to heavy piggybacking cannot distinguish data and control packets Total protocol overhead 14.4% all transmitted bytes including IP/UDP headers relative to received stream data live network, 3 peers For comparison periodic data-driven overlay streaming: ~10% unidirectional HTTP downloading: 7.2% (our measurement)

20 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Total network overhead, simulated (not in paper)

21 © 2008 Nokia continous_scheduling_fmn_2008 / / JAk Continuous scheduling approach: summary Work in progress Not yet tested in real large-scale networks Overhead is largish, but not intolerable not yet optimized Seems to provide small latency high delivery ratio good resilience for dynamics Difficulties with bandwidth constraints congestion close to the source few critical, bandwidth constrained overlay links Need better fan-out and scheduling policies must diffuse new packets quickly far out to the network