Université P&M. Curie / INRIA Rhône-Alpes On the use of On-Demand Layer Addition (ODL) with...
-
Upload
britton-wright -
Category
Documents
-
view
224 -
download
0
Transcript of Université P&M. Curie / INRIA Rhône-Alpes On the use of On-Demand Layer Addition (ODL) with...
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
The cost of an idle multicast group... (cont’)
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
The cost of an idle multicast group... (cont’)
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 !!!
YES, THERE IS A BENEFIT IN USING ODL
sourceMSDP peer
MSDP peerMSDP peer
MSDP peerinforms...
informs...discovers
local cache forthis source
local cache forthis source
local cache forthis source
SITE1
230.1.2.3
V. Roca10
The cost of an idle multicast group... (cont’)
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
The cost of an idle multicast group... (cont’)
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!
YES, THERE IS A BENEFIT IN USING ODL
MulticastBackbone
traffic source
reflector
unicast only sitelayered traffic
tunneled 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
Sketch of ODL... cont’
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_0
LAYER_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
Sketch of ODL... cont’
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 a
layer 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=40pkts
rates: 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
Performance evaluations... cont’
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
Performance evaluations... cont’
Summary
without ODLwithout ODL With ODLWith ODL
total durationtotal duration 89.2 s 51.9 s
traffic sent by sourcetraffic sent by source 2.176.710 bytes 1.631.425 bytes
traffic sent by receiverstraffic sent by receivers 0 2720 bytes
ODL 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
Performance evaluations... cont’
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 layers
DSG assumes independant layers