360 likes | 545 Views
Scalable Reliable Multicast in Wide Area Networks. Sneha Kumar Kasera Department of Computer Science University of Massachusetts, Amherst. Why Multicast ?. one sender three receivers. broadcast. multicast. multiple unicast. Why Reliable Multicast ?. applications
E N D
Scalable Reliable Multicast in Wide Area Networks Sneha Kumar Kasera Department of Computer Science University of Massachusetts, Amherst
Why Multicast ? one sender three receivers broadcast multicast multiple unicast
Why Reliable Multicast ? applications • one-to-many file transfer • information updates (e.g., stock quote, web cache updates) • shared whiteboard lossy network multicast
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
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
sender original transmission retransmission pkt lost loss loss unicast multicast
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
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
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
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
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
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 ?
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
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
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
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
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’
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
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
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
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
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 ?
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
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
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
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)
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%
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
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)
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
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 ?
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
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
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
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
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