on the use of on-demand layer addition (odl) with multi-layer transmission techniques

Université P&M. Curie / INRIA Rhône-Alpes

On the use of On-Demand Layer Addition (ODL) with multi-layer

transmission techniques

Networked Group Communications (NGC2000) November 8-10th, 2000

[email protected] http://www-rp.lip6.fr/

http://www.inrialpes.fr/planete/roca/

V. Roca2

The context: multi-layer multicast transmissions

Motivations an efficient way to address receiver heterogeneityreceiver heterogeneity according to its “congestion control module” a receiver adds or drops a

layer dynamically...

used by hierarchical video coding, multicast file distribution, multicast streaming, etc.

ALC (Asynchronous Layered Coding) is currently being standardized

ADUs fragmentationand scheduling

mid-range receiver

high-end receiver

Multicastdistributionin several

groups

layer 0, rate r0

layer 1, rate r1

layer 2, rate r2

layer 3, rate r3

low-end receiverCC

CC

CC

V. Roca3

Question: “How many layers should a sender define?”

Today the number of layers (i.e. multicast groups) is fixed set in advance

(startup parameter, default value at compilation time)

there is a risk that only a small subset of these layers are actually used at a given time!

because this is an off-period because the content is less attractive than expected because the source largely over-estimated the receiver needs because specifying hundreds of layers is so easy ! because of a configuration error because of the all-too common idea that an idle group has no cost!

V. Roca4

Question ... (cont’)

Everybody knows that......the traffic sent to an idle group is usuallyusually dropped by the first-hop router

... but there are other hidden costshidden costs

The two contributions of this work: What is the cost of an idle multicast groupcost of an idle multicast group ? What can we do to reduce this costreduce this cost from an applicationapplication point of view ?

On-Demand Layer addition (ODL)

MulticastBackbone

traffic sourcefirst hop

mcast router

packet to 230.1.2.3

dropped! idle 230.1.2.3 group !

V. Roca5

PART 1:

The cost of an idle multicast group

V. Roca6

PART 1: The cost of an idle multicast group

No single answer -- Depends on the multicast routing protocol in use !

Example 1: Dense mode protocols

periodical flooding / pruning all the routers are concerned, even those who are not on the path to a

receiver forwarding state in multicast routers

at least 100 bytes for state information per group (mrouted 3.8)

YES THERE IS A BENEFIT IN USING ODL

ok, no longer used for WA multicast routing... but still in use by several sites

V. Roca7

The cost of an idle multicast group... (cont’)

Example 2: Sparse Mode PIM, PIM-SM

PIM-SM in “shared treeshared tree” mode

traffic is forwarded to RP and forwarding state is kept, even for an idle group !

YES, THERE IS A BENEFIT IN USING ODL

RP

source1st hoprouter

receiver1

receiver2(2) traffic tunneled to the RP

(3) delivery througha unidirectional shared tree centered at the RP

(1) traffic to mcast group

V. Roca8


Example 2: cont’

PIM-SM in “per-source shortest path treeper-source shortest path tree” mode

here forwarding state is only kept along the distribution tree, no flooding, packets can be dropped by the first hop router

ODL has little interest here... ...BUT there’s no “per-source tree” with an idle group!!!

RP

source1st hoprouter

receiver1

receiver2

(2) direct deliverythrough a RPF tree(1) traffic to mcast group

V. Roca9


Example 3: MSDP for inter-domain multicast routing

Well, PIM-SM alone is not sufficient... so use MSDP for source discovery...

MSDP signaling traffic is the same with idle groups !!!


sourceMSDP peer

MSDP peerMSDP peer

MSDP peerinforms...

informs...discovers

local cache forthis source



SITE1

230.1.2.3

V. Roca10


Example 4: Source Specific Multicast

The future multicast routing infrastructure ? Many problems are solved

(e.g. MSDP is no longer required...) Builds per-source tree Similar to PIM-SM in “per-source tree” mode

ODL has limited benefits here

V. Roca11


Example 5: Using reflectors

Situation: multicast is not available anywhere (will it be?) use reflectors for unicast/muticast integration

the traffic source is completely separated from the multicast source (ie. the reflector)! No feedback at all!


MulticastBackbone

traffic source

reflector

unicast only site layered traffictunneled in severalunicast connexions

multicast capable site

V. Roca12

PART 2

On-Demand Layer Addition (ODL)

V. Roca13

PART 2: Sketch of the ODL protocol

Assume first that...

each layer a multicast group cumulative scheme

(but ODL can also be used with non-cumulative schemes)

Layer management at the source

TO ADD A LAYER a source sends packets to a new group…

TO DROP A LAYER a source avoids sending packets to a group...the soft-state kept by routers will slowly disappear...

V. Roca14

Sketch of ODL... cont’

ODL is an end-to-end protocol(no assumption on network, immediately deployed)

it is the responsibility of a source source to check that each layer is effectively used

QUERY PRESENT PRESENT_OK messages followed by a DROP_LAYER if no answer

source

receiver 1

receiver 2

(1) QUERY

(2) timeout... answer

(3) PRESENT

(5) PRESENT_OK(6) cancel its reply

multicast backbone(4) cancel max.waiting time

V. Roca15


it is the responsibility of a receiver receiver to ask for an additional layer if not available

INFO_REQ INFO LAYER_REQ ADD_LAYER

a source can refuse to add a layer (e.g. if not enough resources left) example:

time

layers

LAYER_0LAYER_1

LAYER_2

LAYER_3

R2 requests L1

R2 requests L2 & L3 query & drop L3

query & drop L2

query & drop L1

(permanent base layer)

low-end receiver R2

high-end receiver R2

t1 t2 t3 t4

V. Roca16

A bit more in details

Receiver must not reply in multicast ! limit the use of multicast to sources only example: QUERY/PRESENT_OK => multicasted on target layer

PRESENT => unicasted unicasted to the source

Important parameters SOURCE: polling frequency: SOURCE: waiting time before dropping a layer if no answer to a query RECEIVER: maximum waiting time before answering a request

Promote scalable mechanisms ODL doesn’t know the number of receivers there is nothing new here!

V. Roca17

A bit more in details... cont’

Some situations are more complex

multiple sources sources can be heterogeneous too ODL must enable per-source signaling

receiver on the same host as a source in that case the receiver asks for all layers => defeats ODL ! use a TTL of 0 if all receivers are on the same host, the default TTL

otherwise

non cumulative transmission schemes well, it doesn’t change so much exception: signaling previously sent only on the base layer is now sent

on all the groups

V. Roca18

Conclusions

ODL is an end-to-end protocol, immediately deployable

keeps the number of layers to its required minimum to avoid idle groups

can be useful to avoid IP-multicast scalability problems e.g. when you’re not sure of the popularity of the content you’re

sending e.g. on the highest layers if you’re not sure there will be high-end

receivers

reverse-IGMP is a complementary approach (see paper)

we implemented ODL as well as ALC/RLCfreely available on the authors’ home page...http://www.inrialpes.fr/planete/roca/

V. Roca19

V. Roca20


Distinguish between one time transmissions=> synchronous start

And continuous transmissions=> asynchronous start

V. Roca21

A bit more in details... cont’

The two ODL timers of the source

Softstate timer period between two QUERY messages

keep it fixed, or make it depends on transmission rate of that layer: the faster transmissions occur, the lower the “softstate timer”

Tss(k) = min(max_Tss; max(min_Tss; 2 * av_cost / rate(k) - Tdrop))

DROP timer maximum waiting time before dropping alayer after a QUERY

depends in theory on maximum RTT which is difficult to evaluate use an adaptive algorithm for parameter RF (robustness factor) instead

Tdrop = RF * (reasonable_RTT + Tmaxwait)

V. Roca22

Performance evaluations

Testing conditions 1 source 5 layers, cumulative scheme,

av_cost=40pktsrates: 5, 10, 20, 40, 80 kbytes/s

1 high-end receiver receives all 5 layers 1 medium-end receiver receives 3 layers send a 400 kbyte file

Everybody connected to the same local Ethernetsame local Ethernet=> we don’t take into account the impacts of large scale multicast routing here !

Layer 2Layer 2B

D

Layer 1Layer 1 C D

Layer 0Layer 0 A B C D

V. Roca23

Performance evaluations... cont’

traffic at the source without ODL, duration 89.2 seconds

high-end rx leaves

low-end rx leaves

V. Roca24


traffic at the source with ODL, duration 51.9 seconds

high-end rx leaves

low-end rx leaves

detected !

detected !

QUERYs on layer 4

QUERYs on layer 3

QUERYs on layer 2

QUERYs on layer 1QUERYs on layer 0

drop layers 4 and 3

drop layers 2, 1 and 0

V. Roca25


Summarywithout ODLwithout ODL With ODLWith ODL

total durationtotal duration 89.2 s 51.9 straffic sent by sourcetraffic sent by source 2.176.710 bytes 1.631.425 bytestraffic sent by receiverstraffic sent by receivers 0 2720 bytesODL overheadODL overhead N/A 8776 bytes (0.54 %)gains brought by ODLgains brought by ODL N/A 25.1% less bytes

on a WAN, in addition to the previous local gains, there are: shorter group usage smaller forwarding table less management traffic

V. Roca26


Influences of the av_cost parameter...

av_cost is the average number of packets sent uselessly before the last receiver departure is detected

the higher av_cost, the faster the departure is detected, the lower the number of useless packets, but also the higher the ODL overhead

but this is a probabilistic result ! => similar to signal sampling

V. Roca27

Related works

dynamic source adaptation have usually a different goal (traffic adaptation, not group adaptation) example: RTCP

membership size estimation more complex than ODL which returns only a boolean value: yes or no

there is at least a member Express in theory includes member counting… but not the source only

implementation of Express!

multicast router forwarding state aggregation

V. Roca28

Future work

“Reverse IGMP”

the source queries the first-hop router to know if a group is used or not

with traditional IGMP, information flows from end-hosts to the first-hop router

requires an extension to IGMP

what are the limitations ? Is the information always known ?

it’s difficult to answer… greatly depends on the exact configuration example: PIM-SM when using the shared tree… the information is

known by the core which may be far from the source

V. Roca29

The context... (cont’)

One such solution is currently being standardized ALC (Asynchronous Layered Coding) for the general framework MRCC for congestion control

many different situations and models are asynchronous starts (AKA late-arrival) possible or not ?

pushpush versus on-demandon-demand models

are layers cumulative (i.e. receive all layers up to n°i) or not ?ALC assumes cumulative layersDSG assumes independant layers

on the use of on-demand layer addition (odl) with multi-layer transmission techniques

Documents