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@inrialpes.fr http://www-rp.lip6.fr/ http://www.inrialpes.fr/planete/roca/ Université P&M. Curie / INRIA Rhône-Alpes

2. low-end receiver CC layer 0, rate r0 layer 1, rate r1 layer 2, rate r2 layer 3, rate r3 Multicast distribution in several groups fragmentation and scheduling mid-range receiver ADUs CC CC high-end receiver 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 V. Roca

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! V. Roca

4. dropped! idle 230.1.2.3 group ! first hop mcast router Multicast Backbone traffic source packet to 230.1.2.3 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) V. Roca

5. PART 1: The cost of an idle multicast group V. Roca

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 V. Roca

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 V. Roca

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 there’s 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 V. Roca

9. local cache for this source SITE1 MSDP peer MSDP peer informs... source discovers informs... 230.1.2.3 MSDP peer MSDP peer local cache for this source local cache for this source 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 V. Roca

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 V. Roca

11. Multicast Backbone 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 V. Roca

12. PART 2 On-Demand Layer Addition (ODL) V. Roca

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... V. Roca

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 V. Roca

15. layers query & drop L3 R2 requests L2 & L3 LAYER_3 query & drop L2 R2 requests L1 LAYER_2 query & drop L1 LAYER_1 LAYER_0 (permanent base layer) t4 t1 t2 t3 time low-end receiver R2 high-end receiver R2 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: V. Roca

16. 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 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. Roca

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 => 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. Roca

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 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/RLC freely available on the authors’ home page... http://www.inrialpes.fr/planete/roca/ V. Roca

19. V. Roca

20. Sketch of ODL... cont’ • Distinguish between one time transmissions => synchronous start • And continuous transmissions => asynchronous start V. Roca

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) V. Roca

22. Layer 0 A B C D Layer 1 C D B D Layer 2 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 Ethernet => we don’t take into account the impacts of large scale multicast routing here ! V. Roca

23. Performance evaluations... cont’ • traffic at the source without ODL, duration 89.2 seconds high-end rx leaves low-end rx leaves V. Roca

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 V. Roca

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 V. Roca

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 ! => similar to signal sampling V. Roca

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 V. Roca

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 ? • 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. Roca

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 n°i) or not ? ALC assumes cumulative layers DSG assumes independant layers V. Roca