1 / 45

The End-to-end Argument: Multicast’s Friend or Foe?

The End-to-end Argument: Multicast’s Friend or Foe?. Steven McCanne Sylvia Ratnasamy Electrical Engineering and Computer Science University of California, Berkeley NSF PI Meeting January 23, 1999 Washington, DC. Scaling multipoint communication broadcast video group conferencing

caia
Download Presentation

The End-to-end Argument: Multicast’s Friend or Foe?

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. The End-to-end Argument:Multicast’s Friend or Foe? Steven McCanne Sylvia Ratnasamy Electrical Engineering and Computer Science University of California, Berkeley NSF PI Meeting January 23, 1999 Washington, DC

  2. Scaling multipoint communication broadcast video group conferencing directory services remote file distribution hierarchical web cache updates The Problem

  3. S A B C D IP Multicast to the Rescue • Extend IP architecture for multipoint • Best effort • Defer reliability to higher layers

  4. IP Multicast to the Rescue • Extend IP architecture for multipoint • Best effort • Defer reliability to higher layers S A B C D

  5. Keep the network simple & robust Rely upon end-to-end adaptation Build apps on top of IP multicast that scale, and accommodate heterogeneity. Been trying for a decade this is a HARD problem The End-to-end Challenge

  6. Divide and conquer Localize “problems” e.g., recovery and control traffic Impose hierarchy Hierarchy should be congruent with underlying network topology This means we should know something about the topology (maybe indirectly) Topological Awareness

  7. Topological Optimizations S A B C D Logical Topology

  8. Topological Optimizations S S D C A B C D Physical Topology A B Logical Topology

  9. Topological Optimizations S • Reliable multicast recovery groups D C A B

  10. Topological Optimizations S • Reliable multicast recovery groups D C A B

  11. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP DR D DR C A B

  12. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP DR D DR C A B

  13. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP • Optimal transcoder placement for streaming media D C A B

  14. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP • Optimal transcoder placement for streaming media T D C A B

  15. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP • Optimal transcoder placement for streaming media T D T C A B

  16. Topological Optimizations S • Reliable multicast recovery groups • DR placement for RMTP • Optimal transcoder placement for streaming media • Self-organizing web caches $ D $ C A B

  17. IP deliberately hides topology No hooks to discover it Two alternatives extend the service model (e.g., put new forwarding services in the network) infer topological structure from end-to-end measurements The Problem

  18. Let’s look at both service extensions (NSF CAREER grant) How would we minimally extend the IP multicast service model to better support end-to-end transports, and how would we co-design those new transport protocols? inference If restricted to the existing service model, how well could we infer topology through end-to-end observations and use this knowledge in a transport protocol? Our Approach

  19. Let’s look at both service extensions (NSF CAREER grant) How would we minimally extend the IP multicast service model to better support end-to-end transports, and how would be co-design those new transport protocols? inference If restricted to the existing service model, how well could we infer topology through end-to-end observations and use this knowledge in a transport protocol? Our Approach

  20. Self-organizing multicast groups Cluster receivers with similar loss patterns Assumes shared loss implies spatial (topological) correlation Landmark works Liuet al. reliable multicast Kouvelaset al. transcoder placement State of the Art

  21. Loss “finger prints” (lossprints) Exchange lossprints over session channel If shared loss > THRESH, form new group Join group with similar lossprint Problem: it doesn’t work Self-organizing Groups

  22. Lossprint Pathology S A B C

  23. Lossprint Pathology S med loss high loss A B C

  24. Lossprint Pathology S Lossprint thresholding A B C

  25. Lossprint Pathology S • Shared loss does not imply spatial correlation • Haven’t localized the problem Lossprint thresholding A B C

  26. Lossprint Pathology S • Shared loss does not imply spatial correlation • Haven’t localized the problem Ideal A B C

  27. Can we somehow extract the true loss correlations? Red signal (AC) strong but wrong Yellow signal (AB) weak but right Short answer: yes Back to the Drawing Board S A B C

  28. Syvlia’s Infocom ’99 paper Probabilistic model Assumptions Independence Perfect (end-to-end) knowledge everywhere Global exchange of lossprints Lossprints from the beginning of time Tree Inference

  29. Bottom-Up Construction S A B C

  30. Bottom-Up Construction S S A B C A B C

  31. Bottom-Up Construction S S S A B C A B C A B C

  32. The Magic S S S ? A B C A B C A B C

  33. Choose max likelihood pairing Assume independent losses Tease apart real shared loss losses along a common path coincidental shared loss independent losses along separate paths Trick: can observe only the union Probabilistic Model

  34. LHS big P’s are observed Solve for little p’s Choose max likelihood pairing Probabilistic Model Real shared loss S Pa~b = (1- ps) pa (1- pb) P~ab = (1- ps) (1- pa) pb Pab = ps + (1- ps) pa pb ps Coincidental shared loss pb pa A B

  35. Lossprint Pathology Fixed S • Real shared loss does imply spatial correlation • Successful localization A B C P(A,B real shared loss) > P (A,C real shared loss) even though P(A,B shared loss) < P (A,C shared loss)

  36. It works well Simple network models independent losses P(correct inference) -> 1 as N -> oo Open: impact of correlated losses See Sylvia’s paper Results

  37. Unfortunately, global exchange of information is expense and unrealistic Can we apply the lessons learned through this extreme case analysis to a more practical protocol design? Short answer: yes A Group Formation Protocol

  38. source unicastconnections multicast LAN Delivery based model • Unicast data to each homogenous region within the heterogeneous tree. • Tailor the original delivery process to meet varied receiver characteristics, making the subsequent issues of flow/congestion control and reliability that much easier Three core pieces required to enable a delivery based model • Group Formation Protocol • Representative Election Protocol • Scattercast

  39. Group Formation Protocol (GFP) Goal source Organize receivers into a multi -level hierarchy of disjoint multicast delivery groups Metric Pt(i,j) • True shared loss probability • Estimates the loss probability along the shared path between two nodes • [Tree Inference algo. - Infocom ’99] J I • Source continually multicasts probe pkts onto a separate control channel • Receivers use observed loss patterns to infer group structure

  40. Group Formation Protocol source Terminology {1,4,6,9} • Participant:A receiver participates in the GFP if its loss rate > LRmin • Receiver LossPrint (LPr): list of pkts lost by a receiver • Group LossPrint (LPg):list of pkts lost by the group as a whole • Working LossPrint (LPr - LPg):list of pkts lost by a receiver within its current group {3,5} I For receiver I : LPi = { 1,3,4,5,6,9 } LPg= { 1,4,6,9 } LPi-LPg = { 3,5 }

  41. Group Formation Protocol • Every participant sets a timer as a linearly increasing function of its loss rate • On timer expiry, a participant either initiates the formation of a new group (INIT(g) msg) or joins a previously proposed group (JOIN(g) msg) • INIT and JOIN msgs include a LossPrint describing the group’s losses • For every incoming INIT(g)/JOIN(g) msg, a participant (I) computes • R = Pt(i,g) / Pt(g,g) R is indicative of the extent of the shared path between group “g” and participant “I” • Until its timer expires, a participant tracks the group (Gmax) with which it shares the maximum value of R (Rmax)

  42. Group Formation Protocol • On timer expiry : • If ( Rmax > THRESH ) { • participant I joins group Gmax (JOIN msg) <JOIN/Gmax/Gmax’s lossprint> • } else { • participant I initiates the formation of new group (INIT msg)<INIT/Gnew/I’s working lossprint> • } • Value of THRESH determines the “shape” of the final hierarchy • Value of LRmin determines the heterogeneity within a single delivery group

  43. Representative Election Protocol Low loss rate receiver is an ideal group representative • In GFP, initiator of a new group has the lowest loss rate in that group. • Group initiator acts as group representative • Use of soft state principles to achieve robustness in the face of representative crashes • Representative periodically transmits ‘REP’’ messages • Every receiver sets a timer as a linearly increasing function of loss rate • A receiver whose timer expires before it sees a ‘REP’ message takes over as representative • REP message includes group LossPrint LPg

  44. source TCP SRM SRM TCP SRM SRM Scattercast • Source unicasts data to the first-level group representatives • Representatives unicast data to the group representatives at the next level in the hierarchy and multicast data within their own group • Implement reliability and flow/congestion control at two levels • between homogenous regions by the coarse grained clustering of receivers (GFP) • within each homogenous region (e.g.: using SRM global recovery, transmitting at the least common denominator rate etc)

  45. Conclusions? • Open question: To what extent should we retain the end-to-end way of thinking in the context of multicast? • Two areas we’re looking at • End-to-end and infer • Extend service model • Both are hard and the jury is still out...

More Related