1 / 43

A Survey of Reliable Multicast Protocols

A Survey of Reliable Multicast Protocols. Projet Planète; INRIA Rhône-Alpes vincent.roca@inrialpes.fr http://www.inrialpes.fr/planete/people/roca November 13 th , 2001. Outline of the presentation. part 1- introduction part 2 - reliable multicast and associated high level services

lila-martin
Download Presentation

A Survey of Reliable Multicast Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Survey of Reliable Multicast Protocols Projet Planète; INRIA Rhône-Alpes vincent.roca@inrialpes.fr http://www.inrialpes.fr/planete/people/roca November 13th, 2001

  2. Outline of the presentation • part 1- introduction • part 2- reliable multicast and associated high level services • part 3- a small demo • part 4- selected bibliography

  3. Part 1 Introduction • Introduction: what is it and why/when should we use it?

  4. 194.199.25.100 source source site 2 host_1 host_1 Ethernet host_2 multicast router from logical view... ...to physical view receiver multicast group 225.1.2.3 multicast router site 1 Internet receiver multicast router host_3 host_2 host_3 Ethernet receiver 194.199.25.101 receiver 133.121.11.22 multicast distribution tree The Internet group model • multicast/group communications means... • 1  n as well as n  m • a group is identified by a class D IP address (224.0.0.0 to 239.255.255.255) • abstract notion that does not identify any host!

  5. The Internet group model... (cont’) • the group model is an open model • anybody can belong to a multicast group • no authorization is required • a host can belong to many different groups • no restriction • a source can send to a group, no matter whether it belongs to the group or not • membership not required • the group is dynamic, a host can subscribe to or leave at any time • a host (source/receiver) does not know the number/identity of members of the group

  6. The Internet group model... (cont’) • local-area multicast • use the potential diffusion capabilities of the physical layer (e.g. Ethernet) • efficient and straightforward • wide-area multicast • requires to go through multicast routers, use IGMP/multicast routing/... (e.g. DVMRP, PIM-DM, PIM-SM, PIM-SSM, MSDP, MBGP, BGMP, etc.) • routing in the same administrative domain is simple and efficient • inter-domain routing is complex, not fully operational • In this talk we won’t consider mcast routing!

  7. reliability mgmt congestion control other building blocks Multicast and the TCP/IP layered model Application higher-level services user space kernel space Socket layer UDP TCP multicast routing ICMP IP / IP multicast IGMP device drivers

  8. Why IP multicast? • scalability... • scales to an unlimited number of users • reduced costs... • cheaper equipment and access line • increased speed... • increases the delivery speed client access line content server use unicast? ISP and Internet client client access line content server ...or multicast? ISP and Internet client

  9. t0, tx starts... transmission receiver ready... ok, receiver leaves receiver ready... ok, receiver leaves The three delivery models • Streaming(e.g. for audio/video) • multimedia data requires efficiency due to its size • requires real-time, semi-reliable delivery • Push delivery • synchronous model where delivery is started at t0 • usually requires a fully reliable delivery, limited number of receivers time

  10. receiver ready... ok, receiver leaves receiver ready... ok, receiver leaves The three delivery models... (cont’) • On-demand delivery • popular content (video clip, software,update, etc.) is continuously distributed in multicast • users arrive at any time, download, and leave • possibility of millions of users, no real-time constraint transmission time

  11. Some multicast applications • collaborative work applications • many audio/video/application sharing/multicast file transfer/... applications, each with different needs • small to medium sized group • multi-user games (large virtual environments) • requires multicast for scalability, some level of reliability • can use multiple multicast groups for scoping

  12. Some multicast applications... (cont’) • content distribution within large corporations • central management of content (document, database, current version of a sofware projects, etc.) • regular delivery to remote facilities • need for secure, fully reliable transmissions

  13. Part 2 Reliable multicast and associated high-level services • State of the art of current research and standardization efforts

  14. Outline of the section • 2.1- challenges and scalability in reliable multicast • 2.2- various classes of reliable protocols • overview • the NORM PI • the TRACK PI • the ALC PI • 2.3- use of FEC (forward error correction) • 2.4- congestion control protocols

  15. 2.1- The challenges • IETF requirements (RFC 2357) • scalability 10...000s members/sources • congestion control fair in some respect to TCP • security if possible... SMUG (secure mcast group) • Other challenges • many different application requirements  “one size does not fit all” • various group models: closed (members known & fixed), semi-closed, open  reliability is more or less easy to provide • take into account the heterogeneity of receivers • be easy to use, configure (e.g. TRACK), monitor

  16. Reliable multicast scalability • many problems arise with 10000 receivers... • Problem 1: scalable control traffic • ACK each data packet (à la TCP)... oops, 10000ACKs/pkt! • NAK (negative ack) only if failure... oops, if pkt is lost close to src,10000 NAKs! • Problem 2: scalable retransmissions • if each receiver has 1% packets losses, each packet is sent several times... oops! • Problem 3: heterogeneity • send data reliably to everybody at the slowest receiver rate? High end receivers won’t be happy! • Problem 4: scalable membership management • if each receiver is disconnected once a day, membership changes every 8 minutes...

  17. Reliable multicast scalability... (cont’) • Problem 1: scalable control traffic • solution 1: feedback suppression at the receivers • each node picks a random backoff timer • send the NAK at timeout if loss not corrected • solution 2: proactive FEC (forward error correction) • send data plus additional FEC packets • any FEC packet can replace a lost data packet • solution 3: use a tree of intelligent routers/servers • use a tree for ACK aggregation and/or NAK suppression • see PGM

  18. Reliable multicast scalability... (cont’) • Problem 2: scalable retransmissions • solution 1: use proactive/reactive FEC • proactive  always send data + FEC • reactive  in case of retransmission, send FEC (can replace several diff. lost packets) • solution 2: use a tree of retransmission servers • a receiver can be a retransmission server if he has data requested • Problem 3: heterogeneity • solution 1: adjust tx rate to the slowest receiver without going below a given threshold • solution 2: use various homogeneous rx groups • solution 3: use multirate transmissions (ALC)

  19. 2.2- Current IETF standardization work • “One size does not fit all” • “requirements” x “conditions/problems” matrix is too large for a single solution!!! • define several classes of protocols for reliable multicast: Protocol Instanciation (PI) • non reusable • define protocol headers • define Building Blocks (BB) • logical, reusable component • used by the PI • example: Forward Error Correction (FEC)

  20. TRACK protocol NORM protocol ALC protocol Current IETF standardization work... (cont’) • Flat NORM • for small to medium sized groups • simplicity, uses NAK • Hierarchical TRACK • for medium sized to large groups • requires tree building (manual/automatic) • Layered ALC • for all sizes of groups,unlimited scalability

  21. The NORM PI • Negative Acknowledgment Oriented Reliable Multicast • based on NAK transmissions in case of errors • suited to small/medium size groups • Building blocks required (or optionally used) • NACK (control the generation/suppression of NACK and responses) • FEC (for increased scalability) • CC (single layer, adjust tx rate to slowest rx) • security • ...

  22. original pkt mcast retx NACK The NORM PI... (cont’) • An old example: SRM (Scalable Reliable Multicast) • no hierarchy • multicast NACK with limited scope (scalability) • FEC possible for improved scalability • automatic configuration • used by wb (libsrm) • many limitations: • many-to-many multicast • RTT evaluations • moderate scalability src recv recv recv recv recv

  23. The TRACK PI • Tree Based Acknowledgment • a tree offers assistance services for NAK suppr., ACK aggr., retransmissions (or a subset of them) • for medium to large groups • Building blocks required (or optionally used) by the TRACK PI • like the NACK PI (NACK, FEC, CC,security) • plus GRA (Generic Router Assistance) for tree management

  24. The TRACK PI • CISCO’s PGM (pragmatic multicast): • build a tree of NE (Network Elements) (server or router) that perform: • ACK aggregation along the tree • NACK suppression along the tree • localised retransmission in a subset of the tree • retransmission (if data is cached) • FEC possible for increased scalability/lower latency src NE NE recv recv recv recv recv

  25. The ALC PI • Asynchronous Layered Coding • based on multi-rate transmissions and proactive FEC • entirely ``receiver-oriented’’ for maximum scalability (several millions...) • ALC targets multicast file transfert... • ...but a varient can easily handle hierarchical video coding, multicast streaming, etc. • Building blocks required by the ALC PI • FEC • layered CC • security

  26. The ALC PI... (cont’) • Sessions • characterized by a set of {groups/port numbers} • Objects • information carried by a session • example: • a file <=> an object • a jpeg <=> an object • a file slice <=> an object • can be one object per session • e.g. transmission of a tar archive • can be several objects per session • e.g. transmission of a stripped archive file

  27. CC low-end receiver CC mid-range receiver Multicast distribution in several groups CC high-end receiver The ALC PI... (cont’) • How does it work? • multi-rate tx address thereceiver heterogeneity • the congestion control BB (e.g. RLC) tells a receiver when to add or drop a layer layer 0, rate r0 layer 1, rate r1 layer 2, rate r2 layer 3, rate r3 fragmentation and scheduling object

  28. The ALC PI... (cont’) • How does it work... (cont’) • mix in a (more or less) random manner all the data+FEC packets and send them on the various layers • required to counter the random losses and random layer addition/removal

  29. The ALC PI... (cont’) sequential ordering of objects/packets random ordering of packets

  30. 2.3- The FEC BB • FEC (Forward Error Correction) [Rizzo97] • Sender: uses FEC (k, n) for k original data packets, add n-k FEC encoded redundant packets  total of n packets sent • Receiver: as soon as it receives any k packets out of the n, it reconstructs the original k packets source receiver reconstructed data FEC encoder original data FEC decoder network k = 5 n = 7

  31. The FEC BB... (cont’) • several FEC codecs exist... • small-block FEC codes • e.g. Reed-Solomon codes • (k,n) with a k parameter limited to a few tens for computational reasons split large data objects into several blocks • limited number of n-k FEC symbols created can lead to packet duplications • open-source implem. • codec speed: 10-80 Mbps / min(k, n-k) original object block #2 k’ symbols block #1 k orig. symbols FEC codec FEC codec n’ encod. symb. n encoding symbols

  32. 2.4- The Congestion Control BB • general goals of CC • be fair with other data flows(be “TCPfriendly”) • should a multicast transfer use as much resource as a TCP connection or n times as much ? • no single definition • be responsive to network conditions • be stable, i.e. avoid oscillations • utilize network resources efficiently • if only one flow, then use all the available bandwidth

  33. The Congestion Control BB... (cont’) • single layer versus layered transmissions • completely different schemes • single layer • sender oriented • based on ACK / NACK feedbacks • layered • receiver oriented • based on losses experienced

  34. Single rate congestion control • Example PGMCC (PGM Congestion Control) • used with single-rate (i.e. layer) protocols like NORM, TRACK • relies on a window based transmission • mimics TCP • evolves according to the ACKs sent by the ``Acker’’ • relies on an ``Acker’’ selection process • the ``Acker’’ is the receiver with the lowest equivalent TCP throughput equivTCPthroughput =  / (RTT * sqrt(loss_rate)) • the ``Acker’’ changes dynamically

  35. reception rate if no loss The Layered Congestion Control BB • Example: RLC (Receiver Driven Layered Congestion Control) • add synchronization points (SP) / probes • adding a layer is only possible at a SP if no loss has been experienced • before a SP, the source artificially increases its transmission rate to simulate the consequences of subscribing to an additional group SP transmission rate layer 3 SP layer 2 SP layer 1 SP layer 0 time

  36. The layered congestion control BB... (cont’) • RLC... (cont’) • because of IGMP leave latency/multicast tree update latency, after dropping a layer, wait some time before measuring packet loss again • Limitations: • limited by IGMP leave latency (a few seconds) • probing has limitations (which size?) • only adapts to packet loss, not to RTT different from TCP where: rate ~1/(RTT*sqrt(p)) loss detected => drop layer 2 add layer 2 again transmission rate layer 2 end deaf period SP layer 1 SP layer 0 time

  37. Part 3 And now the demo...

  38. Application upper API (open/close/send/recv/select/ctl) buffering segmentation / reassembly transmission & reception thread congestion control scheduling Multicast library FEC User space Kernel space Socket UDP IP multicast MCL in short... (cont’) • MCL: an implementation of ALC • supports RLC Congestion Control and FEC • OpenSource/GPL; for linux/solaris/win2000 • http://www.inrialpes.fr/planete/people/roca/mcl/

  39. FCAST: a multicast file transfer application • an application built on top of MCL • trailer include several meta-data: • Content_base: path to the file • Content-location: file name • Content-length: length of file... • handles single file transfer and recursive file transfers • in fact file(s) are cut in several autonomous slices file data | trailer | trailer_length | checksum file - slice 0 | trailer | trailer_length | checksum file - slice 1 | trailer | trailer_length | checksum file - slice 2 | trailer | trailer_length | checksum file - slice 3 | trailer | trailer_length | checksum

  40. Multicast distribution in several groups Demo configuration • one source and one receiver on this host • use multicast over the loopback interface • use probabilistic losses (proportional to the subscription level) to simulate WAN congestion 5 layers, sends file once (PUSH) or continuously (ON-DEMAND) at most 5 layers start first (PUSH) or arrives at any time (ON-DEMAND) SOURCE RECEIVER packet losses (probabilistic)

  41. Part 4 Short bibliography

  42. Short Bibliography • ALC, LCC, FEC documents [ALC01] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft, ``Asynchronous Layered Coding (ALC): a massively scalable content delivery transport'', RMT Working Group, draft-ietf-rmt-pi-alc-02.txt, October 2001. [LCT01] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft, M. Handley, ``Layered Coding Transport (LCT): a massively scalable content delivery transport'', RMT Working Group, draft-ietf-rmt-bb-lct-03.txt, October 2001. [LCC01] M. Luby, L. Vicisano, A. Haken, ``Reliable Multicast Transport Building Block: Layered Congestion Control'', RMT Working Group, draft-ietf-rmt-bb-lcc-00.txt, November 2000 [FEC00] M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft, ``The use of Forward Error Correction in Reliable Multicast'', RMT Working Group, draft-ietf-rmt-info-fec-00.txt, November 2000. • NORM documents [NORM01] B. Adamson, C. Bormann, M. Handley, J. Macker, ``NACK-oriented reliable multicast protocol (NORM)’’, RMT Working Group, draft-ietf-rmt-pi-norm-02.txt, July2001. [NORM01b]B. Adamson, C. Bormann, M. Handley, J. Macker, ``NACK-oriented reliable multicast (NORM) protocolbuilding blocks’’, RMT Working Group, draft-ietf-rmt-bb-norm-02.txt, July2001.

  43. Short bibliography... (cont’) • TRACK documents [TRACK01] B. Whetten, D.M. Chiu, M. Kadansky, G. Taskale, ``Reliable multicast transport building block for TRACK’’, RMT Working Group, draft-ietf-rmt-bb-track-01.txt, March 2001. [GRA01] K. Calvert, C. Papadopoulos, T. Speakman, D. Towsley, S. Yelamanchi, ``Generic Router Assist, functional specification’’, RMT Working Group, draft-ietf-rmt-gra-fspec-00.txt, July 2001. • Reliable multicast [IETF RMT] Reliable Multicast Transport (RMT) charter, http://www.ietf.org/html.charters/rmt-charter.html [Roca01] V. Roca, ``Un état de l’art sur les techniques de transmission multipoint fiables’’, 4èmes Journées Réseaux (JRES01), December 2001. [MCL]V. Roca, http://www.inrialpes.fr/planete/people/roca/mcl/

More Related