Project Presentation. Reminder 13th November 1 – 5pm Read your emails/Visit web sites for more information (later)

Project Presentation

Reminder

• 13th November 1 – 5pm

• Read your emails/Visit web sites for more information (later)

Reminder

• Please check your project title• Please check your grades

Reviews Categories

• 4 categories• No submission• Did not demonstrate understanding• Understand and summarize• Understand, think and summarize

What I Hope You Have Learned

• How to read papers?• How to evaluate papers?• Think critically about what you

read

Recent Papers

from conferences

Sessions

•Session 1: Movies and Music•Session 2: Peer-to-Peer

Streaming•Session 3: Power-Friendly

Movies and Music

Session 1

Characterizing DVD

Wu-Chi Feng et. al.Packet Video 2003

Motivations

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

research?

DVD data

•107 video streams•140 hours•80 DVDs

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)

GOPs and Sequences

• Each GOP was encoded into a different sequence

• GOP sizes: around 12 frames

NUS.SOC.CS5248OOI Wei Tsang

Sequence

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

NUS.SOC.CS5248OOI Wei Tsang

GOP: Group of Picture

gop header:• time• :

NUS.SOC.CS5248OOI Wei Tsang

Picture

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

Frame Patterns

• Most videos have varying• Number of frames within a GOP • Frame patterns

(ID4 has 134 unique GOP

patterns)

Frame Pattern

• Scene Change Detection used extensively

• IPPPPPPP quite common!

Implication to Research

• Cannot assume fixed frame pattern

• Cannot always drop B frames

Network Musical Performances

UC BerkeleyNOSSDAV 2001

Goal

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

Observation

• Stanford – Berkeley (40 miles)• RTT ~4 ms• 0.72 meters

• Berkeley – Caltech (375 miles)• RTT ~28 ms• 4.88 meters

Observation

• Musical instruments have long production latency

Observation

• Don’t send audio, send command

• Keeps “states” of the current music performance

Example

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

Packet Loss Recovery

• Lost/Late NoteOn • skipped

• Lost/Late NoteOff• executed

Packet Loss Recovery

• Guard packets

• Recovery journals

Bandwidth

• 20 MIDI command per seconds• 640 bps

• With recovery journals• ~7 kbps

Experience

• Lost/Late NoteOn/NoteOff

• But musician can adjust and play fluidly

Peer-to-Peer

Session 2

P2Cast

Yang Guo et. al. WWW 2003

NUS.SOC.CS5248OOI WEI TSANG

Patching

Time

Client Request

mcast

unicast

NUS.SOC.CS5248OOI WEI TSANG

Patching

Time

Client Request

Patching Window: W

mcast

mcast

Problem with VOD

• IP Multicast usually assumed• Patching still requires unicast

connections

P2Cast

New Session

Existing Session + Patch

?

?

Fat Pipe First

Patch Server Selection

Patching Stream

patching stream

base stream

Tree Example

Failure Recovery

X

Failure Recovery

• What if• Patch server failed?

• Base server failed?

PROMISE

Mohamed Hafeeda et. al.

ACM MM 2003

Problem

• P2P with streaming• One peer may not have enough

bandwidth• Need to aggregate multiple

peers

Architecture

B/2B/4B/4

CollectCast

CollectCast

• Select sending peers• Monitor network• Assign streaming rates and data

segments• Decide when to change peers

PROMISE Operations

I want to watch

LOTR:T2T

PROMISE Operations

These are the

candidates..

PROMISE Operations

Max expected goodnessSubject to rate constraints

PROMISE Operations

Here are your peers!

PROMISE Operations

Send these..

PROMISE OperationsShould

I switch

?

PALS

Reza Rejaie et. al.NOSSDAV 2003

Problem

• P2P with streaming• One peer may not have enough

bandwidth• Need to aggregate multiple

peers•Using layered coding•With congestion control

Sliding Window

playout time window

Packet Assignment

playout timeS1 S2

Sending Mechanism

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

one

Power-Friendly

Session 3

GRACE-OS

Wanghong YuanSOSP 2003

Motivation

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

Dynamic Voltage Scaling

•Example: AMD Athlon 4 PowerOn {300, 500, 600, 700, 800, 1000}MHz

• Energy V2

CPU Scheduler

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

NUS.SOC.CS5248OOI WEI TSANG

CPU Reservation

“I need C units of time, out of every T units.”

Probability Distribution

cycles

Cum. Prob.

CPU Requirements

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

Speed Schedulesp

eed

time

Finding Speed Schedule

• Let task execute at speed vx

during cycle x• execution time:• power:• average power:

Optimize This

• Minimize:

• Subjected to:

Implementation

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

Findings

• Probability distribution is quite stable

• Able to meet deadlines with bounded miss ratio

• Save energy by 7 – 72%

Proxy Assisted Streaming

Prashant Shenoy et. al.MMCN 2003

Motivation

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

Architecture

server/proxy client

Here’s my energy budget for decoding +

network reception and max resolution

Architecture

server/proxy client

OK, what should I send?

Information Needed

• Map stream properties to energy requirement

• Need to know decoding time of a frame

Frame Decoding Time

Estimating Frame Decoding Time

Transcoding

• If current stream would exceed client decoding energy budget

• Need to transcode by reducing quality

Transcode to what?

E = estimated energy neededwhile E > energy budget reduce quality by ε E = estimate energy needed

Transcoded Streams

server/proxy client

Reducing NIC Energy

• NIC has two modes : active/sleep

• Client can activate NIC only when packets are expected.

Burst Transmission

I will start transmitting at

10:12:54.86 pm

EvaluationsDecoding Time

Frame Number

Evaluations

• NIC Idle Uptime: 2 – 20%