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

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

• Networked Group Communications (NGC2000) November
  8-10th, 2000
• vincent.roca_at_inrialpes.fr
  http//www-rp.lip6.fr/ http//www.inrialpes.fr/p
  lanete/roca/

2
The context multi-layer multicast transmissions

• Motivations
• an efficient way to address receiver
  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

3
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!

4
Question ... (cont)

• Everybody knows that...
• ...the traffic sent to an idle group is usually
  dropped by the first-hop router
• ... but there are other hidden costs
• The two contributions of this work
• What is the cost of an idle multicast group ?
• What can we do to reduce this cost from an
  application point of view ?
• ? On-Demand Layer addition (ODL)

5
PART 1

• The cost of an idle multicast group

6
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

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

• Example 2 Sparse Mode PIM, PIM-SM
• PIM-SM in shared 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

receiver1
RP
(2) traffic tunneled to the RP
receiver2
(3) delivery through a unidirectional shared
tree centered at the RP
1st hop router
source
(1) traffic to mcast group
8
The cost of an idle multicast group... (cont)

• Example 2 cont
• PIM-SM in per-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 theres no per-source tree with an idle
  group!!!

receiver1
RP
receiver2
1st hop router
source
(2) direct delivery through a RPF tree
(1) traffic to mcast group
9
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

10
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

11
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

multicast capable site
reflector
layered traffic tunneled in several unicast
connexions
unicast only site
traffic source
12
PART 2

• On-Demand Layer Addition (ODL)

13
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...

14
Sketch of ODL... cont

• ODL is an end-to-end protocol
• (no assumption on network, immediately deployed)
• it is the responsibility of a source to check
  that each layer is effectively used
• QUERY ? PRESENT ? PRESENT_OK messages
• followed by a DROP_LAYER if no answer

receiver 1
(1) QUERY
(5) PRESENT_OK
source
(6) cancel its reply
(3) PRESENT
receiver 2
(4) cancel max. waiting time
multicast backbone
(2) timeout... answer
15
Sketch of ODL... cont

• it is the responsibility of a 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

16
A bit more in details

• Receiver must not reply in multicast !
• limit the use of multicast to sources only
• example QUERY/PRESENT_OK gt multicasted on
  target layer
• PRESENT gt 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 doesnt know the number of receivers
• there is nothing new here!

17
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 gt
  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 doesnt change so much
• exception signaling previously sent only on the
  base layer is now sent on all the groups

18
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 youre not sure of the popularity of
  the content youre sending
• e.g. on the highest layers if youre not sure
  there will be high-end receivers
• reverse-IGMP is a complementary approach (see
  paper)
• we implemented ODL as well as ALC/RLC
• freely available on the authors home page...
• http//www.inrialpes.fr/planete/roca/

19
(No Transcript)
20
Sketch of ODL... cont

• Distinguish between one time transmissions
• gt synchronous start
• And continuous transmissions
• gt asynchronous start

21
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)

22
Performance evaluations

• Testing conditions
• 1 source 5 layers, cumulative scheme,
  av_cost40pkts
• 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 Ethernet
• gt we dont take into account the impacts of
  large scale multicast routing here !

23
Performance evaluations... cont

• traffic at the source without ODL, duration 89.2
  seconds

high-end rx leaves
low-end rx leaves
24
Performance evaluations... cont

• traffic at the source with ODL, duration 51.9
  seconds

high-end rx leaves
QUERYs on layer 4
detected !
drop layers 2, 1 and 0
drop layers 4 and 3
QUERYs on layer 3
low-end rx leaves
detected !
QUERYs on layer 2
QUERYs on layer 1
QUERYs on layer 0
25
Performance evaluations... cont

• Summary
• without ODL With ODL
• total duration 89.2 s 51.9 s
• traffic sent by source 2.176.710 bytes 1.631.425
  bytes
• traffic sent by receivers 0 2720 bytes
• ODL overhead N/A 8776 bytes (0.54 )
• gains 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

26
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 ! gt similar
  to signal sampling

27
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

28
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 ?
• its 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

29
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 ?
• push versus on-demand models
• are layers cumulative (i.e. receive all layers up
  to ni) or not ?
• ALC assumes cumulative layers
• DSG assumes independant layers