1 / 36

Scalable Reliable Multicast in Wide Area Networks

This study explores the design and evaluation of multicast loss recovery approaches in wide area networks, focusing on scalability, reliability, and resource efficiency. The use of multiple multicast channels and server-based local recovery techniques are proposed to improve performance and reduce network bandwidth requirements. Active repair services and signaling mechanisms are also discussed. The results demonstrate significant reductions in receiver processing costs and potential improvements in network performance.

ratliff
Download Presentation

Scalable Reliable Multicast in Wide Area Networks

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. Scalable Reliable Multicast in Wide Area Networks Sneha Kumar Kasera Department of Computer Science University of Massachusetts, Amherst

  2. Why Multicast ? one sender three receivers broadcast multicast multiple unicast

  3. Why Reliable Multicast ? applications • one-to-many file transfer • information updates (e.g., stock quote, web cache updates) • shared whiteboard lossy network multicast

  4. Goal design, evaluate multicast loss recovery approaches that • make efficient use of end-host, network resources • scale to several thousand receivers spanning wide area networks

  5. Feedback Implosion sender sender sender NAK implosion ? • NAK suppression (using timers) • NAK aggregation (by building hierarchy) pkt pkt loss pkt ACK ACK NAK receivers receivers receiver problem: ACK implosion solution: use NAKs

  6. sender original transmission retransmission pkt lost loss loss unicast multicast

  7. Problem of Retransmission Scoping • if same channel for retransmissions, retransmissions go everywhere • how to shield receiver from loss recovery due to other receivers ? sender original transmission retransmission loss loss

  8. Loss Recovery Burden • when #receivers large, each pkt lost at some rcvr with high probability • sender retransmits almost all pkts several times • how to share burden of loss recovery ? sender retransmits pkts 1, 2, 3, 4 pkt 4 pkt 1 pkt 2 loss loss pkt 3 loss loss

  9. Thesis Contributions • scoping retransmissions using multiple multicast channels • server-based local recovery • performance benefits • resource requirements • “active” repair services • signaling for locating, invoking, revoking services • router support

  10. Overview • scoping retransmissions using multiple multicast channels • server-based local recovery • performance benefits • resource requirements • “active” repair services • signaling for locating, invoking, revoking services • router support • summary and future directions

  11. one channel for original transmissions, Aorig additional channels for retransmissions, pkt k sent on Ak on detecting loss of pkt k, receiver joins Ak recovers packet k leaves Ak Scalable Reliable Multicast Using Multiple Multicast Channels sender Aorig Ak loss loss Kasera, Kurose, Towsley, ACM SIGMETRICS Conference ‘97

  12. Issues • how much is performance improved ? • receiver, sender processing • network bandwidth • if (multicast channel IP multicast group), realistically only finite channels available ! • overhead of join, leave operations ? • router support for multiple multicast channels ?

  13. rcvrs unicast NAKs to sender infinite channels available system model one sender, R receivers independent loss, probability p NAKs not lost E[Y] = E[Yp] + pE[Yj] + pE[Yn]/(1-p) + p2E[Yt]/(1-p) determined various proc times by instrumenting Linux kernel Y = total per pkt rcv proc time Yp = rcvd pkt proc time Yj = join, leave proc time Yn = NAK proc time Yt = timer proc time Analysis rcvd pkt processing join, leave processing NAK processing timer processing

  14. considerable reduction in rcvr processing costs by using infinite channels example: when R = 1000, p = 0.05, processing cost reduces by approx. 65% similar behavior observed for protocols that multicast NAKs for NAK suppression Receiver Processing Cost Reduction

  15. Finite # of Retransmission Channels • recycle Gretransmission channels, retransmit pkt k on Ak mod G • example, G = 3 transmit 1 2 3 4 5 lost at r1 lost at r2 retransmit pkt 1 on (1) 1 1 1 1 1 received at r1 lost at r1 retransmit pkt 4 on (1) 4 4 lost at r2 received at r2 received at r1 received at r1

  16. Finite # of Retransmission Channels • find #unwanted pkts, U, at receiver due to using G channels only • model • same as before • transmit with interval D • retransmit with interval D’ (if pending NAK) • U depends upon G, p, R, D/D’ • receiver processing cost, E[Y’] = E[Y] + E[U]E[Yp] unwanted pkt processing

  17. How many channels do we need ? • find minimum #channels s.t. increase in cost within 1% • small #channels for wide range of p, D/D’, R • #channels • <= 10whenD/D’ >= 0.5 • sensitive to low D/D’ D/D’

  18. Summary (part 1) • use of multiple multicast channels reduces receiver processing • small to moderate #channels achieve almost perfect retransmission scoping • implementation using router support also saves network bandwidth • sender still bottleneck, no improvement in protocol performance

  19. Local Recovery • server and/or otherreceivers aid in loss recovery • distribution of loss recovery burden • possible reduction in • network bandwidth • recovery latency • retransmission scoping sender transmission server loss loss local domains

  20. Overview • scoping retransmissions using multiple multicast channels • server-based local recovery • performance benefits • resource requirements • “active” repair services • signaling for locating, invoking, revoking services • router support • summary and future directions

  21. Repair Server Based Local Recovery sender • repair servers co-located with routersat strategic locations • placement of application level repair service in routers • repair servers cache recent pkts • receivers,repair servers, recover lost pkts from upper level repair servers, sender repair server receivers Kasera, Kurose, Towsley, IEEE INFOCOM ‘98

  22. Issues • how much is performance improved over traditional local recovery approaches ? • SRM: dynamically elect receiver for every loss • RMTP, LBRM: designated receiver, logger for supplying repairs • where to place repair servers ? • what are repair server resource requirements ?

  23. System Model sender • based on [YKT ‘97] • loss freebackbone, sites • loss atsource link, tails • temporally independent loss, probability p source link backbone tail receivers site local domain

  24. System Model sender • based on [YKT ‘97] • loss freebackbone, sites • loss atsource link, tails • temporally independent loss, probability p source link backbone tail designated receiver receivers site local domain

  25. System Model sender • based on [YKT ‘97] • loss freebackbone, sites • loss atsource link, tails • temporally independent loss, probability p source link backbone repair server tail receivers site local domain

  26. Performance Evaluation • metrics • throughput= 1/max(sender-processing time, receiver-processing time) • bandwidth usage= total bytes transmitted over all links per correct transmission • analysis: similar approach as in previous problem (optimistic bounds for SRM)

  27. Performance Comparison repair server-based (RSB) compared to • SRM:throughput upto 2.5 times, bandwidth reduction 60% • DR-based (DRB):throughput upto 4 times, bandwidth reduction 35%

  28. additional sender retransmission required if some domains without repair servers place repair servers in high loss domains first homogeneous loss: high % domains require repair server 20% tail loss in 20% domains, 1% tail loss in 80% domains Insufficient Repair Servers

  29. theoretically: infinite realistically: allot finite buffers replace pkts when buffers full if required, replaced pkts recovered upstream size depends upon amount of upstream recovery pkt arrival process, buffer holding time replacement policy example: when p = 0.05, 15 buffers ensure almost perfect local recovery Repair Server Buffer Requirements (per session)

  30. examine three policies FIFO, LRU FIFO-MH: FIFO with minimum buffer holding time = one retransmission interval FIFO-MH shows little improvement over FIFO LRU performs better than FIFO only when #buffers large example: arrival rate = 128pkts/sec retransmission interval from round trip time traces Buffer Replacement Policies

  31. Summary (part 2) • repair server-based approach exhibits superior performance over traditional approaches • repair serverplacement - above loss, higher loss domains first • buffer requirement • several 10s of buffers (per session) • simple FIFO replacement policy sufficient • how to make repair server approach dynamic ?

  32. Overview • scoping retransmissions using multiple multicast channels • server-based local recovery • performance benefits • resource requirements • “active” repair services • signaling for locating, invoking, revoking services • router support • summary and future directions

  33. repair server functionality as active repair service design repair service-based protocol, AER locate, invoke repair services using source path messages (SPMs) minimal router support required for interception of SPM, subcast SPMsmulticast but intercepted NAKstake reverse path Active Repair Service S SPM S SPM RS1 SPM RS2

  34. Thesis Contributions • scoping retransmissions using multiple multicast channels • server-based local recovery • performance benefits • resource requirements • “active” repair services • signaling for locating, invoking, revoking services • router support

  35. model cost of additional network resources buffer requirements multiple sessions other applications (e.g., web caching) composable multicast services other multicast research revisit IP multicast service model congestion control pricing Future Directions

  36. identify performance enhancing services, examples feedback aggregation selective forwarding repair, rate conversion, log services invoke/revoke services based on application requirements network conditions issues: implementing composability signaling mechanism (SPM++) measurement-based infrastructure Composable Multicast Services(Work in Progress) sender protocol rate conversion feedback aggregation rcvr protocol rcvr protocol rcvr protocol rcvr protocol

More Related