1 / 17

CSE 561 – Multicast Applications

CSE 561 – Multicast Applications. David Wetherall djw@cs.washington.edu Spring 2000. This Lecture. Floyd, Jacobson, Liu, McCanne, Zhang “A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing” IEEE/ACM Transactions on Networking, 1997. McCanne and Jacobson

dschmitt
Download Presentation

CSE 561 – Multicast Applications

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. CSE 561 – Multicast Applications David Wetherall djw@cs.washington.edu Spring 2000

  2. This Lecture • Floyd, Jacobson, Liu, McCanne, Zhang • “A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing” • IEEE/ACM Transactions on Networking, 1997. • McCanne and Jacobson • “Receiver-driven Layered Multicast” • SIGCOMM 1996. djw // CS 561, Spring 2000

  3. Context • You know about multicast addressing and routing … • Now focus on how to extend to multicast applications • Video broadcasting, shared whiteboard • Adding congestion control and reliability to multicast djw // CS 561, Spring 2000

  4. Why is this difficult? • Heterogeneity • Of network paths: one size doesn’t fit all • Scalability • Implosion, Growth of control traffic • Group membership • Dynamic set w/ late joiners etc. • Application types • Many-to-many vs. one-to-many djw // CS 561, Spring 2000

  5. RLM Paper • Focus on rate adaptation of video transmission in the presence of bandwidth heterogeneity • Non-TCP multicast congestion control • TCP probes the network to track the congested link between one sender and one receiver • Now we need to infer the points of congestion for multiple receivers … difficult problem djw // CS 561, Spring 2000

  6. Previous Approaches • Sender adapts transmission rate based on receiver feedback a la TCP • Feedback needed despite unreliable transport • Typically track slowest receiver • How to gather feedback in a scalable manner? • Implosion problem: source overwhelmed by near simultaneous messages from receivers  decorrelate over an interval • Group size problem: decorrelation not enough  make interval depend on group size and pick a random sample djw // CS 561, Spring 2000

  7. Layered Video • One source rate not right for all receivers • Use layered video to efficiently support multiple rates • Different receivers can receive different rates • Q: How to selectively forward flows in network? • Network support • Multiple multicast groups djw // CS 561, Spring 2000

  8. Priority vs. Uniform Drop • See S. Bajaj, L. Breslau, S. Shenker, “Uniform Versus Priority Drop for Layered Video”, SIGCOMM 98 • RED also useful for RLM djw // CS 561, Spring 2000

  9. RLM algorithms • Receivers run join experiments • How do we determine if it succeeds? • Backoff exponentially if they fail • Experiments are shared for scalability • How does this help? • How does it scale? djw // CS 561, Spring 2000

  10. SRM Paper • Adding the word “reliable” to multicast • Focus on scalability over the wide-area • Protocol works for many-to-many distribution • Protocol tied to application characteristics (ALF) djw // CS 561, Spring 2000

  11. Reliable Multicast Approaches • Token-ring • Sender-based • Receiver-based • Tree-based djw // CS 561, Spring 2000

  12. SRM Design • Receiver and “NACK”-based and relies on co-operation • NACKs triggered by hole in sequence space or session messages • Data, requests and repairs multicast to entire group • Timers bias who sends requests and repairs: • To avoid implosion • To have a neighbor respond/repair loss quickly • Ideally exactly one request and response per loss djw // CS 561, Spring 2000

  13. SRM and ALF • Clark and Tennenhouse, “Architectural Considerations for a New Generation of Protocols”, SIGCOMM 90 • ALF = Application Level Framing • Looks at interaction of network and application protocols and argues network protocol should be designed with application needs in mind. djw // CS 561, Spring 2000

  14. Scalability of SRM • What happens as group size increases? • To request/repair timers • To expected number of messages • Large groups with uncorrelated loss neighborhoods lead to poor scaling • There is a strong need for localized recovery • See M. Yajnik, J. Kurose, D. Towsley, "Packet Loss Correlation in the MBone Multicast Network“ for experimental data djw // CS 561, Spring 2000

  15. Local Recovery in SRM • Want for form appropriate loss neighborhoods (related to topology) and send repairs only to the right group • SRM suggests the use of TTL-scoped multicast • Q: How well does this work? • Alternatively use multiple multicast groups • Q: How well does this work? djw // CS 561, Spring 2000

  16. Other Strategies: FEC • FEC (or parity) on the data stream • Allows single receiver to tolerate some loss • Allows multiple receivers to each tolerate different loss! • “FEC” (or parity) as the repair stream • Allows one message to repair different losses at each receiver djw // CS 561, Spring 2000

  17. Other strategies: Network support • Mismatch between multicast delivery primitive and need for scoping • Q: Can we change multicast delivery? • Cisco’s PGM, Papadopoulos’s Repliers, various active … • Deployment at strategic point an example of network-based support for “discontinuities” djw // CS 561, Spring 2000

More Related