An End-to-end Architecture for Quality-Adaptive Streaming Applications in Best-effort Networks

1USC INFORMATION SCIENCES INSTITUTE

An End-to-end Architecture for Quality-Adaptive Streaming Applications in Best-effort Networks

Reza [email protected]

USC/ISI

http://netweb.usc.edu/reza

April 13, 1999


Motivation Rapid growth in deployment of realtime

streams(audio/video) over the Internet TCP is inappropriate for realtime streams

The Internet requires end-system to react to congestion properly and promptly

Streaming applications require sustained consumption rate to deliver acceptable and stable quality


Best-effort Networks (The Internet)

Shared environment Bandwidth is not known a prior Bandwidth changes during a session Seemingly-random losses

TCP-based traffic dominates End-to-end congestion control is crucial for

stability, fairness & high utilization

End-to-end congestion control in a TCP-friendly fashion is the main requirement in the Internet


Streaming Applications

Delay-sensitive Semi-reliable Rate-based

Require QoS from the end-to-end point of view

Internet

Adaptation

Buffer

Decoder

TCP TCP

Server

Display

Encoder

Source


Designing an end-to-end congestion control mechanism

Delivering acceptable and stable quality while performing congestion control

The Problem


Outline

The End-to-end Architecture Congestion Control (The RAP protocol) Quality Adaptation

Extending the Architecture Multimedia Proxy Caching

Contributions Future Directions


Buffer Manager

Archive

ErrorControl

QualityAdaptation

Transmission Buffer

Cong.Control Acker

Decoder

PlaybackBuffer

Inte

rnet

Server ClientAdaptation Buffer

Data pathControl path

The End-to-end Architecture

Buffer Manager


Outline

The End-to-end Architecture Congestion Control (The RAP Protocol) Quality Adaptation




Previous works on Congestion Ctrl.

Modified TCP [Jacob et al. 97], SCP[Cen et al. 98]

TCP equation [Mathis et al. 97], [Padhye et al. 98]

Additive Inc., Multiplicative Dec. LDA[Sisalem et al. 98]

NETBLT[Lixia!] Challenge: TCP is a moving target


Overview of RAP

Decision Function Increase/Decrease

Algorithm Decision Frequency

Goal: to be TCP-friendlyTime

Rat

e

Decision Frequency

Decision Function

+ --

Increase/Decrease Algorithm


Congestion Control Mechanism

Adjust the rate once per round-trip-time (RTT)

Increase the rate periodically if no congestion

Decrease the rate when congestion occurs Packet loss signals congestion

Cluster Loss Grouping losses per congestion event


Rate Adaptation Algorithm

Coarse-grain rate adaptation Additive Increase, Multiplicative Decrease (AIMD)

Extensive simulations revealed: TCP’s behavior substantially varies with network

conditions, e.g. retransmission timeout, bursty TCP is responsive to a transient congestion

AIMD only emulates window adjustment in TCP


Rate Adaptation Algorithm(cont’d)

Fine-grain rate adaptation The ratio of short-term to long-term average

RTT

Emulates ACK-clocking in TCP Increase responsiveness to transient

congestion


Coarse vs fine grain RAP figImpact of fine-grain rate adaptation


RAP against Tahoe, Reno, NewReno & SACK

Inter-dependency among parameters

Config. parameters: Bandwidth per flow RTT Number of flows

RA

P S

inksT

CP

Sinks

RAP Traffic

SW

TCPTraffic

SW

RA

P S

ourcesT

CP

Sources

RAP Simulation

Fairness Ratio = Avg. RAP BW

Avg. TCP BW


Fairness ratio across the parameter space without F.G. adaptation


Fairness ratio across the parameter space with F.G. adaptation


Impact of RED switches on Fairness ratio


Summary of RAP Simulations

RAP achieves TCP-friendliness over a wide range Fine grain rate adaptation extends inter-protocol fairness to a

wider range Occasional unfairness against TCP traffic is mainly

due to divergence of TCP congestion control from AIMD Pronounced more clearly for Reno and Tahoe The bigger TCP’s congestion window, the closer its behavior

to AIMD RED gateways can improve inter-protocol sharing

Depending on how well RED is configured RAP is a TCP-friendly congestion controlled UDP


Outline





Buffer Manager

Archive

ErrorControl

QualityAdaptation

Transmission Buffer

Cong.Control Acker

Decoder

PlaybackBuffer

Inte

rnet

Server ClientAdaptation Buffer

Data pathControl path

Quality Adaptation

Buffer Manager


The Problem

Delivering acceptable and stable quality while performing congestion control

Seemingly random losses result in random & potentially wide variations in bandwidth

Streaming applications are rate-based


Role of Quality Adaptation

Buffering only absorb short-term variations

Long-lived session could result in buffer overflow or underflow

Quality Adaptation is complementary for buffering

Adjust the quality with long-term variations in bandwidth

BW(t)

Time


Adaptive encoding [Ortega 95, Tan 98] CPU-intensive

Switching between multiple encoding High storage requirement

Layered encoding[McCanne 96, Lee 98] Inter-layer decoding dependency

When/How much to adjust the quality?

Mechanisms to Adjust Quality


Assumptions AIMD variations in bandwidth(rate) Linear layered encoding

Constraint Obeying congestion controlled rate

limit Goal

To control the level of smoothing

Assumptions & Goals


Layered Quality Adaptation

Layer 2

Layer 1

Layer 0

+bw (t)2

bw (t)1

bw (t)0

Inte

rnet

Decoder

Time(sec)

BW

(t)

bw (t)1

bw (t)0

C

C

C Display

Linear layered stream

buf 0

buf 1

buf 2

bw (t)2

QualityAdaptation

Con

sum

ptio

n

ra

te

C

Time(msec)

BW

(t)

BW(t) BW(t)

a c

b

Filling Phase

Draining Phase

C

C


Buffering Tradeoff Each buffering layer can only

contribute at most C(bps) Buffering for more layers

provides higher stability

bw (t)1

bw (t)0

C

C

Cbuf 0

buf 1

bw (t)2

Time

BW

(t)

BW(t)

nC

buf 2

C

C

C

C

Buffered data for a dropped layer is useless for recovery Buffering for lower layers is

more efficient What is the optimal buffer distribution for a single back-off scenario?


Optimal buffer state depends on time of the back-off

Draining pattern depends on the buffer state

Back-off occurs randomly

Keep the buffer state as close to the optimal as possible during the filling phase

Time

BW

(t) Draining

Phase

4CCC

Buf. data &Buf. data &

Filling Phase

Optimal Inter-layer Buffer Allocation

Buf. data &

BW share of L0BW share of L1BW share of L2


Add a layer when buffering is sufficient for a single back-off

Drop a layer when buffering is insufficient for recovery

Random losses could result in frequent add and drop unstable quality

Conservative adding results in smooth changes in quality

Time

Adding & Dropping

BW

(t)

Draining Phase

nC

Draining Phase

(n-1)C

Buf. data for L0Buf. data for L1Buf. data for L2


Conservative adding When average bandwidth is sufficient When sufficient buffering for K back-offs

Buffer constraint is preferred and sufficient Directly relate time of adding to the buffer state Effectively utilizes the available bandwidth

K is a smoothing factor Short-term quality vs long-term smoothing

Smoothing


ProperBuf. State recovery from 1 backoff

ProperBuf. State recovery from 2 backoffs

ProperBuf. State recovery from K backoffs

Add aLayer

Drop aLayer

Filling

Smooth Filling & Draining

Draining


KB/s

C = 10

Buf. L3(KB)9.5

9.5

9.5

9.5

Buf. L2(KB)

Buf. L1(KB)

Buf. L0(KB)

17.5 Buf. L3(KB)

Buf. L2(KB)

Buf. L1(KB)

Buf. L0(KB)

17.5

17.5

17.5

KB/s

C = 10

40 Time(sec)

40 Time(sec)

Effect of smoothing factor

(K = 2)

(K = 4)40 Time(sec)

40 Time(sec)

TX rate & Quality

TX rate & Quality


Buf. L3(KB)

Buf. L3(KB)

Buf. L3(KB)

Buf. L3(KB)

C = 10

17.5

17.5

17.5

17.5

KB

90 Time(sec)30 60

(K = 4)

90 Time(sec)30 60

Adapting to network load

KB/s

TX rate & Quality


No of Dropped Layers

Buffering efficiency

949596979899

100101

2 3 4 5 8

K(smoothing factor)

% u

sed

bu

ffer

No of drops

0

20

40

60

80

2 3 4 5 8

K (smoothing factor)

#dro

ps

T1

T2


Summary of the QA results

Quality adaptation mechanism can efficiently control the quality

Smoothing factor allows the server to trade short-term improvement with long-term smoothing

Buffer requirement is low Deploying for live but non-interactive

sessions!


Delivered quality is limited to the average bandwidth between the server and client

Solutions: Mirror servers Multimedia proxy

caching

Limitation of the E2E Approach

Server

Client

Internet

ClientClient

TimeL0L1L2L3

L4

Qua

lity(

laye

r)


Outline





Server

Assumptions Proxy can perform:

– End-to-end congestion ctrl– Quality Adaptation

Goals Improve delivered

quality Low-latency VCR-

functions Natural benefits of

caching

Proxy

Internet

Multimedia Proxy Caching

Client Client Client


Challenge

Cached streams have variable quality

Layered organization provides opportunity for adjusting the quality

Time

L0

L1

L2

L3

L4

Qua

lity

(lay

er)

Stored stream

Played back streamPlayed back stream


Issues

Delivery procedure Relaying on a cache miss Pre-fetching on a cache hit

Replacement algorithm Determining popularity Replacement pattern


Cache Miss Scenario

Stream is located at the original server

Playback from the server through the proxy

Proxy intercepts and caches the stream

No benefit in a miss scenario

Server

Internet

Proxy



Cache Hit Scenario

Playback from the proxy cache Lower latency May have better

quality! Available bandwidth

allows: Lower quality playback Higher quality playback

Server

Proxy

Internet



Lower quality playback

Missing pieces of the active layers are pre-fetched on-demand

Required pieces are identified by QA

Results in smoothing

Time

L0

L1

L2

L3

L4

Qua

lity

(no.

act

ive

laye

rs)

Pre-fetched data

Stored stream

Played back stream


Pre-fetch higher layers on-demand

Pre-fetched data is always cached

Must pre-fetch a missing piece before its playback time

Tradeoff Time

L0

L1

L2

L3

L4

Qua

lity

(no.

act

ive

laye

rs)

Pre-fetched data

Stored stream

Played back Stream

Higher quality playback


Replacement Algorithm

Goal: converge the cache state to optimal Average quality of a cached

stream depends on – popularity – average bandwidth between

proxy and recent interested clients

Variation in quality inversely depends on

– popularity

Server

Proxy

Internet



Number of hits during an interval User’s level of interest (including VCR-functions)

Potential value of a layer for quality adaptation Calculate whit on a per-layer basis

Layered encoding guarantees monotonically decrease in popularity of layers

Popularity

whit = PlaybackTime(sec)/StreamLength(sec)


Multi-valued replacement decision for multimedia object

Coarse-grain flushing on a per-layer basis

Fine-grain flushing on a per-segment basis

Fine-grain Coarse-grain

Cached segment

Replacement Pattern

Time

Quality(Layer)


Summary of Multimedia Caching

Exploited characteristics of multimedia objs

Proxy caching mechanism for multimedia streams Pre-fetching Replacement algorithm

Adaptively converges state of the cache to the optimal


Contributions

End-to-end architecture for delivery of quality-adaptive multimedia streams

RAP, a TCP-friendly cong. ctrl mechanism over a wide range of network conditions

Quality adaptation mechanism that adjusts the delivered quality with a desired degree of smoothing

Proxy caching mechanism for multimedia streams to effectively improve the delivered quality of popular streams


Future Directions

End-to-end Congestion Control RAP’s behavior in the presence web-like traffic Emulating timer-driven regime TCP Bi-directional RAP connections, Reverse ns

forward path congestion control Experiments over CAIRN & the Internet Integration of RAP and congestion manager Adopting RAP into class-based QoS Using RAP for multicast congestion control Congestion control over wireless networks


Future Directions(cont’d)

Quality Adaptation Extending to other rate adaptation

mechanisms Multimedia Proxy Caching

Other replacement patterns & popularity functions(e.g. chunk-based)

Traffic Measurement and Characterization Imiprical evaluation of streaming applications


An End-to-end Architecture for Quality-Adaptive Streaming Applications in Best-effort Networks

Reza [email protected]

USC/ISI

http://netweb.usc.edu/reza

April 7, 1999


Thank you

Reza Rejaie

http://netweb.usc.edu/[email protected]


Archive

MediaServer Internet

TCPTraffic

TCPTraffic

Target Environment


Optimal Buffer Allocation

Scenario 1 Scenario 2 Scenario 3

Backoff 2

Optimal buffer state is not uniqueS1 and S2 are extreme cases

S1 requires more buffering layersS2 requires more buffer share per layer

Buffer allocation for S1 can recover from S2 but not vice versa

Date post:	11-Jan-2016
Category:	Documents
Upload:	rock
View:	22 times
Download:	0 times

An End-to-end Architecture for Quality-Adaptive Streaming Applications in Best-effort Networks

Documents