160 likes | 314 Views
IP Multicast Applications: Challenges & Solutions. Bob Quinn Stardust Forums, Inc. IP Multicast Initiative. Agenda. ID Motivation & Purpose ID Scope Multicast Application Taxonomy Primary Requirement Challenges Heterogeneous Receivers Reliable Delivery Secure Multicast.
E N D
IP Multicast Applications:Challenges & Solutions Bob QuinnStardust Forums, Inc.IP Multicast Initiative
Agenda • ID Motivation & Purpose • ID Scope • Multicast Application Taxonomy • Primary Requirement Challenges • Heterogeneous Receivers • Reliable Delivery • Secure Multicast
Motivation for the Internet Draft IP Multicast Initiative - ipmulticast.com • What:Multi-vendor Forum • Members are International and Cross-Industry • Why: Promote adoption of IP Multicast • Overcome the Chicken-and-Egg problem • How: Education • Evangelize its benefits, and describe its details • Publish documentation and Host events • Informational Internet Draft...
Purpose of the Internet Draft • Informational • <draft-quinn-multicast-apps-00.txt> • A Roadmap for Application Developers • An Orientation Tool • “You are here...” in terms of • Application Type • Application Requirements • “Here’s where to go now...”
Ultimate Goal of Internet Draft • Help Application Developers to Avoid: • Reinventing Wheels • Spinning Wheels • Running Roughshod over IP Networks • encourage “network-friendly” application designs • “heads-up” when “you can’t get there from here”
Scope of Internet Draft • Focus is on Applications • not Infrastructure or Mechanics • Assumption: Multicast-Enabled Network: • Already Exists • Transparent to Applications • Assumption: Developer aware of mechanics • Refer to Maufer/Semeria ID for details<draft-ietf-mboned-intro-multicast-03.txt>
Multicast Application Taxonomy • Sender/Receiver Relationships • Differentiate Multicast from Unicast • Characterize all Multicast Applications • All Multicast Apps are one of Three Types: • One-to-Many • Many-to-Many • Many-to-One
One-to-Many Applications • Analogous to the TV/Radio Broadcast Model • Useful and valid analogy, but not all there is... • Push Media: headlines, weather, sports... • File Distribution and Caching • Announcements: network time, session schedules, randoms, keys... • Monitoring: stock prices, sensors, security, manufacturing...
Many-to-Many Applications • Multimedia Conferencing: A/V and whiteboard • Synchronized Resources: Database updates... • Concurrent Processing: Distributed & Parallel • Shared Editing and Collaboration • Interactive Distance Learning • Distributed Interactive Simulations (DIS) • Multi-Player Gaming, Chat Groups • Jam Sessions
Many-to-One Applications • Many are request/response... • Resource Discovery: Service Location, Anycast • Data Collection • Auctions • Polling • Juke Box
Multicast App Requirements • Bandwidth, Delay and Jitter • Multicast Apps are no different from Unicast • Useful to characterize needs nonetheless... • Multicast is a Special Case when Servicing: • Heterogeneous Receivers • Reliable Data Delivery • Security
Heterogeneous Receivers • Adapting to receiver rates, delays and jitter • Difficult with unicast, but worse with multicast • Strategies and Challenges: • Feedback loops - Danger of implosions • Forward Error Correction - Uses bandwidth • Shared Learning - Privacy Issues • Local Recovery - Management Issues • No standards yet. Research effort informal.
Reliable Data Delivery • Receivers tolerant of delay, but not loss • TCP model doesn’t translate (implosion) • Strategies and Challenges: • NAKs - implosion potential still exists • FEC, Shared Learning, and Local Recovery are all also relevant • No standards yet. • RMRG in IRTF is defining the problem
Multicast Security • Receivers and Senders are wary • Don’t trust data, or each other, or anyone else • Unicast is hard, and multicast is HARDER • Challenges: authentication and key distribution • Strategies: many and varied • No standards yet. • SMuG in IRTF is defining the problem
Observations • Three Primary Requirements share many of the same Strategies & Challenges • Common issue is dealing with asymmetry in the sender/receiver relationship • e.g., Local Recovery - smarts in the net • Solutions may have cascade effect (?) • Prevailing Consensus: we need more than one protocol to satisfy the varying application requirements in each category
Evaluation • Is this of value? • Should this be a draft from MBoneD WG?? • Any Questions? Comments? Suggestions? • Send to <rcq@stardust.com> & mboned mail-list • Also see http://www.ipmulticast.com