Top Banner
139
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 10.1.1.26.8823

MULTICAST MULTILAYER VIDEOCONFERENCING�

ENHANCEMENT OF A MULTILAYER CODEC AND IMPLEMENTATION

OF THE RECEIVER DRIVEN LAYERED MULTICAST PROTOCOL

A Thesis

by

RALPH AKRAM GHOLMIEH

Submitted to the O�ce of Graduate Studies ofTexas A�M University

in partial ful�llment of the requirements for the degree of

MASTER OF SCIENCE

December ����

Major Subject� Electrical Engineering

Page 2: 10.1.1.26.8823

MULTICAST MULTILAYER VIDEOCONFERENCING�

ENHANCEMENT OF A MULTILAYER CODEC AND IMPLEMENTATION

OF THE RECEIVER DRIVEN LAYERED MULTICAST PROTOCOL

A Thesis

by

RALPH AKRAM GHOLMIEH

Submitted to Texas A�M Universityin partial ful�llment of the requirements

for the degree of

MASTER OF SCIENCE

Approved as to style and content by�

Pierce E CantrellChair of Committee�

Jerry D GibsonMember�

Don R HalversonMember�

Udo W PoochMember�

Chanan SinghHead of Department�

December ����

Major Subject� Electrical Engineering

Page 3: 10.1.1.26.8823

iii

ABSTRACT

Multicast Multilayer Videoconferencing�

Enhancement of a Multilayer Codec and Implementation

of the Receiver Driven Layered Multicast Protocol December �����

Ralph Akram Gholmieh� BS� Saint Joseph University at Beirut

Chair of Advisory Committee� Dr Pierce E Cantrell

Videoconferencing is an important topic on the current Internet The hetero

geneity of the network� its access to all approach and the varying amount of available

bandwidth present many challenges to researchers

Most of the available videoconferencing implementations send video and audio

in a monolithic stream with an adaptive rate In one to many sessions� the available

end to end bandwidth between the source and a receiver might sharply di�er from one

end user to another It is clear that one rate cannot satisfy all the online users because

that would force the source to use a least common denominator strategy Earlier

work of graduate students at the TAMU Multimedia and Networking Laboratory has

focused on multi layered encoding The video is �multiplexed� on several streams

Receivers with more bandwidth can request more streams for a better picture quality

In this research� CafeMocha the videoconferencing tool developed by Sazzad and

Brown at Texas A�M� is enhanced from a two layer codec to a six layer codec Layer

control methods are then tested using the improved codec A simpli�ed version of

the Receiver driven Layered Multicast protocol RLM� proposed by McCanne at UC

Berkeley� is implemented and tested Later� RLM itself is implemented� and tested

in the one to one case A new metric is de�ned whereby each layer control scheme

subscription path� under various rate limits� is compared to a de�ned �ideal� layer

Page 4: 10.1.1.26.8823

iv

subscription sample path We de�ned performance as the ratio of the cumulative

bandwidth delivered in the actual case to the cumulative bandwidth delivered in

the �ideal� case RLM performance values of ���� were recorded when the overall

received bit rate was nearly constant The performance was still good at ����

when the ideal highest subscription layer was bursty RLM was found to be a good

control mechanism for moderately bursty layered streams Propositions for possible

improvements are suggested in the conclusion

Page 5: 10.1.1.26.8823

v

To my parents Issaaf and Badiaa

Page 6: 10.1.1.26.8823

vi

ACKNOWLEDGMENTS

I would like to take this opportunity to thank all the people who made this

research possible First and foremost� my thanks go to my advisor Dr Pierce Cantrell�

working under his guidance has been a pleasant and rewarding experience My thanks

also go to the members of my committee� Dr Jerry Gibson� Dr Udo Pooch and Dr

Don Halverson

This research has built upon and is heavily indebted to the previous research of

current and former members of the TAMU Networking and Multimedia Laboratory

In particular� I would like to thank the original �CafeMocha team� formed of Tom

Brown� Shari� Sazzad and Charles Shroeder I also would like to thank my colleague

Sanku Jo for his help in developing and testing CafeMocha

My stay at A�M would not have been the same without my friends� Deanna�

Aashit� Raul� Scott� and Franck� thank you for the great times we had together

To my parents Issaaf and Badiaa� your sacri�ces� love and guidance will forever

leave me in your debt This degree is more your achievement than it is mine

To my brothers� Aziz� and Ghassan The three musketeers will always follow

their motto� �All for one� and one for all�

Page 7: 10.1.1.26.8823

vii

TABLE OF CONTENTS

CHAPTER Page

I INTRODUCTION � � � � � � � � � � � � � � � � � � � � � � � � � � �

A Recent Developments �

B Layered Coding �

C Previous Related Research at TAMU �

D Thesis Outline �

II OVERVIEW OF RELEVANT PROTOCOLS � � � � � � � � � � � ��

A Real Time Transport Protocol RTP�RTCP� ��

� Real Time Transport Protocol RTP� ��

� Real time Control Protocol RTCP� ��

a Sender Report Block ��

b Receiver Report Block ��

c Goodbye RTCP Packets BYE� ��

d Source Description RTCP Packets SDES� ��

e Application De�ned RTCP Packets APP� ��

B Pruning in Multicast Distribution ��

� DVMRP Routing Protocol ��

� Pruning ��

III CAFEMOCHA � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

A The Encoding Mechanism ��

� Base Layer ��

� Enhancement Layer ��

� Encoder Performance ��

a Base Layer ��

b Pyramidal Layer ��

� Generalizing Assumption ��

B Split of the Base Layer ��

� Threshold Separation ��

� Use of a Bandwidth Limit on the Base Layer ��

C Color Enhancement ��

� YUV��� like Color Scheme ��

� YUV��� like Color Scheme ��

Page 8: 10.1.1.26.8823

viii

CHAPTER Page

D Correlation Between Y band Layers and their Corre

sponding Color Layers ��

E Processing of Incoming Packets at the Decoder ��

F The PARC Algorithm ��

G Stabilization of the Total Output Rate Using PARC ��

IV CONTROL SCHEMES FOR THE LAYERS � � � � � � � � � � � ��

A Overview ��

B RLM ��

� Description ��

� Protocol Details ��

C Basic One to One Control Scheme ��

D Metrics ��

V RESULTS � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

A Testbed ��

B Layer Order ��

C Short Term Packet Loss Estimator ��

D Practical Calculation of the Metrics ��

E Basic One to One Scheme Results ��

� Graphical Data Analysis ��

� Performance Metrics ��

F RLM Results ��

� Graphical Data Analysis ��

� Performance Metrics ���

G Qualitative Description of the Perceived Image ���

� General ���

� Real Time Layer Add�Drop ���

VI CONCLUSION AND FUTURE WORK � � � � � � � � � � � � � � ���

REFERENCES � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

VITA � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

Page 9: 10.1.1.26.8823

ix

LIST OF TABLES

TABLE Page

I Average Uncompressed and Compressed Rates for the �Miss Amer

ica� Sequence Using Various Distance Threshold Values ��� � � � � � � ��

II Average Uncompressed and Compressed Rates for the �Salesman�

Sequence Using Various Distance Threshold Values ��� � � � � � � � � ��

III Average Temporal Bandwidth use of the �When Harry Met Sally�

Test Sequence for Di�erent Quality values at � frames�second � � � � ��

IV Modi�ed YUV ����� Encoding � � � � � � � � � � � � � � � � � � � � � � ��

V Possible Layer Combinations in Scheme � � � � � � � � � � � � � � � � ��

VI Modi�ed YUV ����� Encoding � � � � � � � � � � � � � � � � � � � � � � ��

VII Possible Layer Combinations in Scheme � � � � � � � � � � � � � � � � ��

VIII Average Temporal Bandwidth Rates of the Test Sequence for the

Base Layers at � frames�second Using Color Scheme � � � � � � � � � ��

IX Average Temporal Bandwidth Rates of the Test Sequence for Dif

ferent Quality Values at � frames�second Using Color Scheme �

for the Large Layer � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

X De�nition of Variables Showing in Fig �� � � � � � � � � � � � � � � � ��

XI RLM Protocol Parameters � � � � � � � � � � � � � � � � � � � � � � � � ��

XII RLM Protocol Variables and Update Equations � � � � � � � � � � � � ��

XIII Variables and their De�nitions � � � � � � � � � � � � � � � � � � � � � ��

XIV Values Chosen for the Parameters Controlling the Basic Control Scheme ��

XV Performance of the Basic Control Scheme � � � � � � � � � � � � � � � ��

Page 10: 10.1.1.26.8823

x

TABLE Page

XVI Values Chosen for the Parameters Controlling RLM � � � � � � � � � � ��

XVII Performance of RLM Protocol � � � � � � � � � � � � � � � � � � � � � � ���

Page 11: 10.1.1.26.8823

xi

LIST OF FIGURES

FIGURE Page

� Example of a Heterogeneous Set of Connections � � � � � � � � � � � � �

� Layered Distribution of a Hierarchically Encoded Stream � � � � � � � �

� RTP Data Header � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� RTCP Common Header � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Sender Report RTCP Block � � � � � � � � � � � � � � � � � � � � � � � ��

� Receiver Report RTCP Block � � � � � � � � � � � � � � � � � � � � � � ��

� Canonical Name � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Application Speci�c RTCP Block � � � � � � � � � � � � � � � � � � � � ��

� Sazzad�s Pyramidal Encoding Scheme � � � � � � � � � � � � � � � � � ��

�� Frame Capture� Compression� and Packetization for Pyramidal

Coder ��� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Test Sequence� Pyramidal Layer Coded at Quality � � � � � � � � � � ��

�� Average Rate per Quality Value for the �When Harry Met Sally�

Test Sequence at � frames�second � � � � � � � � � � � � � � � � � � � ��

�� Flow Chart for Splitting Scheme Number � � � � � � � � � � � � � � � ��

�� Algorithm for Adapting the Value of the Separation Threshold in

Splitting Scheme Number � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Test Sequence Coded Using Scheme Number � � � � � � � � � � � � � � ��

�� Flow Chart for Splitting Scheme Number � � � � � � � � � � � � � � � ��

�� Example of Base Block Distribution over Two Consecutive Frames

in Bandwidth Limit Scheme � � � � � � � � � � � � � � � � � � � � � � � ��

Page 12: 10.1.1.26.8823

xii

FIGURE Page

�� Test Sequence Coded Using Scheme Number � � � � � � � � � � � � � � ��

�� Color Scheme � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Upscaling Issues when Using the Same Pyramidal Coding Routine � � ��

�� Byte Order for The Pyramidal Layer Color Data � � � � � � � � � � � ��

�� Color Scheme � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Ratio of the Rate on the Small UV band Layer over the Rate on

the Small Y band Layer during the �When Harry Met Sally� Test

Sequence � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Ratio of the Rate on the Medium UV band Layer over the Rate on

the Medium Y band Layer during the �When Harry Met Sally�

Test Sequence � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Decoding of the Incoming Packets � � � � � � � � � � � � � � � � � � � � ��

�� PARC Algorithm Used for Congestion Avoidance � � � � � � � � � � � ��

�� Total Bandwidth Used by the Y band Layers Small�Medium�Large�

Controlled by the Enhanced Use of the PARC Algorithm under a

Total Rate Limit of ���Kbps � � � � � � � � � � � � � � � � � � � � � � ��

�� Equations for the Enhanced PARC Control Process � � � � � � � � � � ��

�� Total Bandwidth Used by all Base Layers Y band Small�Medium�

UV band Small � Medium� and the Large Y band Layer Con

trolled by the Enhanced Use of the PARC Algorithm under a

Total Rate Limit of ���Kbps � � � � � � � � � � � � � � � � � � � � � � ��

�� Total Bandwidth Used by all Base Frame Layers Y band Small�Medium�

UV band Small � Medium� � � � � � � � � � � � � � � � � � � � � � � � ��

�� RLM Receiver State Diagram ��� � � � � � � � � � � � � � � � � � � � � ��

�� Algorithm for the Basic One to One Layer Control Scheme � � � � � � ��

�� Testbed Topology � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

Page 13: 10.1.1.26.8823

xiii

FIGURE Page

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Actual Receiver Subscription under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbps � � � � � � � � � � � � � � ��

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Observed Bandwidth Received under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbps � � � � � � � � � � � � � � ��

�� Actual Packet Losses Recorded at the Receiver under the One

To One Basic Control Scheme Router Rate Limit of ���kbps � � � � ��

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Actual Receiver Subscription under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbps � � � � � � � � � � � � � � ��

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Observed Bandwidth Received under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbps � � � � � � � � � � � � � � ��

�� Actual Packet Losses Recorded at the Receiver under the One

To One Basic Control Scheme Router Rate Limit of ���kbps � � � � ��

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Actual Receiver Subscription under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbp � � � � � � � � � � � � � � ��

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Observed Bandwidth Received under the One To One Basic Con

trol Scheme Router Rate Limit of ���kbps � � � � � � � � � � � � � � ��

Page 14: 10.1.1.26.8823

xiv

FIGURE Page

�� Actual Packet Losses Recorded at the Receiver under the One

To One Basic Control Scheme Router Rate Limit of ���kbps � � � � ��

�� Ideal Subscription Levels under a Router Rate Limit of ��kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � � ��

�� Actual Receiver Subscription under the One To One Basic Con

trol Scheme Router Rate Limit of ��kbps � � � � � � � � � � � � � � � ��

�� Ideal Bandwidth Distribution under a Router Rate Limit of ��kbps

Testing the One to One Basic Control Scheme � � � � � � � � � � � � ��

�� Observed Bandwidth Received under the One To One Basic Con

trol Scheme Router Rate Limit of ��kbps � � � � � � � � � � � � � � � ��

�� Actual Packet Losses Recorded at the Receiver under the One

To One Basic Control Scheme Router Rate Limit of ��kbps � � � � ��

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Actual Receiver Subscription under RLM Router Rate Limit of

���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Observed Bandwidth Received under RLM Router Rate Limit

of ���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Actual Packet Losses Recorded at the Receiver under RLM

Router Rate Limit of ���kbps � � � � � � � � � � � � � � � � � � � � � � ��

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Receiver Subscription under RLM Router Rate Limit of

���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

Page 15: 10.1.1.26.8823

xv

FIGURE Page

�� Observed Bandwidth Received under RLM Router Rate Limit

of ���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Packet Losses Recorded at the Receiver under RLM

Router Rate Limit of ���kbps � � � � � � � � � � � � � � � � � � � � � � ���

�� Ideal Subscription Levels under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Receiver Subscription under RLM Router Rate Limit of

���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Observed Bandwidth Received under RLM Router Rate Limit

of ���kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Packet Losses Recorded at the Receiver under RLM

Router Rate Limit of ���kbps � � � � � � � � � � � � � � � � � � � � � � ���

�� Ideal Subscription Levels under a Router Rate Limit of ��kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Receiver Subscription under RLM Router Rate Limit of

��kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Ideal Bandwidth Distribution under a Router Rate Limit of ��kbps

Testing RLM � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Observed Bandwidth Received under RLM Router Rate Limit

of ��kbps � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���

�� Actual Packet Losses Recorded at the Receiver under RLM

Router Rate Limit of ��kbps � � � � � � � � � � � � � � � � � � � � � � ���

�� Small Y band Layer� ���x��� greyscale� Level � � � � � � � � � � � � � ���

�� Small and Medium Y band Layers� ���x��� greyscale � � � � � � � � � ���

�� Small� Medium and Large Y band Layers� ���x��� greyscale � � � � � ���

Page 16: 10.1.1.26.8823

CHAPTER I

INTRODUCTION

This last year has seen a multitude of new videoconferencing tools released for the

Internet Speci�cally� the users of the Multicast Backbone MBONE� ��� can already

communicate and broadcast real time multimedia sessions� albeit at low rates of less

than ���Kbps On the other hand� regular unicast users can already download en

coded multimedia streams consisting of video and audio at very low rates Vxtreme�s

Web Theater provides a reasonable video and audio quality at rates as low as ��Kbps

���

During Spring ����� a networking course at Stanford was put on line and dis

tributed via Vxtreme�s Web Theater As better applications get developed� distance

learning via the Internet will no doubt become widely used Undoubtfully� live courses

will be available in the near future on the Internet

Companies are actively researching video on demand applications as the next

possible �killer application� of the World Wide Web Most of these applications try

to reach the largest possible end user population Their high bandwidth requirement

poses interesting challenges to researchers� What is the best way to distribute the

multimedia streams� How can a source serve a multitude of end users with varying

connection bandwidth to each receiver� How can a source transmit to a multitude

of receivers and at the same time make good use of the available bandwidth� This

thesis addresses these problems in the case of real time� one to many multicast video

conferencing sessions

The journal model is IEEE Transactions on Automatic Control�

Page 17: 10.1.1.26.8823

A Recent Developments

Several important recent developments have made videoconferencing possible on the

current Internet�

� A multicast backbone has been deployed over the whole Internet Typically�

system managers have allocated around ��� Kbps to multicast streams on

their incoming and outgoing links Named the Internet Multicast Backbone

or MBONE� it is an interconnected set of subnetworks and routers that sup

port the delivery of IP multicast tra�c Since ����� the MBONE has grown

from �� subnets in four di�erent countries to more than ���� subnets in over

�� countries ����

� Several protocols targeting Real Time Communication have been de�ned in

Internet drafts The most important are� RTP ����� RTCP ����� and RSVP ����

RTP is the Real time Transport Protocol� and RTCP is the Real time Transport

Control Protocol which is used for the control of RTP streams RTP is a

transport protocol usually placed above UDP in the protocol stack Unlike

TCP� RTP does not request a packet�s retransmission in the case of delivery

errors This research uses RTP and RTCP as the transport layer for the testing

videoconferencing tool RSVP is the Resource Reservation Protocol� destined

to manage bandwidth reservation demands� it is still rarely used

� Videoconferencing tools are now widely available Most of these use a sin

gle multicast stream to send data to all the users The most important are�

CUSeeMe ����� nv ����� ivs ����� vat ���� and vic ����

� Workstations and desktop computers are becoming increasingly powerful The

new computing power is fast enough to handle real time encoders�decoders in

Page 18: 10.1.1.26.8823

software

B Layered Coding

The monolithic transmission mentioned earlier adapts badly to the heterogeneous

nature of the Internet In a one to many conference� if the source sends more packets

than a link or a router bu�er can handle� random packets are dropped The receiver on

the other side of the congested link would experience packet loss and a deterioration

of the perceived signal Because redundancy is eliminated from multimedia streams�

a loss rate of a few percent can result in an unacceptable loss of quality to the

receiver ���� If source based rate control is the only control scheme used� the chosen

rate would have to adjust to the smallest bandwidth link capacity That is clearly

unacceptable� a receiver on the same high bandwidth subnet as the source should

not be limited to the bandwidth limitations of a receiver using an ISDN link to get

to the Internet An instantaneous large increase in the available bandwidth for each

user would solve the problem� but that seems unlikely to happen User demand for

bandwidth continues to increase as more and more users access the Internet� and as

applications continue to consume more and more bandwidth

Consider for instance the network example in Fig � If source based congestion

control is used in conjunction with a unique resolution coder� the source would have

to transmit at a rate lower than ��Kbps to satisfy receiver number one Receiver R�

receives a ���Kbps stream even though its link capacity to the source is ��Mbps

Shacham et al ���� propose the separation of high and low bandwidth do

mains by �gateways� that would transform a high bandwidth representation of a

multimedia stream into a low bandwidth representation The conversion would have

to be done �on the �y� because of bu�er concerns and the nature of real time streams

Page 19: 10.1.1.26.8823

128KbpsISDN Line

connection28.8 Kbps modem

Source

R1 R2

Router

Router

R3

T1 Link 1.45 Mbps

10 Mbps Ethernet

10 Mbps Ethernet

Fig � Example of a Heterogeneous Set of Connections

Amir et al ���� successfully implemented a video gateway that converts a �Mbps Mo

tion JPEG video stream into a ���Kbps H��� stream Seminars broadcast at �Mbps

on the Bay Area Network an ATM network� were retransmitted in the H��� format

to the rest of the MBONE users

Cheung et al ���� implement a simulcast scheme whereby several di�erent ver

sions of the same multimedia stream are simultaneously multicast Each stream

provides a di�erent session quality level The set of receivers subscribed to a particu

lar stream can also �agree� to change its quality�bandwidth parameters within that

stream�s minimum and maximum bandwidth The Destination Set Group DSG� pro

tocol that they developed is used by receivers to adapt to the available bandwidth

The intra stream part of the protocol is used by receivers listening to the same stream

to adjust the data rate of the stream within its prescribed limits An inter stream

protocol is used by users to decide changes to a higher or lower quality stream as

Page 20: 10.1.1.26.8823

their needs or bandwidth availability change

Deering ���� on the other hand proposes a realization of a multi layered scheme

where a source stripes the progressive layers of a hierarchically represented signal

across multiple multicast groups Receivers can then adapt to network heterogeneity

by controlling their reception bandwidth through IP Multicast group membership

In layered coding� a data stream is divided into several sub streams Si � � i �

n� where the reception of the streams between S� and Sm m � n� gives an increasing

rendering quality as m increases For example� a video stream can be enhanced by

an increase in its size width and height� or its depth number of bits per pixel� To

maintain e�ciency� the streams should not be redundant

All receivers that wish to receive the broadcast must subscribe to at least the

�rst layer this is typically an RTP stream� In addition� the receiver subscribes to

a control stream that allows it to make more intelligent decisions this is typically

an RTCP stream� Then� depending on the packet loss status� the receiver can join

or drop layers Consecutive multicast addresses are allocated to the multicast layers�

and to the control streams For layer n� the corresponding address is A n� the data

port is P �n� and the control port is P �n � ����� where A and P are the multicast

group address and the port of the base data layer

To emphasize this point� let us go back to the network example in Fig � Suppose

that a three resolution video encoder is in use Assume layer one has a bandwidth

requirement of around �� Kbps and delivers a minimum picture quality� and that

the addition of layer two increases the picture�s quality for a bandwidth increase

of ��Kbps Finally� assume that layer � increases the picture resolution for an ad

ditional increase of ���Kbps Fig � shows the ideal multicast distribution of the

layers Receiver R� receives the maximum video quality constructed by decoding

layers one� two and three with a total bandwidth requirement of ���Kbps Receiver

Page 21: 10.1.1.26.8823

R� receives a moderate video quality by subscribing to both layers one and two for

a total bandwidth of ���Kbps Receiver three can still follow the videoconferencing

session through a stream appropriate to its low bandwidth capability at ��Kbps

connection28.8 Kbps modem

128KbpsISDN Line

Source

R1 R2

Router

Router

R3

T1 Link 1.45 Mbps10 Mbps Ethernet

10 Mbps Ethernet

Layer 1 (20 Kbps)Layer 2 (80 Kbps)Layer 3 (400 Kbps)

Fig � Layered Distribution of a Hierarchically Encoded Stream

Layered coding transmission is only justi�ed when multicast delivery trees are

pruned Pruning is the process by which multicast stream distribution trees are slowly

�shrunk� to span only nodes that have subscribed receivers This means that a mul

ticast distribution tree for a speci�c multicast layer only spans the layer�s subscribed

users The routing daemon �mrouted� versions �� and above implements multicast

pruning Implementation of the pruning of multicast delivery trees is detailed in the

IETF Internet Draft for the Distance Vector Multicast Routing Protocol ����

In its �rst version� IPv� provided for a � bit priority �eld ���� Use of a priority

scheme can make multi layered broadcasts more resilient to packet loss as shown by

Brown ��� In contrast� McCanne et al ��� argue that the use of priority schemes

Page 22: 10.1.1.26.8823

might encourage badly behaved users to keep the network in a state of congestion by

enabling them to obtain their optimal quality level while congesting a link Note that

the optimum subscription level is the same in both cases At the last meeting of the

IPng working group IPv� is also referred to as IP next generation�� Steve Deering

described and supported a proposal to change the meaning of the priority �eld The

low order bit would mean that the packet is a part of �interactive� tra�c whereby

delay is more important than throughput ���� The signi�cance of the other bits were

to be de�ned later

McCanne et al ��� propose the Receiver driven Layered Multicast RLM� Pro

tocol� a non reservation active receiver experiment scheme whereby additional layers

are periodically added in the absence of signi�cant packet loss Since the optimal op

erating point will normally be just below the congestion point of the link maximum

link utilization�� join experiments might have a negative impact on the overall perfor

mance if they are repeated too often An exponentially increasing delay is imposed

between failed experiments to handle this problem In the case of high packet losses

that do not correspond to join experiments� the receiver drops layers periodically until

network congestion ceases

McCanne et al ��� stress the fact that receivers should communicate and an

nounce their join experiments Otherwise� concurrent join experiments a�ecting the

same link might mislead the receiver adding the lower layer The protocol�s e�ciency

would be negatively a�ected by receivers backing o� erroneously

RLM is not compatible with router packet priority forwarding schemes since only

the experimental layer will su�er signi�cant packet loss if the subnet is fully loaded

prior to the experiment When congestion occurs� other receivers will not perceive

packet loss at lower layers and thus will be unaware of the negative experimental

outcome

Page 23: 10.1.1.26.8823

C Previous Related Research at TAMU

Researchers in the TAMU Multimedia and Networking Lab have worked on lay

ered data transmission since ���� Their main research tool is CafeMocha ��� ���� a

videoconferencing tool CafeMocha is a one to many implementation of a pyramidal

encoder which divides video into two separate streams of information and distributes

the streams using multicast channels The base resolution video is coded using the

CU SeeMe compression algorithm ���� and sent on one multicast address The large

resolution video uses two multicast addresses� the medium channel plus an enhance

ment channel ��� Thus� a user receiving layer one would require less bandwidth for

a lower picture quality when compared to a user receiving both layers one and two

Brown ��� developed a quick recovery scheme in conjunction with source based

congestion avoidance techniques In his research� the source adjusts a quantization

parameter for the enhancement layer based upon RTCP packet loss reports If low

packet loss is reported� the source slowly increases quality On the receiver side�

the enhancement layer is dropped immediately with the onset of congestion When

receivers report that the enhancement layer was dropped due to congestion� the source

decreases video quality� reducing the amount of data transmitted Normally� the

receiver waits up to several minutes before rejoining the enhancement layer in order

to prevent recurrence of congestion If the receiver notices that the source has reduced

video quality however� it may rejoin the enhancement layer in a matter of seconds

Quality information is communicated to the receivers in RTCP sender reports

Schroeder ��� developed a rate control algorithm for the enhancement layer The

Predictive�Adaptive Rate Control PARC� algorithm he developed is given a target

rate for the enhancement layer This target rate is exponentially reduced in the

presence of a consensus receiver high packet loss and arithmetically increased in the

Page 24: 10.1.1.26.8823

opposite case

D Thesis Outline

To be able to follow this research potential readers should be familiar with the RTP

protocol� and multicasting through DVMRP Chapter II gives a basic overview of this

indispensable networking infrastructure

Chapter III describes the changes made to the CafeMocha encoder developed by

Sazzad ��� The base layer is split in two� and color information is added in three new

layers

In Chapter IV� layer control mechanisms are explained and presented Chap

ter V presents the results of the simulations done using the layer control mechanisms

described in Chapter IV

A �nal chapter concludes this thesis with a summary of what was learned and

suggestions for future work

Page 25: 10.1.1.26.8823

��

CHAPTER II

OVERVIEW OF RELEVANT PROTOCOLS

The object of this chapter is to introduce the reader to the control information avail

able through the use of the Real Time Transport Protocol RTP�RTCP� and to the

Distance Vector Multicast Routing Protocol DVMRP� Information about these top

ics is widely available� a particularly relevant web site can be found at ����

A Real Time Transport Protocol RTP�RTCP�

� Real Time Transport Protocol RTP�

RTP version �� is a real time transport protocol that provides end to end delivery

services to support applications transmitting real time data over unicast and multicast

network services RTP is de�ned in RFC ���� titled �RTP� A Transport Protocol for

Real Time Applications�� A pro�le for carrying audio and video over RTP is de�ned

in RFC ���� titled �RTP Pro�le for Audio and Video Conferences with Minimal

Control� ���� RTP provides payload type identi�cation� sequence numbering� and

time stamping Control of real time RTP sessions is carried out through the RTCP

control protocolsee next section� RTP provides end to end delivery services� but

it does not provide all of the functionality that is typically provided by a transport

protocol RTP typically runs on top of UDP to utilize its multiplexing and checksum

services Other transport protocols besides UDP can carry RTP as well

An RTP packet as de�ned in RFC���� consists of a common header� a list of

contributing source identi�ers� a potential pro�le speci�c header extension� the actual

payload� and some padding octets if required for encryption or by the underlying

protocol

Page 26: 10.1.1.26.8823

��

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� V�� P X CC M PT sequence number SN ����������������������������������������������������������������� timestamp TS ����������������������������������������������������������������� synchronization source �SSRC� identifier ����������������������������������������������������������������� contributing source �CSRC� identifiers ���� �����������������������������������������������������������������

Fig � RTP Data Header

Fig � shows an RTP data header Field V� is a � bit version identi�er that is

currently set to � Padding bit P� indicates whether the packet carries one or more

padding octets at the end which are not part of the payload The extension bit X�

indicates whether the �xed header is followed by a header extension The � bit CSRC

count CC� contains the number of contributing source CSRC identi�ers that follow

the SSRC identi�er The interpretation of the marker bit M� is pro�le dependent It

can be used to mark signi�cant events such as frame boundaries For video� it usually

identi�es the last packet for a video frame which causes the receiver to render the

image CafeMocha uses the marker bit to identify the last packet on each layer Once

it receives the last packet on its two layers� the frame is rendered ��� The sequence

number NS� and timestamp TS� provide the timing information necessary to syn

chronize and display audio and video data and to determine whether packets have

been lost or have arrived out of order In addition� the header speci�es the payload

type PT�� thus allowing multiple data and compression types RTP is tailored to a

speci�c application via auxiliary pro�le and payload format speci�cations

Each media stream is assigned a �� bit session source identi�er SSRC� This

�� bit value should be unique accross a video conferencing session

Page 27: 10.1.1.26.8823

��

An RTP session is de�ned by a pair of destination transport addresses one

multicast group address plus a pair of ports for RTP and RTCP� In a multimedia

session� information can be fragmented on di�erent RTP sessions each having its own

RTCP information reporting channel This allows receivers to retrieve the particular

media data that they want for example� audio without video or vice versa�

RTP does not provide any mechanisms to ensure timely delivery or provide

quality of service guarantees� nor does it assume that the underlying network is re

liable Auxiliary control mechanisms can be used if resource reservation or reliable

service are required

� Real time Control Protocol RTCP�

RTCP is the control protocol that works in conjunction with RTP RTCP control

packets are periodically transmitted by each participant in an RTP session to all

other participants Feedback of information to the application can be used to control

performance and for diagnostic purposes

As de�ned in RFC ���� ����� RTCP performs the following four functions

� Provide information to applications�

IP multicasting experiments have shown that receiver feedback is critical for

analyzing distribution faults RTCP�s primary function is to report the quality

of data distribution Each RTCP packet contains sender and�or receiver reports

that report statistics useful to the application These statistics include number

of packets sent� number of packets lost� interarrival jitter� etc This reception

quality feedback will be useful for the sender� receivers� and third party moni

tors For example� CafeMocha uses receiver reports to modify the target rate

on its large layer ���

Page 28: 10.1.1.26.8823

��

� Identify RTP sources�

RTCP carries a transport level identi�er for an RTP source called the canonical

name CNAME� The CNAME is used to keep track of the participants in an

RTP session Receivers use the CNAME to associate multiple data streams

from a given participant in a set of related RTP sessions� eg� to synchronize

audio and video

� Control RTCP transmission interval�

RTCP control tra�c should not exceed � percent of the total bandwidth broad

cast by active sources on the corresponding RTP session This can be enforced

by keeping track of the number of participants a session subscriber receives

RTCP control packets from all the participants and can thus calculate the exact

number of subscribed users� The receiver can then estimate the time interval

separating consecutive RTCP compound report packets In CafeMocha�s case�

the limited number of receivers allowed us to �x the RTCP report generation

time interval to � seconds ���

� Convey minimal information�

RTCP packets can be a convenient method of exchanging a limited amount

of information For example� it can be used to exchange personal names in

a loosely controlled session where participants informally enter and leave the

session

The part common to all RTCP packets is shown in Fig �

Each RTCP packet carries in its header one of the following packet type PT�

codes�

� ��� ! SR Sender Report packet

� ��� ! RR Receiver Report packet

Page 29: 10.1.1.26.8823

��

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� V�� P RC PT�SR���� length L ����������������������������������������������������������������� SSRC of sender �����������������������������������������������������������������

Fig � RTCP Common Header

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� V�� P RC PT�SR���� length L ����������������������������������������������������������������� SSRC of sender ����������������������������������������������������������������� NTP timestamp� most significant word NTS ����������������������������������������������������������������� NTP timestamp� least significant word ����������������������������������������������������������������� RTP timestamp RTS ����������������������������������������������������������������� sender�s packet count SPC ����������������������������������������������������������������� sender�s octet count SOC �����������������������������������������������������������������

Fig � Sender Report RTCP Block

� ��� ! SDES Source Description packet

� ��� ! BYE Goodbye packet

� ��� ! APP Application de�ned packet

a Sender Report Block

A Sender Report shown in Fig �� message consists of the header� the sender informa

tion block� a variable number of receiver report blocks� and potentially pro�le speci�c

extensions The � bit RC �eld speci�es the number of reception report blocks con

Page 30: 10.1.1.26.8823

��

tained in this packet The receiver can be �listening� to several multimedia streams

The �� bit NTP timestamp NTS� indicates the point of time measured in wall

clock time when this report was sent In combination with timestamps returned in

reception reports from the respective receivers� it can be used to estimate the round

trip propagation time to and from the receivers

The �� bit RTP timestamp resembles the same time as the NTP timestamp

above�� but is measured in the same units and with the same random o�set as the

RTP timestamps in data packets This correspondence may be used for intra and

inter media synchronization for sources whose NTP timestamps are synchronized�

and may be used by media independent receivers to estimate the nominal RTP clock

frequency

The �� bit sender�s packet count SPC� totals up the number of RTP data packets

transmitted by the sender since joining the RTP session This �eld can be used to

estimate the average data packet rate

The �� bit total number of payload octets SOC� not including the header or

any padding� transmitted in RTP data packets by the sender since starting up trans

mission This �eld can be used to estimate the average payload data rate

b Receiver Report Block

Fig � shows a receiver report block�

The SSRC identi�es the sender whose reception is reported in this block The

sender of the receiver report estimates the fraction F� of the RTP data packets from

source SSRC n that was lost since the previous SR or RR packet

The sender of a receiver report block also tries to estimate the total number of

RTP data packets from source SSRC n that have been lost since the beginning of

reception in �eld C Packets that arrive late are not counted as lost� and the loss may

Page 31: 10.1.1.26.8823

��

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� V�� P RC PT�RR���� length L ����������������������������������������������������������������� SSRC of sender ����������������������������������������������������������������� SSRC�� �SSRC of first source� ����������������������������������������������������������������� fraction lost F cumulative number of packets lost C ���������������������������������������������������������������� extended highest sequence number received EHSN ����������������������������������������������������������������� inter�arrival jitter J ����������������������������������������������������������������� last SR LSR ����������������������������������������������������������������� delay since last SR DLSR ����������������������������������������������������������������� SSRC�� �SSRC of second source� � ��� ������������������������������������������������������������������

Fig � Receiver Report RTCP Block

Page 32: 10.1.1.26.8823

��

be negative if there are duplicates

The low �� bits of the extended highest sequence number contain the highest

sequence number received in an RTP data packet from source SSRC n� and the most

signi�cant �� bits extend that sequence number with the corresponding count of

sequence number cycles

J is an estimate of the statistical variance of the RTP data packet inter arrival

time� measured in timestamp units and expressed as an unsigned integer

c Goodbye RTCP Packets BYE�

A participant sends a BYE packet to indicate that one or more sources are no longer

active� optionally giving a reason for leaving

d Source Description RTCP Packets SDES�

An SDES packet consists of an SDES header and a variable number of chunks for the

described sources Each chunk in turn consists of an SSRC�CSRC identi�er and a

collection of SDES items SDES items themselves consist of an SDES item type code

� bits�� a length �eld � bits� and as many text octets as the length �eld indicates

The di�erent SDES items are encoded according to a type length value scheme

Currently� CNAME� NAME� EMAIL� PHONE� LOC� TOOL� NOTE� and PRIV

items are de�ned in RFC���� The CNAME item is mandatory in every SDES

packet� which in turn is a mandatory part of every compound RTCP packet Like

the SSRC identi�er� a CNAME must di�er from the CNAMEs of every other session

participants But instead of choosing the CNAME identi�er randomly� the CNAME

should allow a person or a program to locate the source by means of its contents

usually the complete email of the user�

Page 33: 10.1.1.26.8823

��

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� CNAME�� length user and domain name ��������������������������������������������������������������������

Fig � Canonical Name

� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �

����������������������������������������������������������������� V�� P ST PT�APP���� length L ����������������������������������������������������������������� SSRC ����������������������������������������������������������������� name �ASCII� N ����������������������������������������������������������������� application�dependent data A ��������������������������������������������������������������������

Fig � Application Speci�c RTCP Block

e Application De�ned RTCP Packets APP�

The APP packet is intended for experimental use at developing new applications and

features Once a new APP RTCP packet type is tested and found useful� it should

be registered with the Internet Assigned Numbers Authority IANA� as an original

packet type

The � bit subtype ST� �eld allows a set of APP packets to be de�ned under

one unique name or provides any application dependent data A � octet name N�

chosen by the person de�ning the set of APP packets to be unique with respect to

other APP packets this application might receive Application dependent data may

or may not appear in an APP packet

Page 34: 10.1.1.26.8823

��

B Pruning in Multicast Distribution

� DVMRP Routing Protocol

The Distance Vector Multicast Routing Protocol DVMRP� is the MBONE�s original

IP Multicast routing protocol It was designed to run over both multicast capable

LANs like Ethernet� as well as through non multicast capable routers In the latter

case� the IP Multicast packets are �tunneled� through non multicast capable routers

as unicast packets This replicates the packets and has an e�ect on performance

but has provided a temporary solution for IP Multicast routing on the Internet while

router vendors decide to support native IP Multicast routing Most of the new routers

are multicast capable� however� there is still a limited deployment of multicast on In

tranets since the Internet backbone does not perform multicast routing yet DVMRP

still uses a single routing table to make forwarding decisions for multicast octets

Thus� it does not consider properties of individual sessions� such as clustering of

receivers� in computing the distribution tree

� Pruning

Every multicast packet has a time to live �eld that indicates the number of hops that

the packet can go through before it is discarded In the absence of pruning� a multicast

packet will also reach unsubscribed receivers located at less than n hops away from

the sender� n being the time to live of the packet Pruning is the �trimming� of

multicast distribution trees to span only subnets that have users subscribed to a

multicast address Initially� the distribution tree spans all the users located at less

than n hops away from the source Multicast routers who have no subscribed users

send a Non Membership Report up the distribution tree to their �parent� router This

process is constantly repeated until the multicast distribution tree of each multicast

Page 35: 10.1.1.26.8823

��

stream spans exactly the subnets where receivers are located

Page 36: 10.1.1.26.8823

��

CHAPTER III

CAFEMOCHA

As mentioned earlier� CafeMocha is the hierarchical videoconferencing tool developed

by Sazzad� Brown and Shroeder at TAMU ��� ��� The encoder encodes frames at two

di�erent resolutions The base layer is encoded using the codec developed by Tim

Dorcey for the popular CUSeeMe videoconferencing tool �����which encodes ���x���

frames at �� grayscale levels Sazzad�s pyramidal encoder adds the information neces

sary to form a corresponding ���x��� frame at �� grayscale levels ��� The �x� blocks

forming the ���x��� picture are designated as base blocks� and the ��x�� pyramidal

di�erence blocks are designated as pyramidal or large resolution blocks

Two layers are not adequate to fully simulate a hierarchical stream To further

research multicast transmission of hierarchically coded data� additional layers were

added to CafeMocha Two important changes were made to the codec The base

layer was split into two layers� providing users with three grayscale B�W� quality

levels Color information corresponding to each layer was transmitted in three new

layers Thus� the �nished codec has six layers

This chapter describes the initial encoding mechanism and the changes imple

mented to get to the �nal version of CafeMocha

A The Encoding Mechanism

� Base Layer

The base layer uses regular CUSeeMe coding ���� Frames are ���x��� coded at ��

levels of gray Each pixel is represented by � bits The picture is divided into �x�

blocks that are conditionally replenished� a block is not encoded and transmitted

Page 37: 10.1.1.26.8823

��

unless it exhibits enough change according to an appropriate distance measure The

source maintains a copy of the current video frame at the receiver That copy is

exactly the same as the receiver�s rendered frame if the receiver does not experience

any losses A distance is computed between the current �x� block and its counterpart

at the receiver using a distance measure If the computed distance is larger than

a given threshold� the block is losslessly compressed and put in a bu�er for later

packetization and transmission A forced transmission mechanism is used to make

sure that all blocks are refreshed at least once every n number of frames

It is important to note the high lowering in bandwidth caused by the use of

conditional replenishment A high threshold considerably reduces the bandwidth used

at the cost of having �jerky� motion and many �coding artifacts� A low threshold

causes more blocks to be sent� thus increasing the video quality while raising the

output bit rate

There is one di�erence in the way the base stream is encoded from the standard

CU SeeMe coding In the standard encoder� blocks chosen for forced transmission

are determined by the number of frames since the block was last transmitted This

requires a signi�cant overhead as transmission statistics must be kept for each of

the ��� blocks in a frame The Sazzad implementation eliminates this overhead by

using a probabilistic approach in which each block is transmitted with probability p�

where ���� � p � ��� In this work� a value of ���� was adopted for p� on average� a

block will be updated at least once every thirty three frames A ���� value was used

by Brown ���� whereas� a lower value was judged appropriate for the high motion

sequences used in our testing

Page 38: 10.1.1.26.8823

��

� Enhancement Layer

The enhancement layer has a frame size of ���x��� pixels For each �x� base block�

there is a corresponding ��x�� pyramidal pixel block If a base layer �x� block

is to be transmitted� the di�erence between an upscaled version of the �x� block

and its enhancement counterpart is also transmitted after being compressed through

quantization and run length coding Fig � shows the process graphically

To decrease bandwidth� small pyramidal di�erences are mapped to zero depend

ing on a quality level parameter For a quality level of zero� the coding is lossless For

a quality level of ��� all the di�erences are mapped to zero A quality level of � was

found to be optimal by Sazzad ��� Shroeder developed the Predictive�Adaptive Rate

Control PARC� algorithm which sets a target rate for the pyramidal layer PARC

keeps the data rate on the pyramidal layer close to the target rate by varying the

quality parameter from frame to frame ���

Fig �� shows a block diagram of the whole coding process Encoded data is

placed in channel bu�ers until at least ���� bytes are available for transmission This

packet size is large enough to avoid excessive block overhead� and at the same time

small enough to avoid IP packet fragmentation

� Encoder Performance

a Base Layer

Table I taken from Sazzad�s thesis ���� shows the average bandwidth utilization for the

video sequence commonly known as �Miss America� The �Miss America� sequence

shows a �head and shoulder� video of a woman talking The subject exhibits limited

motion in that she moves her lips a little while talking� blinks occasionally and per

forms a small left to right movement with her body The background is uniformly

Page 39: 10.1.1.26.8823

��

240

160

120

320

Pres

ent B

ase

Fram

e

8x8

bloc

ks

If th

e di

stan

ce >

thre

shol

d =

> e

ncod

e ba

se b

lock

th

en e

ncod

e py

ram

idal

dif

fere

nce

Com

pute

the

dist

ance

bet

wee

n th

e co

rres

pond

ing

bloc

ks

Buf

fere

d B

ase

Fram

e

8x8

bloc

ks

Cur

rent

Lar

ge F

ram

16x1

6 bl

ocks

Ups

ampl

ed B

ase

fram

e

16x1

6 bl

ocks

Subt

ract

320

Ups

ampl

e

Enc

ode

the

corr

espo

ndin

g

pyra

mid

al d

iffe

renc

e bl

ocks

Fig�Sazzad�sPyramidalEncodingScheme

Page 40: 10.1.1.26.8823

��

160x

120

RT

P H

eade

r

RT

P H

eade

r

Con

ditio

nal R

elpe

nish

men

ton

8x8

blo

cks

of 4

bit

pixe

ls

Subt

ract

ion

FRA

ME

CA

PTU

RE

PYR

AM

IDA

LC

OM

PRE

SSIO

NPA

CK

ET

IZA

TIO

N

Dec

imat

ion

Raw

16x

16

320x

240

Ups

cale

d 1

6x16

8x8

"Los

sy"

Com

pres

sion

of

Pyra

mid

alD

iffe

renc

e

Los

sles

s C

ompr

essi

on

Qua

lity

Con

trol

Tra

nsm

it if

the

buff

ersi

ze >

100

0 by

tes

orif

ther

e is

a r

esid

ual

whe

n fr

ame

is f

inis

hed

Stre

am

Pyra

mid

al

Bas

elin

eSt

ream

NE

TW

OR

KL

AY

ER

Buf

fer

Bas

elin

e

Buf

fer

Pyra

mid

al

*Set

RT

P T

imes

tam

p*I

ncre

ase

RT

P Se

q. N

umbe

r*S

et R

TP

Las

t Pac

ket M

arke

r

Fig��FrameCapture�Compression�andPacketizationforPyramidalCoder���

Page 41: 10.1.1.26.8823

��

black Table II also taken from Sazzad�s thesis ���� shows the average bandwidth uti

lization for the video sequence commonly known as �Salesman� The sequence shows

an upper body shot of a person The subject is holding a small box His entire upper

body is visible The background is full of details The bandwidth is shown for all

quality values Bandwidth values do not include the RTP�RTCP overhead

Table I Average Uncompressed and Compressed Rates for the �Miss America� Se

quence Using Various Distance Threshold Values ���

Threshold Uncompressed Rate Compressed Rate Ratio

Kbits�frame� kbits�frame�

� ��� ��� ���

�� ��� ��� ���

�� ��� ��� ���

�� ��� �� ���

�� ��� �� ���

Table II Average Uncompressed and Compressed Rates for the �Salesman� Sequence

Using Various Distance Threshold Values ���

Threshold Uncompressed Rate Compressed Rate Ratio

Kbits�frame� Kbits�frame�

� ��� ��� ���

�� ��� ��� ���

�� ��� ��� ���

�� ��� �� ���

�� ��� �� ���

Page 42: 10.1.1.26.8823

��

Tables I and II show that the CU SeeMe codec provides a compression ratio of

at least ��� for typical sequences The threshold value has a very clear e�ect on the

bit rate In our further tests� the threshold is set to �� Our test sequences have

more motion than the �Miss America� and �Salesman� sequences The frame rate

used is low making changes high between consecutive real time frames The choice

of the threshold value is empirical� it was found to provide a good visual �ow of the

received video while reducing the percentage of encoded blocks

b Pyramidal Layer

Fig �� shows the temporal bandwidth of the test sequence actually used for the

layer control testing discussed in the next chapter�� which was �rst used by Brown

Taken from the movie �When Harry Met Sally� ����� it starts with two minutes of low

motion where Harry and Sally are talking on the phone and watching Casablanca

Throughout the rest of the sequence� there is a wide variance of motion The sequence

ends after the restaurant scene when the elderly lady says� �I�ll have what she is

having� The pyramidal layer is encoded with a constant quality of zero in Fig ��

Table III shows the average bandwidth per frame for the test sequence run at

three frames per second for di�erent quality values The average rate per quality level

is drawn in Fig ��

� Generalizing Assumption

While splitting the layers and adding new ones� we assumed the following�

� A coding mechanism for �x� base blocks is available

� For each coded base layer block� a ��x�� pyramidal block can be hierarchically

encoded using Sazzad�s mechanism

Page 43: 10.1.1.26.8823

��

Base Layer Pyramidal Layer

0 100 200 300 400 500 600 7000

100

200

300

400

500

600

Time (seconds)

Rat

e (k

bps)

Fig �� Test Sequence� Pyramidal Layer Coded at Quality �

Page 44: 10.1.1.26.8823

��

Table III Average Temporal Bandwidth use of the �When Harry Met Sally� Test

Sequence for Di�erent Quality values at � frames�second

Average Standard Minimum Maximum

Quality Bandwidth Deviation Bandwidth Bandwidth

kbps� kbps� kbps� kbps�

� ����� ����� ���� �����

� ����� ����� ��� �����

� ���� ����� ��� �����

� ���� ���� ��� �����

� ���� ���� ��� �����

� ���� ���� ��� �����

� ���� ���� ��� ����

� ���� ��� ��� ����

�� ���� ��� ��� ����

�� ���� ��� ��� ����

�� ��� ��� ��� ���

Page 45: 10.1.1.26.8823

��

0 5 10 150

50

100

150

200

250

300

Quality Parameter

Rat

e (K

bps)

Fig �� Average Rate per Quality Value for the �When Harry Met Sally� Test Se

quence at � frames�second

Page 46: 10.1.1.26.8823

��

If the above two assumptions are met� any hierarchical encoding scheme can be

used Sazzad suggests the use of a DCT based encoder for the base blocks claiming

that the compression ratio can be brought up to � or � as compared to the current

value of ��� ���

B Split of the Base Layer

Two approaches are investigated for replacing the �rst layer by two sub layers The

�rst approach makes use of block distance measures� the second makes use of a max

imum bandwidth constraint on the new base layer

� Threshold Separation

The �rst proposition is simple In addition to the block replenishment threshold� ��� a

separation threshold� �� is used� where �� � �� If the distance measure is larger than

the separation threshold� ��� the base �x� block is sent over the small layer� otherwise�

it is sent over the medium layer Thus� a user receiving layers � and � would actually

be receiving the entirety of the old base layer The change requires no modi�cation

to the way the enhancement layer is coded�decoded In the �rst tests� �� was �xed

and �� was adaptively changed to insure that the replenishment blocks were divided

equally between the two new layers Fig �� is a �ow chart of the process described

above

The threshold �� is updated every � seconds using the algorithm listed in Fig ��

If the rate on the small layer is ��� larger than the rate on the medium layer� �� is

increased by ��� increasing the distance range of the medium layer a block is sent

on the medium layer if �� � distance � ��� In the opposite case� the separating

threshold is decreased by two The control values were chosen arbitrarily Note that

Page 47: 10.1.1.26.8823

��

Last Block

Processed ?

No

Yes, end processing for current frame

Distance>

SeparationThreshold ?

>

Threshold

Distance

Send Base Block

Base Block

Distance on Current

Compute the

YesNo

Yes

No

Pyramidal Block on

Large Channel

Send corresponding

On Small Channel

Send Base Block

On Medium Channel

Fig �� Flow Chart for Splitting Scheme Number �

Page 48: 10.1.1.26.8823

��

the algorithm reacts more aggressively if the rate on the medium layer is higher than

the rate on the small layer

if ByteCountOnSmall � ��� �ByteCountOnMedium

�� ! �� ��

if �� � ���

�� ! ���

if ByteCountOnSmall � ��� �ByteCountOnMedium

�� ! �� � �

if �� � ��

�� ! ��

Fig �� Algorithm for Adapting the Value of the Separation Threshold in Splitting

Scheme Number �

Fig �� shows the bandwidth rates for the new small and medium layers Al

though the control process was not �nely tuned� it yielded good results The base

layer was split into two layers of approximately equal size The bias of the control

algorithm toward sending more data on the medium layer is apparent� the average

data rate on the small layer was ��Kbps compared to ���Kbps on the medium layer

This scheme was abandoned because the second alternative described next� was

found to be superior in both ease of control and visual quality of the received picture

� Use of a Bandwidth Limit on the Base Layer

The second approach is a bit more complicated A maximum bandwidth is de�ned

for the new small layer in terms of bytes per frame Base layer blocks are sent over

the small channel until the allowable number of bytes per frame is reached The

Page 49: 10.1.1.26.8823

��

Medium LayerSmall Layer

0 100 200 300 400 500 600 7000

20

40

60

80

100

120

140

160

180

200

time (seconds)

Rat

e (k

bps)

Fig �� Test Sequence Coded Using Scheme Number �

remaining replenishment block are sent on the medium layer Again� a user receiving

layers one and two would actually be receiving the entirety of the old base layer To

insure that the receiver of the base layer always receives full screen information� the

starting point of the search for blocks that need to be replenished must be changed for

each new frame explained below� Every time a base block is encoded to be sent on

either the base or the medium layer� the corresponding pyramidal di�erences needed

to construct its corresponding ��x�� large layer block are also encoded on the large

layer

Two complementary bu�ers are used to compute the distance needed in condi

tional replenishment

� The �small� bu�er keeps track of the image of users receiving the small layer

Every time an �x� block is to be sent on the small layer� the bu�ered image is

Page 50: 10.1.1.26.8823

��

used to compute the distance If the block is sent� both the small and medium

bu�ers are updated Note that before subscribing to the medium layer� a user

always subscribes to the small layer

� The �medium� bu�er keeps track of the image of users receiving both the small

and medium layers When the allocated bandwidth is exhausted on the small

layer� the distance is calculated using this bu�er If the block is sent� only the

medium bu�er is updated

This process creates some redundancy because updates targeted to the receivers

of the small layer are also received by the medium layer The redundancy was found

to be around ��

If the motion is low� all �x� base blocks are sent at the required bandwidth on the

�rst layer If the motion is high� a user receiving only the small layer receives updates

of successive portions of the screen without any loss of quality at the base layer

Fig �� is a �ow chart of the splitting process One problem that might arise in this

case is that the received small layer picture might have clear horizontal separation at

the start and end of successive updates because successive portions of the display are

coded from successive temporal frames This will happen in high motion sequences�

which is not what a videoconferencing tool typically handles

Fig �� shows how blocks of two consecutive frames might be sent In frame

number one� the gray blocks are sent on the base layer and the black blocks are sent

on the medium layer The byte count allocated for the base layer is exhausted at line

seven In frame number two� scanning of blocks to be sent starts at block line eight

Blocks are sent on the small layer until the allocated byte count is reached on block

line thirteen Blocks on lines fourteen to �fteen and one to seven that exhibit enough

motion are sent on the medium layer

Page 51: 10.1.1.26.8823

��

>

Threshold

Distance

>

Threshold

Distance

Update Medium Buffer

On Medium Channel

Send Base Block

Yes, end processing for current frame

Last Block

Processed ?

the Small Layer ?

Bandwidth Available on

Send Base Block

On Small Channel

Update Both Medium

and Small Buffers

No

No

YesYes

YesNo

Large Channel Large ChannelPyramidal Block onSend corresponding Send corresponding

Pyramidal Block on

Compute the

Distance on Current

Base Block Using

Distance on Current

Compute the

Base Block Using

Medium Buffer Small Buffer

Fig �� Flow Chart for Splitting Scheme Number �

Page 52: 10.1.1.26.8823

��

������������

������������

������������

������������

������������

������������������������

������������

������������

������������

������������

������������

������������

������������

���������������

���������

����������������

������������

������������

������������

���������������

������������

���������

������������ ���

������

���������

���������

���������������������

������������

������������

������������

������������

������������

8x8 Block Sent on the Small Channel

8x8 Block sent on the Medium Channel

Frame 2

Frame 1

13

8

7

Fig �� Example of Base Block Distribution over Two Consecutive Frames in Band

width Limit Scheme

Page 53: 10.1.1.26.8823

��

To test this scheme� the �When Harry met Sally� test sequence is used to deter

mine the encoder�s performance under a wide variety of motion levels The bandwidth

limit on the base layer was set to ��Kbps Fig �� shows the results The base layer

is always close to ��Kbps If very low motion is exhibited� all the blocks are sent on

the small layer and none are sent on the medium layer

small layer medium layer

0 100 200 300 400 500 600 7000

50

100

150

200

250

Time(seconds)

Ban

dwid

th (

kbps

)

Fig �� Test Sequence Coded Using Scheme Number �

This splitting scheme was preferred to the splitting scheme mentioned earlier

Beside being easy to control� the output is constant at an assigned bandwidth value

The new small layer will be the base layer to which all users need to subscribe It has

a low� nearly constant� bit rate allowing reliable access for all low bandwidth users

Page 54: 10.1.1.26.8823

��

C Color Enhancement

The other enhancement made is the transmission of color information for each lumi

nance layer the grayscale information� That is done by coding the U and V color

bands The Y band� which is the luminance� is already encoded in the three grayscale

layers

Note that any color picture can be encoded in several di�erent formats� each

corresponding to a di�erent colorspace The most simple is the red green blue RGB

colorspace Another possible colorspace is the Y UV format in which the luminance

information is located in the Y band black � white component� and the color in

formation is located in the U and V chrominance bands The Y UV format is widely

used because it allows straightforward reconstruction of the black and white version

of a color picture U and V represent the color di�erence signals B � Y and R � Y

B and R are the Blue and Red components in the RGB colorspace� In the digital

domain� as speci�ed in ����� the U and V color di�erences are referred to as Cb and

Cr

� YUV��� like Color Scheme

A distribution similar to the NTSC YUV ����� is used The only di�erence is that

pixels are encoded over � bits instead of � bits per datum Table IV shows the en

coding for each set of two pixels Every pixel is represented by a � bit datum on the

Y band Every two consecutive pixels share the same color U band and V band data

Table IV Modi�ed YUV ����� Encoding

� bits Y band � bits U band � bits Y band � bits V band

Pixel � Both Pixels Pixel � Both Pixels

Page 55: 10.1.1.26.8823

��

The U and V nibbles are grouped together to form a �UVUVUV � data stream

on the base layer The compression algorithms and routines used for the grayscale

layers are also used for the color layers For each �x� base block that is encoded� an

�x� UV block is also encoded This is possible because for every � bits of Y data �

pixels�� a � bit U datum and a � bit V datum need to be encoded Intuitively� it can

be assumed that the new streams have more vertical redundancy than the luminance

streams Results have con�rmed that the compression algorithms are well suited for

these streams Fig �� shows the data available through each band for two consecutive

pixels in the base frame� and their corresponding �x� pixels in the large frame Note

that if a receiver elects to receive the base and pyramidal Y band layers� the reception

of only the base frame color information would mean that a �x� block of pixels in

the reconstructed large frame would share the same color U and V data U���V�� in

Fig ���

U1ab U2ab

U1cd U2cd

V1ab

V1cd V2cd

V2ab

Y1bY1a Y2a Y2b

Y2dY2cY1dY1c

V12

U12

Y1 Y2

Upscaled Data

Y1 Y2

U12

V12

Corresponding Pyramidal 8 PixelsBase Pixels

Fig �� Color Scheme �

Page 56: 10.1.1.26.8823

��

In Fig ��� the physical order of the data found in Fig �� is shown An interesting

problem is noticeable The base color layer data order is set to �UVUVUV � The

same pyramidal encoding routine used for encoding the Y band is used again for the

pyramidal di�erences on the UV bands If the large color layer�s data order is also

set to �UVUVUV �� then pyramidal di�erences will not be minimized since some

data of a particular band would be subtracted from upscaled data of another band

Compression through run length coding would not be e�ective since di�erence values

are likely to be large This problem can be easily solved by adopting for the large

layer the �UUVVUUVV �data order shown in Fig �� before calling the encoding

routines

U12

V12

V12V12

V12U12U12

U12

Y1bY1a Y2a Y2b

Y2dY2cY1dY1c

U1ab V1ab

U1cd V1cd

U2ab V2ab

U2cd V2cd

Y1 Y1 Y2

Y1 Y1 Y2 Y2

Y2Upscale

Upscale

Corresponding Shared Color Data

Base Pixels

Y1 Y2

U12 V12

Upscaled Base Pixels

Normal Data Order

Corresponding Pyramidal 8 Pixels

Corresponding Color Data

Fig �� Upscaling Issues when Using the Same Pyramidal Coding Routine

U1ab U2ab V1ab V2ab

U1cd V2cdU2cd V1cd

Fig �� Byte Order for The Pyramidal Layer Color Data

Page 57: 10.1.1.26.8823

��

TableVPossibleLayerCombinationsinScheme�

B�W

SmallUV band

SmallUV band�

SmallUV band�

Bandwidth

MediumUV band

MediumUV band�

Limited�

LargeUV band

SmallY band

B�W

YUV�����

bandwidthlimited�

���x���

���x���

SmallY band�

B�W

YUV�����

YUV�����

MediumY band

���x���

���x���

���x���

SmallY band�

B�W

YUV�����

YUV�����

YUV�����

MediumY band�

���x���

���x���

���x���

���x���

LargeY band

Page 58: 10.1.1.26.8823

��

The �nished encoder�decoder has the possible layer combinations shown in Ta

ble V The UV band pixel information is shared by each two consecutive pixels in

the YUV ����� format The YUV ����� format shown in the table corresponds to the

reception of complete Y band information for the large frame with only base frame

color data In this case the color data is upsampled to display a large color frame

Each color data that was shared by two base pixels is consequently shared by their

upscaled eight corresponding pixels �x� block� in the large frame

� YUV��� like Color Scheme

A distribution similar to the NTSC YUV ����� was also tried a compile time pa

rameter determines which color scheme is used by CafeMocha� Table VI shows the

encoding for each set of two pixels

Table VI Modi�ed YUV ����� Encoding

� bits Y band � bits U band � bits V band

Pixel � Pixel � Pixel �

The U and V nibbles are again grouped together to form a �UVUVUV �

stream for the small and medium layers The small and medium layers are formed

of small frame �x� blocks The same compression algorithms used for the base and

pyramidal grayscale Y band� blocks are again used for the color layer blocks Every

time an �x� base Y band block is encoded� two �x� base UV bands blocks are encoded

To each pixel corresponds a Y band � bit datum� a U band � bit datum and a V band

� bit datum Fig �� shows the information available for each base block pixel� its

upscaled in�uence on the large frame� and the corresponding � pixels in the large

frame

Page 59: 10.1.1.26.8823

��

U

V

Y

VVb

Vd

Va

Vc

Ua Ub

Uc UdU

Yb

Yc Yd

Ya

Upscaled Data Corresponding Pyramidal 8 PixelsBase Pixels

Y

Fig �� Color Scheme �

The upscaling problem encountered for the previous color scheme is present here

too Again� adopting a �UUVVUUVV � data order on the large color layer solves

the problem

Our �nished encoder�decoder has the possible layer combinations shown in Ta

ble VII UV band pixel information is complete for each pixel in the YUV �����

format and subsampled by a factor of � in our YUV ����� format Every base U

and V pixel data corresponds to a �x� block of pixels in the large frame due to the

up sampling of the U and V bands Note that the actual YUV ����� format has a

similar distribution� but each datum is represented by � pixels

Tables VIII and IX give the average data rates for every layer when coding the

�When Harry met Sally� test sequence at three frames per second Surprisingly� the

rate on the large Y band layer is the same at an average of ��Kbps for all quality

values above zero

Page 60: 10.1.1.26.8823

��

TableVIIPossibleLayerCombinationsinScheme�

B�W

SmallUV band

SmallUV band�

SmallUV band�

Bandwidth

MediumUV band

MediumUV band�

Limited�

LargeUV band

SmallY band

B�W

YUV�����

bandwidthlimited�

���x���

���x���

SmallY band�

B�W

YUV�����

YUV�����

MediumY band

���x���

���x���

���x���

SmallY band�

B�W

YUV�����

YUV�����

YUV�����

MediumY band�

���x���

���x���

���x���

���x���

LargeY band

Page 61: 10.1.1.26.8823

��

Table VIII Average Temporal Bandwidth Rates of the Test Sequence for the Base

Layers at � frames�second Using Color Scheme �

Average Standard Minimum Maximum

Bandwidth Deviation Bandwidth Bandwidth

kbps� kbps� kbps� kbps�

Small Y band ������ ����� ����� ������

Small UV band ������ ����� ����� ������

Medium Y band ������ ������ ����� �������

Medium UV band ������ ������ ����� �������

Page 62: 10.1.1.26.8823

��

Table IX Average Temporal Bandwidth Rates of the Test Sequence for Di�erent Qual

ity Values at � frames�second Using Color Scheme � for the Large Layer

Average Standard Minimum Maximum

Bandwidth Deviation Bandwidth Bandwidth

kbps� kbps� kbps� kbps�

Quality � Y band ������� ������� ������ �������

Quality � UV band ������� ������ ����� �������

Quality � Y band ������� ������� ����� �������

Quality � UV band ������ ������ ����� ������

Quality � Y band ������� ������� ����� �������

Quality � UV band ������ ������ ����� ������

Quality � Y band ������ ������ ����� �������

Quality � UV band ������ ������ ����� ������

Quality � Y band ������ ������ ����� �������

Quality � UV band ������ ������ ����� ������

Quality � Y band ������ ������ ����� ������

Quality � UV band ������ ������ ����� ������

Quality � Y band ������ ����� ����� ������

Quality � UV band ������ ������ ����� ������

Quality �� Y band ������ ����� ����� ������

Quality �� UV band ������ ������ ����� ������

Page 63: 10.1.1.26.8823

��

D Correlation Between Y band Layers and their Corresponding Color Layers

Since the same number of blocks will be sent on any Y band layer and its corre

sponding UV band layer� then the rate on both will be highly correlated Fig �� and

Fig �� con�rm our intuition Over the small layers� the sample mean of the ratio of

the octet count sent on the color layer to the one sent on the Y band layer is ����

with a sample standard deviation of ���� Over the medium layers� the same ratio is

���� with a sample standard deviation of ����

0 100 200 300 400 500 600 7000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Time (seconds)

Rat

io

Fig �� Ratio of the Rate on the Small UV band Layer over the Rate on the Small

Y band Layer during the �When Harry Met Sally� Test Sequence

The Large UV band layer� shows a relatively low bit rare when compared to

the total bit rate of the layers that are added before it No strict correlation was

found between the large UV band layer and it�s Y band counterpart However� it was

observed that the bit rate on the former is less than the bit rate on the latter most

Page 64: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Time (seconds)

Rat

io

Fig �� Ratio of the Rate on the Medium UV band Layer over the Rate on the Medium

Y band Layer during the �When Harry Met Sally� Test Sequence

of the time

Thus we will do rate control exclusively on the Y band layers The rate on the

corresponding color layers will be controlled simultaneously

E Processing of Incoming Packets at the Decoder

Fig �� shows the decoding process at the receiver side The process is event driven

Arrival of a packet on one of the subscribed layers instigates an action at the receiver

Incoming packets are bu�ered until the receiver knows that no more packets are

incoming for that layer A receiver detects that no more packets for the current

frame are available by checking for the arrival of the end of frame bit markers on all

the layers� or by detecting the arrival of a packet corresponding to a frame that has

Page 65: 10.1.1.26.8823

��

a greater timestamp When decoding� the data of the base frame small and medium

layers� should be decoded before the data of the large frame Decoded pyramidal

di�erences are meaningless if the corresponding base blocks have not been decoded

F The PARC Algorithm

The Predictive�Adaptive Rate Control algorithm developed by Schroeder ��� can

maintain the rate of the pyramidal stream at a �Target Rate� set at the source

by sending consecutive frames at di�erent quality levels Brown used this �Target

Rate� to adapt the rate of the large layer to avoid congestion Fig �� shows the

target rate and the actual rate of the pyramidal layer Brown�s approach was to add

�Kbps to the Target Rate in the absence of congestion� and to multiply it by ���

whenever congestion is reported

Fig �� shows how the PARC algorithm performs in the case of the test sequence

PARC�s target rate was set to �� Kbps� the target quality was set to � the encoding

quality parameter can vary between the �target quality� and ��� The bandwidth

of the layer is maintained at nearly ��Kbps for most of the time Even in very high

motion� the PARC algorithm still limits excessive bandwidth use Between seconds

��� and ���� the consumed bandwidth is brought down from ���Kbps at quality � to

an average of ���Kbps Note that the algorithm�s performance relies on the ability to

predict what quality values can be used for encoding the pyramidal di�erences Bad

performance indicates a failure to predict how many octets are needed to encode the

processed frame at a given quality q This can happen when unusually high motion

is encountered as in our test sequence as occurs between seconds ��� and ���

PARC is a good control scheme for the pyramidal layer However� the aggregate

rate of the Y band layers would exhibit higher variability mainly because of the Y

Page 66: 10.1.1.26.8823

��

Tim

esta

mp

> C

urre

nt u

ndis

play

edT

imes

tam

p ?

Sav

e th

e D

ata

into

the

corr

espo

ndin

gC

hann

el's

Buf

fer

Last

Pac

ket

Mar

ker

?H

ave

we

rece

ived

the

last

pack

et o

f ev

ery

laye

r ?

Unc

ompr

ess

All

the

buff

ers

that

nee

d to

be

deco

ded

acco

rdin

g to

the

subs

crip

tion

leve

l.D

ecod

e in

thi

s or

der:

smal

l, m

ediu

m t

hen

larg

e Y

-ban

dsm

all,

med

ium

the

nla

rge

UV

-ban

d

Tim

esta

mp

< C

urre

nt T

imes

tam

p ?

Unc

ompr

ess

All

the

avai

labl

e in

form

atio

nin

the

buf

fers

tha

t ne

edto

be

deco

ded

acco

rdin

g to

the

curr

ent

subs

crip

tion

leve

l.D

ecod

e in

thi

s or

der:

smal

l, m

ediu

m t

hen

larg

e Y

-ban

dsm

all,

med

ium

the

nla

rge

UV

-ban

d

Ren

der

Imag

e at

the

reso

lutio

n re

quir

ed b

yth

e cu

rren

t su

bscr

iptio

nle

vel

Igno

re D

ata

RT

PP

acke

tR

ecei

ved

Ret

urn

Yes

No

Yes

No

No

Yes

No

Yes

Ret

urn

Ret

urn

Fig��DecodingoftheIncomingPackets

Page 67: 10.1.1.26.8823

��

Large Y−band LayerTarget Rate

0 100 200 300 400 500 600 7000

50

100

150

200

250

Time (seconds)

Ban

dwid

th (

Kbp

s)

Fig �� PARC Algorithm Used for Congestion Avoidance

Page 68: 10.1.1.26.8823

��

band medium layer

G Stabilization of the Total Output Rate Using PARC

We enhanced the e�ectiveness of Shroeder�s PARC algorithm ��� by estimating the

bandwidth used on the base layer and then setting PARC�s target rate to the desired

global target rate minus the base layer�s rate The total output rate of the encoder

was greatly stabilized as can be seen in Fig ��

All Y−data Target Rate

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

Time(seconds)

Ban

dwid

th(k

bps)

Fig �� Total Bandwidth Used by the Y band Layers Small�Medium�Large� Con

trolled by the Enhanced Use of the PARC Algorithm under a Total Rate Limit

of ���Kbps

The control process is simple We estimate the bandwidth on the base layer

through a �rst order low pass �lter estimator with gain g PARC�s target rate is

then set to the di�erence between a maximum rate set by the user and the calculated

Page 69: 10.1.1.26.8823

��

estimate The update equations are listed in Fig �� A minimum rate of ��Kbps

was assigned to the Y band pyramidal layer during our tests The assigned global

rate is only relevant to the Y band layers We chose a value of ��� for g� the update

equations are run every time a frame is encoded

EstimateOnBase ! �� g�EstimateOnBase gOctetCountSmall�Medium�

PARCTargetRate !MaxRate � EstimateOnBase

PARCTargetRate ! min����Bytes� PARCTargetRate�

Fig �� Equations for the Enhanced PARC Control Process

As will be seen in Chapter V� the large Y band layer will be joined after all

the Y band and UV band base layers have been successfully added That level of

subscription will be labeled �Level �� In that case� the OctetCountSmall�Medium

value in Fig �� is replaced by the octet count on both the Y band and UV band� small

and medium layers A reasonable value for the parameter PARCTargetRate is ��� Kbps

as can be seen in Fig �� The rate at �Level �� exceeds the target rate ��� of the

time But� if we disregard the period between seconds ��� and ��� where an unusual

amount of motion is present� and if we allow the algorithm an error of ���� the

percentage of time spent above the target rate drops to ���� The poor performance

of the algorithm is easily explained by the fact that the aggregate bandwidth of the Y

band small� Y band medium� UV band small and UV band medium can signi�cantly

exceed the target rate as can be seen in Fig ��

This bandwidth limiting scheme was used during the simulation of the various

layer control schemes

Page 70: 10.1.1.26.8823

��

Target Rate Bandwidth at Level 4

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

Time(seconds)

Ban

dwid

th(K

b/s)

Fig �� Total Bandwidth Used by all Base Layers Y band Small�Medium� UV band

Small � Medium� and the Large Y band Layer Controlled by the Enhanced

Use of the PARC Algorithm under a Total Rate Limit of ���Kbps

Target Rate Bandwidth at Level 3

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

Time(seconds)

Ban

dwid

th(K

b/s)

Fig �� Total Bandwidth Used by all Base Frame Layers Y band Small�Medium�

UV band Small � Medium�

Page 71: 10.1.1.26.8823

��

CHAPTER IV

CONTROL SCHEMES FOR THE LAYERS

A Overview

The objective of any multicast video distribution scheme is to reach a fair distribution

of the video data Cheung et al ���� de�ne fairness as the reception by each receiver

of video stream quality commensurate with its capabilities or the capabilities of the

paths leading to it In one to many multicast video� di�culties stem from the real

time nature of the digital video and the potential for a large number of receivers with

heterogeneous capabilities Approaches to deal with these problems can be divided

into two categories� a� the use of a network capable of resource reservation� and

b� the use of feedback control to adjust video stream requirements to meet current

network capabilities In this thesis� we focus on the latter approach� mainly because

of the open to all non reservation nature of the Internet and its multicast backbone

MBONE�

Through packet loss measurement� receivers try to get their optimal video quality

and thus use as much of the available bandwidth as possible� Optimal protocol be

havior can be measured by running one to one sessions In the absence of interference

between clients the protocol should behave at its best The performance can then

be compared to each receiver�s behavior in an actual one to many videoconferencing

session

Streams hierarchically encoded and multicast distributed provide good granu

larity of control Clients can add and drop layers until they receive the best video

quality that they can handle Multicasting each hierarchical layer on a separate IP

multicast group eliminates most but not all� of the �interference� between receivers

Page 72: 10.1.1.26.8823

��

�Interference� between clients can occur when a client elects to add a layer and

inadvertedly congests a link on its reception path All the clients located at the same

side of the link as the �interfering client� would experience packet loss and lower video

quality A good protocol should be able to recognize transient packet losses due to

clients �trying to join� extra layers We call �join experiments� the act of subscribing

to a new video layer by a client In the absence of resource reservation schemes or

router bandwidth evaluation agents� a receiver cannot be sure beforehand whether

its join experiment will succeed or fail

McCanne et al ��� have proposed and implemented the Receiver driven Lay

ered Multicast RLM� Protocol� a non reservation active receiver experiment scheme

whereby additional layers are periodically added in the absence of signi�cant packet

loss

RLM was simulated for constant bit rate CBR� sources ��� The challenge

of implementing it with the CafeMocha encoder is the variable bit rate of most of

CafeMocha�s layers The variability of the bit rate is minimal for the small Y band

and UV band layers It is video motion dependent for users receiving any of the

medium layers Y band or UV band� The large layer can also be a source of rate

variability unless the Enhanced PARC algorithm is used The Enhanced PARC con

trol mechanism stabilizes the overall rate for receivers accepting all small� medium�

and large layers

In this chapter� we �rst give a brief overview of RLM Then� we describe a basic

one to one control scheme implemented in preliminary tests We conclude by listing

the metrics selected to evaluate the protocol�s performance

Page 73: 10.1.1.26.8823

��

B RLM

� Description

Under RLM� each receiver adapts individually to observed network performance by

adjusting its level of subscription within the overall layered multicast group structure

Simply put� each receiver runs the following simpli�ed control loop�

� on congestion� drop a layer

� on spare capacity� add a layer

Link capacity is inferred by carrying out active experiments These experiments

consist in the spontaneous addition of layers at well chosen times If a join experiment

causes congestion� the receiver drops the layer that was just added and deems the

experiment a failure In case of success no congestion occurs�� the receiver stays at

the new level of subscription

Optimal operating points are normally just below the congestion point of the link

maximum link utilization� Join experiments might have a negative impact on the

overall performance if they are repeated too often An exponentially increasing delay

is imposed between failed experiments In the case of high packet losses that do not

correspond to join experiments� the receiver drops layers periodically until network

congestion ceases

Concurrent join experiments can mislead receivers adding lower layers For ex

ample� assume that a receiver R� undertakes a join experiment that causes a link

to congest� and assume that a receiver R� is conducting a similar experiment at a

lower subscription level If the path from the source to receiver R� passes through

the link congested by R�� then the packet losses would make R� assume that it�s join

experiment has failed The protocol�s e�ciency is negatively a�ected by receivers

Page 74: 10.1.1.26.8823

��

backing o� erroneously Consequently� receivers have to communicate and announce

their join experiments This allows receivers to observe concurrent join experiments

A user observing the failure of an experiment can infer that a similar join experiment

would not work for it negative learning� On the other hand� positive learning does

not occur in this scheme since a successful join experiment can not be recognized by

other receivers

RLM is not compatible with router packet priority forwarding schemes If lower

layer packets have more priority than any higher layer packets� packets of higher layers

are selectively dropped at routers in case of congestion This eliminates negative

shared learning When congestion occurs� other receivers would not perceive packet

loss at lower layers and thus are unaware of the negative experimental outcome

Scalability problems arise if a large number of receivers interfere with each other�s

join experiments

The protocol is described in more detail in the next section

� Protocol Details

Fig �� shows the state diagram of a receiver using RLM A receiver can be in any

one of the following states� Steady S�� Measurement M�� Drop D�� or Hysteresis

H� Each transition is labeled with the reason of the transition� either packet loss or

timeout

Table X explains the variables� timers and transition causes in Fig ��

Page 75: 10.1.1.26.8823

��

L F R . . _ _

L F

R .

.

_

TD

TD

TD

TD

TJ

L<

L>

L F.S

H

M

D

(relax)

Hysterisis

Measurement

Drop

(drop)Steady

(add)

Fig �� RLM Receiver State Diagram ���

Page 76: 10.1.1.26.8823

��

Table X De�nition of Variables Showing in Fig ��

Events

L Packet loss as low as one single packet

F Our layer is highest of recently added layers

R Our layer was recently added

L� Loss rate exceeds threshold� loss rate measured with a short term esti

mator

L� Loss rate below threshold� loss rate measured with a short term esti

mator

Timers

TJ Join Timer for the current layer� it will be referred to as T kJ where k is

the current subscription level It is randomized around its actual value

to avoid protocol synchronization e�ects

TD Detection timer set to a weighted value of the detection time estimator

It is an estimation of how long we need to wait before being able to

detect the congestion of the network� k� "TD k�"�D

Actions

add Subscribe to the next layer in the multicast group hierarchy

drop Drop the current layer and multiplicatively increase the join timer for

that layer

relax Multiplicatively decrease the join timer for the current layer

Page 77: 10.1.1.26.8823

��

Note that whenever a join timer is scaled back or relaxed ie� multiplicatively

increased or decreased� to a value T for layer X� the add timer of each layer above

layer X is set to the maximum of its current value and T � and the add timer of each

of the layers below layer X is set to the minimum of its current value and T This

ensures the invariant that join timer values increase with the layer number Table XI

gives the parameters necessary for the protocol variables� updates Table XII lists

the variables maintained and updated by the receivers

Table XI RLM Protocol Parameters

Parameter Description

� Join timer backo� constant � ��

� Join timer relaxation constant � ��

"TminJ Minimum join timer interval

"TmaxJ Maximum join timer interval

k�� k� Detection time estimator scaling term

g�� g� Detection time estimator �lter constants

Threshold Threshold used in making drop decision

The essential parameters and variables of interest have been brie�y described in

this section For a thorough description� the reader is referred to McCanne�s doctoral

dissertation ���

Page 78: 10.1.1.26.8823

��

Table XII RLM Protocol Variables and Update Equations

Variable Description Update Equation

State State identi�er S�H�M�D�

N Current level of subscription

"T kJ Join timer for level k relax � max� "T k

J � "TminJ �

backo� � min� "T kJ � "T

maxJ �

Di Detection time estimate� computed by

correlating failed failed joined experiment

start times with the onset of congestion

Simple measurement

"TD Detection time sample mean� updated

through a �rst order low pass �lter every

time Di is measured

"TD � �� g�� "TD g�Di

"�D Detection time sample deviation� updated

through a �rst order low pass �lter every

time Di is measured

"�D � � � g��"�D g�jDi �

"TDj

Page 79: 10.1.1.26.8823

��

C Basic One to One Control Scheme

A basic control scheme was �rst developed and tested for one to one layer control

The burstiness of the codec did not allow tight controls The controlling algo

rithm accepts transient packet losses The appraisal algorithm runs every time an

RTCP Receiver Report packet is sent Time is counted in RTCP intervals �xed to

� seconds in CafeMocha� The intervals are integer values The scheme is described

in Fig ��

Note that the timers are multiplicatively increased when a layer is dropped� and

multiplicatively increased if a layer is added If the addition of a layer is not success

ful within two epochs� the AddT imer on the starting layer receiver�s subscription

level before the addition� is multiplicatively increased twice since it has already been

multiplicatively decreased

The variables used by the algorithm are given in Table XIII

Table XIII Variables and their De�nitions

� Backo� Constant� used to multiplicatively increase the add timers

� Relaxation Constant� used to multiplicatively decrease the add timers

Tj Add Timer Value for Level j

Counter Counter used to Keep Track of Elapsed Epochs

CLF Current Loss Fraction Computed over the Highest Subscription Layer

ALF Average Loss Fraction

Average losses are estimated using a linear �lter as follows�

ALF ! ALF � �� CLF � ��

The formula reduces the impact of transient low packet losses It is computed every

Page 80: 10.1.1.26.8823

��

AverageLosses ! AverageLosses � �� CurrentLosses � ��

if we have joined a layer one epoch ago

ignore current AverageLosses

else

if AverageLosses � AcceptableAverageLoss

Go down one Level

Multiplicatively increase the AddT imers on all higher layers

if we made a join experiment two epochs ago

Multiplicatively increase the AddT imer on current layer

else

Increment Counter

if Counter ! AddT imerForCurrentLevel

Reset the counter

If AverageLosses � AcceptableAverageLossesatAddT ime

Go up one Level

Multiplicatively decrease the Add Timers on all lower levels

Reset the AverageLosses parameter to zero

Fig �� Algorithm for the Basic One to One Layer Control Scheme

Page 81: 10.1.1.26.8823

��

time the control routine is run� ie once every � seconds The CurrentLossFraction

value is based on calculated losses reported in RTCP receiver reports

The loss fraction is computed over the highest layer in the hierarchy If lower

layers have a higher priority at the network routers� then the impact of the congestion

would be primarily felt at the highest layer� and the algorithm would react faster to

packet losses If no priority scheme is used� then the loss percentage on the highest

layer should be statistically the same as that of the whole stream� the algorithm would

still perform normally

D Metrics

The metrics selected are similar to the ones used by Cheung et al ���� Cheung

judges his Destination Set Grouping protocol�s performance by comparing it to an

�Optimal� protocol behavior as explained below �Optimal� protocol behavior is

measured by running one to one sessions In the absence of interference between

clients the protocol should behave at its best The performance can then be compared

to each receiver�s behavior in an �actual� one to many videoconferencing session

We also de�ne an �Ideal� protocol behavior The ideal layer distribution can be

calculated by assuming that a receiver has the ideal number of layers that do not

congest its link path to the source at any time t

We can then assess the performance of the protocol by comparing the �Actual�

bandwidth delivered and packets lost� to the same values in the �Optimal� case

The �Optimal� performance can also be appraised by comparing its total bandwidth

delivery to the �Ideal� case

The �Actual� one to many situation will not be implemented in our testing be

cause we simulate One to One cases exclusively

Page 82: 10.1.1.26.8823

��

Other metrics that will be computed are the Congestion Period Duration CPD�

and the Congestion Period Interval CPI�� both introduced by McCanne ��� McCanne

de�nes a loss event as the time interval that starts at a successful packet arrival just

before a dropped packet and ends when a subsequent successful packet arrives He

further de�nes a congestion event to be the union of loss events that are separated

by less than a threshold �T Finally� he de�nes a congestion period as the start time

of a congestion event�s earliest loss event and the end time of the congestion event�s

last loss event

The CPD is the average value of the sample congestion periods It was shown by

McCanne to be more or less bounded by feedback delays in the system ��� This is true

for a constant bit rate source where detected packet losses usually induces the quick

drop of a layer In the case of a variable bit rate source� we expect the CPD to also

depend on the variation in bitrate of the broadcast video stream Transient packet

losses caused by uncommonly high motion in a video sequence causes congestion

periods but does not necessarily lead to layer drops

The CPI is the time interval between congestion events It re�ects the activity of

the whole source receivers system It is small at the start of a session when concurrent

join experiments are taking place� and large when the receivers reach stable conditions

when congestion periods seldom occur A time weighted average of the CPI is needed

so that the intervals that correspond to transient behavior do not make the CPI

average biased toward the more numerous transient small intervals If congestion

periods are given by the following time intervals�

t�� t��� t�� t��� � � � � tN��� tN�

Page 83: 10.1.1.26.8823

��

then the time averaged CPI is �

CPI ! t� � t��t� � t�tN � t�

� � � tN�� � tN���tN�� � tN��tN � t�

where t� is the one to many multimedia session start time

Page 84: 10.1.1.26.8823

��

CHAPTER V

RESULTS

Performance appraisal of the protocols is done by calculating the metric values listed

at the end of the previous chapter

A Testbed

Simulations were carried out using the simple topology used by Brown ��� That

topology consists of a source and a receiver separated by a router as can be seen in

Fig ��� a rate limit can be set on the router

VCMRouteRate Limit set on multicast traffic

VCSun1 VCSun3

Fig �� Testbed Topology

VCSun� is a Sun Sparc �� VCSun� is a Sun Sparc �� Both machines are

running the Solaris �� operating system The router is an ����� running FreeBSD

We ran the source on vcsun� and the receiver on vcsun�

The mroute daemon mrouted version ��� running on VCMRoute is assigned

a rate limit on multicast tra�c The rate limit can vary between � and ��� kbps

Mrouted uses a token bucket �lter to regulate data transmission If a packet arrives

while the queue is full� it is discarded An mrouted on a leaf network prunes as soon

as it knows that there are no remaining members on the subnet The Internet Group

Management Protocol IGMP�� described in RFC ���� ����� is used by hosts and

routers to control multicast group membership Before pruning� IGMPv� requires a

Page 85: 10.1.1.26.8823

��

timeout to learn that there are no remaining members� IGMPv� allows for an end

station to let the router know that it is leaving the group Any IGMPv� group

member causes the router to revert to using the timeout ���� Solaris �� comes with

IGMPv�� but it can be upgraded to IGMPv� through system patches With IGMPv��

we relied on lowering the GroupQueryInterval and GroupExpireT ime parameters

of mrouted in order to make pruning faster� they were set to �ve and ten seconds

respectively Mrouted polled all the receivers in this case it polled vcsun�� the only

machine on the subnet� every �ve seconds� and could prune a multicast distribution

tree for a given layer�s multicast group if no receiver responded during two consecutive

query intervals The system patch required to upgrade to IGMPv� was later applied

to vcsun� In all our tests� the daemon prunes a layer three seconds after it receives

an IGMP leave message from the last subscribed receiver vcsun� is the only receiver

in our case� This three second delay should ideally have been shorter� however� the

timer resolution of mrouted does not allow a smaller value for the LeaveExpireT ime

parameter All our results were obtained with vcsun� running IGMPv�

The source video was obtained from a VCR that delivers an analog video stream

The source output rate can vary between di�erent runs since we are running at a low

frame rate three frames per second� For example� the number of blocks that need to

be updated from one frame to the next can vary if the grabbed frames are all shifted

by ��� seconds� di�erent blocks are updated di�erently according to the amount of

variation occurring from frame to frame This variation can a�ect the determination

of the �ideal� layer distribution if the output of the source is close to the bandwidth

limit Furthermore� sustained high motion between seconds ��� and ��� of the test

sequence can momentarily peg the CPU at the source� CPU pegging at the source was

observed to slightly slow down the frame rate The changes in the ideal subscription

sample paths were found to be small but not negligible To obtain very accurate data�

Page 86: 10.1.1.26.8823

��

we consider each run of the test sequence as a separate event Global performance

metrics are not a�ected by the above factors� they can be used to compare the two

layer control protocols

B Layer Order

The following layer join order was chosen note that each subscription level corre

sponds to an entry in Table VII��

� Subscription level �� Small Y band layer All receivers must be subscribed to

this layer

� Subscription level �� add Small UV band A receiver at this subscription level

reconstructs a ���x��� color frame As many �x� blocks as possible are updated

per frame within the rate limit set on the small Y band layer

� Subscription level �� add Medium Y band layer A receiver at this subscription

level can reconstruct all the Y band information for the base ���x��� pixel

frame as well as partial color information

� Subscription level �� add Medium UV band A receiver at this subscription

level� can reconstruct the full color base ���x��� pixel frame

� Subscription level �� add Large Y band layer At this subscription level� the

receiver can reconstruct a ���x��� pixel frame The Y band information is

complete� but the color UV band data is subsampled

� Subscription level �� add Large UV band layer A receiver at this subscription

level� can reconstruct the full color base ���x��� pixel frame

Page 87: 10.1.1.26.8823

��

We use the process described in Section G of Chapter III to stabilize the total

bandwidth received by a user at subscription level � We �xed the rate limit on the

enhanced PARC mechanism to ���kbps We also have control of the bandwidth sent

on the small Y band layer� this value was set to �� kbps

Our tests showed that the �When Harry Met Sally� test sequence broadcast

at three frames per second can sometimes peg the CPU of the VCSun� receiver at

subscription level � Therefore� we decided to limit receivers to subscription level �

Thus� we will be working with a � layer codec

C Short Term Packet Loss Estimator

RLM needs a short term loss estimator Short term packet loss appraisal is done by

using a FIFO list that keeps track of the most recently received data All frames

received in the last �T seconds have entries in the FIFO list After the display of

a frame with timestamp T � a new entry is created for the frame and all entries that

correspond to frames whose timestamps are less than T��T are cleared the number

of entries cleared is usually one except if data for one or more whole frames were lost�

Each entry contains the following frame information� timestamp� number of packets

received� number of packets lost� and octet count received The value of �T was

chosen to be ��� seconds in accordance with the value suggested by McCanne ���

McCanne de�nes the occurrence of congestion as sustained packet loss over a period

of � seconds Using the elements present in the FIFO list� the packet loss percentage

is calculated and used to make drop or add decisions in the RLM protocol

Page 88: 10.1.1.26.8823

��

D Practical Calculation of the Metrics

Every time we run the test sequence� we keep track of a number of program state

variables

At the source for each encoded frame� we save the frame timestamp and the octet

count on each encoded layer With this data and the knowledge of the rate limit at the

separation router� we are able to construct the �ideal� subscription sample path for

the receiver Using that ideal sample path� we can then calculate the corresponding

bandwidth received by a user under an ideal layer control mechanism

At the receiver for each frame received� we save the local time� the frame�s times

tamp� the total number of octets received� the number of packets received� the number

of packets lost during the reception of the frame� and the level of subscription With

this data� we can construct the receiver�s subscription sample path and its received

bandwidth We then evaluate the e�ectiveness of the layer add�drop algorithm by

comparing the results to the �ideal� case In particular� we compute the ratio of the

cumulative octet count received by users in the actual case to the one received by

users in the �ideal� case We also compute the ratio of the cumulative octet count

lost to the incoming receiver octet count

To compute the CPI and CPD� we keep track of all packet loss events at the

receiver We then group those packet loss events into congestion periods All packet

loss events separated by less than two seconds are grouped together� the process is

repeated exhaustively Having determined all congestion periods� we then proceed to

compute the mean and standard deviation of the CPD� and the mean of the CPI

In addition� we calculate the e�ciency of the algorithm in terms of the ratio

of the bandwidth used to the bandwidth available The protocols have not been

optimized in regard to this metric� its value is very important if the protocol is put to

Page 89: 10.1.1.26.8823

��

practical use E�ciency of the bandwidth usage can be increased over what we obtain

currently by implementing a scheme that updates the rate parameters at subscription

levels �� �� �� and � Feedback mechanisms similar to the Destination Set Grouping

scheme developed by Cheung et al ���� can be used

Results are presented in the next section for the Basic one to one control scheme

followed by results for RLM

E Basic One to One Scheme Results

The Basic one to one control scheme described in Section C of Chapter IV� was added

to CafeMocha It was tested using the testbed topology used by Brown ��� and

described in Section A of this chapter

Table XIV gives the values of the parameters that control the basic layer control

algorithm Time is counted in �ve second epochs A time value equivalent to only

one minute was chosen for Tmax� this ensures a larger number of join experiments

in our tests The parameter values are similar to the ones chosen by McCanne ���

The acceptable average loss of �� allows the receiver to ignore transient packet losses

due to occasional high motion in the video stream causing higher bandwidth use and

sometimes CPU pegging

Since we are only running one receiver� we do not worry about protocol synchro

nization problems that can occur when several receivers are running simultaneously

The protocol was tested for di�erent router rate limits The �When Harry Met

Sally� test sequence was broadcast under router rate limits of ���kbps� ���kbps�

���kbps� ���kbps� and ��kbps We will show a graphical data analysis followed by a

performance analysis where we compute the metrics

Page 90: 10.1.1.26.8823

��

Table XIV Values Chosen for the Parameters Controlling the Basic Control Scheme

Parameter Description Value

� Backo� Constant on Add Counter Values ��

� Relaxation Constant on Add Counter Values ��

Tmax Maximum Add Counter Value �� epochs � minute�

Tmin Minimum Add Counter Value � epoch � seconds�

CLF Acceptable Average Loss at Add Time ��

AAL Acceptable Average Loss ��

� Graphical Data Analysis

Figs �� �� show the data obtained from testing the basic control scheme at a router

rate limit of ���kbps Figs �� and �� show the ideal and observed subscription

level sample paths Figs �� and �� show the ideal and measured bandwidth usage

Fig �� shows the packet losses measured at the receiver during the broadcast of the

test sequence

A ���kbps rate limit does not cause any packet drop at the router� the receiver

should ideally add layers successively and get to subscription level � The occasional

packet losses seen in Fig �� are due to CPU pegging at receiver VCSun� when sub

scribed at level � Transient packet losses due to CPU pegging can induce erroneous

decisions at the receiver as can be seen between ��� and ��� seconds in Fig ��

Packet losses due to CPU pegging are of a transient nature in our case The decision

to drop a layer because of local shortage of CPU power is good in itself and does not

signi�cantly a�ect the performance of the protocol Except for the period of time be

tween ��� and ��� seconds� the receiver is constantly subscribed to the ideal number

of layers

Page 91: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing the

One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under the One To One Basic Control Scheme

Router Rate Limit of ���kbps

Page 92: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

the One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under the One To One Basic Control Scheme

Router Rate Limit of ���kbps

Page 93: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under the One To One Basic

Control Scheme Router Rate Limit of ���kbps

Page 94: 10.1.1.26.8823

��

The large loss spike at time ��� seconds� see Fig ��� is ignored because the basic

scheme ignores the �rst packet loss report after a join

Under the basic control scheme� consecutive join experiments are separated by

at least two epochs �� seconds� and the reaction to packet losses is delayed by an

average of �� seconds the control algorithm is run once every � seconds� In Fig ���

the receiver requires �� seconds to get to subscription level � having added a layer

to get to subscription level � shortly after the start of the experiment Furthermore�

join experiments are only attempted if the AveragePacketLoss value is zero Due to

the progressive update of that value� the protocol is slowed down some more

Figs �� �� show the data obtained from testing the basic control scheme at a

router rate limit of ���kbps Figs �� and �� show the ideal and observed subscription

level sample paths Figs �� and �� show the ideal and measured bandwidth usage

Fig �� shows the packet losses measured at the receiver during the broadcast of the

test sequence

We expected the receiver to perform poorly at this rate limit The target band

width rate for the enhanced PARC algorithm at �level �� is ���kbps The rate for

level � exceeds ���kbps intermittently� and the control protocol would have to be able

to react very quickly in order to achieve the �ideal� subscription levels at all time

Occasional packet losses at subscription level � due to CPU pegging complicate the

issue even further Fig �� shows that the user�s ideal control scheme should have very

quick response times during time periods ��� ��� and ��� ��� seconds These peri

ods of high variability can cause the receiver�s level � join timer to be multiplicatively

increased because join experiments in those periods fail Add and drop actions under

the one to one basic scheme are separated by at least �� seconds � RTCP intervals�

because the �rst loss report after a join�drop action is ignored

Page 95: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing the

One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under the One To One Basic Control Scheme

Router Rate Limit of ���kbps

Page 96: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

the One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under the One To One Basic Control Scheme

Router Rate Limit of ���kbps

Page 97: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under the One To One Basic

Control Scheme Router Rate Limit of ���kbps

Page 98: 10.1.1.26.8823

��

Fig �� shows subscription levels that are mostly lower than the ideal distribution

as we expected The same explanation applies when we compare the bandwidth

received to the ideal bandwidth distribution Figs �� ���

Between seconds ��� and ��� in Fig ��� transient packet losses of unknown

origin occur These losses might be caused by a transient over�ow of the multicast

packet distribution queue at the router The packet losses cause a sub optimal drop

to level � at ��� seconds in Fig �� and then a further drop to level � at ��� seconds

Corresponding low bandwidth usage can be observed in Fig �� during the same time

period

Note that failed join experiments cause packet losses over at least thirteen seconds

as can be seen in Fig �� at seconds ���� ���� ���� and ��� If a join experiment causes

congestion� the basic one to one scheme drops the o�ending layer after two epochs

packet loss reports over the �rst epoch after a drop or join are ignored� Packet

losses cease three seconds after the o�ending layer is dropped causing a total delay of

thirteen seconds� the additional three second delay is caused by the LeaveExpireT ime

delay at the router

Figs �� �� show the data obtained from testing the basic control scheme at a

router rate limit of ���kbps Figs �� and �� show the ideal and observed subscription

level sample paths Figs �� and �� show the ideal and measured bandwidth usage

Fig �� shows the packet losses measured at the receiver during the broadcast of the

test sequence

Comparing the ideal subscription sample path Fig ��� to the receiver�s actual

sample path Fig ���� and the ideal subscription bandwidth Fig ��� to the actual

received bandwidth Fig ��� indicate visually that the protocol has performed very

well

Page 99: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing the

One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under the One To One Basic Control Scheme

Router Rate Limit of ���kbp

Page 100: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

the One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under the One To One Basic Control Scheme

Router Rate Limit of ���kbps

Page 101: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under the One To One Basic

Control Scheme Router Rate Limit of ���kbps

Page 102: 10.1.1.26.8823

��

In particular� the actual and ideal subscription sample paths follow the same

general outline� subscription at level � during the time period � ��� seconds� a drop

to level � at time ��� seconds� a return to level � at time ��� seconds� and similar

behavior during the rest of the experiment

Packet losses are frequent as can be seen in Fig �� These are due to actual

packet drop at the router since the receiver is seldom at subscription level � As

noted in the ���kbps router limit case� every failed join experiment under the basic

one to one scheme causes a period of congestion of thirteen seconds at the router

Figs �� �� show the data obtained from testing the basic control scheme at a

router rate limit of ��kbps Figs �� and �� show the ideal and observed subscription

level sample paths Figs �� and �� show the ideal and measured bandwidth usage

Fig �� shows the packet losses measured at the receiver during the broadcast of the

test sequence

As stated in Section B� the rate limit on the small Y band layer was set to

��kbps Earlier results Section D of Chapter III� had shown that the rate on the

small UV band layer was highly correlated to its Y band counterpart The rate on

small Y band plus small UV band is nearly constant at around ��kbps except when

very low motion in present as in the �rst ��� seconds of the video sequence� In this

case adding the medium Y band layer would take the overall bandwidth used beyond

��kbps Thus we ideally expect the receiver to subscribe at level � after the �rst two

minutes of the sequence

Page 103: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ��kbps Testing the

One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under the One To One Basic Control Scheme

Router Rate Limit of ��kbps

Page 104: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ��kbps Testing

the One to One Basic Control Scheme

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under the One To One Basic Control Scheme

Router Rate Limit of ��kbps

Page 105: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under the One To One Basic

Control Scheme Router Rate Limit of ��kbps

Page 106: 10.1.1.26.8823

��

Fig �� shows a behavior identical to what we expected After the initial low

motion part of the sequence time period � to ��� seconds�� and except for a small

glitch between seconds ��� and ���� the receiver is subscribed at level � and carries

out periodic join experiments at the maximum timer interval set to �� seconds ��

RTCP intervals� Again� as in all previous cases� we can see that every failed join

experiment causes a thirteen second period of congestion in Fig ��

� Performance Metrics

Table XV shows the performance of the basic control scheme for each bandwidth

limit case When compared to the ideal case� the protocol fares well in terms of

bandwidth usage except when the rate limit is set to ���kbps� which is the case we

discussed earlier in the graphical data analysis� even then� the protocol performs at

��� Otherwise� the protocol�s performance varies between ��� and ���

The e�ciency in terms of bandwidth use varies between ��� and ��� The

bandwidth usage is acceptable Higher bandwidth usage can be obtained by either

having additional evenly spaced layers� or by using some kind of receiver feedback

control scheme to adapt each level�s bandwidth usage at the source to an optimal

value if such a bandwidth control mechanism is available to the layer�

The drawback in using the basic one to one scheme is the high packet loss caused

by failed join experiments Since an increase in the level of subscription means a much

higher bandwidth consumption� failed join experiments cause high packet losses In

the case of the ��kbps rate limit for example� failed join experiments can increase the

bandwidth demand from ��kbps at level �� to possibly more than ���kbps at level

� The low value of the maximum join timer �� seconds� means that congestion

will occur every �� seconds for a period of �� seconds The ���� loss ratio at rate

limit ��kbps is explained by the fact that the lost data bit count during congestion is

Page 107: 10.1.1.26.8823

��

Table XV Performance of the Basic Control Scheme

R ! Rate Limit kbps� ��� ��� ��� ��� ��

Cr ! Cumulative Received

Bit Count kbits�

������ ����� ����� ����� �����

Ci ! Cumulative Ideal Bit

Count kbits�

������ ������ ����� ����� �����

Cl ! Cumulative Lost Bit

Count kbits�

����� ����� ����� ����� �����

Performance CrCi ���� ���� ���� ���� ����

E�ciency CrR � Ttotal� ���� ���� ���� ���� ����

Loss Ratio ClCr Cl� ���� ���� ���� ���� ����

Mean of CPD seconds� ��� ��� ��� ��� ���

Standard Deviation of CPD

seconds�

��� ��� ��� ��� ���

Mean of CPI seconds� ���� ���� ���� ���� ����

Page 108: 10.1.1.26.8823

��

very high when compared to the cumulative delivered data bit count The protocol

performs poorly in terms of packet loss at subscription levels ���kbps loss ratio of

������ ���kbps loss ratio of ������ and ���kbps loss ratio of �����

The average CPD is approximately � seconds with a standard deviation of about

� seconds for rate limits of ���� ���� and ��kbps The average CPD values in the

���kbps and ���kbps cases are smaller because small congestion periods caused by

CPU pegging are averaged in with actual router congestion periods The average

CPD and its standard deviation are a measure of the latency of the protocol to react

to packet loss added to the pruning delay at the router

The mean value of the CPI indicates that a receiver will spend ��� seconds

on average between loss periods This value is quite high considering that a join

experiment is attempted in the absence of packet loss at least once every �� seconds

In conclusion� the results show that the basic control scheme has an unsatisfac

tory performance because of its high cumulative bit loss ratio

F RLM Results

The RLM control protocol was added to CafeMocha It was tested using the testbed

topology used by Brown ��� and described in Section A of this chapter

RLM deems a join experiment a failure if a single packet loss is measured during

a period equal to the detection timer after the join experiment Early tests showed

that most join experiments were accompanied by packet losses at the receiver The

origin of the packet losses were not clear to us� we speculate that new layers add an

instantaneous increase in demand on CPU power at the receiver�s machine prompting

some momentary packet loss A small change was made to the way RLM works�

the �rst loss report after a join experiment is ignored The change stabilized join

Page 109: 10.1.1.26.8823

��

experiments without any signi�cant delay in the recognition of failed join experiments

After RLM drops a layer that causes congestion� packet losses occur for a subsequent

period of three seconds due to the LeaveExpireT ime in the mrouted daemon

Table XVI gives the values of RLM constants �rst listed in Table XI Time

is counted in milliseconds The parameter values chosen are the ones suggested by

McCanne ���

Again� we do not worry about protocol synchronization problems that can occur

when several receivers are running simultaneously In the actual RLM speci�cation�

timers are randomized around their chosen values

The add timers "T kJ � and the detection timer sample deviation "�D� were initial

ized to the add timers� minimum value "TminJ � The detection timer sample mean

"TD� was initialized to two times the add timers� minimum value � � "TminJ �

Table XVI Values Chosen for the Parameters Controlling RLM

Parameter Description Value

� Join timer backo� constant � �� ��

� Join timer relaxation constant � �� ��

"TminJ Minimum join timer interval ����ms

"TmaxJ Maximum join timer interval �����ms

k�� k� Detection time estimator scaling terms �� �

g�� g� Detection time estimator �lter constants �������

Threshold Threshold used in making drop decision ��

The protocol was tested under the same rate limits used previously for the basic

control scheme The �When Harry Met Sally� test sequence was broadcast under

router rate limits of ���kbps� ���kbps� ���kbps� ���kbps and ��kbps Note that the

Page 110: 10.1.1.26.8823

��

ideal distributions calculated in the basic scheme�s case are no longer valid because of

slight di�erences in the source output rate during di�erent runs We will follow the

analysis methodology used for the basic control scheme with a graphical data analysis

followed by a performance analysis through the computed metrics

� Graphical Data Analysis

A ���kbps rate limit does not cause any packet loss� the receiver should add layers

quickly and get to subscription level � Figs �� �� show the obtained data Figs ��

and �� show the ideal and observed subscription level sample paths Figs �� and

�� show the ideal and measured bandwidth usage Fig �� shows the packet losses

measured at the receiver during the broadcast of the test sequence

The occasional packet losses in Fig �� are caused by CPU pegging at receiver

VCSun� Note that at second ��� in Fig �� the large packet loss spike is ignored

because the RLM receiver moves into a hysteresis state when losses are �rst encoun

tered In our case� a receiver can stay in the hysteresis state for up to ten seconds�

ten seconds is the observed average value of the detection timer RLM performed

much better than the basic control scheme when faced with transient packet losses

due to CPU pegging The small glitch starting at time ��� seconds lasts for only

�� seconds This is a huge improvement on the basic scheme whose response was to

drop one extra layer and stay below the ideal subscription level for approximately ��

seconds

RLM has a distinct advantage over the basic control scheme in that it is an event

driven protocol RLM can react instantly to loss events� it can add layers quicker �

layers are added initially at �� second intervals�� and can react instantly when the

addition of a layer causes packet loss

Page 111: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under RLM Router Rate Limit of ���kbps

Page 112: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under RLM Router Rate Limit of ���kbps

Page 113: 10.1.1.26.8823

��

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under RLM Router Rate

Limit of ���kbps

Page 114: 10.1.1.26.8823

��

Figs �� �� show the data obtained from testing RLM at a router rate limit of

���kbps Figs �� and �� show the ideal and observed subscription level sample paths

Figs �� and �� show the ideal and measured bandwidth usage Fig �� shows the

packet losses measured at the receiver during the broadcast of the test sequence

Again� for the same reasons listed when describing the performance of the basic

scheme under a rate limit of ���kbps� we expect the receiver to perform poorly The

target rate of the bandwidth for the enhanced PARC algorithm at �level �� is ���kbps

The rate for level � exceeds ���kbps intermittently� the control protocol would have

to be able to react very quickly in order to achieve the �ideal� subscription levels

at all times Occasional packet losses at subscription level � due to CPU pegging

complicate the issue even further Fig �� shows subscription levels that are for the

most part lower than the ideal distribution as we expected in the above paragraph

The same applies when we compare the bandwidth received to the ideal bandwidth

distribution Figs �� ��� Between time values ��� and ���� we can see how failed join

experiments cause the join timer to be repeatedly doubled When the join experiment

succeeds at time value ���� the join timer of the new layer is already large enough

so that the receiver only gets to its ideal subscription level at around time value ���

This is typical of the behavior of RLM and of any receiver which does not know the

exact available bandwidth Under the circumstances� RLM performs well

In contrast to the one to one scheme� failed join experiments cause packet losses

during only three seconds The o�ending layer is dropped instantly� not after ten

seconds as in the case of the basic scheme Packet losses over the experimental

layer do not a�ect our receiver The measured packet loss percentages after failed

join experiments as in Fig �� at seconds ���� ���� ���� ���� ���� ��� and ����

are measured over the subscription level that precedes and follows the failed join

experiment

Page 115: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under RLM Router Rate Limit of ���kbps

Page 116: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under RLM Router Rate Limit of ���kbps

Page 117: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under RLM Router Rate

Limit of ���kbps

Page 118: 10.1.1.26.8823

���

Figs �� �� show the data obtained from testing RLM at a router rate limit of

���kbps Like the basic scheme earlier� RLM performs well under this rate limit

Figs �� and �� show the ideal and observed subscription level sample paths Figs ��

and �� show the ideal and measured bandwidth usage Fig �� shows the packet losses

measured at the receiver during the broadcast of the test sequence

Comparing the ideal subscription sample path Fig ��� to the receiver�s actual

sample path Fig ���� and the ideal subscription bandwidth Fig ��� to the actual

received bandwidth Fig ��� indicate visually that the protocol performed very well

As in the basic scheme�s case under a rate limit of ���kbps� the actual and ideal

subscription sample paths follow the same general outline� subscription at level �

during the time period � ��� seconds� a drop to level � at time ��� seconds� a return

to level � at time ��� seconds� and similar behavior during the rest of the experiment

Packet losses are not as frequent as in the case of the basic scheme RLM reacts

much faster to failed join experiments as can be seen in Fig �� Packet losses after a

failed join experiment last for only three seconds after the instantaneous drop by the

receiver of the o�ending layer The three second packet loss period is much better

than the thirteen second packet loss period that follows a failed join experiment when

the receiver is controlled by the basic scheme

Page 119: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under RLM Router Rate Limit of ���kbps

Page 120: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ���kbps Testing

RLM

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under RLM Router Rate Limit of ���kbps

Page 121: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under RLM Router Rate

Limit of ���kbps

Page 122: 10.1.1.26.8823

���

Figs �� �� show the data obtained from testing RLM at a router rate limit of

��kbps Figs �� and �� show the ideal and observed subscription level sample paths

Figs �� and �� show the ideal and measured bandwidth usage Fig �� shows the

packet losses measured at the receiver during the broadcast of the test sequence

As we stated when studying the same case under the basic scheme protocol� the

rate on the small Y band layer plus the small UV band layer subscription level ���

is nearly constant at around ��kbps except when very low motion in present as in

the �rst ��� seconds of the video sequence� In this case adding the medium Y band

layer would take the overall bandwidth used beyond ��kbps Thus we ideally expect

the receiver to subscribe at level � after the �rst two minutes of the sequence

Fig �� shows a behavior almost identical to what we expected After the initial

low motion part of the sequence time period � to ��� seconds�� the receiver is carrying

a join experiment at level �� its experiment fails and the receiver drops from level �

to level � after a hysteresis period After time value ���� the receiver is subscribed at

level � and carries out periodic join experiments at the maximum timer interval set

to �� seconds Note that occasional packet losses� when a receiver is in the steady

state� reset the join timer This explains why the join experiments are not evenly

spaced after time value ���

Fig �� shows typical steady state behavior of RLM When faced with packet

losses in the steady state� an RLM receiver moves into the hysteresis state and ignores

all packet losses for a period of time equal to the detection timer in our case about

ten seconds� Between seconds ��� and ���� our receiver drops from subscription level

� to subscription level � Packet loss percentages as high as ��� are momentarily

ignored for ten seconds before causing a layer drop A possible improvement for RLM

is to drop a layer without going into the hysteresis waiting period when packet losses

are higher than a threshold of ��� over two seconds for example

Page 123: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Ideal Subscription Levels under a Router Rate Limit of ��kbps Testing RLM

0 100 200 300 400 500 600 7000

1

2

3

4

5

time(seconds)

Leve

l

Fig �� Actual Receiver Subscription under RLM Router Rate Limit of ��kbps

Page 124: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Ideal Bandwidth Distribution under a Router Rate Limit of ��kbps Testing

RLM

0 100 200 300 400 500 600 7000

50

100

150

200

250

300

350

400

450

500

time(seconds)

Rat

e(K

bps)

Fig �� Observed Bandwidth Received under RLM Router Rate Limit of ��kbps

Page 125: 10.1.1.26.8823

���

0 100 200 300 400 500 600 7000

10

20

30

40

50

60

70

80

90

100

time(seconds)

Per

cent

age

of P

acke

ts L

ost o

ver

1 se

cond

Fig �� Actual Packet Losses Recorded at the Receiver under RLM Router Rate

Limit of ��kbps

Page 126: 10.1.1.26.8823

���

� Performance Metrics

Table XVII shows the performance of RLM for each bandwidth limit case When

compared to the ideal case in terms of cumulative bandwidth performance� the pro

tocol fares well except when the rate limit is set to ���kbps which is the case we

discussed earlier� even then� the protocol performs at ��� Otherwise� the protocol�s

performance varies between ��� and ����

Table XVII Performance of RLM Protocol

T !Rate Limit kbps� ��� ��� ��� ��� ��

Cr ! Cumulative Received Bit

Count kbits�

������ ����� ����� ����� �����

Ci ! Cumulative Ideal Bit Count

kbits�

������ ������ ����� ����� �����

Cl ! Cumulative Lost Bit Count

kbits�

���� ���� ���� ���� ����

Performance CrCi ���� ���� ���� ���� ����

E�ciency CrR � Ttotal� ���� ���� ���� ���� ����

Loss Ratio ClCl Cr� ���� ���� ���� ���� ����

Mean of CPD seconds� ��� ��� ��� ��� ���

Standard Deviation of CPD sec

onds�

��� ��� ��� ��� ���

Mean of CPI seconds� ���� ���� ���� ���� ����

The e�ciency in terms of bandwidth use varies between ���� and ���� This

suggests that more evenly spaced layers or extra rate adaptation schemes are needed

if good usage of the available bandwidth is sought

Page 127: 10.1.1.26.8823

���

RLM shows a signi�cant improvement over the basic scheme when we look at the

cumulative loss ratio At all rate limits� the loss ratio of RLM is much better than

that of the basic one to one scheme The maximum loss ratio is of ���� compared

to ���� in the basic one to one scheme under the same rate limit of ��kbps

The average CPD is of about �� seconds with a standard deviation of about ��

seconds as is the case for rate limits of ���� ���kbps The average CPD values in the

���kbps and ���kbps cases are smaller because small congestion periods caused by

CPU pegging are averaged in with actual router congestion periods More scattered

small packet losses in the ���kbps case meant that congestion periods were smaller and

the CPI was larger than their counterparts in the basic one to one case The average

CPD value for the ��kbps case is unusually large because of one large congestion

period occurring between time values ��� and ��� in Fig �� Again� the average

CPD and its standard deviation are a measure of the latency of the protocol to react

to packet loss added to the pruning delay at the router RLM reacts faster than the

basic scheme to packet loss events

The mean value of the CPI indicates that a receiver will spend ��� seconds

on average between loss periods This value is quite high considering that a join

experiment is attempted in the absence of packet loss at least once every �� seconds

This metric shows a ��� improvement over the basic scheme

In conclusion� RLM signi�cantly betters the performance of the basic control

scheme It shows excellent performance when the layers are moderately bursty ���

at ���kbps� ��� at ���kbps� and ��� at ��kbps�� and acceptable performance when

the source has a bursty behavior ��� at ���kbps� Its loss ratio is as low as �� in

the typical cases of rate limits of ���kbps and ���kbps The high loss ratio at ��kbps

is mainly due to the slow layer drop mechanism of RLM in steady state even when

faced by ��� packet losses� even then� it is signi�cantly better than the ���� loss

Page 128: 10.1.1.26.8823

���

Fig �� Small Y band Layer� ���x��� greyscale� Level �

ratio of the basic one to one scheme in the same conditions

G Qualitative Description of the Perceived Image

We �rst describe the general look and feel of each subscription level then describe the

perceived picture quality when a rate control algorithm is run

� General

Since the CafeMocha encoder truncates the four lower bits of the data in each color

band datum� we expected scenery that has many shades of the same color to be

rendered poorly and scenery with high contrast to be rendered well� experimental

visual appraisal con�rmed our intuition

At subscription level �� a subscribed user receives Y band update blocks of the

base ���x��� frame under a rate limit of ��kbps Picture updates of successive

portions on the screen can substantially degrade the perceived image if very high

motion is present This problem is particularly obvious when the background of the

Page 129: 10.1.1.26.8823

���

Fig �� Small and Medium Y band Layers� ���x��� greyscale

image changes and most blocks are updated On the other hand� if reasonably low

motion is exhibited� as in the case of a talking head scene� the received picture has

an acceptable quality Fig �� shows how movement can cause successive parts of the

receiver�s frame to be updated at subscription level �

Subscription level � adds color to the blocks updated at subscription level � The

same comments can be made The picture is clearer through the presence of colors

At subscription level �� Y band information for the whole frame is updated�

whereas� only the color information for the blocks updated at level � is refreshed

This leads to a degradation in the perceived quality when some blocks whose Y band

data is updated exclusively have the wrong colors We noticed that in scenes where

the background is stable� most blocks tended to have the correct colors On the other

hand� when the camera moved some color discrepancies were obvious

At subscription level �� all Y band and color information are received for the

base ���x��� color picture with good perceived quality Fig �� shows the greyscale

version of level �

Page 130: 10.1.1.26.8823

���

Fig �� Small� Medium and Large Y band Layers� ���x��� greyscale

At subscription level �� di�erence blocks are received A ���x��� picture is

reconstructed� the color information of the base picture is upsampled to cover the

larger frame Fig �� shows the greyscale ���x��� frame reconstructed when the

receiver decodes all the Y band layers

� Real Time Layer Add�Drop

As was shown in the previous sections� the basic control scheme causes higher packet

loss than RLM The basic scheme also took more time to drop an o�ending layer and

continued displaying at the o�ending layer�s level of visualization for �� extra seconds

In practice� the visual quality under the basic scheme su�ered highly under packet

Page 131: 10.1.1.26.8823

���

loss Since no layer prioritization mechanism was used� some ghosting was observed

when pyramidal blocks where updated without a corresponding refresh of their base

block counterparts On the other hand� RLM reacted much quicker to packet losses

and the visual quality of the rendered picture was much better

Going up from level � to � brings full ���x��� Y band updates to the displayed

picture Perceived picture quality is much better although it might be a good idea

to display Y band information uniquely in high motion scenes This was always a

dilemma when choosing a layer add�drop order� would it be better to add progressive

color updates small UV band layer� followed by the total update of color informa

tion small UV band and medium UV band layers�� or to add the two base color

layers simultaneously after adding the two base Y band layers� We chose the current

add�drop layer order to maximize the number and the bandwidth distribution of the

subscription levels

Going up from level � to � had little noticeable e�ect in still background scenes

but gives a much better rendition of the frame in higher motion scenes

Perceived image quality at size ���x��� is much higher than that of a ���x���

picture Going up from level � to level � increases the perceived quality of the picture

considerably

Page 132: 10.1.1.26.8823

���

CHAPTER VI

CONCLUSION AND FUTURE WORK

We have developed a �exible � layer codec and tested a distributed control protocol

to control multilayered multimedia sessions CafeMocha� the videoconferencing tool

developed by Sazzad and Brown at Texas A�M� was enhanced from a two layer codec

to a six layer codec Additional layers were created by splitting the previous base layer

data into two layers giving us a total of three black and white layers� small� medium

and large A receiver can choose between a ���x��� pixel frame partially refreshed

under a small layer rate limit chosen at the source� a fully refreshed ���x��� pixel

frame picture� or a ���x��� pixel frame size if he subscribes to all three layers We then

added color data corresponding to each black and white layer over three additional

layers A receiver can enhance the previous de�ned black and white resolutions by

adding color data layers In our tests we chose the following join layer order� start

with the small black and white layer� then add its color counterpart� add the medium

black and white layer� then add its color counterpart� add the large black and white

layer� then add its color counterpart Layer drop actions are done in reverse order

from the join order

A basic control scheme� which is a simpli�ed version of the Receiver driven Lay

ered Multicast protocol RLM� proposed by McCanne was devised� developed� imple

mented and tested RLM was also implemented� and tested Our tests were carried

out in a one to one testbed con�guration� however� CafeMocha can be run in a one

to many environment with full RLM support

New metrics were de�ned whereby layer control scheme subscription paths are

compared to the �ideal� layer subscription sample path under the same rate limits

RLM performance values of ���� in comparison to the �ideal� case were recorded

Page 133: 10.1.1.26.8823

���

when the overall received bit rate was nearly constant The performance was still good

at ��� when the ideal highest subscription layer was bursty Cumulative packet loss

ratios as low as �� were recorded in bursty conditions RLM was found to be a good

control mechanism for moderately bursty layered streams The basic control scheme

performed well in terms of received bandwidth usage but had an unacceptable loss

ratio that could exceed ��� in bursty conditions

A subject of future research is the control of layer rates within each stream The

bandwidth allocated for the small layer and the bandwidth allocated for the whole

stream can be changed at will Feedback from receivers can be used to control the

target rate of the small Y band layer and the target rate of the Enhanced PARC

algorithm described in Section G of Chapter III

Prioritizing the base layers small and medium grayscale� would make sessions

more resilient to transient packet losses before adaptation takes place� However�

prioritization con�icts with the scalability of RLM ��� One possible solution is to use

more active communication between receivers In addition to announcing join exper

iments� receivers can also announce the outcome of their join experiments Control

messages should not be allowed to �ood the network One possible solution might be

to give inter communication packets a small time to live � or � hops� Receivers can

alternatively try to identify other users who are experiencing the exact same network

conditions similar patterns on packet losses per layer� These receivers can then

cluster together and bene�t from individual member join experiments

In this research� we have selected a pre de�ned join�drop layer order when adding

and dropping layers As shown in Table ��� a user can enhance the quality of its

received picture by either going to the right increasing the quality of the UV band

data�� or by going down increasing the quality of the Y band data� An interesting

area for future research is the development of the layer control stream to take into

Page 134: 10.1.1.26.8823

���

account the multiple join�drop options available to receivers

In conclusion� regular RLM appears to cope well with bursty layers It per

formed well in most of our tests and showed loss ratios as low as �� in typical bursty

conditions

Page 135: 10.1.1.26.8823

���

REFERENCES

��� H Eriksson� �MBONE� The multicast backbone�� Communications of the ACM�

vol ��� pp ��#��� Aug ����

��� Vxtreme Inc� website at wwwvxtremecom� Internet� accessed Aug ��� ����

��� T Brown� �A layered multicast packet video system�� MS� Texas A�M Uni

versity� May ����

��� C G Schroeder� �Increased network e�ciency for variable video streams in an

integrated services packet network environment�� MS� Texas A�M� May ����

��� S Sazzad� �Design of a three resolution coder�� MS� Texas A�M University�

Dec ����

��� T B Brown� P E Cantrell� and J D Gibson� �Multicast layered video telecon

ferencing� Overcoming bandwidth heterogeneity�� in Proc� First Annual Tele�

com� Conf�� pp ���#���� Austin� TX� Oct ����

��� T Brown� S Sazzad� C Schroeder� P Cantrell� and J Gibson� �Packet video for

heterogeneous networks using CU SeeMe�� in Proc� ICIP���� pp �#��� Lausanne�

Switzerland� Sep ����

��� S McCanne� V Jacobson and M Vetterli� �Receiver driven layered multicast��

in Proc� SIGCOMM ���� pp ���#���� Stanford� CA� Aug ����

��� S McCanne� �Scalable compression and transmission of Internet video��PhD

dissertation� University of California at Berkeley� Berkeley� CA� Dec ����

���� S Deering� �IP multicast and the MBone� Enabling live� multiparty� multimedia

communication on the Internet�� talk given at CERN� Geneva� Feb ����

Page 136: 10.1.1.26.8823

���

���� H Schulzrinne� S Casner� R Frederick� V Jacobson� �RTP� A transport protocol

for real time applications�� Internet Request for Comments� Jan ����� available

at http���dsinternicnet�rfc�rfc����txt� Internet� accessed Aug ��� ����

���� B Braden� L Zhang� S Berson� S Herzog� S Jamin� �Resource reservation

protocol RSVP� Version � functional speci�cation�� ACT Working Group� In

ternet Draft� Dec ����� available at ftp���ftpietforg�internet drafts�draft ietf

rsvp spec ��txt� Internet� accessed Aug ��� ����

���� R Cogger� CU SeeMe� Cornell University Software available at ftp���cu

seemecornelledu� Internet� accessed Aug ��� ����

���� Ron Frederik� Network Video� Xerox Palo Alto Research Center Software avail

able at ftp���ftpparcxeroxcom�pub�net research� Internet� accessed Aug ���

����

���� Thierry Turletti� INRIA Video Conferencing System� Institut National

de Recherche en Informatique et en Automatique Software available at

http���wwwinriafr�rodeo�ThierryTurletti�ivshtml� Internet� accessed Aug ���

����

���� Van Jacobson and Steven McCanne� Visual Audio Tool� Lawrence Berkeley Lab

oratory Software available at ftp���ftpeelblgov�conferencing�vat� Internet� ac

cessed Aug ��� ����

���� Steven McCanne� Video Conferencing Tool� Lawrence Berkeley Laboratory

Software available at ftp���ftpeelblgov�conferencing�vic� Internet� accessed

Aug ��� ����

Page 137: 10.1.1.26.8823

���

���� D Ferrari� �Client requirements for real time communication services�� IEEE

Comm� Mag� � vol ��� pp ��#��� Nov ����

���� Madhu Sudan and Nachum Shacham� �Gateway based approach for conduct

ing multiparty multimedia sessions over heterogeneous signaling domains��

Technical Report� Computer Science Laboratory� SRI International� available

from http���wwwcslsricom�reports�postscript�csl �� ��ps� Internet� accessed

Aug ��� ����

���� Elan Amir� Steven McCanne� and Hui Zhang� �An application level video gate

way�� in Proc� ACM Multimedia ���� pp ���#���� San Francisco� CA� Nov ����

���� S Deering� �Internet multicast routing� State of the art and open research is

sues�� MICE Seminar� Stockholm� Oct ��� ����

���� M Speer� S McCanne� �RTP usage with layered multimedia streams�� Internet

Draft� Dec ��� ����� available at ftp���ftpietforg�internet drafts�draft speer

avt layered video ��txt� Internet� accessed Aug ��� ����

���� D Waitzman� C Partridge� S Deering� �Distance vector multicast rout

ing protocol�� Internet Request for Comments� Nov ����� available from

http���dsinternicnet�rfc�rfc����txt� Internet� accessed Aug ��� ����

���� S Deering� R Hinden� �Internet protocol� version � IPv�� speci�

cation�� Internet Request for Comments� Dec ����� available from

http���dsinternicnet�rfc�rfc����txt� Internet� accessed Aug ��� ����

���� S Y Cheung� M Ammar� and X Li �On the use of destination set grouping

to improve fairness in multicast video distribution�� in Proc� INFOCOM ���

pp ���#���� San Fransisco� Mar ����

Page 138: 10.1.1.26.8823

���

���� IP Multicast Initiative Web Page� located at� http���wwwipmulticastcom� In

ternet� accessed Aug ��� ����

���� �Encoding parameters of digital television for studios�� CCIR Rec ��� ���� Rec�

ommendations of the CCIR� vol XI� Part �� pp ��#���� ����

���� Internet Requests for Comments RFCs� available at

http���dsinternicnet�rfc�rfcnnnntxt� Internet � where nnnn is the RFC

number� accessed Aug ��� ����

���� IETF Internet Drafts available from ftp���ftpietforg�internet drafts�� Internet�

accessed Aug ��� ����

���� IPNG Working Group Meeting� ��th IETF Proceedings� April ����� Mem

phis� TN� Report available from ftp���ftpietforg�ietf�ipngwg�ipngwg minutes

��aprtxt� Internet� accessed Aug ��� ����

���� MBONE Mailing List� archive available at

ftp���ftpisiedu�mbone�mbonemail$� Internet� accessed Aug ��� ����

���� �When Harry met Sally�� Columbia Pictures� Hollywood� CA ����

Page 139: 10.1.1.26.8823

���

VITA

Ralph Akram Gholmieh was born in Fort Lee Virginia in ���� He obtained

his Bachelor of Science in Electical Engineering from the Saint Joseph University at

Beirut in ���� He can be reached through his email address ralph%eetamuedu His

future address is ���� Nobel Drive &��� San Diego� California �����

The typist for this thesis was Ralph Akram Gholmieh