ARIES

A

Rearrangeable

Inexpensive

Edge-based

On-line

Steiner

Algorithm

Fred

Bauer

Anujan

Varma

Computer

Engineering

Department

University

of

California

Santa

Cruz

CA

August

This

research

is

supported

by

the

Advanced

Research

Projects

Agency

-LRB-

ARPA

-RRB-

under

Contract

No

and

by

the

NSF

Young

Investigator

Award

No

This

paper

was

presented

in

part

at

INFOCOM

San

Francisco

March

Abstract

In

this

paper

we

propose

and

evaluate

ARIES

a

heuristic

for

updating

multicast

trees

dynamically

in

large

point

to-point

networks

The

algorithm

is

based

on

monitoring

the

accumulated

damage

to

the

multicast

tree

within

local

regions

of

the

tree

as

nodes

are

added

and

deleted

and

triggering

a

rearrangement

when

the

number

of

changes

within

a

connected

subtree

crosses

a

set

threshold

We

derive

an

analytical

upper-bound

on

the

competitiveness

of

the

algorithm

We

also

present

simulation

results

to

compare

the

average-case

performance

of

the

algorithm

with

two

other

known

algorithms

for

the

dynamic

multicast

problem

GREEDY

and

EBA

-LRB-

Edge-Bounded

Algorithm

-RRB-

Our

results

show

that

ARIES

provides

the

best

balance

among

competitiveness

computational

effort

and

changes

in

the

multicast

tree

after

each

update

I.

Introduction

Many

future

applications

of

computer

networks

such

as

distance

education

remote

collaboration

and

teleconferencing

will

rely

on

the

ability

of

the

network

to

provide

multicast

services

Multicasting

is

sometimes

supported

in

a

point-to-point

packet

network

by

setting

up

a

multicast

tree

connecting

the

members

of

the

multicast

group

Many

of

the

multicast

applications

also

require

the

network

to

support

dynamic

multicast

sessions

where

the

membership

of

the

multicast

group

changes

frequently

Supporting

such

applications

requires

the

ability

to

alter

an

existing

multicast

tree

to

accommodate

membership

changes

as

nodes

join

and

leave

the

multicast

session

While

much

has

been

written

on

the

subject

of

establishing

a

static

multicast

tree

in

point-to-point

networks

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

algorithms

to

modify

an

existing

multicast

tree

by

adding

and

deleting

members

is

a

relatively

unexplored

area

of

research

Multicast

update

algorithms

to

update

the

multicast

tree

quickly

already

exist

Few

algorithms

however

address

the

issue

of

how

to

update

the

multicast

tree

so

that

its

cost

-LRB-

its

sum

of

edge

weights

as

described

below

-RRB-

does

not

increase

unnecessarily

over

time

Since

some

multicast

applications

are

delay-sensitive

the

ability

of

a

multicast

algorithm

to

modify

the

multicast

tree

well

assumes

special

significance

This

paper

presents

a

new

low-cost

heuristic

for

updating

the

multicast

tree

for

dynamic

multicast

groups

Previous

authors

have

established

that

determining

an

optimal

multicast

tree

for

a

static

multicast

group

may

be

modeled

as

the

NP-complete

Steiner

problem

in

networks

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

Consequently

its

explicit

solutions

are

prohibitively

expensive

For

example

two

popular

explicit

algorithms

the

spanning

tree

enumeration

algorithm

and

the

dynamic

programming

algorithm

-LSB-

-RSB-

have

algorithmic

complexities

of

O

-LRB-

-LRB-

n?p

-RRB-

-RRB-

and

O

-LRB-

-RRB-

respectively

where

n

is

the

number

of

nodes

in

the

graph

and

p

the

number

of

multicast

members

A

number

of

good

inexpensive

heuristics

exist

for

the

Steiner

problem

in

networks

and

have

been

reviewed

extensively

elsewhere

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

Approaches

to

creating

multicast

trees

that

do

not

use

Steiner

tree

heuristics

have

been

proposed

elsewhere

Three

notable

papers

of

alternative

approaches

include

DVMRP

-LSB-

-RSB-

PIM

-LSB-

-RSB-

and

core-based

trees

-LSB-

-RSB-

These

approaches

are

appropriate

for

datagram

environments

such

as

the

Internet

in

which

the

routes

taken

by

multicast

packets

may

vary

and

low

algorithm

overhead

is

more

important

than

multicast

tree

cost

-LRB-

sum

of

tree

edge

weights

as

defined

below

-RRB-

On

the

other

hand

Steiner

tree

heuristic

based

approaches

-LCB-

such

as

the

one

described

in

this

paper

-LCB-

apply

to

virtual-circuit

environments

in

which

low

multicast

tree

cost

is

of

most

interest

For

example

consider

a

long-term

multicast

session

employing

a

pre-determined

multicast

tree

over

a

network

with

tariffs

Here

the

additional

overhead

of

a

Steiner

heuristic

is

balanced

by

the

decreased

cost

of

the

multicast

session

This

paper

addresses

the

problem

of

modifying

an

existing

multicast

tree

when

new

members

enter

or

existing

members

leave

the

multicast

group

The

problem

of

updating

the

multicast

tree

after

each

addition

and

deletion

is

known

as

the

on-line

multicast

problem

in

networks

This

paper

focuses

on

its

Steiner

equivalent

the

on-line

Steiner

problem

in

networks

-LSB-

-RSB-

If

the

sequence

of

m

updates

to

the

multicast

group

is

represented

by

a

request

vector

R

-LRB-

rm

-RRB-

where

each

element

of

R

is

a

request

to

add

or

delete

a

single

node

the

on-line

multicast

problem

is

defined

formally

as

follows

GIVEN

A

simple

undirected

connected

graph

G

-LRB-

V

E

-RRB-

with

non-negative

edge

costs

a

set

of

multicast

members

W

V

a

request

vector

R

-LRB-

rm

-RRB-

and

an

initial

multicast

tree

T

-LRB-

V

-RRB-

V

V

and

E.

FIND

Multicast

trees

Tm

such

that

the

member

nodes

of

each

tree

Ti

are

those

of

tree

T

modified

by

requests

ri

and

its

cost

-LRB-

sum

of

edge

weights

-RRB-

is

the

minimumamong

all

possible

choices

for

tree

Ti

In

the

extreme

case

a

multicast

tree

may

be

completely

rebuilt

after

each

change

using

a

static

multicast

heuristic

This

approach

however

is

prohibitively

expensive

if

used

for

each

addition

and

deletion

In

addition

real-time

multicast

sessions

can

not

tolerate

large

changes

in

the

multicast

tree

after

each

update

This

is

because

data

packets

are

constantly

in

flight

within

the

multicast

tree

and

large

changes

to

the

tree

might

cause

an

unacceptable

disruption

in

the

packet

flow

An

ideal

multicast

algorithm

therefore

must

minimize

both

the

number

of

changes

between

successive

updates

and

the

cost

of

the

multicast

tree

formed

after

each

update

We

know

however

that

the

Steiner

problem

in

graphs

is

NP-complete

and

no

such

ideal

algorithm

exists

that

runs

in

polynomial

time

The

on-line

multicast

problem

was

first

presented

by

Waxman

-LSB-

-RSB-

and

has

received

little

attention

since

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

We

present

a

new

heuristic

for

the

on-line

Steiner

problem

balancing

heuristic

run-time

against

competitiveness

that

is

the

ratio

between

the

cost

of

the

heuristic

tree

and

the

cost

of

an

optimal

tree

The

cost

of

the

tree

is

taken

as

the

sum

of

the

weights

of

the

edges

in

the

tree

We

derive

analytical

bounds

on

the

competitiveness

of

the

new

heuristic

In

addition

we

also

compare

the

heuristic

with

previous

on-line

heuristics

by

simulation

on

a

large

number

of

random

test

graphs

representing

sparse

pointto-point

networks

with

low

to

medium

multicast

membership

-LRB-

of

the

graph

nodes

-RRB-

We

consider

a

graph

with

less

than

of

the

possible

edges

in

a

complete

graph

to

be

a

sparse

graph

This

definition

leads

to

test

graphs

with

low-average

degree

at

each

node

We

restrict

our

analysis

to

sparse

networks

for

two

reasons

-LRB-

i

-RRB-

they

are

more

representative

of

real

point-to-point

networks

and

-LRB-

ii

-RRB-

they

are

inherently

more

difficult

to

solve

because

in

general

fewer

feasible

solutions

exist

in

a

sparse

network

than

in

a

dense

one

Similarly

the

simulated

multicast

groups

are

small

relative

to

the

size

of

the

network

reflecting

likely

multicast

applications

such

as

video-conferencing

or

distance

education

The

heuristics

are

compared

on

the

basis

of

three

criteria

competitiveness

CPU

time

and

differences

between

successive

trees

Note

that

our

results

are

not

specific

to

any

particular

type

of

network

such

as

the

Internet

or

ATM

networks

but

apply

to

both

connectionless

and

virtual-circuit-based

networks

Our

results

show

that

heuristic

ARIES

performs

extremely

well

often

producing

solutions

close

in

quality

to

those

generated

by

a

good

static

Steiner

heuristic

In

addition

it

often

outperformed

two

known

heuristics

the

Edge-Bounded

Algorithm

-LRB-

EBA

-RRB-

and

GREEDY

Further

the

algorithm

may

be

tuned

to

achieve

the

desired

tradeoff

between

performance

and

cost

The

difference

between

successive

trees

produced

by

ARIES

is

often

small

reducing

the

disruption

caused

by

rearrangements

The

remainder

of

this

paper

is

organized

as

follows

Section

II

reviews

previous

heuristics

for

the

on-line

Steiner

problem

and

summarizes

their

bounds

Section

III

describes

our

new

on-line

heuristic

and

Section

IV

derives

an

upper

bound

on

its

competitiveness

Section

V

presents

simulations

results

comparing

our

algorithm

to

previous

on-line

heuristics

Finally

Section

VI

concludes

the

paper

with

a

discussion

of

the

results

Appendix

A

contains

the

detailed

derivation

of

an

upper

bound

on

the

competitiveness

of

ARIES

II

Previous

Algorithms

for

the

On-Line

Steiner

Problem

in

Networks

This

section

summarizes

previous

algorithms

to

solve

the

on-line

Steiner

problem

We

use

the

following

basic

definitions

and

notations

in

the

paper

The

cost

of

a

tree

is

the

sum

of

its

edge

weights

Multicast

nodes

are

referred

to

as

members

and

non-multicast

nodes

as

non-members

The

distance

between

two

nodes

is

defined

to

be

the

distance

of

the

shortest

path

between

them

Likewise

the

distance

between

a

node

and

a

tree

is

the

minimum

among

the

shortest

paths

between

the

node

and

every

node

in

the

tree

Finally

the

distance

between

two

trees

is

the

distance

of

the

shortest

among

all

paths

between

any

node

in

one

tree

and

any

node

in

the

other

In

his

original

paper

on

the

on-line

multicast

problem

-LRB-

referred

to

as

the

dynamic

multipoint

problem

-RRB-

Waxman

divides

on-line

heuristics

into

two

types

those

that

allow

rearrangement

of

the

tree

and

those

that

do

not

-LSB-

-RSB-

In

this

first

paper

and

a

subsequent

one

Waxman

and

Imase

describe

a

heuristic

of

each

type

-LSB-

-RSB-

-LSB-

-RSB-

We

summarize

both

heuristics

below

for

the

reader

's

convenience

A.

Heuristic

GREEDY

The

non-rearrangement

on-line

heuristic

GREEDY

-LSB-

-RSB-

-LSB-

-RSB-

perturbs

the

existing

tree

as

little

as

possible

For

each

add

request

it

connects

the

new

member

to

the

nearest

tree

node

using

the

shortest

path

For

each

delete

request

GREEDY

deletes

only

leaf

nodes

If

this

deletion

creates

a

non-member

leaf

GREEDY

also

deletes

the

new

leaf

This

continues

until

no

non-member

leaves

remain

B

The

Edge-Bounded

Algorithm

-LRB-

EBA

-RRB-

The

rearrangement

heuristic

EBA

-LRB-

the

edge-bounded

algorithm

-RRB-

-LSB-

-RSB-

enforces

bounds

on

the

distance

between

nodes

in

the

tree

after

each

change

and

performs

rearrangements

when

the

distance

exceeds

a

set

bound

EBA

starts

by

converting

the

original

graph

to

a

corresponding

distance

graph

The

distance

graph

is

a

complete

graph

on

the

same

set

of

nodes

as

in

the

original

graph

with

the

cost

of

each

edge

-LRB-

i

j

-RRB-

assigned

as

the

cost

of

a

shortest

path

between

the

nodes

i

and

j

in

the

original

graph

The

multicast

tree

is

also

represented

in

terms

of

its

distance

graph

equivalent

Let

G

and

T

represent

the

distance

graphs

corresponding

to

the

original

graph

G

and

the

tree

T

respectively

For

each

add

request

EBA

selects

the

least-cost

edge

in

the

distance

graph

G

from

the

new

member

v

to

the

nodes

in

the

existing

tree

This

edge

represents

the

shortest

path

between

the

new

member

v

and

the

closest

tree

node

in

the

original

graph

G

The

tree

T

is

extended

by

appending

this

least-cost

edge

EBA

then

compares

the

cost

of

the

maximum-cost

edge

in

the

path

from

the

new

member

v

to

every

other

node

u

in

the

tree

T

with

the

cost

of

the

edge

-LRB-

u

v

-RRB-

in

G

The

latter

represents

the

cost

of

a

shortest

path

between

the

nodes

u

and

v

in

the

original

graph

G

If

the

cost

of

this

maximum-cost

edge

is

more

than

ffi

times

that

of

the

edge

-LRB-

u

v

-RRB-

in

G

the

former

edge

is

deleted

from

T

and

replaced

with

the

edge

-LRB-

u

v

-RRB-

This

ensures

that

the

cost

of

the

multicast

tree

after

rearrangements

is

bounded

by

times

the

cost

of

a

Steiner

tree

found

by

pruning

a

minimum

spanning

tree

of

the

graph

G

The

cost

of

the

latter

in

turn

is

no

more

than

twice

that

of

an

optimal

Steiner

tree

Since

Imase

and

Waxman

chose

a

value

of

for

the

constant

ffi

in

-LSB-

-RSB-

we

also

use

ffi

in

our

simulations

This

ensures

that

the

cost

of

the

multicast

tree

found

by

EBA

is

always

within

times

that

of

an

optimal

Steiner

tree

for

the

multicast

group

For

each

delete

request

EBA

's

actions

depend

on

the

deleted

node

's

degree

with

respect

to

the

tree

T

If

the

node

has

degree

three

or

more

no

action

is

taken

If

the

node

has

degree

one

it

is

deleted

just

as

in

GREEDY

If

the

node

has

degree

two

it

and

its

incident

edges

are

deleted

splitting

the

tree

into

two

components

These

two

components

are

then

reconnected

by

an

edge

e

chosen

as

follows

Let

vi

and

vj

be

the

neighboring

vertices

of

the

deleted

node

in

T

before

it

was

deleted

The

edge

e

is

chosen

so

that

the

cost

of

the

maximum-cost

edge

in

the

path

between

vi

and

vj

in

T

is

minimized

EBA

also

requires

that

the

tree

T

produced

after

each

add

or

delete

operation

be

an

extension

tree

for

its

set

of

multicast

members

An

extension

tree

is

one

that

contains

all

multicast

members

and

for

which

the

degree

of

every

non-member

node

is

greater

than

two

If

the

tree

T

does

not

satisfy

this

property

it

is

modified

as

follows

If

a

nonmember

node

v

in

T

has

degree

the

node

v

and

its

incident

edges

are

deleted

from

T

The

resulting

components

are

then

reconnected

just

as

outlined

in

the

previous

paragraph

that

is

by

means

of

an

edge

chosen

to

minimize

the

cost

of

the

maximum-cost

edge

in

the

path

between

the

neighbors

of

the

deleted

node

This

is

repeated

until

no

non-member

nodes

with

degree

remain

in

T

C

The

Geographic-Spread

Dynamic

Multicast

Heuristic

A

second

rearrangement

heuristic

is

Kadirire

's

GSDM

the

geographic-spread

dynamic

multicast

routing

algorithm

-LSB-

-RSB-

When

adding

nodes

this

heuristic

relies

on

exploring

four

explicit

connection

configurations

between

the

new

member

and

three

nearby

nodes

in

the

existing

tree

For

each

add

request

it

identifies

the

tree

node

closest

to

the

new

member

and

its

two

closest

multicast

neighbors

in

the

tree

The

heuristic

then

chooses

the

least-cost

configuration

among

four

possible

ways

to

connect

the

new

member

to

the

three

identified

nodes

If

more

than

one

cheapest

alternative

exists

GSDM

chooses

the

one

with

greatest

geographic

spread

-LSB-

-RSB-

For

each

delete

request

GSDM

be

haves

exactly

as

GREEDY

does

D.

Bounds

for

On-Line

Heuristics

Waxman

and

Imase

-LSB-

-RSB-

provide

bounds

for

the

competitiveness

of

all

non-rearrangement

heuristics

in

general

and

GREEDY

in

specific

when

only

add

requests

are

honored

Here

competitiveness

is

defined

as

the

ratio

between

the

cost

of

a

multicast

tree

found

by

the

heuristic

and

that

of

an

optimal

tree

The

lower

bound

for

all

non-rearrangement

algorithms

considering

only

add

requests

is

-LRB-

ni

-RRB-

c

and

the

upper

bound

for

GREEDY

is

-LRB-

ni

-RRB-

where

ni

is

the

number

of

nodes

added

to

the

tree

while

processing

the

requests

ri

These

bounds

are

shown

in

Figure

Westbrook

-LSB-

-RSB-

provides

a

tighter

upper

bound

for

heuristic

GREEDY

when

only

add

requests

are

honored

This

upper

bound

is

O

-LRB-

-LRB-

dmax

Copt

ni

-RRB-

-RRB-

where

dmax

is

the

maximum

distance

between

members

along

the

tree

and

Copt

is

the

cost

of

an

optimal

tree

for

the

modified

multicast

group

Imase

and

Waxman

have

shown

that

no

such

finite

bound

exists

if

delete

requests

are

also

honored

-LSB-

-RSB-

A

rearrangeable

heuristic

however

can

have

a

finite

bound

for

competitiveness

for

both

add

and

delete

requests

For

example

heuristic

EBA

's

upper

bound

is

where

ffi

is

EBA

's

constant

as

described

in

Section

II-B

In

both

our

simulations

and

Imase

and

Waxman

's

paper

ffi

and

the

upper

bound

is

therefore

-LSB-

-RSB-

No

similar

bounds

are

known

for

GSDM

III

Heuristic

ARIES

While

our

simulation

results

show

the

solutions

produced

by

GREEDY

to

be

comparable

to

those

of

EBA

in

terms

of

their

competitiveness

on

many

of

our

random

test

graphs

the

former

still

suffers

from

the

disadvantage

that

it

may

perform

poorly

for

delete

requests

A

superior

rearrangeable

heuristic

would

be

one

that

combines

GREEDY

's

light

computation

requirements

with

the

ability

to

force

a

rearrangement

when

the

competitiveness

of

the

solution

tree

has

degraded

beyond

a

certain

threshold

This

was

our

motivation

for

developing

heuristic

ARIES

Like

GREEDY

ARIES

does

the

minimum

necessary

modifications

to

the

existing

tree

for

each

add

and

delete

60 80 100 120

140 160 180 200

Cost

-LRB-

Heuristic

-RRB-

Cost

-LRB-

Optimal

-RRB-

Added

Tree

Nodes

Upper

Bound

for

GREEDY

Lower

Bound

for

All

Non-rearrangement

Heuristics

Fig.

Bounds

on

the

competitiveness

of

non-rearrangement

heuristics

for

add

requests

member

deleted

member

Fig.

A

tree

with

one

deleted

multicast

member

node

request

For

each

add

request

ARIES

joins

the

new

member

to

the

existing

tree

by

its

shortest

path

to

the

tree

For

each

delete

request

ARIES

deletes

the

node

only

if

it

is

a

leaf

The

difference

lies

in

ARIES

's

rearrangement

mechanism

When

the

accumulated

damage

to

a

part

of

the

tree

is

judged

to

be

too

high

ARIES

rearranges

that

region

of

the

tree

as

described

in

the

next

paragraph

Formally

damage

to

the

entire

tree

is

measured

by

the

tree

's

degradation

factor

C

-LRB-

i

-RRB-

Copt

-LRB-

i

-RRB-

where

C

-LRB-

i

-RRB-

is

the

cost

of

the

modified

tree

after

request

ri

and

Copt

-LRB-

i

-RRB-

is

the

cost

of

an

optimal

Steiner

tree

after

this

same

request

ri

As

the

tree

is

modified

this

degradation

factor

will

tend

to

increase

Informally

ARIES

monitors

the

degradation

factor

of

the

heuristic

tree

and

rearranges

portions

of

the

tree

as

necessary

to

reduce

the

degradation

factor

In

the

example

given

in

Figure

the

grey

shaded

region

of

the

tree

is

the

part

of

the

tree

most

affected

by

the

deletion

of

the

white

node

The

deleted

node

is

not

removed

from

the

tree

but

merely

marked

as

a

former

member

of

the

multicast

group

If

ARIES

judges

that

the

damage

to

the

tree

introduced

by

the

delete

operation

exceeds

a

given

threshold

only

the

grey

shaded

portion

of

the

tree

would

be

rearranged

sparing

the

majority

of

the

tree

from

disruption

during

the

rearrangement

In

this

way

the

effort

required

to

maintain

a

low-cost

tree

is

performed

only

within

a

region

of

the

tree

in

the

vicinity

of

the

update

Damage

to

the

tree

is

monitored

by

a

number

of

counters

within

multicast

member

nodes

that

register

the

number

of

changes

-LRB-

additions

or

deletions

-RRB-

in

their

immediate

vicinity

Each

member

node

has

one

counter

corresponding

to

each

of

its

edges

that

are

part

of

the

tree

When

a

member

node

is

deleted

or

a

new

node

added

the

node

sends

a

message

to

all

its

multicast

neighbors

to

increase

their

counters

by

one

Propagation

of

the

counter-update

messages

is

confined

to

regions

within

the

tree

bordered

by

multicast

members

so

that

rearrangements

can

be

confined

to

these

regions

as

well

A

rearrangement

is

triggered

when

the

value

of

a

counter

in

a

multicast

node

exceeds

a

chosen

threshold

We

will

later

formalize

the

concept

of

the

region

used

to

confine

the

rearrangements

A.

Definitions

and

Notations

Having

outlined

the

basic

concepts

we

can

now

formalize

our

description

of

ARIES

We

begin

by

introducing

the

following

assumptions

and

definitions

We

assume

that

additions

and

deletions

occur

one

at

a

time

with

adequate

time

between

events

to

allow

each

node

's

edge

counters

to

settle

before

the

next

addition

or

deletion

event

We

further

assume

that

a

reliable

protocol

is

used

to

communicate

counter

updates

within

the

network

We

define

the

union

of

a

graph

G

-LRB-

V

E

-RRB-

and

a

path

P

denoted

as

G

-LSB-

P

as

a

graph

-LRB-

V

-RRB-

whose

vertex

set

is

the

union

of

V

and

the

vertices

in

P

and

whose

edge

set

is

the

union

of

E

and

the

edges

of

P

In

addition

we

use

the

convenient

notations

v

G

and

e

G

to

denote

that

a

vertex

v

is

part

of

the

graph

G

and

an

edge

e

belong

to

the

set

of

edges

in

G

respectively

Let

W

-LRB-

t

-RRB-

denote

the

set

of

network

nodes

belonging

to

the

multicast

session

at

time

t.

Let

t

represent

the

time

the

multicast

session

was

first

set

up

In

general

the

multicast

tree

for

W

-LRB-

t

-RRB-

may

contain

four

different

types

of

nodes

at

any

time

t

Stable

multicast

nodes

These

are

nodes

currently

belonging

to

the

multicast

group

W

-LRB-

t

-RRB-

that

have

either

remained

in

the

group

throughout

the

interval

-LRB-

t

-RRB-

or

have

caused

a

rearrangement

since

their

addition

A

node

i

W

-LRB-

t

-RRB-

is

defined

as

a

stable

multicast

node

if

it

satisfies

one

of

the

following

conditions

-LRB-

a

-RRB-

Node

i

has

remained

a

member

of

the

multicast

group

since

the

group

was

first

set

up

that

is

i

W

-LRB-

o

-RRB-

for

all

o

in

the

interval

o

t

-LRB-

b

-RRB-

A

part

of

the

multicast

tree

containing

i

was

rearranged

since

the

most

recent

addition

of

i

to

the

multicast

group

We

refer

to

the

set

of

stable

multicast

nodes

at

time

t

as

Z

-LRB-

t

-RRB-

or

simply

as

Z.

Note

that

the

set

does

not

include

those

multicast

members

in

W

-LRB-

t

-RRB-

that

were

added

since

first

setting

up

the

multicast

session

at

time

and

have

not

caused

a

rearrangement

Deleted

nodes

These

are

nodes

that

were

once

part

of

the

multicast

group

but

were

since

deleted

A

node

i

W

-LRB-

t

-RRB-

is

defined

as

a

deleted

node

if

it

satisfies

the

following

condition

Let

o

t

be

the

last

time

i

was

a

member

of

the

multicast

group

Then

no

rearrangements

have

occurred

in

any

part

of

the

multicast

tree

containing

i

during

the

interval

-LRB-

o

t

-RRB-

We

use

D

-LRB-

t

-RRB-

or

simply

D

to

denote

the

set

of

deleted

nodes

at

time

t.

Appended

nodes

An

appended

node

is

one

that

was

added

to

the

group

after

it

was

formed

and

has

not

been

involved

in

a

rearrangement

since

it

was

added

Formally

a

node

i

W

-LRB-

t

-RRB-

is

defined

as

an

appended

node

if

the

following

condition

is

satisfied

Let

o

be

the

time

at

which

node

i

was

last

added

to

the

multicast

group

W

Then

no

rearrangements

have

occurred

in

any

part

of

the

multicast

tree

containing

i

during

the

interval

-LRB-

o

t

-RRB-

We

use

A

-LRB-

t

-RRB-

or

simply

A

to

denote

the

set

of

appended

nodes

at

time

t.

Non-multicast

nodes

These

are

nodes

currently

not

belonging

to

any

of

the

previous

three

categories

A

node

belongs

to

this

set

S

-LRB-

t

-RRB-

if

it

satisfies

one

of

the

following

conditions

-LRB-

a

-RRB-

Node

j

was

never

part

of

the

multicast

group

W

during

the

interval

-LRB-

t

-RRB-

or

-LRB-

b

-RRB-

node

j

was

last

deleted

from

W

at

time

o

t

and

a

rearrangement

occurred

in

a

part

of

the

multicast

tree

containing

j

during

the

interval

-LRB-

o

t

-RRB-

We

refer

to

this

set

of

non-multicast

nodes

as

S-nodes

If

V

is

the

set

of

nodes

in

the

network

and

W

-LRB-

t

-RRB-

the

members

of

the

multicast

group

at

time

t

the

following

relations

hold

at

any

time

t

V

Z

-LRB-

t

-RRB-

-LSB-

D

-LRB-

t

-RRB-

-LSB-

A

-LRB-

t

-RRB-

-LSB-

S

-LRB-

t

-RRB-

stable

member

node

-LRB-

Z-node

-RRB-

non-member

node

-LRB-

S-node

-RRB-

modified

node

-LRB-

M-node

-RRB-

Fig.

A

multicast

tree

containing

two

modified

regions

and

W

-LRB-

t

-RRB-

Z

-LRB-

t

-RRB-

-LSB-

A

-LRB-

t

-RRB-

We

refer

to

the

set

of

multicast

nodes

W

-LRB-

t

-RRB-

Z

-LRB-

t

-RRB-

-LSB-

A

-LRB-

t

-RRB-

at

time

t

as

the

set

of

active

multicast

nodes

The

damage

to

the

multicast

tree

is

in

the

areas

surrounding

the

deleted

and

appended

nodes

We

use

modified

node

or

M-node

as

a

common

term

to

refer

to

both

these

types

of

nodes

That

is

the

set

of

modified

nodes

is

defined

by

M

-LRB-

t

-RRB-

D

-LRB-

t

-RRB-

-LSB-

A

-LRB-

t

-RRB-

Since

the

area

of

damage

to

the

multicast

tree

is

confined

to

the

modified

nodes

and

the

stable

multicast

neighbors

surrounding

them

it

becomes

necessary

to

formalize

the

concept

of

multicast

neighbor

Definition

Two

nodes

i

j

Z

-LRB-

t

-RRB-

-LSB-

M

-LRB-

t

-RRB-

are

multicast

neighbors

in

T

if

and

only

if

either

-LRB-

i

-RRB-

i

and

j

are

directly

connected

through

an

edge

in

T

or

-LRB-

ii

-RRB-

the

path

between

i

and

j

in

T

passes

through

only

nodes

in

the

set

S

-LRB-

t

-RRB-

For

example

in

Figure

the

multicast

neighbors

of

node

a

are

b

c

d

e

and

f

If

rearrangements

are

performed

locally

they

should

be

applied

to

areas

where

the

damage

is

likely

to

be

maximum

The

following

definition

allows

grouping

of

M-nodes

into

regions

so

that

rearrangements

can

be

confined

within

one

or

more

of

the

regions

where

changes

have

occurred

Definition

A

modified

region

Ri

of

a

multicast

tree

T

is

a

subtree

of

T

defined

as

follows

Ri

contains

at

least

one

modified

node

in

the

set

M

If

a

modified

node

j

is

in

Ri

then

every

multicast

neighbor

of

j

in

T

is

also

in

Ri

If

two

nodes

j

and

k

belong

to

Ri

then

all

the

edges

in

the

path

between

j

and

k

in

T

are

included

in

Rj

Thus

for

a

given

M-node

j

the

modified

region

containing

j

is

the

maximal

connected

subtree

of

T

containing

only

S

nodes

or

M-nodes

as

its

internal

nodes

A

leaf

node

of

Ri

may

be

either

a

Z-node

or

a

pendant

M-node

in

T

while

an

internal

node

must

be

an

M-node

We

refer

to

a

modified

region

simply

as

region

for

convenience

When

a

local

rearrangement

is

performed

on

T

the

edges

in

the

region

are

the

candidates

for

rearrangement

For

example

the

modified

nodes

in

the

example

tree

of

Figure

form

two

modified

regions

and

B.

Algorithm

Description

Having

introduced

the

concept

of

a

region

we

can

now

describe

the

details

of

the

algorithm

The

number

of

modified

nodes

in

each

region

is

monitored

by

a

set

of

counters

one

within

each

Z-node

belonging

to

the

region

Since

a

Z-node

can

be

part

of

as

many

distinct

regions

as

its

degree

the

maximum

number

of

counters

needed

in

a

Z-node

is

equal

to

its

degree

When

the

multicast

tree

is

initially

set

up

the

counters

in

each

node

are

reset

to

zero

At

any

time

only

the

counters

in

the

Z-nodes

are

active

the

counters

in

other

nodes

are

inactive

and

have

a

a

value

of

zero

by

definition

When

a

Z-node

is

deleted

or

a

new

node

added

each

Z-node

in

that

region

increment

its

counter

corresponding

to

the

region

This

can

be

achieved

by

the

modified

node

broadcasting

a

counter-update

message

to

all

the

Z-nodes

within

the

region

along

the

multicast

tree

The

pseudocode

of

ARIES

is

shown

in

Figure

Given

a

Steiner

tree

Ti

and

an

update

request

ri

the

objective

of

the

algorithm

is

to

determine

a

Steiner

tree

Ti

for

the

modified

multicast

group

after

the

update

Note

that

ri

can

either

be

an

add

request

or

a

delete

request

these

two

cases

are

handled

separately

If

the

request

is

an

add

the

new

node

v

is

connected

to

the

existing

tree

Ti

via

the

shortest

path

from

v

to

Ti

The

only

exception

to

this

is

the

trivial

case

when

v

is

part

of

the

existing

tree

The

new

node

is

then

marked

an

an

A-node

If

the

node

was

previously

marked

as

a

D

node

no

further

processing

is

needed

Otherwise

if

all

of

v

's

multicast

neighbors

are

currently

Z-nodes

then

a

new

region

is

formed

containing

node

v

and

its

multicast

neighbors

On

the

other

hand

if

v

is

already

part

of

a

region

at

least

one

of

the

multicast

neighbors

of

v

must

be

an

M

node

In

either

case

let

Rj

denote

the

region

containing

v.

Every

Z-node

u

within

region

Rj

has

a

counter

cu

j

whose

value

is

equal

to

the

number

of

M-nodes

within

Rj

each

of

these

counters

must

be

increased

by

when

v

is

added

to

the

multicast

tree

This

is

accomplished

by

broadcasting

a

counter-update

message

from

v

to

all

Z-nodes

within

the

region

With

delete

requests

the

situation

can

be

more

complex

First

if

the

node

being

deleted

is

a

leaf

node

of

the

multicast

tree

it

is

simply

marked

as

an

M-node

and

a

counter-update

message

is

transmitted

to

all

the

Z-nodes

in

the

region

enclosing

it

in

the

case

of

the

add

operation

explained

in

the

previous

paragraph

Since

paths

to

deleted

leaf

nodes

can

be

removed

from

the

multicast

tree

with

little

effort

an

optional

pruning

algorithm

is

used

to

remove

any

inactive

subtrees

in

Ti

left

behind

by

the

deleted

node

This

step

is

optional

because

such

subtrees

will

automatically

be

removed

when

the

region

undergoes

a

rearrangement

When

the

node

being

deleted

v

has

a

degree

of

or

more

it

may

belong

to

more

than

one

region

Thus

when

v

is

deleted

all

regions

containing

v

must

be

merged

into

a

single

region

This

is

achieved

by

v

sending

counter-update

messages

to

all

Z-nodes

within

regions

it

is

currently

part

of

The

counter

increment

sent

to

a

Z-node

in

region

Rk

is

one

plus

the

sum

of

all

counters

in

v

excluding

that

representing

region

Rk

Thus

when

the

counters

are

updated

by

adding

the

increment

all

counters

corresponding

to

the

merged

region

are

now

set

to

the

total

number

of

M-nodes

within

the

region

After

processing

each

add

or

delete

request

the

algorithm

checks

to

see

if

the

quality

of

the

tree

has

degraded

beyond

a

threshold

This

checking

is

accomplished

simply

by

comparing

the

counter

values

for

the

region

enclosing

the

newly

modified

node

against

a

chosen

threshold

If

the

counter

values

reach

the

set

threshold

a

rearrangement

is

triggered

Although

any

static

Steiner

heuristic

can

be

used

to

perform

the

rearrangement

we

use

the

Kruskal

shortest-path

heuristic

-LRB-

K-SPH

-RRB-

for

a

number

of

reasons

First

it

is

naturally

suited

to

constructing

multicast

trees

by

combining

fragments

of

the

tree

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

Second

the

algorithm

lends

itself

to

distributed

asynchronous

implementation

-LSB-

-RSB-

Finally

K-SPH

has

been

shown

to

be

among

the

best

of

Steiner

heuristics

in

terms

of

the

cost

of

the

multicast

trees

produced

in

our

previous

evaluations

-LSB-

-RSB-

-LSB-

-RSB-

Using

K-SPH

the

rearrangement

algorithm

proceeds

as

follows

If

Rj

is

the

region

in

which

the

rearrangement

was

triggered

the

algorithm

removes

all

the

D-nodes

and

edges

in

Rj

The

fragments

left

behind

are

then

combined

Given

existing

tree

Ti

find

new

tree

Ti

taking

into

account

request

ri

case

ri

of

add

request

for

node

v

if

v

Ti

then

Join

node

v

to

Ti

by

shortest

path

to

closest

node

u

Let

P

-LRB-

v

u

-RRB-

denote

the

shortest

path

from

v

to

Ti

Ti

Ti

-LSB-

Pv

u

Expand

the

region

Rj

enclosing

node

v

to

include

paths

from

v

to

its

multicast

neighbors

Let

PT

-LRB-

v

k

-RRB-

denote

the

path

from

v

to

node

k

Ti

along

the

tree

Ti

for

all

multicast

neighbors

k

of

v

Rj

Rj

-LSB-

PT

-LRB-

v

k

-RRB-

end

for

end

if

mark

node

v

as

an

A-node

if

v

was

not

a

D-node

in

Ti

Update

edge

counters

in

all

Z-nodes

of

Rj

Let

ck

j

node

k

's

edge

counter

for

Rj

for

all

Z-nodes

u

Rj

do

cu

j

cu

j

end

for

if

cu

j

threshold

u

Rj

then

rearrange

Rj

end

if

end

if

delete

request

for

node

v

Rj

mark

node

v

as

a

D-node

if

v

's

degree

then

for

all

Z-nodes

u

Rj

do

cu

j

cu

j

end

for

perform

optional

pruning

algorithm

-LRB-

Figure

-RRB-

else

if

v

's

degree

then

Need

to

merge

regions

containing

node

v

into

one

for

all

Rk

with

v

Rk

do

Update

counters

in

each

region

containing

v

for

all

Z-nodes

u

Rk

do

cu

k

cu

k

X

m

k

cv

m

end

for

end

for

Let

Rj

refer

to

the

merged

region

if

cu

j

threshold

u

Rj

then

rearrange

Rj

end

if

end

if

end

case

Fig.

Pseudocode

for

heuristic

ARIES

member

deleted

node

Before

rearrangementAfter

rearrangementBefore

deleting

E

Fig.

Operation

of

ARIES

on

a

delete

request

into

a

new

multicast

tree

by

the

K-SPH

algorithm

Note

that

each

of

the

A-nodes

in

Rj

forms

a

fragment

by

itself

K-SPH

combines

the

fragments

pairwise

starting

with

two

that

have

the

shortest

distance

between

them

and

repeating

the

procedure

until

a

single

fragment

remains

The

counters

corresponding

to

the

region

that

triggered

the

rearrangement

are

reset

to

zero

once

the

rearrangement

is

completed

In

addition

all

the

A-nodes

in

the

region

are

updated

as

Z-nodes

and

all

D-nodes

become

S-nodes

Figure

illustrates

the

operation

of

the

algorithm

with

respect

to

a

delete

request

The

numbers

in

the

figure

denote

counter

values

within

nodes

Initially

there

is

a

single

modified

region

in

the

multicast

tree

containing

the

deleted

node

F

the

counters

in

C

D

and

E

corresponding

to

this

region

have

a

value

of

When

node

E

is

deleted

the

region

expands

to

include

nodes

A

and

B

and

the

counters

in

A

B

C

D

corresponding

to

this

region

are

updated

to

If

the

threshold

is

set

as

a

rearrangement

is

now

triggered

The

rearrangement

algorithm

removes

the

nodes

E

and

F

and

all

the

edges

within

the

region

leaving

behind

four

disconnected

nodes

A

B

C

D

The

nodes

are

reconnected

using

K-SPH

to

obtain

the

new

tree

The

choice

of

the

threshold

to

trigger

a

rearrangement

affects

the

behavior

of

the

algorithm

significantly

A

larger

threshold

reduces

the

frequency

of

rearrangements

but

may

cause

large

variations

in

the

cost

of

the

multicast

tree

in

comparison

to

that

of

an

optimal

tree

In

addition

if

rearrangements

are

performed

infrequently

more

work

may

be

needed

each

time

the

rearrangement

algorithm

is

invoked

In

Section

IV

we

provide

an

analytical

upper

bound

on

the

competitiveness

of

the

algorithm

as

a

function

of

the

threshold

value

selected

C.

Pruning

Algorithm

After

each

delete

operation

the

multicast

tree

may

be

further

pruned

by

removing

subtrees

consisting

of

only

deleted

nodes

The

optimization

is

initiated

by

each

D

node

that

is

currently

a

leaf

of

the

multicast

tree

The

procedure

is

performed

iteratively

until

no

D-nodes

remain

as

leaves

of

the

tree

Each

D-node

that

is

currently

a

leaf

of

the

multicast

tree

sends

a

message

to

its

neighboring

node

in

the

tree

Any

S-nodes

in

the

tree

with

a

degree

of

receiving

such

a

message

simply

relay

it

to

its

neighbor

on

the

opposite

side

along

the

tree

The

message

terminates

when

it

reaches

a

Z-node

an

M-node

or

an

S-node

with

more

than

two

incident

edges

in

the

tree

Depending

on

the

type

of

node

where

the

message

terminates

the

following

actions

are

performed

by

the

terminating

node

If

the

message

reaches

a

Z-node

say

x

the

entire

path

from

x

to

the

leaf

node

that

originated

the

message

is

removed

from

the

tree

The

counter

in

x

corresponding

to

the

path

is

reset

to

zero

If

the

message

terminates

at

an

M-node

say

y

the

path

from

y

to

the

originating

leaf

node

is

removed

as

in

the

previous

case

In

addition

y

broadcasts

a

counter

update

message

to

all

the

nodes

in

its

region

to

decrement

their

counters

by

one

Finally

if

the

terminating

node

is

an

S-node

say

s

the

path

from

s

to

the

originating

node

is

removed

as

in

the

above

cases

In

addition

s

is

now

marked

as

a

D-node

Since

the

number

of

modified

nodes

in

the

region

enclosing

the

originating

leaf

node

remains

unchanged

no

counter-update

messages

are

generated

in

this

case

It

is

easy

to

see

that

when

performed

iteratively

the

above

distributed

algorithm

removes

all

inactive

subtrees

from

the

multicast

tree

Pseudocode

for

this

pruning

algorithm

is

shown

in

Figure

D

A

Distributed

Version

of

ARIES

Heuristic

ARIES

was

described

in

this

section

as

a

centralized

algorithm

for

clarity

To

be

practical

however

the

algorithm

must

have

a

distributed

implementation

The

rearrangement

heuristic

we

have

chosen

heuristic

K-SPH

already

has

a

published

distributed

implementation

-LSB-

-RSB-

The

remaining

portion

of

ARIES

may

be

implemented

as

shown

by

the

finite

state

machine

in

Figure

In

the

following

description

of

the

distributed

version

of

ARIES

each

multicast

tree

node

executes

the

finite

state

machine

shown

in

Figure

As

each

node

joins

the

multicast

tree

either

as

part

of

the

original

multicast

tree

or

while

D-nodes

with

degree

remain

in

Ti

do

u

D-node

with

degree

v

neighbor

-LRB-

u

-RRB-

while

v

an

S-node

of

degree

do

delete

node

u

and

edge

-LRB-

u

v

-RRB-

from

Ti

u

v

v

neighbor

-LRB-

u

-RRB-

end

while

delete

node

u

and

edge

-LRB-

u

v

-RRB-

from

Ti

Let

Ri

region

enclosing

v

case

v

of

type

Z

cv

i

type

D

or

A

if

c

then

broadcast

counter

increment

of

to

all

Z-nodes

in

Ri

type

S

Mark

v

as

a

D-node

end

case

end

while

Fig.

Pseudocode

for

the

pruning

algorithm

waitinitDistributed

ARIES

donecounter

threshold

updatemessage

rearrange

update

counter

counter

threshold

rearrangement

algorithm

K-SPH

Fig.

The

finite

state

machine

in

member

nodes

corresponding

to

a

distributed

implementation

of

ARIES

later

via

addition

or

rearrangement

the

node

enters

state

init

After

initializing

the

counter

for

each

adjacent

edge

to

zero

the

node

enters

state

wait

The

node

leaves

the

wait

state

on

receiving

a

counter-update

message

or

when

a

rearrangement

of

its

region

is

triggered

A

node

receiving

an

update

message

on

one

of

its

edges

enters

state

update

counter

and

updates

the

corresponding

edge

counter

by

adding

or

subtracting

the

value

contained

in

the

update

message

These

update

messages

are

generated

by

tree

nodes

directly

involved

in

the

addition

or

deletion

of

a

multicast

member

For

example

the

tree

node

closest

to

a

new

member

sends

an

update

message

on

all

of

its

adjacent

edges

when

that

new

member

joins

the

tree

by

connecting

itself

to

the

closest

node

via

its

shortest

path

Upon

receipt

of

this

update

message

all

members

of

the

nearest

node

's

region

increment

their

edge

counters

to

reflect

the

addition

of

the

new

member

Now

consider

the

case

of

a

delete

request

as

shown

in

Figure

Here

node

E

is

deleted

and

becomes

a

D-node

Just

before

changing

its

state

node

E

sends

an

update

message

out

all

of

its

adjacent

edges

which

arrives

at

nodes

A

B

C

and

D.

Note

that

node

F

simply

multicasts

the

update

message

down

the

tree

since

it

is

not

a

multicast

member

This

ensures

that

all

of

the

members

in

the

region

containing

E

receive

a

copy

of

the

update

message

The

value

of

each

update

message

sent

from

node

E

is

the

necessary

increment

to

bring

all

the

edge

counters

in

the

new

merged

region

to

parity

For

example

the

update

message

sent

from

E

to

neighbors

A

and

B

has

a

value

of

while

the

update

message

sent

to

neighbors

C

and

D

has

a

value

of

These

values

are

computed

as

described

in

the

pseudocode

for

ARIES

shown

in

Figure

From

state

update

counter

the

node

either

returns

to

state

wait

or

enters

the

rearrangement

state

The

rearrangement

state

is

entered

only

if

its

edge

counter

is

greater

than

the

threshold

value

We

assume

reliable

delivery

of

all

update

messages

and

that

all

nodes

use

the

same

threshold

value

to

trigger

a

rearrangement

Since

all

edge

counters

in

a

region

have

the

same

value

as

shown

above

it

follows

that

every

node

at

the

boundary

of

the

region

needing

rearrangement

will

receive

an

update

message

on

an

edge

causing

the

counter

to

exceed

its

threshold

value

In

the

rearrangement

state

the

node

resets

the

counter

corresponding

to

the

edge

through

which

the

message

arrived

at

the

node

drops

the

edge

from

the

multicast

tree

and

executes

the

distributed

rearrangement

algorithm

to

connect

the

fragments

so

formed

Consider

Figure

again

The

region

being

rearranged

consists

of

node

F

and

its

adjacent

edges

After

rearrangement

all

of

the

edges

and

nodes

in

the

region

have

been

replaced

and

the

edge

counters

in

the

region

reset

to

zero

Addition

and

deletion

of

members

as

well

as

the

generation

of

update

messages

can

be

performed

by

the

rearrangement

algorithm

since

distributed

Steiner

algorithms

such

as

that

described

in

-LSB-

-RSB-

already

provide

mechanisms

to

connect

nodes

by

their

shortest

path

and

propagate

messages

in

a

distributed

fashion

Note

that

we

did

not

describe

the

additional

provisions

necessary

in

an

environment

in

which

update

messages

do

not

arrive

reliably

While

these

additional

provisions

are

of

interest

they

are

outside

the

scope

of

this

paper

Additional

research

in

the

robustness

of

such

a

distributed

algorithm

is

an

area

of

future

research

IV

Algorithm

Analysis

We

now

turn

to

an

analysis

of

heuristic

ARIES

to

evaluate

its

worst-case

behavior

Our

primary

objective

is

to

derive

an

upper

bound

on

its

competitiveness

between

rearrangements

Between

rearrangements

ARIES

behaves

similar

to

GREEDY

and

shares

its

bounds

From

Imase

and

Waxman

-LSB-

-RSB-

we

know

that

the

upper

bound

considering

only

add

requests

is

-LRB-

ni

-RRB-

where

ni

is

the

number

of

nodes

in

the

tree

Ti

after

request

ri

However

no

such

finite

bounds

exist

for

GREEDY

with

respect

to

delete

requests

In

Technical

Report

-LRB-

available

from

UC

Santa

Cruz

-RRB-

we

derive

an

upper

bound

for

the

competitiveness

of

ARIES

considering

both

add

and

delete

requests

For

reasons

of

brevity

we

do

not

include

the

proof

in

this

paper

but

only

cite

its

main

result

Starting

from

an

optimal

solution

the

ratio

of

the

cost

of

the

multicast

tree

produced

by

ARIES

to

that

of

an

optimal

Steiner

tree

at

any

time

before

a

rearrangement

is

triggered

is

given

by

C

-LRB-

t

-RRB-

Copt

-LRB-

t

-RRB-

cth

where

cth

is

the

counter

threshold

that

triggers

a

rearrangement

The

time

complexity

of

ARIES

is

also

of

interest

and

is

heavily

influenced

by

the

Steiner

heuristic

used

for

rearrangement

This

is

because

the

time

complexity

of

ARIES

between

rearrangements

is

simply

the

cost

of

updating

edge

counters

and

region

membership

while

the

time

complexity

of

each

rearrangement

is

that

of

the

Steiner

heuristic

invoked

In

our

simulations

we

used

heuristic

K-SPH

with

a

time

complexity

O

-LRB-

-RRB-

where

z

is

the

number

of

multicast

members

Consequently

the

time

complexity

of

ARIES

is

dominated

by

that

of

the

rearrangement

algorithm

Section

V-B

includes

a

discussion

of

the

effect

of

graph

size

and

multicast

group

size

on

ARIES

V.

Performance

Evaluation

Having

provided

an

analytical

upper

bound

on

the

competitiveness

of

solutions

produced

by

ARIES

we

now

turn

to

its

average-case

behavior

Since

the

analytical

upper

bound

provides

little

insight

into

the

algorithm

's

average

behavior

we

simulated

ARIES

on

a

large

number

of

random

test

networks

We

found

that

in

practice

the

competitiveness

of

the

solutions

produced

by

ARIES

was

much

better

than

the

upper

bound

In

fact

the

majority

of

the

solutions

found

were

within

of

the

best

solution

found

by

a

static

Steiner

heuristic

in

terms

of

their

competitiveness

The

details

of

our

simulations

follow

A.

Evaluation

Methodology

We

simulated

our

heuristic

on

randomly

generated

sparse

test

networks

each

with

multicast

members

We

also

simulated

heuristics

GREEDY

and

EBA

and

include

their

results

for

comparison

We

chose

to

use

random

networks

because

our

choice

of

suitable

existing

networks

was

very

limited

Instead

we

generated

random

networks

as

described

below

We

consider

our

graphs

to

be

sparse

because

each

has

less

than

of

the

possible

edges

present

in

a

complete

graph

We

chose

multicast

members

for

two

reasons

-LRB-

i

-RRB-

we

believe

it

likely

that

a

multicast

group

will

consist

of

a

minority

of

graph

nodes

and

-LRB-

ii

-RRB-

multicast

members

in

a

graph

presents

a

difficult

problem

for

Steiner

heuristics

Each

heuristic

received

requests

to

add

or

delete

a

multicast

member

for

each

test

network

The

probability

of

an

add

request

is

related

to

Nt

the

number

of

nodes

in

the

tree

by

the

function

-LSB-

-RSB-

-LRB-

Nt

-RRB-

-LRB-

Nt

-RRB-

-LRB-

-RRB-

Nt

The

value

of

determines

the

equilibrium

point

at

which

the

probability

of

an

add

or

delete

is

equally

likely

In

our

simulations

was

set

to

the

fraction

of

multicast

members

As

a

result

each

test

network

received

approximately

the

same

number

of

addition

and

deletion

requests

In

our

simulations

each

request

was

presented

to

the

network

only

after

the

previous

request

was

completely

serviced

The

test

graphs

were

generated

to

resemble

real

networks

in

a

manner

similar

to

that

of

Doar

-LSB-

-RSB-

Each

of

the

nodes

is

distributed

across

a

Cartesian

coordinate

plane

with

minimum

and

maximum

coordinates

-LRB-

-RRB-

and

-LRB-

-RRB-

creating

a

forest

of

nodes

spread

across

this

plane

The

nodes

are

then

connected

by

a

random

spanning

tree

This

tree

is

generated

by

iteratively

considering

a

random

edge

between

nodes

and

accepting

those

edges

that

connect

distinct

components

The

remaining

redundant

edges

of

the

graph

are

chosen

by

examining

each

possible

edge

-LRB-

x

y

-RRB-

and

generating

a

random

number

r

If

r

is

less

than

a

probability

function

P

-LRB-

x

y

-RRB-

based

on

the

distance

between

x

and

y

then

the

edge

is

accepted

Each

edge

's

distance

is

its

rectilinear

distance

We

used

the

probability

function

P

-LRB-

x

y

-RRB-

e?dx

y

where

dx

y

is

the

rectilinear

distance

between

nodes

x

and

y

-LSB-

-RSB-

The

parameters

ff

and

govern

the

density

of

the

graph

Increasing

ff

increases

the

number

of

connections

to

nodes

far

away

and

increasing

increases

the

number

of

edges

from

each

node

After

some

experimentation

we

chose

ff

and

for

generating

the

graphs

used

in

this

simulation

These

values

produced

graphs

of

realistic

density

and

degree-distribution

Each

heuristic

was

implemented

on

top

of

our

Steiner

problem

simulation

platform

designed

to

provide

a

level

playing

field

upon

which

to

base

comparisons

It

supplies

the

basic

graph

manipulation

routines

used

by

the

heuristics

such

as

procedures

for

adding

and

deleting

edges

B.

Simulation

Results

In

this

section

we

present

our

simulation

results

for

heuristic

ARIES

For

comparison

we

also

include

simulation

results

for

heuristics

GREEDY

and

EBA

The

metrics

we

use

are

competitiveness

CPU

time

and

the

number

of

edges

that

are

different

between

successive

multicast

trees

Competitiveness

is

defined

to

be

the

ratio

between

the

heuristic

tree

cost

and

the

cost

of

the

static

heuristic

K-SPH

for

each

test

case

Ideally

we

should

be

comparing

heuristic

results

to

the

optimal

tree

for

each

case

but

this

is

impractical

Instead

we

use

static

heuristic

K-SPH

as

our

benchmark

Our

second

criterion

CPU

time

is

measured

by

the

CPU

seconds

on

an

IBM

for

a

serial

implementation

of

the

algorithms

Our

third

criterion

the

difference

between

successive

trees

is

measured

by

the

number

of

edges

that

are

different

between

successive

trees

Figure

presents

the

cumulative

distribution

for

the

competitiveness

for

four

variants

of

heuristic

ARIES

as

well

as

heuristics

GREEDY

and

EBA

Each

variant

of

ARIES

uses

a

different

threshold

value

and

For

example

in

each

region

of

the

tree

may

have

at

most

five

modified

nodes

without

triggering

a

rearrangement

As

seen

in

Figure

all

of

ARIES

's

variants

occupy

the

favorable

upper

half

As

rearrangements

are

postponed

longer

ARIES

's

cumulative

distribution

becomes

closer

to

that

of

GREEDY

The

two

lowest

distributions

belong

to

heuristics

GREEDY

and

EBA

For

a

competitiveness

of

more

than

EBA

produced

higher-quality

solutions

more

often

as

compared

to

GREEDY

This

is

because

no

rearrangements

are

performed

by

the

latter

for

delete

requests

Considering

only

the

best

of

the

solutions

produced

by

each

heuristic

however

GREEDY

slightly

outperformed

EBA

in

competitiveness

This

is

because

of

the

use

of

distance

graphs

in

EBA

A

Steiner

trees

produced

by

EBA

resembles

a

merged

shortest

path

tree

when

translated

back

Competitiveness

-LRB-

Heuristic/K-SPH

-RRB-

Cumulative

Percentage

of

Cases

ARIES

ARIES

GREEDY

EBA

Fig.

The

cumulative

distribution

of

competitiveness

for

each

heuristic

CPU

Seconds

Cumulative

Percentage

of

Cases

GREEDY

EBA

Fig.

The

cumulative

distribution

of

CPU

time

for

each

heuristic

Edges

Changed

Cumulative

Percentage

of

Cases

GREEDY

EBA

Fig.

The

cumulativedistribution

of

edges

changed

for

each

heuristic

to

its

real-world

equivalent

and

we

know

merged

shortestpath

trees

to

be

sub-optimal

-LSB-

-RSB-

This

disadvantage

is

exaggerated

because

EBA

requires

internal

non-member

nodes

to

have

degree

greater

than

two

EBA

's

competitiveness

distribution

becomes

superior

to

that

of

GREEDY

for

competitiveness

greater

than

because

the

former

the

tree

when

additions

or

deletions

violate

its

constraints

Figure

complements

Figure

by

presenting

the

cumulative

distributions

for

CPU

seconds

Heuristic

GREEDY

has

the

lightest

computation

requirements

and

finished

all

cases

well

within

CPU

seconds

By

comparison

ARIES

's

least

expensive

variant

completed

of

its

cases

within

the

same

CPU

time

heuristic

EBA

completed

of

its

cases

and

ARIES

's

most

expensive

variant

completed

of

its

cases

Thus

varying

ARIES

's

threshold

may

significantly

affect

its

computational

requirements

Figure

completes

the

comparison

of

heuristics

by

displaying

the

number

of

edges

that

are

different

between

successive

trees

for

all

fifty

test

networks

This

criterion

would

be

important

to

applications

seeking

the

smallest

possible

change

between

multicast

trees

such

as

video

conferencing

and

real-time

data

broadcasts

Heuristic

GREEDY

changes

successive

trees

the

least

accomplishing

each

change

using

no

more

than

four

edges

in

our

test

networks

ARIES

variants

and

appear

next

followed

by

heuristic

EBA

and

ARIES

variant

All

of

the

ARIES

variants

and

EBA

change

Heuristic

Number

of

Average

Number

of

Total

CPU

Rearrangements

Edges

Changed

Seconds

Static

K-SPH

EBA

GREEDY

TABLE

I

Comparison

of

number

of

rearrangements

number

of

edges

changed

between

successive

trees

and

running

time

of

the

heuristics

for

one

example

graph

over

all

requests

successive

trees

by

six

or

less

edges

for

over

of

the

test

cases

Here

we

see

that

as

ARIES

's

threshold

is

relaxed

the

number

of

edges

changed

between

successive

graph

also

decreases

For

our

fifty

test

networks

the

two

most

promising

variants

of

ARIES

were

and

Both

cases

strike

a

middle

ground

between

frequent

rearrangements

and

degradation

in

solution

quality

Their

competitiveness

is

roughly

equivalent

even

though

rearranges

the

graph

less

frequently

than

In

our

simulations

represents

the

best

balance

among

competitiveness

computational

effort

and

edges

changed

The

best

threshold

value

in

general

will

of

course

depend

on

the

problem

instance

The

next

two

figures

Figures

and

present

tree

cost

and

CPU

time

as

a

function

of

each

addition

or

deletion

request

for

one

example

network

of

the

fifty

test

networks

used

in

our

simulations

In

Figure

static

heuristic

K-SPH

is

the

lowest

curve

and

represents

the

baseline

Heuristic

ARIES

is

often

closest

to

this

baseline

trading

position

with

heuristic

EBA

after

rearrangements

are

triggered

Heuristic

GREEDY

shows

the

largest

variation

from

the

baseline

Figure

compares

the

CPU

requirements

of

static

heuristic

K-SPH

and

heuristic

ARIES

Heuristic

K-SPH

is

the

upper

curve

plotting

the

CPU

time

necessary

to

recompute

for

each

case

As

seen

in

the

figure

the

computational

requirement

of

ARIES

is

light

except

for

the

occasional

rearrangements

shown

by

spikes

in

the

curve

The

number

and

size

of

these

spikes

are

dependent

on

the

counter

threshold

chosen

Heuristic

EBA

by

contrast

performs

a

more

uniform

amount

of

work

for

most

requests

This

difference

can

be

more

clearly

seen

in

Figure

Here

heuristic

EBA

is

contrasted

with

heuristic

While

each

of

the

seven

spikes

in

the

plot

for

exceeds

CPU

seconds

the

remaining

cases

fall

well

below

CPU

seconds

EBA

spreads

its

CPU

seconds

more

evenly

over

requests

often

taking

five

times

as

much

CPU

time

for

the

same

request

as

ARIES

Table

I

summarizes

the

number

of

rearrangements

average

number

of

edges

changed

and

total

CPU

time

spent

for

each

of

the

ARIES

variants

EBA

and

GREEDY

for

one

sample

graph

over

all

requests

Heuristic

rearranges

the

tree

most

times

with

the

highest

average

number

of

edges

different

between

successive

trees

Heuristic

EBA

follows

rearranging

the

tree

times

and

changes

an

average

of

edges

between

successive

trees

The

remaining

ARIES

variants

perform

between

and

rearrangements

and

have

moderate

values

for

the

average

number

of

edge

changes

between

successive

trees

This

is

primarily

the

result

of

confining

rearrangements

within

modified

regions

A

cursory

examination

of

Table

I

could

lead

to

the

false

assumption

that

every

variant

of

ARIES

is

much

more

expensive

on

average

than

heuristic

EBA

This

is

a

false

impression

Even

though

each

variant

of

ARIES

requires

more

CPU

seconds

overall

than

heuristic

EBA

most

of

this

CPU

time

is

spent

in

a

handful

of

rearrangements

The

remaining

cases

as

many

as

out

of

rearrangements

require

only

enough

CPU

time

to

update

counters

In

addition

even

the

most

expensive

variant

of

ARIES

is

inexpensive

compared

to

static

K

SPH

every

variant

of

ARIES

requires

less

than

of

the

CPU

time

of

static

K-SPH

We

find

this

to

be

an

acceptable

tradeoff

for

increased

competitiveness

In

addition

the

advantage

of

EBA

in

terms

of

its

lower

CPU

time

is

unlikely

to

hold

in

a

distributed

implementation

since

the

algorithm

can

not

be

extended

to

the

distributed

case

in

a

straightforward

manner

Heuristic

GREEDY

of

course

performs

no

rearrangements

has

the

minimum

value

in

terms

of

the

average

number

of

edges

changed

between

successive

trees

and

requires

the

least

CPU

time

Figures

through

illustrate

the

effect

of

graph

size

and

multicast

membership

size

on

heuristic

ARIES

The

rearrangement

threshold

in

all

these

experiments

was

set

at

The

six

graphs

are

divided

into

three

pairs

of

graphs

showing

the

effect

of

varying

the

graph

size

and

multicast

group

size

separately

Each

pair

presents

one

measure

-LCB-

algorithm

competitiveness

CPU

time

used

or

edges

changed

-LCB-

as

a

function

of

either

graph

size

or

multicast

membership

size

Graph

size

was

varied

between

and

nodes

in

node

increments

while

multicast

membership

was

varied

between

and

of

the

nodes

in

a

graph

Each

point

along

with

its

error

bar

represents

additions

or

deletions

on

a

test

graph

Consider

algorithm

competitiveness

first

Figures

and

show

that

ARIES

is

relatively

insensitive

to

changes

in

either

graph

size

or

multicast

membership

These

results

are

consistent

with

our

worst-case

bounds

for

competitiveness

given

in

Section

IV

since

our

bound

depended

only

on

the

threshold

value

While

our

worst-case

competitiveness

bound

was

c

times

optimal

these

simulation

results

show

average

case

competitiveness

much

better

than

the

bound

These

results

for

competitiveness

are

consistent

with

our

experience

with

Steiner

tree

heuristics

both

in

this

paper

and

previous

research

-LSB-

-RSB-

-LSB-

-RSB-

While

maximum

and

minimum

values

for

competitiveness

were

relatively

random

between

cases

they

seemed

to

vary

most

for

small

graphs

This

is

also

consistent

since

adding

or

deleting

members

in

a

small

graph

may

significantly

affect

graph

cost

and

consequently

the

ratio

between

a

heuristic

tree

's

cost

and

that

of

the

baseline

tree

Other

variations

between

cases

are

likely

influenced

more

by

test

graph

characteristics

than

graph

size

or

multicast

membership

The

next

pair

of

graphs

Figures

and

represent

average

maximum

and

minimum

values

for

CPU

time

as

a

function

of

graph

size

and

multicast

membership

Here

the

dependence

of

ARIES

processing-time

requirements

on

graph

size

or

multicast

membership

are

weaker

than

might

be

expected

This

is

because

most

of

the

time

a

member

addition

or

deletion

does

not

trigger

a

rearrangement

and

consequently

consumes

little

CPU

time

From

the

height

of

the

maximum

error

bar

in

each

case

we

see

that

rearrangements

can

and

do

require

significant

CPU

time

However

the

average

case

CPU

time

is

very

close

to

that

of

the

minimum

error

bar

since

no

rearrangement

is

necessary

most

of

the

time

This

in

fact

was

a

design

goal

of

ARIES

since

we

wished

to

preserve

heuristic

GREEDY

's

low

CPU

time

requirement

while

improving

its

competitiveness

The

maximum

error

bars

in

Figure

display

a

closer

relationship

between

CPU

time

and

graph

size

than

shown

by

the

maximum

error

bars

in

Figure

In

both

cases

however

the

time

complexity

of

the

static

Steiner

heuristics

employed

for

rearrangements

heuristic

K-SPH

is

O

-LRB-

-RRB-

This

bound

shows

that

rearrangement

CPU

time

is

indeed

dependent

on

both

multicast

membership

size

and

graph

size

even

if

it

is

overshadowed

by

test

graph

characteristics

other

than

graph

size

and

multicast

membership

The

final

pair

of

graphs

included

for

completeness

Figures

and

show

that

the

number

of

edges

changed

between

successive

graphs

is

very

insensitive

to

graph

size

or

multicast

membership

These

results

are

consistent

with

expectations

since

multicast

tree

characteristics

such

as

node

degree

member

proximity

and

concentration

would

more

likely

affect

the

number

of

edges

changed

between

membership

changes

than

graph

size

or

multicast

membership

The

low

average

values

represent

the

majority

of

cases

where

no

rearrangement

is

necessary

The

maximum

error

bars

represent

cases

where

rearrangements

forced

considerable

changes

to

the

multicast

tree

VI

Concluding

Remarks

In

this

paper

we

proposed

and

evaluated

a

new

rearrangeable

heuristic

ARIES

for

the

on-line

multicast

problem

The

algorithm

is

based

on

monitoring

the

accumulated

damage

to

the

multicast

tree

within

local

regions

of

the

tree

as

nodes

are

added

and

deleted

and

triggering

a

rearrangement

when

the

number

of

changes

within

a

connected

subtree

crosses

a

set

threshold

We

presented

analytical

upper

bounds

on

the

competitiveness

of

the

algorithm

and

presented

simulation

results

using

competitiveness

CPU

time

and

differences

between

successive

trees

as

the

metrics

The

results

were

compared

with

those

from

two

previous

heuristics

GREEDY

and

EBA

Of

the

heuristics

evaluated

heuristic

ARIES

performed

closest

in

competitiveness

to

the

baseline

solutions

produced

by

the

static

Steiner

heuristic

K-SPH

It

also

lends

itself

to

tuning

by

varying

its

counter

threshold

that

triggers

a

rearrangement

The

quality

of

solutions

produced

by

ARIES

on

our

test

networks

on

average

was

considerably

better

than

the

worst-case

analytical

bound

In

addition

successive

trees

were

often

very

close

reducing

the

disruption

caused

by

large

rearrangements

Among

the

variants

of

ARIES

emerged

as

the

most

promising

for

our

test

networks

The

best-performing

variant

for

a

particular

case

will

of

course

depend

on

the

network

and

the

pattern

of

updates

to

the

multicast

tree

In

addition

to

our

description

of

heuristic

ARIES

as

a

centralized

heuristic

we

have

also

outlined

how

this

heuristic

could

be

implemented

as

a

distributed

asynchronous

algorithm

This

distributed

version

would

likely

have

the

greatest

practical

use

At

least

two

open

topics

remain

First

the

upper

bound

for

competitiveness

we

have

shown

assumes

that

the

multicast

tree

is

restored

to

an

optimal

tree

after

each

rearrangement

A

more

difficult

but

interesting

problem

would

be

to

bound

the

competitiveness

across

more

than

one

rearrangement

taking

into

account

the

sub-optimal

solutions

produced

by

the

rearrangement

algorithm

Second

we

have

only

sketched

a

distributed

implemen

tation

of

ARIES

Admittedly

a

distributed

implementation

in

our

ideal

assumed

environment

would

be

straightforward

In

a

real

environment

however

network

nodes

may

enter

and

leave

the

multicast

group

simultaneously

Multiple

simultaneous

modifications

to

the

multicast

membership

could

result

in

race

conditions

under

which

the

distributed

algorithm

does

not

converge

Mechanisms

must

be

devised

to

coordinate

the

updates

in

a

consistent

manner

In

addition

counter

updates

need

to

be

communicated

to

tree

nodes

within

a

local

region

reliably

These

difficulties

however

are

not

unique

to

ARIES

but

arise

in

the

design

of

many

distributed

algorithms

ARIES

represents

a

balance

among

the

conflicting

demands

of

competitiveness

of

the

solutions

produced

computational

requirements

and

complexity

of

implementation

Of

particular

interest

are

its

finite

upper

bounds

on

competitiveness

that

holds

for

both

addition

and

deletion

of

multicast

members

Coupled

with

its

good

average

case

behavior

this

make

ARIES

a

suitable

choice

for

real-world

on-line

multicast

routing

applications

References

-LSB-

-RSB-

F.

Bauer

and

A.

Varma

Degree-constrained

multicasting

in

point-to-point

networks

in

Proc

IEEE

INFOCOM

Boston

Apr.

pp.

-LCB-

-LSB-

-RSB-

L.

Berry

Graph

theoretic

models

for

multicast

communications

in

Traffic

theories

for

new

telecommunications

services

ITC

Specialists

Seminar

Adelaide

Australia

Sept.

pp.

-LCB-

-LSB-

-RSB-

V.

Kompella

J.

Pasquale

and

G.

Polyzos

Multicasting

for

multimedia

applications

in

Proc

IEEE

INFOCOM

New

York

NY

May

pp.

-LCB-

-LSB-

-RSB-

J.

Beasley

An

sst-based

algorithm

for

the

steiner

problem

in

graphs

Networks

vol

pp.

-LCB-

-LSB-

-RSB-

K.

Bharath-Kumar

and

Jaffe

Routing

to

multiple

destinations

in

computer

networks

IEEE

Transactions

on

Communications

vol

no.

pp.

-LCB-

Mar.

-LSB-

-RSB-

F.

Hwang

and

D.

Richards

Steiner

tree

problems

Networks

vol

pp.

-LCB-

-LSB-

-RSB-

P.

Winter

Steiner

problem

in

networks

a

survey

Networks

vol

no.

pp.

-LCB-

-LSB-

-RSB-

M.

Smith

and

P.

Winter

Path-distance

heuristics

for

the

steiner

problem

in

undirected

networks

Algorithmica

vol

no.

pp

-LCB-

-LSB-

-RSB-

H.

Takahashi

and

A.

Matsuyama

An

approximate

solution

for

the

steiner

problem

in

graphs

Math

Japonica

vol

no.

pp

-LCB-

-LSB-

-RSB-

S.

Voss

Steiner

's

problem

in

graphs

heuristic

methods

Discrete

Applied

Mathematics

vol

pp.

-LCB-

-LSB-

-RSB-

S.

Deering

and

D.

Cheriton

Multicast

routing

in

datagram

internetworks

and

extended

lans

ACM

Transactions

on

Computer

Systems

vol

no.

pp.

-LCB-

-LSB-

-RSB-

S.

Deering

D.

Estrin

D.

Farinacci

V.

Jacobson

et

al.

The

pim

architecture

for

wide-area

multicast

routing

IEEE/ACM

Transactions

on

Networking

vol

no.

pp.

-LCB-

-LSB-

-RSB-

T.

Ballardie

P.

Francis

and

J.

Crowcroft

Core

based

trees

-LRB-

cbt

-RRB-

an

architecture

for

scalable

inter-domain

multicast

routing

Computer

Communication

Review

vol

no.

pp.

-LCB-

-LSB-

-RSB-

J.

Westbrook

and

D.

Yan

Greedy

algorithms

for

the

on-line

steiner

tree

and

generalized

steiner

problems

in

Algorithms

and

data

structures

Third

Workshop

WADS

Montreal

Quebec

Canada

Aug.

pp.

-LCB-

-LSB-

-RSB-

B.

Waxman

Routing

of

multipoint

connections

IEEE

Journal

on

Selected

Areas

in

Communications

vol

no.

pp.

-LCB-

Dec.

-LSB-

-RSB-

M.

Imase

and

B.

Waxman

Dynamic

steiner

tree

problem

SIAM

J.

Disc

Math.

vol

no.

pp.

-LCB-

Aug.

-LSB-

-RSB-

J.

Kadirire

Comparison

of

dynamic

multicast

routing

algorithms

for

wide-area

packet

switched

-LRB-

asynchronous

transfer

mode

-RRB-

networks

in

Proc

IEEE

INFOCOM

Boston

Apr.

pp.

-LCB-

-LSB-

-RSB-

F.

Bauer

and

A.

Varma

Distributed

algorithms

for

multicast

path

setup

in

data

networks

in

Proc

IEEE

GLOBECOM

Singapore

Nov.

pp.

-LCB-

-LSB-

-RSB-

M.

Doar

and

I.

Leslie

How

bad

is

naive

multicast

routing

in

Proc

IEEE

INFOCOM

San

Francisco

CA

Apr.

pp.

-LCB-

Member

Addition

or

Deletion

Event

Tree

Cost

greedy

eba

K-SPH

Fig.

Tree

cost

for

one

example

graph

over

all

requests

Member

Addition

or

Deletion

Event

CPU

Time

-LRB-

in

Seconds

-RRB-

K-SPH

Fig.

CPU

time

for

one

example

graph

over

all

requests

Member

Addition

or

Deletion

Event

CPU

Seconds

eba

Fig.

Comparison

of

CPU

time

of

heuristics

EBA

and

for

one

example

graph

over

all

requests

60 80 100 120

140 160 180 200

Graph

Size

-LRB-

in

Nodes

-RRB-

Competitiveness

-LRB-

Heuristic/K-SPH

-RRB-

Average

Fig.

Competitiveness

of

heuristic

ARIES

versus

graph

size

Multicast

Membership

-LRB-

in

Percent

-RRB-

Competitiveness

-LRB-

Heuristic/K-SPH

-RRB-

Average

Fig.

Competitiveness

of

heuristic

ARIES

versus

multicast

group

size

60 80 100 120

140 160 180 200

Graph

Size

-LRB-

in

Nodes

-RRB-

CPU

Seconds

Average

Fig.

Heuristic

ARIES

CPU

time

versus

graph

size

Multicast

Membership

-LRB-

in

Percent

-RRB-

CPU

Seconds

Average

Fig.

Heuristic

ARIES

CPU

time

versus

multicast

group

size

60 80 100 120

140 160 180 200

Graph

Size

-LRB-

in

Nodes

-RRB-

Edges

Changed

Average

Fig.

Number

of

edges

changed

versus

graph

size

Multicast

Membership

-LRB-

in

Percent

-RRB-

Edges

Changed

Average

Fig.

Number

of

edges

changed

versus

multicast

group

size

multicast algorithms
on-line steiner problem
rearrangeable multicast algorithms