FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W1608776568> ?p ?o ?g. }

• W1608776568 abstract "IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 12, NO. 3, JUNE 2004 A Comparison of Application-Level and Router-Assisted Hierarchical Schemes for Reliable Multicast Pavlin Radoslavov, Christos Papadopoulos, Member, IEEE, Ramesh Govindan, and Deborah Estrin, Fellow, IEEE Abstract—One approach to achieving scalability in reliable mul- ticast is to use a hierarchy. A hierarchy can be established at the application level, or by using router-assist. With router-assist we have more fine-grain control over the placement of error-recovery functionality, therefore, a hierarchy produced by assistance from the routers is expected to have better performance. In this paper, we test this hypothesis by comparing two schemes, one that uses an application-level hierarchy (ALH) and another that uses router-as- sisted hierarchy (RAH). Contrary to our expectations, we find that the qualitative performance of ALH is comparable to RAH. We do not model the overhead of creating the hierarchy nor the cost of adding router-assist to the network. Therefore, our conclusions in- form rather than close the debate of which approach is better. Index Terms—Reliable multicast, router-assist for reliable multicast. I. I NTRODUCTION ELIABLE multicast has received significant attention re- cently in the research literature [1]–[8]. The key design challenge for reliable multicast is scalable recovery of losses. The two main impediments to scale are implosion and exposure. Implosion occurs when, in the absence of coordination, the loss of a packet triggers simultaneous redundant messages (requests and/or retransmissions) from many receivers. In large multicast groups, these messages may swamp the sender, the network, or even other receivers. Exposure wastes resources by delivering a retransmitted message to receivers which have not experienced loss. Another challenge that arises in the design of reliable mul- ticast is long recovery latency, which may result from suppres- sion mechanisms introduced to solve the implosion problem. Latency can have significant effect on application utility and on the amount of buffering required for retransmissions. One popular class of solutions is hierarchical data recovery. In these schemes, participants are organized into a hierarchy. R Manuscript received April 12, 2002; revised May 28, 2003; approved by IEEE/ACM T RANSACTIONS ON N ETWORKING Editor S. Paul. This work was supported by the National Science Foundation under Cooperative Agreement NCR-9321043. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation. P. Radoslavov is with the International Computer Science Institute, Berkeley, CA 94704 USA (e-mail: pavlin@icsi.berkeley.edu). C. Papadopoulos and R. Govindan are with the Computer Science Depart- ment, University of Southern California, Los Angeles, CA 90089-0781 USA (e-mail: christos@isi.edu; ramesh@usc.edu). D. Estrin is with the Department of Computer Science, University of Cali- fornia, Los Angeles, CA 90095 USA (e-mail: destrin@cs.ucla.edu). Digital Object Identifier 10.1109/TNET.2004.828950 By limiting the scope of recovery data and control messages between parents and children in the hierarchy, both implosion and exposure can be substantially reduced. Hierarchies intro- duce a latency penalty, but that is proportional to the depth of the hierarchy. The biggest challenge with hierarchical solutions is the construction and maintenance of the hierarchy, especially for dynamic groups. For optimal efficiency, the recovery hier- archy must be congruent with the actual underlying multicast tree. 1 Divergence of these structures can lead to inefficiencies when children select parents who are located downstream in the multicast tree. One approach, exemplified by reliable multicast transport protocol (RMTP) [3], is to use manual configuration or application-level mechanisms to construct and maintain the hierarchy. Manual hierarchy construction techniques rely either on complete or partial (e.g., where the border routers are) knowledge of the topology. Automated hierarchy construction techniques rely on dynamically discovering tree structure, either explicitly by tracing tree paths [6], or implicitly by using techniques based on expanding ring search. Once a hierarchy is formed, children recursively recover losses from their parents in the hierarchy by sending explicit negative acknowledgments. Another approach, exemplified by light-weight multicast services (LMS) [2], proposes to use minimal router support not only to make informed parent/child allocation, but also to adapt the hierarchy under dynamic conditions. PGM [9] is another example of a router-assisted approach. In some of these router-assisted schemes, hierarchy construction is achieved by routers keeping minimal information about parents for downstream receivers, then carefully forwarding loss recovery control and data messages to minimize implosion and exposure. In these schemes, hierarchy construction requires little explicit mechanism at the application level at the expense of adding router functionality. Because of this, one would expect these router-assisted hierarchies (Section II-B) to differ from the application-level hierarchies (Section II-A) in two different ways: 1) router-assisted hierarchies are finer-grained; that is, have many more “internal nodes” in the hierarchy; and 2) they are more congruent to the underlying multicast tree. Then, it is natural to ask, as we do in this paper: Is the per- formance of application-level hierarchies qualitatively different than that of router-assisted hierarchies? To our knowledge, this question has not been addressed before. We study this question by evaluating two specific schemes: LMS and an RMTP-like 1 Congruency is achieved when the virtual hierarchy and the underlying mul- ticast tree coincide. 1063-6692/04$20.00 © 2004 IEEE" @default.
• W1608776568 created "2016-06-24" @default.
• W1608776568 creator A5008219533 @default.
• W1608776568 creator A5042326103 @default.
• W1608776568 creator A5050123117 @default.
• W1608776568 creator A5051587086 @default.
• W1608776568 date "2004-01-01" @default.
• W1608776568 modified "2023-09-23" @default.
• W1608776568 title "A Comparison of Application-Level and Router-Assisted Hierarchical Schemes for Reliable Multicast" @default.
• W1608776568 hasPublicationYear "2004" @default.
• W1608776568 type Work @default.
• W1608776568 sameAs 1608776568 @default.
• W1608776568 citedByCount "0" @default.
• W1608776568 crossrefType "journal-article" @default.
• W1608776568 hasAuthorship W1608776568A5008219533 @default.
• W1608776568 hasAuthorship W1608776568A5042326103 @default.
• W1608776568 hasAuthorship W1608776568A5050123117 @default.
• W1608776568 hasAuthorship W1608776568A5051587086 @default.
• W1608776568 hasConcept C112037812 @default.
• W1608776568 hasConcept C120314980 @default.
• W1608776568 hasConcept C162324750 @default.
• W1608776568 hasConcept C174174714 @default.
• W1608776568 hasConcept C18787934 @default.
• W1608776568 hasConcept C192059732 @default.
• W1608776568 hasConcept C2775896111 @default.
• W1608776568 hasConcept C31170391 @default.
• W1608776568 hasConcept C31258907 @default.
• W1608776568 hasConcept C32295351 @default.
• W1608776568 hasConcept C34447519 @default.
• W1608776568 hasConcept C41008148 @default.
• W1608776568 hasConcept C44892269 @default.
• W1608776568 hasConcept C48044578 @default.
• W1608776568 hasConcept C77088390 @default.
• W1608776568 hasConceptScore W1608776568C112037812 @default.
• W1608776568 hasConceptScore W1608776568C120314980 @default.
• W1608776568 hasConceptScore W1608776568C162324750 @default.
• W1608776568 hasConceptScore W1608776568C174174714 @default.
• W1608776568 hasConceptScore W1608776568C18787934 @default.
• W1608776568 hasConceptScore W1608776568C192059732 @default.
• W1608776568 hasConceptScore W1608776568C2775896111 @default.
• W1608776568 hasConceptScore W1608776568C31170391 @default.
• W1608776568 hasConceptScore W1608776568C31258907 @default.
• W1608776568 hasConceptScore W1608776568C32295351 @default.
• W1608776568 hasConceptScore W1608776568C34447519 @default.
• W1608776568 hasConceptScore W1608776568C41008148 @default.
• W1608776568 hasConceptScore W1608776568C44892269 @default.
• W1608776568 hasConceptScore W1608776568C48044578 @default.
• W1608776568 hasConceptScore W1608776568C77088390 @default.
• W1608776568 hasLocation W16087765681 @default.
• W1608776568 hasOpenAccess W1608776568 @default.
• W1608776568 hasPrimaryLocation W16087765681 @default.
• W1608776568 hasRelatedWork W1521940819 @default.
• W1608776568 hasRelatedWork W1533304448 @default.
• W1608776568 hasRelatedWork W1541648063 @default.
• W1608776568 hasRelatedWork W1566968109 @default.
• W1608776568 hasRelatedWork W170128344 @default.
• W1608776568 hasRelatedWork W2116752417 @default.
• W1608776568 hasRelatedWork W2129757603 @default.
• W1608776568 hasRelatedWork W2218709642 @default.
• W1608776568 hasRelatedWork W2241444905 @default.
• W1608776568 hasRelatedWork W2399869146 @default.
• W1608776568 hasRelatedWork W2485325889 @default.
• W1608776568 hasRelatedWork W2492951885 @default.
• W1608776568 hasRelatedWork W2771749585 @default.
• W1608776568 hasRelatedWork W2803793399 @default.
• W1608776568 hasRelatedWork W2939696158 @default.
• W1608776568 hasRelatedWork W2951961058 @default.
• W1608776568 hasRelatedWork W2952222395 @default.
• W1608776568 hasRelatedWork W2968870987 @default.
• W1608776568 hasRelatedWork W38192683 @default.
• W1608776568 hasRelatedWork W72844283 @default.
• W1608776568 isParatext "false" @default.
• W1608776568 isRetracted "false" @default.
• W1608776568 magId "1608776568" @default.
• W1608776568 workType "article" @default.