10.1.1.26.8823
TRANSCRIPT
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
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
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
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
v
To my parents Issaaf and Badiaa
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�
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 ��
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 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���
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 � � � � � � � � � � � � � � � ��
x
TABLE Page
XVI Values Chosen for the Parameters Controlling RLM � � � � � � � � � � ��
XVII Performance of RLM Protocol � � � � � � � � � � � � � � � � � � � � � � ���
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 � � � � � � � � � � � � � � � � � � � � � � � ��
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 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��
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 � � � � � � � � � � � � � � ��
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 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���
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 � � � � � ���
�
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�
�
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
�
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
�
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
�
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
�
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
�
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
�
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
�
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
��
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
��
� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �
����������������������������������������������������������������� 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
��
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 ���
��
� 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
��
� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �
����������������������������������������������������������������� 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
��
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
��
� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �
����������������������������������������������������������������� 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
��
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�
��
� � � �� � � � � � � � � � � � � � � � � � � � � � � � � �
����������������������������������������������������������������� 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
��
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
��
stream spans exactly the subnets where receivers are located
��
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
��
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
��
� 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
��
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
��
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���
��
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�
� ��� ��� ���
�� ��� ��� ���
�� ��� ��� ���
�� ��� �� ���
�� ��� �� ���
��
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
��
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 �
��
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�
� ����� ����� ���� �����
� ����� ����� ��� �����
� ���� ����� ��� �����
� ���� ���� ��� �����
� ���� ���� ��� �����
� ���� ���� ��� �����
� ���� ���� ��� ����
� ���� ��� ��� ����
�� ���� ��� ��� ����
�� ���� ��� ��� ����
�� ��� ��� ��� ���
��
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
��
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
��
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 �
��
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
��
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
��
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
��
>
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 �
��
������������
������������
������������
������������
������������
������������������������
������������
������������
������������
������������
������������
������������
������������
���������������
���������
����������������
������������
������������
������������
���������������
������������
���������
������������ ���
������
���������
���������
���������������������
������������
������������
������������
������������
������������
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
��
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
��
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
��
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 �
��
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
��
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
��
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
��
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
��
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
��
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 ������ ������ ����� �������
��
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 ������ ������ ����� ������
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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�
��
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
��
�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
��
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
��
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 ��
��
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 ���
��
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
��
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 ���
��
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
��
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
��
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
��
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
��
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�
��
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
��
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
��
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�
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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
��
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� ���� ���� ���� ���� ����
��
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
��
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
��
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
��
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
��
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
��
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
��
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
���
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
���
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
���
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
���
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
���
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
���
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
���
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
���
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
���
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
���
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
���
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
���
� 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
���
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
���
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
���
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 �
���
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
���
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
���
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
���
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
���
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
���
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 ����
���
���� 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 ��� ����
���
���� 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 ����
���
���� 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 ����
���
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