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

PDF

Download

Open document

Flip pages

Download a page range

Dante DeLucia and Katia Obraczka. "A multitcast congestion control mechanism using representatives." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 651 (1997).

Transcript (if available)

Content A Multicast Congestion Con trol Mec hanism Using Represen tativ es
Dan te DeLucia Katia Obraczk a
Hughes Researc h Lab oratories USC Information Sciences Institute
Malibu Can y on Road Admiralt yW a y Suite Malibu CA Marina Del Rey CA email dan teuscedu email k atiaisiedu
Abstract
In this pap er w e prop ose a congestion con trol
mec hanism for reliable m ulticast applications that
uses a small set of group mem bers or r epr esentatives to pro vide timely and accurate feedbac k on b ehalf of
congested subtrees of a m ulticast distribution tree
Our algorithm do es not need to compute roundtrip
time R TT from all receiv ers to the source nor do es
it require kno wledge of group mem bership or net w ork
top ology Through sim ulations w eev aluate our algo
rithm with and without TCP cross trac This ini
tial ev aluation study sho ws that our algorithm tak es
adv an tage of net w ork bandwidth when a v ailable y et
do es not starv e comp eting o ws
In tro duction
The In ternet relies on applications p erforming con
gestion con trol to react to net w ork congestion and
a v oid congestion collapse Most applications in use
on the In ternet emplo y TCPs congestion con trol al
gorithms The increasing p opularit y of group comm unication
applications suchasm ultipart y teleconferencing to ols
and information dissemination services had lead to a
great deal of in terest in the dev elopmentof m ulticast
transp ort proto cols la y ered on top of IP m ulticast
UnlikeTCPs poin ttop oin t mo del whic htreats m ul
tip oin t data deliv ery as a collection of p oin ttop oin t
o ws th us sending duplicate data rep eatedly o v er the
same net w ork links m ulticast proto cols can greatly
impro v e the eciency of m ultip oin t data distribution
b y using a man ytoman y deliv ery mo del On the
other hand they can cause considerably more dam
age to the net w ork than p oin ttop oin t proto cols T o
allowm ulticast proto cols to b e deplo y ed on the In ter
net it is imp erativ e that they incorp orate mec hanisms
for handling net w ork congestion While man y prop os
als ha v e b een forthcoming on reliable m ulticast proto
cols few of them ha v e fo cused on congestion con trol
mec hanisms to accompan y these proto cols
Unlik e poin ttop oin t comm unication where the
source reacts to feedbac k from a single receiv er con
gestion con trol in a m ulticast en vironmen t requires the
source to react to feedbackfromsev eral p ossibly het
erogeneous receiv ers A rather simplistic solution is
to x the group bandwidth at the lo w est bandwidth
constrain t Ho w ev er it is m uc h more ecien t if once
the minimal group bandwidth has been established
the transmission rate is increased as bandwidth be comes a v ailable
Reliable m ulticast proto cols also face the feedbac k
implosion problem whic h b ecomes critical as m ul
ticast group size increases Sev eral existing reliable
m ulticast transp ort proto cols use probabilistic sup
pression to limit the amoun t of feedbac k receiv ed at
the source SRM for example p erforms
probabilistic suppression based on the roundtrip time
R TT measured b et w een receiv ers and the source
In this pap er w e describ e and ev aluate a scalable
resp onsivem ulticast congestion con trol mec hanism for
reliable m ulticast transp ort proto cols that do es not
rely on R TT computation bet w een all receiv ers and
the source and do es not require kno wledge of group
mem b ership or net w ork top ology y et can react to
congestion on the order of R TT to receiv ers in the
group Our algorithm is based on the assumption
that in a m ulticast group a small set of b ottlenec k
links will cause the ma jorityof the congestion prob
lems W e dynamically select a small set of group mem
b ers to represen t the congested m ulticast subtrees
These group r epr esentatives pro vide immediate feed
backwhic h suppresses feedbac k from other receiv ers
th us prev en ting feedbac k implosion at the source In
addition to suppressing feedbac k represen tativefeed bac k allo ws the source to concen trate its congestion
con trol eorts on the congested subtrees Based on
the feedbac k from represen tativ es the source adjusts
the curren t transmission rate As new congestion ap
p ears in the tree new represen tativ es are selected and
old ones dropp ed from the represen tativ e set

In the follo wing section w e describ e our mo del
Section presen ts the algorithm in detail Our ev al
uation metho dology and results are describ ed in Sec
tion Section puts our w ork in p ersp ectiv e with
related w ork and Section describ es our plan for fu
ture w ork
The Mo del
Our congestion con trol mec hanism assumes the fol
lo wing applicationlev el requiremen ts and lo w erla y er
services paragraphIP Multicast
Senders transmit data pac k ets using In ternet m ul
ticast There is no cen tralized group managemen t
Hosts can join or lea v e the group at an y time An y
host can transmit to the group
Single Data Source All dataissen t from a single
source The source is a memberofthe m ulticast group
Receiv ers send con trol messages but no data Our
congestion con trol algorithm is done in a p ersource
basis Multiple sources can b e accommo dated byrun ning m ultiple instances of the algorithm Aggregate
congestion con trol is sub ject for future w ork and out
side the scop e of this pap er
Unkno wn Group Mem b ership Lik e IP m ulti
cast w e assume the set of receiv ers is unkno wn to
supp ort scalabilit y In a real implemen tation there
needs to b e some con trol o v er mem b ership to prev en t
denial of service attac ks Authen tication is outside the
scop e of the congestion con trol mec hanism
Unkno wn Net w ork T op ology No kno wledge of
the underlying ph ysical net w ork top ology is assumed
Routers are not relied on to pro vide feedbac k ab out
net w ork conditions or lter feedbac k requests
Receiv er Supp ort Our algorithm do es not require
receiv ers to measure R TT to the source Represen ta
tiv es are the primary source of feedbac k while other
receiv ers only pro vide feedbackasa bac k up in case of
represen tativ e failure
Application Seman tics Applications are resp on
sible for the proto col seman tics When mo ving from a
onetoone reliabilit y proto col suc h as TCP to a one
toman y proto col it b ecomes m uc h more dicult to
build a single proto col that can handle all the p ossible
seman tics that migh t b e required bym ultip oin t appli
cations F or instance higher lev el applications migh t
require an explicit join proto col or migh t guaran tee
atomic deliv ery Others mightonlypro vide b est eort
deliv ery to receiv ers
Algorithm
Based on the assumption that only a small set of
b ottlenec k links cause the ma jorit y of congestion prob
lems our congestion con trol algorithm dynamically se
lects a small n um ber of receiv ers or r epr esentatives to represen t the congested m ulticast subtrees Rep
resen tativ es pro vide immediate feedbac k allo wing the
source to adjust to the curren t state of the net w ork in
a timely fashion F urthermore represen tativ es limit
the amountoffeedbac k generated b y suppressing feed
bac k from other receiv ers Probabilistic suppression is
used as bac kup in regions of the m ulticast tree not y et
co v ered b y the curren t represen tativeset Figure illustrates the concept of represen tativ es
using an arbitrary m ulticast tree as example Figure
a sho ws the m ulticast tree with the source at the
ro ot of the tree and receiv ers at in termediate no des
and lea v es When our algorithm starts Figure b
the represen tativ e set is empt y and since there is no
indication of congestion all participating receiv ers are
eligible to b ecome represen tativ es The source selects
the receiv er from whic h it receiv es feedbac k rst Fig
ure c Since receiv ers feedbac k timers are initially
set to an arbitrarily large v alue curren tly the
source will probably receiv e feedbac k to the closest
receiv ers rst When congestion is detected in the
righ t subtree whic his not y et co v ered b y the curren t
represen tativ e set Figure d a new represen tativeis
selected to co v er the newly congested subtrees Figure
e Toa v oid excessiv e uctuation of the represen ta
tiv e set the curren t implemen tation of our congestion
con trol algorithm selects only one new represen tativ e
per group roundtrip time the distance to the most
remote receiv er kno wn
The source m ulticasts data at a v ariable rate It
adjusts the rate dynamically to a v oid net w ork conges
tion while trying to mak e use of a v ailable net w ork
bandwidth
Receiv ers send feedbac k to the source in the form of
p ositiv e and negativ e congestion indicators Although
these can b e thoughtofasA CKs and NA CKs w e will
use the terms Congestion Clear CC and Conges
tion Indication CI to a v oid confusion with reliablit y
mec hanisms
CCs are used to detect congestion as it builds in the
net w ork b efore pac k et drops o ccur The t yp e of infor
mation they return dep ends on the congestion metric
in use F or example receiv e rate can b e returned and
used b y the source in conjunction with the curren t
transmit rate to detect incipien t congestion CIs pro

Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Source
a
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Source
b
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Source
Representative
c
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Source
Representative
Congestion
Receiver
Congestion Detected
d
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Receiver
Source
Congestion
Receiver
Representative
Representative
Congestion
e
Figure An example m ulticast tree illustrating the
concept of represen tativ es
vide feedbac k in the case of pac k et drops indicating
that congestion has o ccurred and has b een detected
b y the receiv er
If a source do es not receiv e an y feedbac k it can
assume that there are no group mem b ers other than
itself or that there has b een some sort of catastrophic
net w ork failure
F eedbac k Con trol
Represen tativ es pla y a cen tral role in the feedbac k
con trol mec hanism Their feedbac k is immediate and
not sub ject to suppression If nonrepresen tativefeed bac k timers are set long enough feedbac k from rep
resen tativ es can tra v erse the en tire group suppressing
an y nonrepresen tativ e feedbac k F eedbac k from non
represen tativ es is sc heduled o v er a random in terv al
the suppr ession in terv al based on the groups maxi
m um roundtrip time GR TT W e explain ho w sup
pression timers and the GR TT are set in Section b elo w
Toa v oid congesting the net w ork with CCs A CKs
represen tativ es send CCs with probabilit y
R
where R
is the n um b er of represen tativ es Since w e assume the
represen tativ e set is small limited and timely feedbac k
will still b e receiv ed at the source
Represen tativ e Selection
The source selects represen tativ es and m ulticasts the
curren t represen tativ e set to the group A receiv er
designates itself as a represen tativ e up on receipt of a
represen tativ e set notication in whic h it is a mem b er
A represen tativ e rev erts to nonrepresen tativ e op era
tion when it receiv es a represen tativ e set up date in
whichit is not amem b er
A t startup an y receiv er pro viding feedbac k is el
igible for selection as a represen tativ e After a full
represen tativ e set has b een obtained only CIs qualify
a receiv er for selection as a represen tativ e T o prev en t
a sudden turno v er of the represen tativ e set only one
new represen tativema y b e selected p er GR TT
When the represen tativ e set is full and a new rep
resen tativ e is selected an existing one m ust b e ejected
from the curren t set T o select a candidate for ejection
from the represen tativeset w e curren tly use a LR U
algorithm based on the time since the last CI w as sen t
This criteria is based on the assumption that a repre
sen tativ e that has not sen t a CI is ha ving the few est
n um b er of congestion problems
In the curren t v ersion of the algorithm the rep
resen tiv e set size is a xed parameter An issue for
further in v estigation is ho w to determine this set size
dynamically
Suppression
Suppression refers to the canceling of sc heduled feed
bac k in resp onse to the receipt of another receiv ers
feedbac k Since CIs are an immediate indication of
congestion feedbac k suppression giv es precedence to
CIs o v er CCs ie CIs suppress CCs F urther re
ceiv ers sending CIs tak e precedence o v er receiv ers
sending CCs for consideration as represen tativ es As
net w ork conditions c hange feedbac k receiv ed b y the
source is used to up date the represen tativeset Probabilistic suppression is used in conjunction
with represen tativ e suppression to limit feedbac k from
m ulticast subtrees not y et co v ered b y the curren t rep
resen tativ e set
Nonrepresen tativ e receiv ers suppression timers
consist of t w o comp onen ts The rst is a simple wait
p erio d and the second is a random suppr ession in ter
v al The purp ose of the w ait p erio d is to allo w time for
represen tativefeedbacktotra v erse the group thereb y
suppressing feedbac k from nonrepresen tativ es A tthe
same time if set to o long losses not co v ered b y the
curren t represen tativ e will not b e detected in a timely
fashion The purp ose of the suppression in terv al is to
space out feedbac k resp onses and allo w probabilistic
suppression to reduce the amoun t of feedbac k
The w ait and suppression in terv als are set as a p er
cen tage of the estimated GR TT describ ed b elo w
GR TT Measuremen t
In k eeping trackof GR TT wew antto ha vea rough
estimate of the curren t largest R TT in the group y et
a v oid o v erly p essimistic estimates Our solution is at
the source k eep a table of the largest R TTs noted on
anypac k et receiv ed Eac h table en try con tains a R TT
measuremen t and a timetoliv e TTL Eachtime a
pac k et is sen t the TTL is decremen ted Wek eep trac k
of the largest R TTs receiv ed When a new largest R TT
is receiv ed it is added to the set and givenaTTLAs
TTLs expire those estimates are dropp ed from the
table This prev en ts stale estimates that migh t be
o v erly p essimistic
Note that the GR TT is based only on feedbac k re
ceiv ed at the source No sp ecial messages are required
Congestion Con trol
The congestion con trol algorithm consists of t w o
phases The rst is the slo wstart phase conceptu
ally b orro w ed from TCP As so on as congestion is de
tected the algorithm rev erts to its congestion a v oid
ance phase
Initially the source transmission rate is set to a pre
dened minim um rate r ate min The transmission
rate is nev er allo w ed to drop b elowthis v alue
The general rate adjustmen t strategy is to use lin
ear increase and decrease for congestion a v oidance
purp oses and m ultiplicativ e decrease for sev ere con
gestion reco v ery ie when the source receiv es CIs
Slo wStart
The slo wstart phase attempts to quic kly nd the
a v ailable net w ork bandwidth Initially the transmis
sion rate is set to rate min and is increased b y
ev ery
GR T T This rate increase is conserv ativ e and at
tempts to a v oid pac k et loss
Slo wstart is terminated when a CI is receiv ed or
when congestion is detected using information gleaned
from CCs In either case the transmission rate is re
duced b y half and the algorithm switc hes to the con
gestion a v oidance phase W e explain ho w w e deriv e
congestion information from CCs later
Congestion Av oidance
Up on detecting congestion the source needs to per form the appropriate transmission rate adjustmen ts
Belo w w e describ e the congestion detection and rate
adjustmen t approac hes used
Congestion Detection When the source receiv es a
represen tativ e feedbac k message it examines the mes
sage to determine if congestion exists in the net w ork
This decision dep ends on the t yp e of congestion metric
in use
W e exp erimen ted with t w o dieren t congestion
metrics r ateb ase d and delayb ase d The ratebased
metric is essen tially the rate at whichpac k ets w ere re
ceiv ed b y a group mem b er Inspired b y TCP V egas
congestion a v oidance mec hanism the dela ybased
metric measures the amoun t of data queued in the
net w ork
If the ratebased congestion metric is used the
source compares its transmit rate to the w orst receiv e
rate rep orted b y the feedbackpac k ets receiv ed in re
sp onse to a data pac k et
When using the dela ybased metric the n um ber of
pac k ets queued in the net w ork pack ets
queued
isgiv en
b y
pack ets
q ueued
rtt
cur r ent
rtt
min
rate
pack et siz e
where rtt
cur r ent
is the w orst R TT the source mea
sured using the curren t feedbac k rtt
min
is the min
im um R TT the source has measured from feedbac k

receiv ed so far r ate is the curren t transmit rate and
pack et siz e is the size of a data pac k et
If pack ets
q ueued
the source has an indication
that congestion is building up and the source de
creases its transmission rate Otherwise it increases
the rate There is an ob vious tradeo in setting if
it is set to o lo w the congestion a v oidance algorithm
b ecomes to o conserv ativ e On the other hand if it is
set to a large n um ber congestion can lead to pac k et
drops W e curren tly set to pac k ets
Adjusting the T ransmit Rate When the source
receiv es CCs in resp onse to a data pac k et and do es
not detect congestion it increases its transmit rate
additiv ely b y r ate Rate increases are limited to
once ev ery GR T T If congestion is detected the
transmit rate is decreased b y r ate Decreases can
o ccur once ev ery GR T T Instead of the traditional rate decrease w ec hose
to decrease half as fast when w e detect queue buildup
and not an actual pac k et drop It could b e argued that
the curren t increase strategy is to o conserv ativ e As
part of our future w ork in tuning the algorithm w e will
in v estigate alternate increase and decrease strategies
Up on receipt of a CI the transmit rate is m ulti
plicativ ely reduced b y half if there has b een no de
crease for one GR TT In other w ords a CI is ignored if
congestion is detected using CC information less than
one GR TT ago
Ev aluation
This section rep orts the p erformance of our con
gestion con trol algorithm Previous w ork ev aluated
the feedbackcon trol mec hanism and established that
when compared to a pure suppression algorithm rep
resen tativ es con tribute signican tly to limiting the
amountoffeedbac k while main taining its timeliness
These results and a more detailed discussion can be
found in
This p erformance study v alidates the basic conges
tion con trol algorithm The results sho w that our ap
proachis v ery promising ho w ev er further ev aluation
is required as the proto col matures
Sim ulator
W e implemen ted our congestion con trol algorithm
as a new proto col in NS Net w ork Sim ulator NS
has already b een used in p erformance studies of TCP
and m ulticast proto cols By using NS rather
than writing a sim ulator from scratc h or using other
sim ulation to ols w e are able to test in teractions b e t w een our proto col and sev eral TCP v arian ts and gate
w a y queuing strategies suc h as droptail and RED
that ha v e b een implemen ted in NS F or the purp oses
of this study w e limited our in v estigations to TCP
T aho e and droptail gatew a ys
Our implemen tation allo ws us to v ary man y param
eters of the sim ulation including m ulticast group size
top ology link sp eed propagation dela y represen ta
tiv e set size congestion metric and congestion metric
thresholds
Exp erimen ts
W e conducted exp erimen ts on top ologies of up to
receiv ers These w ere the largest net w orks that
could b e ev aluated giv en the resources a v ailable W e
discuss the top ologies used as w ell as the other sim u
lation parameters b elo w
Cross T rac Cross trac w as generated in the
form of concurren t TCP sessions W e used t w o dif
feren t crosstrac patterns the rst one p attern consists of a longliv ed TCP connection that starts s
after the m ulticast o w and lasts for the remainder of
the exp erimen t
The second trac pattern p attern adds burst y
trac to the rst pattern it consists of the same
longliv ed TCP session running concurren tly with a se
quence of shortliv ed nono v erlapping TCP sessions
They also start s after the m ulticast o w starts and
last s eac h
W e do not claim these are realistic trac patterns
W e use them to ha v e an initial assessmentof ho w our
congestion con trol trac beha v es in the presence of
cross trac Clearly more w ork needs to be done
in order to ev aluate the algorithm with more realistic
cross trac scenarios
W e used TCPbased cross trac as a y ardstic k for
our congestion con trol algorithm TCPs congestion
con trol mec hanisms ha v e b een w ell tuned for an en
vironmentlikethe In ternet and sho wing that our al
gorithm b eha v es w ell when comp eting for bandwidth
with a reasonably conserv ativ e algorithm is promising
T op ologies Initial ev aluations used pure star and
linear top ologies Star top ologies w ere c hosen as they
theoretically defeat man y of the adv an tages of repre
sen tativ es The concept of represen tativ es relies on
nding b ottlenec k links In a star net w ork with uni
form bandwidths there is no b ottlenec k link Conges
tion w ould only arise due to comp eting cross trac or
b y exceeding a v ailable bandwidth
Linear top ologies w ere c hosen as they are the other
extreme of star net w orks They allo w us to ev alu
ate our algorithm in terms of long dela y man y hop
net w orks In linear top ologies represen tativ es can b e
quite eectiv e

TCP src
Bursty
...
Source
Receivers
Router Long TCP source
Long TCP Sink Bursty
TCP Sink
Figure T est T op ology
F or this study w e c hose to use a h ybrid top ology
com bing star and linear top ologies The result is a
t w olev el top ology with the toplev el no des connected
according to a linear top ology and eac h toplev el no de
b eing the cen ter of a ring at the secondlev el Figure
sho ws the starlinear top ology w eusedinour exper imen ts Our exp erimen tal top ology has toplev el
and secondlev el no des
As sho wn in the gure the m ulticast source and
receiv ers w ere all lo cated on leaf no des ie only
the lea v es are activ e m ulticast participan ts Conse
quen tly the diameter of the m ulticast group is hops The propagation dela y for all links w as ran
domly distributed b et w een ms and ms The band
width of eac h link is KilobitssecKbps Since the
longliv ed TCP sessions source and sink are in opp o
site extremes of the test top ology the sessions propa
gation delayis s o v er hops with the dela ybeing
dominated b y the pac k et transmission time o v er eac h
link due to queuing dela y Congestion Metrics W e conducted exp erimen ts
using b oth rate and dela ybased congestion metrics
Recall that the ratebased metric uses the receiv e rate
as a congestion indicator while the dela ybased metric
rep orts the n um ber of pac k ets queued in the net w ork
Due to space limitations w e only sho w results from
runs that used the dela ybased metric W e discuss the
results from the runs using the ratebased metric in
Section Other Sim ulation P arameters The other param
eters used b y our sim ulator and their v alues include
The represen tativ e set size w as set to Pre
vious exp erimen ts sho w that small represen
tativ e sets are quite eectiv e in suppressing feed
bac k and pro viding timely feedbac k
The CC w ait in terv al is set to GR T T while
the CC random in terv al is set to GR T T The CI w ait in terv al and CI random in ter
v al are set to GR T T and GR T T By using a small w ait in terv al nonrepresen tativ e
receiv ers do not w ait v ery long b efore sending
a CI whic h mak es the algorithm more resp on
siv e to congestion in p ortions of the m ulticast
tree not y et co v ered b y represen tativ es Ho w ev er
the longer random in terv al giv es represen tativ es a
c hance to suppress CIs from tree branc hes they al
ready co v er The ev aluation presen ted in also
studies the eect of dieren tCI w ait in terv als on
our algorithm
Results
All sim ulations used the top ology sho wn in Figure
The rst run ev aluates the p erformance of the al
gorithm with no cross trac The second ev aluates
the algorithm in the presence of cross trac giv en b y
pattern while the third nal exp erimen t sho ws the
algorithms b eha vior when pattern cross trac is
presen t
Our p erformance results are presen ted b y graphs
sho wing pac k et sequence n um ber progressions o v er
sim ulation time and graphs sho wing m ulticast trans
mission rate o v er time In the sequence n um ber
graphs the m ulticast o ws pac k et sequence n um ber
progression alw a ys app ears in the bottom horizon tal
p ortion of the graph Cross trac if presen t for the
longer TCP connection and the sequence of short TCP
connections app ear in the mid and top p ortions of the
graph resp ectiv ely No cross trac
The tests without cross trac where in tended to ex
amine howw ell the basic proto col w ork ed on uncon
gested links Ideally w e w ould lik e to see few or no
pac k et drops and maxim um bandwidth utilization
Figures a and b sho wthe pac k et sequence n um
b er progression and the source transmit rate of a m ul
ticast o w with no comp eting cross trac During
the slo wstart phase whic h lasts from to sec
onds the source increases the transmit rate un til it
detects queue build up whic h causes the rate to be
decreased b y half Note that no data pac k ets w ere
lost during slo w start F or the remainder of the run
the transmit rate oscillated around Kbs
link bandwidths are Kbs
Our congestion a v oidance strategy p erformed rea
sonably w ell the table in Figure c sho ws that only
of the pac k ets w ere dropp ed Note that when the
rst data pac k et loss o ccurred at seconds it did
not cause a m ultiplicativ e rate decrease This is due
to the fact that the CI arriv ed at s but a rate de
crease had o ccured at s Since the GR TT is s

the next rate decrease will not tak e place un til s
W e observ e that other pac k et drops o ccurred just af
ter queuing w as detected but b efore another rate de
crease could tak e eect Ho w ev er the indication that
the rate decrease that had already tak en place w as ef
fectiv e in reducing queuing in the net w ork is that the
source w as able to increase its rate afterw ards
P attern cross trac
The goal of the exp erimen ts using cross trac is to
demonstrate that our congestion con trol algorithm
do es not starv e comp eting TCP trac
Figure sho ws the b eha vior of our congestion con
trol algorithm in the face of pattern cross trac
The pac k et sequence n um b er progression graph Fig
ure a sho ws that TCP cross trac causes conges
tion at the onset and causes pac k et loss in our m ul
ticast o w As sho wn in the transmission rate graph
Figure b the m ulticast o wquic kly bac ks o in
the face of comp eting TCP cross trac It main tains
a less than fair but steady and resp ectable share of
the bandwidth for ab out s but then suers a sharp
decrease due to a pac k et loss After the m ultiplicativ e
decrease due to the pac k et loss the linear increase re
co v ers some of the lost bandwidth Most data pac k et
losses did not cause a reduction in transmission rate
since they o ccurred to o so on after a rate adjustmen t
Data pac k et transmission for the m ulticast and
comp eting TCP sessions are tabulated in Figure c
The m ulticast session although it do es not gain the
same throughput as the TCP session do es fa v orably
in terms of pac k et loss
P attern cross trac
W e used this cross trac pattern to test the perfor mance of our algorithm in the face of comp eting burst y
cross trac in the lea v es
As can be seen from the table in Figure c the
m ulticast session loses a fair n um ber of pac k ets due
to comp eting trac in the lev el subtrees The long
TCP session do es not suer these losses since it is only
tra v ersing t w o lev el links and the bac kb one Hence
it do es not encoun ter most of the cross trac Com
paring the pac k et loss results the m ulticast session
do es m uc h b etter than the burst y TCP sessions It
should b e noted though that man y of the burstyTCP
losses happ ened during TCPs slo w start since these
sessions are not long enough to fully stretc h TCPs
congestion windo w
W e observ e that the o v erall b eha vior of our algo
rithm in the presence of b oth cross trac patterns
0
0.5
1
0 50 100 150 200250 300 350 400 450 500
Sequence number
Seconds
Sequence number progression
Packets
CC/CI Drops
Data Drops
a Sequence n um b er progression
0
2000
4000
6000
8000
10000
12000
0 50 100 150 200250 300 350 400 450 500
Bytes/Second
Seconds
Transmission rate at source
Rate
b Rate c hanges
T otal Sen t Drops
Multicast Data
c Data pac k ets sen t and dropp ed
Figure Congestion con trolled m ulticast o w with
no bac kground trac

0
0.5
1
1.5
2
0 50 100 150 200250 300 350 400 450 500
Sequence number
Seconds
Sequence number progression
Packets
CC/CI Drops
Data Drops
a Sequence n um b er progression
1000
2000
3000
4000
5000
6000
7000
8000
0 50 100 150 200250 300 350 400 450 500
Bytes/Second
Seconds
Transmission rate at source
Rate
b Rate c hanges
T otal Sen t Drops
Multicast Data
Long TCP Data
c Data pac k ets sen t and dropp ed
Figure Congestion con trolled m ulticast o w with
pattern comp eting trac
0
0.5
1
1.5
2
2.5
3
0 50 100 150 200250 300 350 400 450 500
Sequence number
Seconds
Sequence number progression
Packets
CC/CI Drops
Data Drops
a Sequence n um b er progression
1000
2000
3000
4000
5000
6000
7000
8000
0 50 100 150 200250 300 350 400 450 500
Bytes/Second
Seconds
Transmission rate at source
Rate
b Rate c hanges
T otal Sen t Drops
Multicast Data
Long TCP Data
Burst y Data TCP
c Data pac k ets sen t and dropp ed
Figure Congestion con trolled m ulticast o w with
pattern comp eting trac

is quite similar it k eeps a less than fair y et reason
able share of the a v ailable bandwidth After a rate
decrease the linear increase reco v ers some of the lost
bandwidth
Other exp erimen ts
Man y v ariations of the algorithm w ere in v estigated
but space precludes us from presen ting all the results
In this section w e will discuss some of the other ob
serv ations weha v e made in a more cursory fashion
Beha vior against TCP Besides the runs in whic h
the TCP sessions start after the m ulticast o w w ealso
ran exp erimen ts in whic h the m ulticast session started
after establishing the TCP session In eac h case the
results w ere comparable to those ab o v e
Rate vs Dela y Metric Initial exp erimen ts w ere
p erformed using a ratebased congestion metric W e
observ ed that the rate metric has a tendency to sat
urate in termediate routers queues While this is ne
in the case of a single m ulticast session TCP con
nections exp erience dicult y up on initiation due to a
high probabilityof pac k et drops o v er congested links
This problem motiv ated us to in v estigate dela y
based metrics Dela y metrics allo w us to estimate and
hence con trol queue size and generally lead to bet ter results Rate metrics on the other hand w ere of
ten v ery eectiv e at nding a v ailable bandwidth The
main problem with rate metrics is kno wing when to
increase the rate The rate migh t settle in to a steady
state but that steady state can cause the in terme
diate routers queues to be saturated and saturated
queues lead to unfair link utilization with comp eting
cross trac
Related W ork
W e put our w ork in p ersp ectiveb y reviewing related
w ork in the areas of congestion and feedbac k con trol
Congestion Con trol
Congestion has b een studied extensiv ely in the con
text of unicast transp ort proto cols Curren tly most
applications in use on the In ternet use TCPs conges
tion con trol mec hanisms TCP is the underlying trans
port proto col in HTTP FTP TELNET and other
application proto cols requiring reliable deliv ery In Jacobson describ es his congestion con trol
algorithm for TCP During slo w start TCP op ens
the transmission windo w exp onen tially as the source
receiv es ac kno wledgmen ts from the receiv ers un til a
pac k et loss o ccurs TCP uses data loss as sign of con
gestion and sh uts the windowdo wn to pac k et after
a loss After the slo w start phase TCP op ens the
windo w linearly and closes it m ultiplicativ ely Both
the T aho e and Reno distribution of BSD UNIX incorp orate Jacobsons slo wstart algorithm
Another v arian t of TCP called TCP V egas
implemen ts a senderside congestion a v oidance algo
rithm In Ahn et al conrm that V egas conges
tion a v oidance sc heme yields higher throughput and
k eeps less data in the net w ork than Reno By com
puting the dierence bet w een b est and curr ent R TT
aV egas sender measures the amoun t of data queued
in the net w ork and adjusts its transmission windo w
accordingly Pro viding congestion con trol mec hanisms is criti
cal in enabling reliable m ulticast transp ort proto cols
to b e deplo y ed on the In ternet Ho w ev er only a few
existing m ulticast transp ort proto cols implemen t con
gestion con trol
La y ered Multicast addresses the congestion
problem in the con text of video stream m ulticast
transmission Streams are decomp osed in to sev eral
la y ers Enco ding is done suc h that the comp osition
of la y ers leads to higher qualit y video The lo w est
la y er in the stream is a lo w qualit y lo w bandwidth
stream Eac h successivela y er pro vides more informa
tion that when com bined with the lo w er la y ers results
in a higher qualit y image The more bandwidth that
is a v ailable the more la y ers one can receiv e As con
gestion is detected at the receiv er via pac k et loss the
receiv er unsubscrib es to higher bandwidth groups P e
rio dically receiv ers that are not exp eriencing conges
tion join higher bandwidth groups to tak eadv an tage
of a v ailable net w ork bandwidth
Unlikethe La y ered Multicast approac h whic h tar
gets applications that can tolerate data loss our ap
proachto congestion con trol fo cuses on services that
require reliable deliv ery It uses represen tativ e re
ceiv ers to pro vide timely feedbac k so that incipien t
congestion can b e detected and pac k et loss a v oided
F eedbac k Con trol
Multicast transp ort proto cols suer from the feed
bac k implosion problem sp ecially when losses o c cur higher up in the m ulticast tree in larger groups
o v er lossy net w orks In this section w e fo cus on pro
p osed solutions to the feedbac k implosion problem in
the con text of reliable m ulticast transp ort proto cols
In solutions to the feedbac k implosion prob
lem are classied as structur eb ase d or timerb ase d Structurebased approac hes suc h as rely on a
designated site either a dedicated serv er in the case
of or a preassigned group mem b er to pro cess and
lter feedbac k information

Timerbased solutions rely on probabilistic feed
bac k suppression to a v oid implosion at the source Re
ceiv ers in the SRM proto col whic hw as designed to
supp ort the distributed whiteb oard application dela y
their retransmission requests for a random in terv al
uniformly distributed bet w een the curren t time and
the onew a y trip time to the source The goal is that
group mem bers closer to the source send their feed
bac k so oner suppressing feedbac k from farther a w a y
mem bers A site uses periodic session messages to
measure its distance based on the resulting R TT to
the other group mem bers The Deterministic Timeouts for Reliable Multicast
DTRM algorithm also uses R TT bet w een re
ceiv ers and the sender to compute the receiv ers sup
pression timeouts suc h that only one receiv er in a m ul
ticast subtree the r epr esentative r e c eiver resp onds to
losses
The feedbac k con trol mec hanism prop osed in do es not fall in to either the structurebased or the
timerbased categories In this approac h to feedbac k
con trol whic h is used b y the IVS video conferencing
to ol and is la y ered atop of R TP video sources
use probabilistic p olling to select a set of receiv ers that
should pro vide feedbac k
Our approac h to feedbackcon trol do es not require
R TT computation bet w een receiv ers and the source
It relies on represen tativ es to suppress feedbac k from
other receiv ers Probabilistic suppression is used as
bac kup as the represen tativ e set c hanges to co v er new
congestion Our approac h b enets applications suc h
as data dissemination services where data o ws from
one source to the rest of the group In these services
receiv ers w ould ha veto generate sp ecial messages to
measure R TT to other group mem bers F uture W ork
W e plan to con tin ue w ork to fully ev aluate our con
gestion con trol algorithm In addition to testing more
realistic top ologies and w orkloads rate increase and
decrease strategies need to be in v estigated as w ell
Based on the kno wledge gained from the exp erimen ts
using dela y and ratebased congestion metrics w e plan
to exp erimen t with a h ybrid metric that uses b oth
ratebased for rate decreases and dela ybased for rate
increases
A metho d of dynamically determining repreresen
tativ e set size needs to be dev elop ed W e also plan
to ev aluate our congestion algorithm against m ultiple
instances of itself
Group size estimation can greatly enhance the ef
fectiv eness of the suppression algorithm T ec hniques
for doing this ha v e b een dev elop ed elsewhere and need to b e in v estigated in this con text Curren tly in v ery large groups CI feedbac k from unrepresen ted
subtrees can still cause transien t congestion if losses
occur high in the m ulticast tree Estimating group
size w ould greatly decrease the poten tial for conges
tion
Conclusions
W e presen ted our congestion con trol algorithm for
use in reliable m ulticast transp ort proto cols The k ey
features of the algorithm are the use of represen tativ es
com bined with probablistic feedbac k suppression to
eliminate the need to for precise timer settings based
on R TT to the source
W e ev aluated our algorith with and without TCP
cross trac The results from these preliminary p er
formance ev aluation exp erimen ts are quite promising
they sho w that our algorithm tak es full adv an tage of
a v ailable bandwidth when there is no comp eting traf
c y et yields bandwidth in the presence of comp eting
TCP trac
In the future w e will in v estigate alternate con
gestion metrics as w ell as rate increase and decrease
strategies to impro v e p erformance in terms fair share
of bandwidth and bandwidth utilization W e will also
ev aluate our algorithm using more realistic top ologies
and comp eting trac patterns
References
JS Ahn P B Danzig Z Liu and L Y an Ev al
uation of tcp v egas Em ulation and exp erimen t
A CM SIGCOMM Confer enc e pages Octob er JC Bolot T T urletti and I W ak eman Scalable
feedbackcon trol for m ulticast video distribution
in the in ternet Pr o c of the Confer enc e on Com
munic ations A r chite ctur es Pr oto c ols and Appli
c ations A CM SIGCOMM August
LS Brakmo SW OMalley and LL P eterson
TCP V egas New tec hniques for congestion de
tection and a v oidance A CM SIGCOMM
Confer enc e pages Ma y
P B Danzig Optimal ly Sele cting the Par ame
ters of A daptive Backo A lgorithms for Computer
Networks and Multipr o c essors PhD thesis Uni
v ersit y of California Berk eley Decem b er K F all and S Flo yd Sim ulationbased compar
isons of taho e reno and sac k tcp A CM Com
puter Communic ations R eviewJuly
S Flo yd and V Jacobson Random early detec
tion gatew a ys for
congestion a v oidance IEEEA CM T r ansactions
on Networking August S Flo yd V Jacobson S McCanne CG Liu
and L Zhang A reliable m ulticast framew ork for
ligh tw eigh t sessions and applicationlev el fram
ing A CM Sigc omm Confer enc e pages Octob er Omitted for anon ymit y M Grossglauser Optimal deterministic timeouts
for reliable scalable m ulticast Pr o c of the IEEE
Info c om San F r ancisc o CA pages Marc h
HW Holbro ok SK Singhal and DR Cheri
ton Logbased receiv erreliable m ulticast for dis
tributed in teractivesim ulation A CM Sig
c omm Confer enc e pages Octob er V Jacobson Berk eley tcp ev olution from
taho e to reno Pro ceedings of the British
Colum bia In ternet Engineering T ask F orce July

V an Jacobson Congestion a v oidance and con trol
A CM SIGCOMM pages J Mac k er and W Dang The m ulticast dissemi
nation proto col mdp framew ork In ternet Draft
In ternet Engineering T ask F orce draftmac k er
mdpframew orktxt No v em b er S McCanne ns LBNL net w ork sim ulator
Av ailable from h ttpwwwnrgeelblgo vns
S McCanne and V Jacobson Receiv erdriv en
la y ered m ulticast A CM Sigc omm Confer
enc e pages August R Morris Bulk m ulticast transp ort proto col Ac
cepted for publication in IEEE Info com
B Sabata MJ Bro wn and BA Denn y T rans
p ort proto col for reliable m ulticast TRM Pr o
c e e dings of the IASTED International Confer enc e
on Networks pages Jan uary
H Sc h ulzrinne S Casner R F rederic k and
V Jacobson R TP A transp ort proto col for real
time applications In ternet Request for Com
men ts RF C Jan uary T T urletti H soft w are co dec for video confer
encing o v er the in ternet INRIA Researc h Rep ort
Jan uary

Asset Metadata

Creator DeLucia, Dante (author), Obraczka, Katia (author)

Core Title USC Computer Science Technical Reports, no. 651 (1997)

Alternative Title A multitcast congestion control mechanism using representatives (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 UC16270122

Identifier 97-651 A Multicast Congestion Control Mechanism Using Representatives (filename)

Legacy Identifier usc-cstr-97-651

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)

Linked assets

Computer Science Technical Report Archive