1 / 32

A Case for End System Multicast

A Case for End System Multicast. Author: Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan and Hui Zhang. OVERVIEW. I.INTRODUCTION II.END SYSTEM MULTICAST III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery IV.CONCLUSION. OVERVIEW. I.INTRODUCTION

kratz
Télécharger la présentation

A Case for End System Multicast

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 Case for End System Multicast Author: Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan and Hui Zhang

  2. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  3. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  4. Abstract • IP is the natural protocol layer for implementing multicast related functionality. • End System Multicast: • End systems implement all multicast related functionality including membership management and packet replication.

  5. I.INTRODUCTION • Traditional Network Architectures: • End systems (hosts) and the network (routers and switches). • Internet Architecture: • Internetworking layer, or IP implements a minimal functionality — a best-effort unicast datagram service. • End systems implement all other important functionality such as error, congestion, and flow control.

  6. What new features should be added to the IP layer? • Multicast and QoS. • In particular, it is possible for end systems to implement multicast services on top of the IP unicast service.

  7. Whether should be implement multicast services at the IP layer or at end systems? a functionality should be • (i) Pushed to higher layers if possible; unless • (ii) Implementing it at the lower layer can achieve large performance benefits that outweigh the cost of additional complexity at the lower layer.

  8. IP Multicast Drawbacks • First, IP Multicast requires routers to maintain per group state, which not only violates the “stateless” architectural principle of the original design, but also introduces high complexity and serious scaling constraints at the IP layer. • Second, IP Multicast is a best effort service, and attempts to conform to the traditional separation of routing and transport that has worked well in the unicast context. However, providing higher level features such as reliability, congestion control, flow control, and security has been shown to be more difficult than in the unicast case. • Finally, IP Multicast calls for changes at the infrastructural level, and this slows down the pace of deployment.

  9. Consider a model in which multicast related features, such as group membership, multicast routing and packet duplication, are implemented at end systems, assuming only unicastIP service. We call the scheme End System Multicast. • End systems participating in the multicast group communicate via an overlay structure.

  10. End System Multicast Issues • An overlay approach to multicast, however efficient, cannot perform as well as IP Multicast. It is impossible to completely prevent multiple overlay edges from traversing the same physical link and thus some redundant traffic on physical links is unavoidable. • Further, communication between end systems involves traversing other end systems, potentially increasing latency.

  11. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  12. II.END SYSTEM MULTICAST • Example to illustrate naive unicast, IP Multicast and End System Multicast. • Peer-to-peer architectures and proxy-based architectures.

  13. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  14. III.NARADA DESIGN • Self-organizing: The construction of the end system overlay must take place in a fully distributed fashion and must be robust to dynamic changes in group membership • Overlay efficiency:The tree constructed must be efficient both from the network and the application perspective. • Self-improving:Evolve into a better structure as more information becomes available. • Adaptive to network dynamics:Resilient to inaccuracies inherent in the measurement of these quantities

  15. Construct trees in a two-step process: • Constructs a richer connected graph that we term a mesh,and tries to ensure that the mesh has desirable performance properties . • Constructs spanning trees of the mesh, each tree rooted at the corresponding source using well known routing algorithms. • Good mesh properties: • The quality of the path between any pair of members is comparable to the quality of the unicast path between that pair of members. • Limited number of neighbors.

  16. A.Group Management • High degree • do not rely on a single non-failing • burden of group maintenance is shared jointly by all members. solution: every member maintain a list of all other members in the group. • Updated when a new member joins or an existing member leaves. • Periodically generate a refresh message with monotonically increasing sequence number.

  17. i keeps following information for every other member k: • (i) member address k; • (ii) last sequence number ski that i knows k has issued. • (iii) local timeat i when i first received information that k issued ski. If member i has not received an update frommember k for Tm time, then, i assumes that k is either dead or potentially partitioned from i.

  18. Each member periodically exchange its knowledge of group membership with its neighbors in the mesh. • Actions taken by a member i on receiving a refresh message from member j.

  19. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  20. A.1 Member Join • Get a list of group members by an out-of-band bootstrap mechanism. • Randomly selects a few group members and sends them messages requesting to be added as a neighbor. • Until it gets a response from some member. • Starts exchanging refresh messages with its neighbors.

  21. A.2 Member Leave and Failure • Notifies its neighbors, and this information is propagated to the rest of the group members along the mesh. • For unexpected:Detected locally and propagated to the rest of the group. • Every member needs to retain entries in its group membership table for dead members.

  22. A.3 Repairing Mesh Partitions • Scheduling algorithm used by member i to repair mesh partition

  23. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  24. B. Mesh Performance • The constructed mesh can be quite sub-optimal, because • (i)Initial neighbor selection by a member joining the group is random given limited availability of topology information at bootstrap; • (ii)Partition repair might aggressively add edges that are essential for the moment but not useful in the long run; • (iii)Group membership may change due to dynamic join and leave; • and (iv) Underlying network conditions, routing and load may vary.

  25. Narada allows for incremental improvement of mesh quality by adding and dropping of overlay links. • New links may be added depending on the perceived gain in utility. • Drop links perceived as not useful. • A good quality mesh must ensure that for any pair of members can provide performance comparable to the performance of the unicast path between the members.

  26. A member i computes the utility gain if a link is added to member j based on • (i) The number of members to which j improves the performance of i; and • (ii) How significant this improvement in performance is.

  27. Example algorithm that i uses in determining utility of adding link to j, when latency is the main metric of interest.

  28. Algorithm that i uses to determine consensus cost to a neighbor j

  29. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  30. C.Data Delivery • Runs a distance vector protocol on top of the mesh. In order to avoid the well-known count-to-infinity problems. • Each member maintains the routing cost and path to every other member. • The persource trees used for data delivery are constructed from the reverse shortest path between each recipient and the source, in identical fashion to DVMRP. • Introduce a new routing cost called Transient Forward (TF).

  31. OVERVIEW • I.INTRODUCTION • II.END SYSTEM MULTICAST • III.NARADA DESIGN A.Group Management B.Mesh PerforMance C.Data Delivery • IV.CONCLUSION

  32. IV.CONCLUSION • The shifting of multicast support from routers to end systems, while introducing some performance penalties.

More Related