Recent Papers

1
Recent Papers

• from conferences

2
Sessions

• Session 1 Movies and Music
• Session 2 Peer-to-Peer Streaming
• Session 3 Power-Friendly

3
Movies and Music

• Session 1

4
Characterizing DVD

• Wu-Chi Feng et. al.
• Packet Video 2003

5
Motivations

• Lots of DVD videos available
• How are they encoded?
• What is the implications to our research?

6
DVD data

• 107 video streams
• 140 hours
• 80 DVDs

7
Bit-rates

• Maximum DVD bit rates 10 Mbps
• Found on DVD 3.3 7.8 Mbps
• VBR
• Quantization values change over time
• (only Spy Kids is CBR)

8
GOPs and Sequences

• Each GOP was encoded into a different sequence
• GOP sizes around 12 frames

9
Sequence

• sequence header
• width
• height
• frame rate
• bit rate

10
GOP Group of Picture

• gop header
• time

11
Picture

• pic header
• number
• type (I,P,B)

12
Frame Patterns

• Most videos have varying
• Number of frames within a GOP
• Frame patterns
• (ID4 has 134 unique GOP patterns)

13
Frame Pattern

• Scene Change Detection used extensively
• IPPPPPPP quite common!

14
Implication to Research

• Cannot assume fixed frame pattern
• Cannot always drop B frames

15
Network Musical Performances

• UC Berkeley
• NOSSDAV 2001

16
Goal

• Show that networked musical performances (NMP)
  can be done

17
Observation

• Stanford Berkeley (40 miles)
• RTT 4 ms
• 0.72 meters
• Berkeley Caltech (375 miles)
• RTT 28 ms
• 4.88 meters

18
Observation

• Musical instruments have long production latency

19
Observation

• Dont send audio, send command
• Keeps states of the current music performance

20
Example

• NoteOn(channel, note, velocity)
• NoteOff(channel, note)

21
Packet Loss Recovery

• Lost/Late NoteOn
• skipped
• Lost/Late NoteOff
• executed

22
Packet Loss Recovery

• Guard packets
• Recovery journals

23
Bandwidth

• 20 MIDI command per seconds
• 640 bps
• With recovery journals
• 7 kbps

24
Experience

• Lost/Late NoteOn/NoteOff
• But musician can adjust and play fluidly

25
Peer-to-Peer

• Session 2

26
P2Cast

• Yang Guo et. al.
• WWW 2003

27
Patching
Time
mcast
unicast
Client Request
28
Patching
Patching Window W
Time
mcast
mcast
Client Request
29
Problem with VOD

• IP Multicast usually assumed
• Patching still requires unicast connections

30
P2Cast
31
New Session
32
Existing Session Patch
Fat Pipe First
?
?
33
Patch Server Selection
34
Patching Stream
base stream
patching stream
35
Tree Example
36
Failure Recovery
X
37
Failure Recovery

• What if
• Patch server failed?
• Base server failed?

38
PROMISE

• Mohamed Hafeeda et. al.
• ACM MM 2003

39
Problem

• P2P with streaming
• One peer may not have enough bandwidth
• Need to aggregate multiple peers

40
Architecture
B/2
B/4
B/4
CollectCast
41
CollectCast

• Select sending peers
• Monitor network
• Assign streaming rates and data segments
• Decide when to change peers

42
PROMISE Operations
I want to watch LOTRT2T
43
PROMISE Operations
These are the candidates..
44
PROMISE Operations
Max expected goodness Subject to rate
constraints
45
PROMISE Operations
Here are your peers!
46
PROMISE Operations
Send these..
47
PROMISE Operations
Should I switch?
48
PALS

• Reza Rejaie et. al.
• NOSSDAV 2003

49
Problem

• P2P with streaming
• One peer may not have enough bandwidth
• Need to aggregate multiple peers
• Using layered coding
• With congestion control

50
Sliding Window
playout time
window
51
Packet Assignment
S1
S2
playout time
52
Sending Mechanism

• Request packets in priority order
• Sender must send in order
• Next request overwrites previous one

53
Power-Friendly

• Session 3

54
GRACE-OS

• Wanghong Yuan
• SOSP 2003

55
Motivation

• Mobile devices run on battery
• How to save battery?

56
Dynamic Voltage Scaling

• Example AMD Athlon 4 PowerOn 300, 500, 600,
  700, 800, 1000MHz
• Energy ? V2

57
CPU Scheduler

• When to execute a task
• How long to execute it
• How fast to execute it

58
CPU Reservation

• I need C units of time, out of every T units.

59
Probability Distribution
Cum. Prob.
0.8
80 of the time, this task requires 500 cycle.
cycles
500
60
CPU Requirements

• I need C units of time, out of every T units.
• CPU only needs to run at

With 80 success rate, C is 500 cycle
61
Speed Schedule
If task can finish early, we save energy by not
running it at higher speed
speed
time
62
Finding Speed Schedule

• Let task execute at speed vx during cycle x
• execution time 1/vx
• power ? vx2
• average power ? (1-F(x))vx2

63
Optimize This

• Minimize
• Subjected to

64
Implementation

• Linux Kernel
• AMD Athlon 4
• 716 lines of code

65
Findings

• Probability distribution is quite stable
• Able to meet deadlines with bounded miss ratio
• Save energy by 7 72

66
Proxy Assisted Streaming

• Prashant Shenoy et. al.
• MMCN 2003

67
Motivation

• Power-aware streaming to mobile device
• save energy in decoding frames
• save energy in receiving packets

68
Architecture
Heres my energy budget for decoding network
reception and max resolution
server/proxy
client
69
Architecture
OK, what should I send?
server/proxy
client
70
Information Needed

• Map stream properties to energy requirement
• Need to know decoding time of a frame

71
Frame Decoding Time
Time (s)
Frame Size (bits)
72
Transcoding

• If current stream would exceed client decoding
  energy budget
• Need to transcode by reducing quality

73
Transcode to what?

• E estimated energy needed
• while E gt energy budget
• reduce quality by e
• E estimate energy needed

74
Transcoded Streams
server/proxy
client
75
Reducing NIC Energy

• NIC has two modes active/sleep
• Client can activate NIC only when packets are
  expected.

76
Burst Transmission
I will start transmitting at 101254.86 pm
77
Evaluations
Decoding Time
Frame Number
78
Evaluations

• NIC Idle Uptime 2 20