190 likes | 209 Views
DyRAM: Dynamic Replier Active reliable Multicast. Moufida Maimour and C. D. Pham INRIA-RESO RESAM UCB-Lyon – ENS Lyon. ISCC’02, Taormina. Tuesday, July 2nd, 2002. Outline. Introduction The DyRAM protocol Protocol description Some simulation results Preliminary experimantal measurements
E N D
DyRAM: Dynamic Replier Active reliable Multicast Moufida Maimour and C. D. Pham INRIA-RESO RESAM UCB-Lyon – ENS Lyon ISCC’02, Taormina Tuesday, July 2nd, 2002
Outline • Introduction • The DyRAM protocol • Protocol description • Some simulation results • Preliminary experimantal measurements • Conclusions
Introduction • Many applications require reliable multicast. • At the routing level : IP Multicast provides efficient delivery without any reliability guarantees. • Reliability has to be addressed at a higher level. • Main objective : scalability !
Local Recovery : What and Why Packets retransmission is performed by an other entity (replier) instead of the source : It mainly, • unloads the source from retransmissions, • reduces the end-to-end delay, • reduces bandwidth consumption,
Local Recovery : How • The replier can be : • Any receiver in the neighborhood [SRM]. • A parent receiver in a hierarchical structure (static [RMTP] or dynamic [TMTP,TRAM] ). Problem : the lack of topology information at the end hosts. Solution : router-assisted schemes
NACK4 Active Local Recovery [ARM] • routers perform cache of data packets • repair packets are sent by routers, when available data data data5 data1 data2 data1 data3 data2 data4 data3 data5 data4 data5 data4 data1 data2 data3 data5
However … • Router’s caching means are limited. • Routers have to support many sessions in parallel. Question : How the memory usage at the routers can be reduced ? Answer : Perform the local recovery from the receivers with the help of the routers : DyRAM.
DyRAM main characteristics • DyRAM is based on active services (router-assisted). • the recovery is performed from the receivers (no data cache at the routers) • A recovery tree is constructed on a per-packet basis via a replier election mechanism. • Use of NACKs combined with periodic ACKs.
Main Active Services in DyRAM • Global NACK suppression • Subcast of repair packets • Dynamic replier election
NACK4 NACK4 data4 NACK4 NACK4 only one NACK is forwarded to the source NACK4 Nacks Suppression
NAK 2 from link2 NAK 2 from link1 IP multicast IP multicast IP multicast IP multicast IP multicast NAK 2 Repair 2 NAK 2,@ Repair 2 NAK 2 NAK 2,@ NAK 2,@ NAK 2 Repair 2 Replier election and subcast D0 DyRAM 0 2 1 D1 DyRAM Repair 2 R1 1 0 R2 R3 R4 R5 R7
Network Model 10 MBytes file transfer
#grp: 6…24 p=0.25 Local recovery from the receivers (1) 4 receivers/group • Local recoveries reduces the end-to-end delay (per packet)
Local recovery from the receivers (2) • As the group size increases, doing the recoveries from the receivers greatly reduces the bandwidth consumption 48 receivers distributed in g groups #grp: 2…24
DyRAM vs ARM • ARM performs better than DyRAM only for very low loss rates and with considerable caching requirements
DyRAM implementation • Tamanoir execution environment • Java 1.3.1 and a linux kernel 2.4 • A set of receivers and 2 PC-based routers ( Pentium II 400 MHz 512 KB cache 128MB RAM) • Active processing cost of a • data packet : 20 micro sec • NACK packet : 135 micro sec • repair packet : 123 micro sec
Conclusion & perspectives • Reliability on large-scale multicast session is difficult. Active services at the edges can provide efficient solutions for reducing implosion and exposure problems and so achieving scalability. • Optimizing the replier election based on an estimation of the receivers power (by means of BW, delay …) • A congestion control is currently under evaluation and will be integrated into DyRAM in the near future.
A reference • http://www.ens-lyon.fr/LIP/RESAM