Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 585 (1994)

(USC DC Other)

USC Computer Science Technical Reports, no. 585 (1994)

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content An Arc hitectural Comparison of STI I and RSVP
USCCS
Dann y J Mitzel
Deb orah Estrin
Scott Shenk er
Lixia Zhang
Computer Science Dept
XeroxP AR C
Univ ersit y of Southern California Co y ote Hill Road
Los Angeles CA P alo Alto CA fmitzel estrin guscedu fshenk er lixia gparcxero xcom
Hughes Aircraft Co
USCInformation Sciences Institute
P O Bo x Admiralt yW a y
Los Angeles CA Marina del ReyCA Septem b er COMPUTER SCIENCE DEP AR TMENT
UNIVERSITY OF SOUTHERN CALIF ORNIA
LOS ANGELES CALIF ORNIA
An Arc hitectural Comparison of STI I and RSVP
Dann y J Mitzel
Deb orah Estrin
Scott Shenk er
Lixia Zhang
Computer Science Dept
XeroxP AR C
Univ ersit y of Southern California Co y ote Hill Road
Los Angeles CA P alo Alto CA fmitzel estrin guscedu fshenk er lixia gparcxero xcom
Hughes Aircraft Co
USCInformation Sciences Institute
P O Bo x Admiralt yW a y
Los Angeles CA Marina del ReyCA Septem b er Abstract
This p ap er pr esents a c omp ar ative analysis of two
r esour cer eservation pr oto c ols STII and RSVP
in supp ort of an Inte gr ate d Servic es Packet Net
work ISPN We use simulations to examine the
networkwide r esour cer e quir ements for e ach pr oto
c ol to supp ort a numb er of applic ation c ommunic ation
styles acr oss a r ange of gr oup sizes and memb ership
distributions We also pr esent a c omp arison of the
pr oto c ol fe atur es to ac c ommo date network and gr oup
memb ership dynamics
In tro duction
There has b een considerable researc h eort recen tly
in dev eloping an in tegrated services net w ork arc hitec
ture to supp ort new applications suc h as remote video
m ultim edia conferencing scien tic visualization and
virtual realit y Tw o requiremen ts of manyof these
new applications are their need for Qualityof Ser vice QoS guaran tees from the net w ork and supp ort
for m ultip oin ttom ul tip oi n t comm unications T radi
tional data net w orks based on datagram pac k et deliv
ery suc h as the TCPIP proto col suite exhibit sev
eral distinctivec haracteristics Datagram net w orks
maxim ize net w ork utilization bym ultiplexing m ulti
ple data streams can pro vide m ultip oin t comm unica
tion and pro vide robustness b y adapting to net w ork
dynamics Ho w ev er datagram net w orks pro vide only
a b esteort deliv ery service Curren t circuit switc hed
telecomm unication and ISDN net w orks pro vide service
guaran tees Ho w ev er the circuit mo del leads to inef
cien t use of net w ork resources when sending burst y
data it do es not adapt to link and router failures and
it lac ks supp ort for m ultip ointcomm unications The
goal of an In tegrated Services P ac k et Net w ork ISPN
is to merge these t w o paradigms com bining the m ulti
plexing m ultip oin t comm unicatio n and robustness of
pac k et switc hed net w orks with the service guaran tees
of the circuit switc hed mo del
Dev elopmen t of this new ISPN net w ork arc hitec
ture requires sev eral distinct comp onen ts including
a o w sp ecication dening the source trac
stream and receiv er service requiremen ts a rout
ing proto col supp orting QoS and m ulticast paths a reserv ation proto col to create and main tain resource
reserv ations an admission con trol algorithm to
main tain net w ork load at a prop er lev el and a
pac k et service algorithm to sc hedule pac k et transmis
sions in an order that main tains service guaran tees for
individual data streams
The reserv ation proto col is resp onsible for request
ing allo cation and release of net w ork resources along
the data distribution path to ensure QoS requiremen ts
are met The resulting net w ork utilization and e ciency dep ends to a great exten t on the reserv ation
proto cols service mo del and dynamic resp onse Ser
vice mo dels can b e c haracterized b y the set of comm u
nication st yles p oin ttop oin t m ultip oin t and reser
v ation st yles to con trol aggregation of reserv ations
at in termediate switc hes supp orted and b y the abil
it y to supp ort heterogeneous group mem bers The
dynamic resp onse of the reserv ation proto col can b e
c haracterized b y the supp ort for dynamic group mem
b erships and the resp onse to link and router failures
Initial w ork in supp orting m ulticast endtoend
guaran teed service within the In ternet proto col suite
resulted in the dev elopmen t of the ST stream proto
col and the later dev elopmen t of a second v er
sion of the proto col STI I whic hw as sp ecied as
an exp erimen tal proto col within the In ternet comm u
nit y A more recen t prop osal targeted at supp orting
the resource reserv ation requiremen ts of an ISPN is
the RSVP proto col The RSVP proto col is cur
ren tly in the design phase an IETF w orking group has
b een formed to ev olv e the proto col along the standard
trac k
In this pap er w e compare the op eration of the STI I
and RSVP proto cols in supp ort of applications t ypical
of an ISPN In Section w e presentan o v erview of the
t w o proto cols W e divide our comparison of the pro
to cols in to t w o distinct topics static resource require
men ts and dynamic b eha vior The static resource in
v estigation lo oks at net w ork resource requiremen ts to
supp ort a xed set of comm unicating applications o v er
a range of comm unicationst yles these results are pre
sen ted in Section In Section w e describ e the pro
to col mec hanisms for supp orting net w ork dynamics
and lo ok at the proto col o v erhead asso ciated with ac
commo dating group mem b ership dynamics Section concludes with a summary and a few commen ts on
future w ork
Proto col o v erview
A simplistic reserv ation service could b e imple
men ted on top of a p oin ttop oin t service mo del b y
establishing a separate reserv ation b et w een eac h pair
of comm unicating applications This service mo del
migh t b e sucien t if the only goal of the ISPN w as
to extend the currentIP poin ttop oin t service mo del
with QoS supp ort ho w ev er the goal of the ISPN ar
c hitecture is to pro vide ecien t supp ort for applica
tions requiring QoS supp ort and m ultip ointcomm uni
cations As w e shall see the simplistic p oin ttop oin t
reserv ation mec hanism is v ery inecien t in terms of
net w ork resource allo cation required to supp ort m ul
tip oin t comm unications
An enabling tec hnology for supp orting m ultip oin t
comm unication incorp orated in to b oth STI I and
RSVP is m ulticast routing Deering describ es ho w
m ulticast distribution can b e incorp orated in to a data
gram net w ork to impro venet w ork resource utilization
ho w ev er STI I and RSVP mak e dieren t assumptions
ab out the lev el of m ulticast supp ort pro vided bythe
net w ork STI I builds a m ulticast distribution tree
based up on unicast routing tables and p erforms the
replication and forw arding of data pac k ets RSVP is
decoupled from the m ulticast routing and data for
w arding functions it assumes they are pro vided b y
the underlying net w ork This dierence in assump
tions ab out the lev el of m ulticast supp ort pro vided b y
the net w ork is largely historical A t the time STI I w as
dev elop ed there w as no in ternet w ork m ulticast rout
ing While incorp orating m ulticast forw arding in to the
STI I proto col adds some pro cessing o v erhead it do es
not aect the resource allo cation or proto col messag
ing o v erhead and th us do es not aect our comparativ e
analysis
The m ultip oin t comm unicatio n capabilities of STI I
and RSVP pro vide impro v ed net w ork resource utiliza
tion when compared to the simplistic p oin ttop oin t
reserv ation mo del Additional gains in terms of im
pro v ed resource utilization are p ossible b y incorp orat
ing applicationlev el comm uni cation requiremen ts in to
the reserv ation service mo del In the follo wing subsec
tions an o v erview of the STI I and RSVP reserv ation
proto col and service mo del are presen ted these act as
the basis for our comparisons throughout the remain
der of the pap er It should b e emphasized that these
descriptions pro vide only a summary of the proto col
functions relev an t to the discussion F or a complete
proto col description the appropriate proto col do cu
men ts should b e consulted
STI I proto col
STI I mo dels a resource reserv ation as a sim
plex data stream ro oted at the source and extend
ing to all receivers viaam ulticast distribution tree
Stream setup is initiated when a source ST agen t gen
erates a Conne ct message listing the o w sp ecication
and initial set of participan ts Connect pro cessing at
eachin termediate ST agentin v olv es determining the
set of next hop subnets required to reac h all do wn
stream receiv ers installing m ulticast forw arding state
and reserving net w ork lev el resources along eachnext
hop subnet If the actual resource allo cation obtained
along a subnet is less than the amoun t requested then
this is noted in the Connect pac k et b y up dating the
o w sp ecication Up on receiving a Connect indica
tion a receiv er m ust determine whether it wishes to
join the group and return either an A c c ept or a R efuse
message to the stream source In the case of an Accept
the receiv er ma y further reduce the resource request
b y up dating the returned o w sp ecication
During connection setup the stream source m ust
w ait for an AcceptRefuse reply from eac h initial
receiv er b efore b eginning data transmission STI I
treats the en tire stream as a homogeneous distribu
tion path Whenev er the source receiv es an Accept
with a reduced o w sp ecication it m ust either adapt
to the lo w er QoS for the en tire stream or reject group
participation for the sp ecic receiv er bysending ita
Disc onne ct message
Group mem b ership dynamics are accommo dated
b y allo wing stream receiv ers to b e added or deleted af
ter initial stream setup Eac h addition of a receiv er re
quires an in teraction with the stream source to trigger
the sending of a Connect message This in teraction is
not dened b y the proto col sp ecication but is instead
p erformed outofband using IP As in the initial setup
the stream source m ust examine the o w sp ecication
in a returned Accept and either reduce its QoS or re
ject the new receiv er if the resources allo cated are less
than those curren tly allo cated for the stream Deletion
of receiv ers ma y b e done async hronously b y a receiv er
sending a Refuse message or the source sending a Dis
connect message the Disconnect message can either
list individual receiv ers to remo v e or set the Global
Disconnect ag to tear do wn the en tire stream
Reliabilit y and robustness are incorp orated in to the
STI I proto col via t w o separate mec hanisms First all
con trol messages used to create and manage a stream
are transmitted reliably using hopb yhop ac kno wledg
men ts with retransmission Second a Hel lo proto col
is used to query the status of neigh b oring ST agen ts
sharing activ e streams When a c hange in reac habilit y
bet w een neigh b oring ST agen ts is detected automatic
stream reco v ery ma y b e attempted
The only service mo del directly supp orted b y ST
I I is that of a homogeneous reserv ation o v er a p oin t
tom ultip oin t simplex distribution tree W ecallthis
the Indep endent Str e ams reserv ation st yle a separate
and indep enden t resource reserv ation is allo cated for
eac h distribution tree The STI I proto col sp ecica
tion denes the concept of a group of streams whic h
ma y b e useful in dening more sophisticated reserv a
tion st yles Groups can b e used to express relation
ships among individual streams or for p erforming op
erations on the group as a whole Ho w ev er the group
mec hanism is an exp erimen tal feature and no stream
relations ha v e b een dened at this time W edo not
consider the group mec hanism in an y of our analysis
RSVP proto col
RSVP is similar to STI I in that a data stream
is mo deled as a simplex distribution tree ro oted at
the source and extending to all receiv ers Ho w ev er
the mec hanisms for group sources and receiv ers to es
tablish resource reserv ations and the reserv ation st yles
supp orted dier substan tially from the STI I mo del
Under RSVP a source application b egins participa
tion in a group b y sending a Path message con tain
ingao w sp ecication to the destination m ulticast
address The P ath message serv es t w o purp oses to
distribute the o w sp ecication to the receiv ers and
to establish P ath state in in termediate RSVP agen ts
to b e used in propagating reserv ation requests to w ard
sp ecic sources RSVP do es not restrict a source from
transmitting data ev en when no receiv er has installed
a reserv ation to it ho w ev er data service guaran tees
are not enforced
Before establishing a reserv ation eac h receiv er m ust
rst join the asso ciated m ulticast group to b egin re
ceiving P ath messages This m ulticast group join op
eration is a function of the m ulticast routing pro
to col and is outside the scop e of RSVPEachre ceiv er ma y use information from P ath messages and
an y lo cal kno wledge computing resources a v ailable
application requiremen ts cost constrain ts to deter
mine its QoS requiremen ts it is then resp onsible for
initiating its o wn R eservation request message In
termediate RSVP agen ts reservenet w ork resources
along the subnet leading to w ard the receiv er then use
the established P ath state to propagate the Reserv a
tion request to w ard the group senders Reserv ation
message propagation ends as so on as the reserv ation
splices in to an existing distribution tree with suf
cien t resources allo cated to meet the requested QoS
requiremen ts This r e c eiverinitiate d
reserv ation st yle
enables RSVP to accommo date heterogeneous receiv er
requiremen ts
RSVP incorp orates a datagram messaging proto col
with p erio dic refreshes to main tain soft state
in in ter
mediate switc hes to pro vide reliabilit y and robustness
P ath refreshes automatically adapt to c hanges in the
m ulticast distribution tree and install P ath state in
an y new branc hes of the tree Reserv ation refreshes
main tain established reserv ations and incorp orate new
The receiv erinit iat ed approachw as inspired b y Deerings
w ork on m ulticast routing in whic h the receiv er is resp onsible
for initiating group mem b ership requests
Clark c haracterize s the concept of soft state in supp ort
of t yp e of service as follo ws It w ould b e necessary for the gate
w a ys to ha veo w state in order to remem b er the nature of the
o ws whic h are passing through them but the state informa
tion w ould not b e critical in main taining the desired t yp e of
service asso ciated with the o w Instead that t yp e of service
w ould b e enforced b y the end p oin ts whic hw ould p erio dicall y
send messages to ensure that the prop er t yp e of service w as
b eing asso ciated with the o w In this w a y the state informa
tion asso ciated with the o w could b e lost in a crash without
p ermanen t disruption of the service features b eing used
receiv er reserv ations This refresh based mec hanism
allo ws orphaned reserv ations and state to b e automat
ically timed out and reco v ered
RSVP mo dels a reserv ation as t w o distinct comp o nen ts a resource allo cation and a pac k et lter The
resource allo cation sp ecies what amount of resources
is reserv ed while the pac k et lter selects whic hpac k
ets can use the resources This distinction b et w een
the resource reserv ation and pac k et lter and an abil
ityto c hange the pac k et lter without c hanging the
resource allo cation enables RSVP to oer sev eral dif
feren t r eservation styles A reserv ation st yle captures
applicationlev el comm unications requiremen ts these
dictate ho w reserv ation requests from individual re
ceiv ers should b e aggregated inside the net w ork A t
the momen t RSVP has dened reserv ation st yles
these are Wildc ar d Fixe d Filterand Dynamic Fil
ter other st yles ma y b e iden tied as new m ulticast
applications with dieren t needs are dev elop ed A
Wildcard reserv ation indicates that a source sp ecic
reserv ation is not required and that anypac k ets des
tined for the asso ciated m ulticast group ma y use the
reserv ed resources This allo ws a single resource allo
cation to b e made across all distribution paths for the
group When a source sp ecic reserv ation is required
a receiv er ma y indicate whether it desires to receiv e
a xed set of sources or the abilit y to dynamically
switc h its reserv ation among the sources A Fixed Fil
ter reserv ation cannot b e c hanged during its lifetime
without rein v oking setup and admission con trol this
allo ws the reserv ation to b e shared among m ultiple
requests for the same source
The Dynamic Filter
reserv ation allo ws a receiv er to mo dify its pac k et lter
o v er time This requires that sucien t resources b e
allo cated to handle the w orst case when all receiv ers
tak e input from dieren t sources
Static analysis
The proto col descriptions in Section noted that
STI I and RSVP are similar in that they mo del a
data stream as a simplex p oin ttom ultip oi n t distribu
tion tree Ho w ev er the RSVP proto col incorp orates
heterogeneous receiv er requests and m ultiple reserv a
tion st yles pro viding additional opp ortunities to im
pro v e net w orkwide resource utilization In this sec
tion welook atsev eral applications t ypical of an ISPN
map the service mo del of the t w o proto cols to the ap
plication comm unication requiremen ts and compare
Note that while the Indep enden t Streams and Fixed Fil
ter reserv ation st yles result in equiv alen t reserv ations w euse
distinct names to distinguish the mec hanistic dierences
the net w orkwide resource requiremen ts for supp ort
ing the application
Supp orting selflimiting applications
An um ber of m ultip oin ttom ulti poin t applications
ha v e applicationlev el constrain ts that prohibit all
data sources from transmitting sim ultaneously one
example is an audio conference In an audio conference
there is t ypically only one p erson sp eaking at a time
b ecause when more than a few sp eak ers are sim ultane
ously activ e the result is usually unin telligible There
fore instead of reserving sucien t resources for ev ery
p oten tial sp eak er to transmit sim ultaneously it ma y
b e adequate to reserv e only enough resources to han
dle a few sim ultaneous audio c hannels RSVP is able
to capture these application comm unicatio n require
men ts exactly using the Wildcard reserv ation and re
questing resources for the maxim um n um ber of sim ul
taneously activ e sources STI I requires that an In
dep enden t Stream reserv ation b e established for eac h
audio source
In this section w e compare the total net w orkwide
resource allo cation to supp ort an nw a y audio confer
ence under the t w o reserv ation proto cols W emodel
a hierarc hical net w ork con taining routers in tercon
nected via links and v ary the n um b er of confer
ence participan ts from up to Eac h audio source
w as randomly distributed among the no des
and is
mo deled as a request for a Kbs PCM audio stream
Figure presen ts the total net w orkwide resources al
lo cated under the t w o reserv ation proto cols to sup
p ort audio conferences of v arious sizes F or the RSVP
Wildcard reserv ation st yle wesho w the resource re
quiremen ts when eac h participan t requests a reserv a
tion for or v oice streams w orth of bandwidth
this represen ts the limit on the n um ber of sim ultane
ous sp eak ers F or STI I w esho w the resources reserv ed
when eac h source establishes an Indep enden t Stream
to all receiv ers and net w ork links are mo deled as ha v
ing unlimited capacit y The small slop e of the RSVP plots highligh ts the
eciency in adding participan ts using the Wildcard
reserv ation st yle Resources are reserv ed only along
new links required to splice in to the distribution
mesh
As a group b ecomes more dense the group
The random placemen t function used throughout the sim u
lations selects a random order for adding participan ts to unique
no des this precludes m ultiple participan ts at a single no de un til
all no des ha v e at least one participan t Note that the total resource allo cation under Wildcard
reserv ation is based up on the union of the links in all distri
bution trees while its based up on the sum under Indep enden t
Streams
0
50000
100000
150000
200000
250000
0 10 20 30 40 50 60 70
Total Network-wide Reservation (Kb/s)
Number of Group Participants
RSVP Wildcard (1 resv)
RSVP Wildcard (2 resv)
RSVP Wildcard (3 resv)
ST-II Independent Streams
Figure Resource requiremen ts in supp ort of nw a y
audio conference
mem b ership co v ers a higher p ercen tage of the total
net w ork no des the a v erage n um b er of new links re
quired to splice in to the distribution tree decreases
resulting in a smaller o v erhead p er new mem b er In
con trast adding a participan t under the STI I mo del
requires splicing in to N existing distribution trees
and setting up an indep enden t distribution tree from
the new participan t to all existing mem b ers The dis
paritybet w een the Indep enden t Streams and Wild
card plots represen ts a resource o v erallo cation whic h
is sho wn to rapidly div erge as the group size increases
Allo cating an indep enden t resource reserv ation for
eac h STI I source eectiv ely places an upp er b ound on
the maxim um group size that can b e supp orted F or
a group of size N a participantm ust allo cate N reserv ations to receiv e from all sources In the com
mon scenario of a host at the net w ork p eriphery with
a single access link all N reserv ations m ust b e
accommo dated on the same link Making the opti
mistic assumption that the pac k et service algorithm
can main tain QoS guaran tees at link utilization
the group size is th us limited to
M aximum Gr oup S iz e B ottl eneck Link B andw idth
S ing l e S tr eam Resour ce Req uest

participan ts Rep eating the STI I sim ulations pre
sen ted in Figure with link bandwidth limited to
Mbs conrmed that resource allo cation requests
b egin to b e rejected this is termed c al l blo cking in
the telephon y literature for group sizes greater than
RSVP Wildcard reserv ations do not encoun ter
M bs
K bs
this scaling problem The maxim um resource reserv a
tion across all links is limited to the n um ber of sim ul
taneous sources requested whic h is indep endentof the
size of the group
One nal observ ation is to note that the total re
source requiremen ts of the RSVP Wildcard reserv a
tion are b ounded while STI I resource requiremen ts
are un b ounded Under RSVP once there is a partici
pantateac h net w ork no de resources for the complete
distribution mesh ha v e b een allo cated and no further
resources need to b e allo cated to accommo date addi
tional group mem bers This is eviden t in the plots
in Figure b y the zero slop e line when going from
to group participan ts STI I alw a ys requires
allo cating an indep enden t reserv ation from the new
participan t to all existing mem b ers
Supp orting heterogeneous groups
In a globalscale in ternet w ork receiv ers as w ell as
the paths used to reac h the receiv ers can ha vev ery
dieren t prop erties from one another Net w ork and
host tec hnologies are lik ely to span sev eral orders of
magnitude in terms of bandwidth and pro cessing ca
pabilities In this en vironmentit ma y not b e reason
able to assume that all receiv ers in a group p ossess the
same capacit y for pro cessing incoming data or desire
the same QoS from the net w ork Applications in v olv
ing widespread distribution services suc h as cableTV
distribution or broadcasting of an audiovideo lecture
ma y b e able to accommo date additional participan ts
b y incorp orating supp ort for heterogeneous receiv er
capabilities An application ma y emplo y a hierarc hi
cal co ding sc heme or pro vide m ultiple data streams
utilizing dieren t media enco dings to presentv arying
signal qualitylev els to the receiv ers Eac h receiv er
ma y then determine its QoS requiremen ts based on
lo cal constrain ts
STI I and RSVP accommo date heterogeneit yv ery
dieren tly Under the STI I service mo del a data
source m ust view the en tire stream as a homogeneous
distribution path After stream setup the source m ust
conform to the minim um resource allo cation forcing
all participan ts to suer with the least capable or
least demanding receiv er T o satisfy the most de
manding receiv er the source m ust allo cate the max
im um requested resources along all links RSVPs
receiv erinitiated reserv ation sc heme propagates reser
v ation requests from a receiv er up the sink tree to w ard
the source splicing in to the distribution tree This
reserv ation establishmen t pro cess reserv es the mini
m um resources on eac h link required to satisfy the
QoS requiremen ts of all do wnstream receiv ers Th us
RSVP incorp orates supp ort for heterogeneous reserv a
tions directly in the proto col in a manner transparen t
to b oth endp oin ts
In this section w e compare the total net w orkwide
resource requiremen ts to supp ort a heterogeneous mix
of receiv ers listening to an audio lecture The no de
net w ork in tro duced in Section is used again and
the lecture is mo deled as a single data source trans
mitting a high qualit y Kbs audio stream that
also con tains a subband Kbs lo w qualit y audio
stream Tw o alternativ es for supp orting this applica
tion are to send the high qualit y and lo w qualit y
comp onen ts on separate m ulticast trees or to send
the en tire data stream o v er a single m ulticast tree
Sending the en tire data stream on a single m ulticast
tree and forw arding only the comp onen ts required to
satisfy all do wnstream receiv ers pro vides the most ef
cien t supp ort of the application This is the mo del
wein v estigate
Figure sho ws the link reserv ations installed b y
RSVP to supp ort randomly selected receiv ers of
the audio lecture using a Fixed Filter reserv ation receiv ers request the full Kbs stream and re
ceiv ers request the Kbs lo wqualit y audio sub
c hannel This diagram depicts RSVPs abilit y to in
stall a heterogeneous resource reserv ation across the
data distribution tree Only those branc hes leading to
receiv ers requesting the high qualit y audio stream
require the high bandwidth reserv ation this can re
sult in signican t resource sa vings F or the scenario
illustrated only of the links in the m ulticast dis
tribution tree require a high bandwidth reserv ation
resulting in a sa vings in net w ork resource allo
cation when compared to a homogeneous distribution
tree
T able presen ts the total net w orkwide resource
requiremen ts for b oth STI I and RSVP to supp ort
the receiv er audio lecture with v arious n um bers
of lo w qualit y receiv ers The STI I stream exhibits
an allornothing eect due to the proto cols limita
tion of treating the stream as a homogeneous distri
bution path As long as there is at least one demand
ing receiv er the maxim um resources m ust b e allo cated
along all links this ensures the QoS for the demand
ing receiv ers is met Under RSVP the total net w ork
wide resources reserv ed reects the minim um allo ca
tion required along the distribution tree to satisfy all
receiv ers QoS requests As the n um ber of lo w qualit y
receiv ers increases additional branc hes in the distribu
tion tree shed their high qualit y resource reserv ation
Sp ecicati on of the mec hanisms to enco dedecode this
stream and the lter to select the subband audio are outside
the curren t discussion
Num ber of STI I RSVP
Lo w Resource Resource
Qualit y Allo cation Allo cation
Receiv ers Kbs Kbs

T able Resource requiremen ts in supp ort of re
ceiv er heterogeneous audio lecture
resulting in a gradual decrease in total net w orkwide
resource allo cation
Supp orting c hannel selection
In large m ultipart y conferences a receiv er maybe
unable to accommo date data streams from all activ e
participan ts sim ultaneously but w ould lik e the abil
it y to select dynamically a subset of the sources to
receiveat an y time This restriction on n um ber of
sim ultaneous sources ma y b e due to bandwidth lim
itations displa y or co dec hardw are or the inabilit y
of the user to assimilate information from all sources
concurren tly w e term this comm unicationst yle chan
nel sele ction F rom the users p ersp ectiv e there are
t w o p ossible service mo dels assured c hannel selection
and nonassured c hannel selection A k ey c haracteris
tic of assured c hannel selection is that once a receiv er
has established its reserv ation it should b e guaran teed
that a c hange request will not b e denied The non
assured c hannel selection mo del do es not pro vide suc h
a guaran tee and a c hange request ma y b e denied
The traditional metho d to pro vide assured c han
nel selection is to allo cate an indep enden t reserv ation
for eac h source whic h is just the Indep enden t Streams
reserv ation st yle discussed in Section The receiv er
can then switchbet w een c hannels b y selecting the de
sired incoming stream The c hannel selecting or lter
ing of incoming data is done en tirely at the receiv er
RSVP in tro duces the Dynamic Filter reserv ation
st yle whic h allo cates sucien t resources on eac h link
so that the receiv er can alw a ys select without failure
an y set of m sources where m is the maxim um n um ber
of sim ultaneous sources Once the resource allo cation
is xed a receiv er ma y dynamically mo dify the asso
ciated lter whic hc ho oses whic h pac k ets get to use
Note that in the w orst case scenario of a linear net w ork
RSVP allo cation is iden tical to the STI I case while the b est
case scenario of a fully connected net w ork yields allo cations that
are linear in the n um ber of lo w qualit y receiv ers
1
2
3
60
4
5
6
7
8 9 10 11 12 13 14
15
16
17 18
19
20
21 22 23
24
25
26
27 28 29
30 31 32 33 34 35 36 37 38 39 40
41
42
43
44
45 46 47 48 49 50 51 52 53 54 55
56 57 58
59
Low Quality Receiver
High Quality Receiver
Low BW Reservation
High BW Reservation
Data Source
Figure Link reserv ations for RSVP heterogeneous audio lecture receiv ers
that resource Th us the ltering is done within the
net w ork The actual resource allo cation on eac hlink
is limited to the maxim um n umberofnono v erlapping
reserv ations this is the sum of all do wnstream receiv er
requests limited b y the n um b er of upstream sources
The third c hannel selection alternativ e is to makea
new reserv ation ev ery time a new c hannel is selected
and then to tear do wn the old reserv ation This
pro vides the nonassured service b ecause the new re
quest ma y b e blo c k ed W e call this the Chosen Sour c e
reserv ation st yle since it only reserv es for the curren tly
c hosen sources Resources are reserv ed along the dis
tribution tree from eac h source to the set of receiv ers
that are curren tly tuned in to that source and the trees
from dieren t sources are indep enden t Because the
Chosen Source reserv ation st yle reserv es for only the
curren tly selected sources it pro vides a useful lo w er
b ound for the resource consumption required byas sured service
T able presen ts the total net w orkwide resource
allo cation required byeachof the c hannel selection
mec hanisms to supp ort the participan ts of the nw a y
conference in tro duced in Section While the Cho
sen Source reserv ation st yle do es not pro vide assured
switc hing among the sources it is presen ted to quan
tify the o v erhead in the assured c hannel selection
sc hemes as indicated in the Ov erhead Ratio col
umn F or the sim ulations conducted the resource
o v erhead incurred using the Indep enden t Streams
mec hanism can b e quite substan tial and it increases as
the group size is increased The resource o v erhead in
pro viding assured c hannel selection is m uc h smaller us
ing the Dynamic Filter mec hanism most imp ortan tly for the class of graphs sim ulated the o v erhead app ears
to b e b ounded as the group size is increased
The only requiremen t on the reserv ation proto col
to supp ort the Indep enden t Streams or Chosen Source
c hannel selection mec hanism is that a xed resource
allo cation can b e established from eac h selected source
to the receiv er Both the STI I stream mo del and the
RSVP Fixed Filter reserv ation st yle pro vide this ser
vice F or the Dynamic Filter c hannel selection mec h
anism a distinction m ust b e made b et w een a resource
allo cation and the pac k et lter this distinction is cur
ren tly pro vided only b y the RSVP Dynamic Filter
reserv ation st yle
Analysis sho ws that the Dynamic Filter reserv ation st yle
uses exactly the same resources as the w orst case of the Chosen
Source reserv ation st yle and app ears to b e only a constan t fac
tor w orse than the a v erage case of the Chosen Source reserv ation
st yle
Chosen Source Dynamic Filter Indep enden t Streams
Reserv ations Reserv ations N Reserv ations
Group Resource Resource Ov erhead Resource Ov erhead
Size Allo cationKbs Allo cationKbs Ratio Allo cationKbs Ratio
T able Channel selection resource o v erhead
Dynamic analysis
In Section w e compared the resource allo cations
of the STI I and RSVP proto cols to supp ort a xed
set of group mem bers In a real large scale in ter
net w ork en vironmen t there maybe frequen t dynamic
ev en ts that m ust b e accommo dated b y the reserv ation
proto col These ev en ts include b oth net w ork dynam
ics suc h as link and router failurereco v ery and group
mem b ership dynamics participan ts join and lea vethe
m ulticast group It is extremely imp ortan t that the
group mem b ership dynamics b e supp orted ecien tly
as mem b ership c hange is exp ected to b e a common o c
currence whereas top ology c hange represen ts an ex
ceptional ev en t In this section w e describ e the ST
I I and RSVP mec hanisms for supp orting net w ork dy
namics and compare the proto col o v erhead asso ciated
with accommo dating group mem b ership dynamics
Net w ork dynamics
Section describ ed the mec hanisms incorp orated
in to the STI I and RSVP proto cols to pro vide relia
bilit y and robustness in the face of net w ork dynamics
STI I utilizes a reliable con trol message proto col and
a Hello proto col to monitor neigh b or ST agen t health
while RSVP uses a datagram con trol message proto
col in conjunction with a soft state refresh mec hanism
The dicult y in conducting a comparison of the dy
namics of the t w o proto cols is that b oth rely hea vily
on timers STI I Hello in terv al and RSVP refresh p e rio d whic hha v e a great eect on the proto col o v er
head and reco v ery p erio d and no explicit timer v alues
are mandated b y the proto col standards Instead w e
compare the design philosophies b ehind the dynamics
supp ort in the t w o proto cols
The in tegration of supp ort for net w ork dynamics in
STI I and RSVP are substan tially dieren t in terms of
b oth implem en tation and design philosoph y STI I in
corp orates a failure detection mec hanism using Hello
Status and Notify messages and these add consider
able complexit y to the proto col
In con trast RSVP
relies on the soft state refreshes to automatically adapt
without additional proto col complexit y RSVP could
b e mo died to incorp orate a failure detection mec h
anism to trigger refreshes as an optimization ho w
ev er there are more fundamen tal dierences that dis
tinguish the proto cols The k ey dierence b et w een the
t w o proto cols is in where reco v ery tak es place STI I
requires that the net w ork b e resp onsible for correct
ness b y either restoring itself or reliably con tacting the
source this leads to complex proto cols with strange
failure mo des Clark notes that systems relying on
distributed state are dicult to build and few truly
pro vide protection against failure RSVP lea v es the
nal resp onsibilit y for main taini ng reserv ations with
the ends this is consisten t with the currentIn ternet
philosoph y of fatesharing among the endp oin ts
Note that ev en in steady state no net w ork or group
dynamics there is an o v erhead asso ciated with b oth
proto cols Under STI I this o v erhead is a result of
eac h ST agen t p erio dically exc hanging one Hello mes
sage with eac h activ e neigh b or Requiring the agen tto
trac k p eers separately from streams ma y p ose a sligh t
complication in data structure organization ho w ev er
it results in a proto col that scales indep endentof the
n um b er of activ e streams Proto col o v erhead in RSVP
results from the p erio dic P ath and Reserv ation re
freshes This w ould seem to imply that RSVP o v er
head scales directly with the n um b er of participan ts
ho w ev er RSVP incorp orates a proto col o v erhead re

P artridge and Pink note that m uc h of the functionalit y
is o v erlapping

Clark c haracteriz es the fatesharing mo del as gathering
the critical state information at the endp oin t of the net in
the en tit y whic h is utilizing the service of the net w ork It is
then acceptable to lose the state informatio n asso ciated with
the en tit y if and only if the en tit y itself has failed at the same
time
duction mec hanism called merging to reduce this
o v erhead The merging pro cess insures that only a
single reserv ation message is propagated o v er a link
p er refresh p erio d With a Wildcard reserv ation there
is only a single reserv ation on eac h link for the en tire
group for a Fixed Filter reserv ation there is one reser
v ation for eac h source forw arding along a link while
a Dynamic Filter requires a separate reserv ation p er
receiv er b ounded b y the total n um b er of upstream
sources Th us RSVP proto col o v erhead scales with
the n um b er of reserv ations
Group mem b ership dynamics
Large m ulticast groups suc h as global distribution
of a conference or lecture are lik ely to encoun ter fre
quen t mem b ership dynamic ev en ts These ev en ts
are a result of participan ts tuning in to and lea ving
the conference In a correctly functioning in ternet
group mem b ership c hanges are m uc h more common
than net w ork dynamic ev en ts It is imp ortantthat
the reserv ation proto col b e able to accommo date these
mem b ership dynamics ecien tly Proto col eciency
can b e ev aluated in terms of messaging o v erhead and
latency in adapting to c hanges In this section w e
compare the proto col o v erhead for STI I and RSVP
to adapt to group mem b ership c hanges
Dynamic addition of receiv ers under STI I requires
the generation of Connect and Accept messages b e t w een source and receiv er The endtoend messaging
of STI I results in an o v erhead on eac h link prop or
tional to the n um ber of do wnstream receiv ers This
results in links closer to the source b ecoming hot
sp ots in that they incur a higher o v erhead in terms
of bandwidth and proto col pro cessing o v erhead Also
the explicit source in teraction required for ev ery group
mem b ership dynamics could result in a pro cessing b ot
tlenec k at the source
The receiv er initiated reserv ations in RSVP result
in a v ery dieren t join o v erhead mo del Assuming
homogeneous receiv ers the join o v erhead is reduced
to one proto col message on eac h link in eac h direc
tion This represen ts a single P ath message sentb y
the source to build the rev erse path state and a sin
gle reserv ation request sentbyeac h receiv er The k ey
to RSVPs reduced join o v erhead is the merging func
tion as so on as the reserv ation request splices in to an
existing distribution branc h the request can b e merged
discarded The situation b ecomes only sligh tly more
complicated when heterogeneous receiv ers are in tro
duced In this case the merging function m ust ensure
the request splices in to the distribution tree and there
are sucien t resources allo cated This ma y result in
0
10000
20000
30000
40000
50000
60000
70000
80000
0 5 10 15 20 25 30 35 40 45 50
Protocol Overhead (Bytes)
Number of Receivers
ST-II
RSVP
Figure Proto col o v erhead for indep endentgroup
joins for audio lecture
m ultiple reserv ation messages b eing propagated o v er
a link if a more demanding request is receiv ed after a
less demanding reserv ation has already b een installed
The use of receiv er initiated reserv ations and reser
v ation merging in RSVP result in t w o distinct ad
v an tages o v er the endtoend proto col of STI I First
the implosion of messages at the sender causing hot
sp ots is eliminated second the total net w orkwide
proto col o v erhead is reduced Figure sho ws the total
net w orkwide proto col o v erhead for STI I and RSVP
for v arious n um b ers of homogeneous receiv ers inde
p enden tly joining the audio lecture rst describ ed in
Section This graph sho ws that the RSVP merging
function is indeed highly eectiv e in reducing proto
col o v erhead In fact RSVP b ecomes more ecien tas
the group b ecomes more dense due to the a v erage
n um b er of hops to splice in to an existing distribution
branc h decreases
In addition to proto col o v erhead another imp or
tan t measure of group dynamics supp ort is the latency
in reacting to group c hanges RSVP latency can b e
tuned b y adjustmen t of refresh timers making di
rect comparison of latency times dicult ho w ev er
w e can mak e some general observ ations regarding the
t w o proto cols Under STI I the reserv ation setup and
teardo wn times for a target are nominally one round
trip time b et w een source and receiv er and one endto
end dela y resp ectiv ely Latencies in RSVP are m uc h

Note that the curren t assumption of homogeneous receiv ers
result in a b est case scenario of one proto col message on eac h
link in eac h direction The w orst case is encoun teredin a het erogeneous en vironme n t when the receiv ers join in order from
least demanding to most demanding resulting in an o v erhead
prop ortiona l to the n um ber of do wnstream receiv ers on eac h
link
less precise Adding a new receiv er mayin v olvean
initial delayinw aiting for a P ath refresh if the re
ceiv er is on a new branc h in the m ulticast distribution
tree reserv ation setup time is also v ariable from as
little as one hop up to an endtoend dela y dep ending
up on whether an existing reserv ation can b e spliced
When a receiv er lea v es explicit reserv ation teardo wn
can release the resources immedia tely Summary and F uture W ork
Weha v e describ ed ho w the STI I and RSVP pro
to cols pro vide resource reserv ation establishmentin
supp ort of an In tegrated Services P ac k et Net w ork
Both proto cols utilize m ulticast data distribution to
impro v e net w ork eciency for m ultip oin t comm unica
tion ho w ev er w e argue that a ric her service mo del is
required for the ISPN en vironmen t Our sim ulations
sho w that RSVPs supp ort for heterogeneous receiv er
requests and m ultiple reserv ation st yles can b e ex
ploited to obtain signican timpro v emen ts in net w ork
wide resource allo cation for sev eral common applica
tions If these application classes mak e up a signican t
fraction of the resource demands in an ISPN then in
corp oration of RSVP could result in a substan tial re
duction in net w ork resource requiremen ts and impro v e
scaling in terms of the n um b er and size of groups that
can b e accommo dated
Both STI I and RSVP use timer based mec hanisms
to pro vide robustness in adapting to net w ork dynam
ics ho w ev er the design philosophies are quite dier
en t STI I requires that the net w ork b e resp onsible
for correctness leading to increased proto col com
plexit y RSVP uses a soft state mec hanism lea v
ing endsystems resp onsible for refreshing state W e
also sho w ed that the receiv erinitiated reserv ation and
merging in RSVP reduces the load on links closer
to the source reduces sourcereceiv er in teractions
and reduces the net w orkwide proto col o v erhead when
compared to STI I
There are sev eral features of RSVP that are cur
ren tly not w ell understo o d or that can b e further im
pro v ed to increase eciency RSVP related topics
op en for further in v estigation include
Channel selection is a new comm uni cation
paradigm and not w ell understo o d what are the
tradeos b et w een using the assured and non
assured mec hanisms What is the o v erhead of
the dynamic lter reserv ation st yle is it b ounded
for t ypical net w ork top ologies and group mem ber
distributions
Proto col o v erhead curren tly scales with the n um
b er of data sources is it p ossible to further re
duce this b y aggregating refresh messages across
groups
As noted in Section a fault detection and
refresh trigger mec hanism could b e incorp orated
in to the proto col ho ww ould this aect proto col
complexit y and reco v ery latency
Timer settings con trol adaptation latency and
ha v e a large eect on proto col o verheadis itpos sible to dynamically adapt timers to measured
net w ork p erformance to reduce proto col o v er
head
What additional reserv ation st yles are required to
ecien tly supp ort future ISPN applications
References
Clark D The Design Philosoph y of the
D ARPAIn ternet Proto cols Pr o c e e dings of A CM
SIGCOMM August Deering S Multicast Routing in a Datagram
In ternet w ork T ec hnical Rep ort ST ANCS
Stanford Univ ersit y Decem b er
F orgie J ST A Prop osed In ternet Stream
Proto col In ternet Exp erimen tal Notes IEN
Septem ber Mitzel D Shenk er S Asymptotic Resource
Consumption in Multicast Reserv ation St yles
unpublished preprin t
P artridge C Pink S An Implemen tation of
the Revised In ternet Stream Proto col ST
Journal of Internetworking R ese ar ch and Exp e
rienc ev ol no Marc h T op olcic C Exp erimen tal In ternet Stream Pro
to col V ersion STI I In ternet RF C Oc
tob er Zhang L Braden B Estrin D Herzog
S Jamin S ReSource ReserV ation Proto
col RSVP F unctional Sp ecication In ternet
Draft Marc h Zhang L Deering S Estrin D Shenk er
S and Zappala D RSVP A New Resource
ReSerV ation Proto col IEEE Network Maga
zine Septem ber

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 606 (1995)

PDF

USC Computer Science Technical Reports, no. 648 (1997)

PDF

USC Computer Science Technical Reports, no. 656 (1997)

PDF

USC Computer Science Technical Reports, no. 586 (1994)

PDF

USC Computer Science Technical Reports, no. 655 (1997)

PDF

USC Computer Science Technical Reports, no. 670 (1998)

PDF

USC Computer Science Technical Reports, no. 614 (1995)

PDF

USC Computer Science Technical Reports, no. 565 (1994)

PDF

USC Computer Science Technical Reports, no. 607 (1995)

PDF

USC Computer Science Technical Reports, no. 731 (2000)

PDF

USC Computer Science Technical Reports, no. 724 (2000)

PDF

USC Computer Science Technical Reports, no. 708 (1999)

PDF

USC Computer Science Technical Reports, no. 686 (1998)

PDF

USC Computer Science Technical Reports, no. 818 (2004)

PDF

USC Computer Science Technical Reports, no. 677 (1998)

PDF

USC Computer Science Technical Reports, no. 704 (1999)

PDF

USC Computer Science Technical Reports, no. 657 (1997)

PDF

USC Computer Science Technical Reports, no. 631 (1996)

PDF

USC Computer Science Technical Reports, no. 603 (1995)

PDF

USC Computer Science Technical Reports, no. 608 (1995)

Description

Danny J. Mitzel, Deborah Estrin, Scott Shenker, Lixia Zhang. "An architectural comparison of ST-II and RSVP." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 585 (1994).

Asset Metadata

Creator Estrin, Deborah (author), Mitzel, Danny J. (author), Shenker, Scott (author), Zhang, Lixia (author)

Core Title USC Computer Science Technical Reports, no. 585 (1994)

Alternative Title An architectural comparison of ST-II and RSVP (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 11 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270220

Identifier 94-585 An Architectural Comparison of ST-II and RSVP (filename)

Legacy Identifier usc-cstr-94-585

Format 11 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)