410 likes | 511 Views
Stealth Multicast - A New Paradigm for Incremental Multicast Deployment. Dr. Aaron Striegel Notre Dame Systems & Software Laboratory Dept. of Computer Science & Engineering University of Notre Dame October 20, 2003. Talk Overview. Information Dissemination Motivation Stealth Multicast
E N D
Stealth Multicast - A New Paradigm for Incremental Multicast Deployment Dr. Aaron Striegel Notre Dame Systems & Software Laboratory Dept. of Computer Science & Engineering University of Notre Dame October 20, 2003 Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 1
Talk Overview • Information Dissemination • Motivation • Stealth Multicast • Basic Architecture • Example: MYDEKI • Preliminary Results • Future Research • Inter-domain Peering • Network stack enhancement Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 2
Information Dissemination • Distribute rich content in a timely fashion to users • Problem: Internet evolved as point-to-point • Inefficient but currently manageable via unicasts • Two main approaches • Active involvement - Multicast • Close temporal proximity • Applications, network can participate • Community participation -> network efficiency • Passive involvement - Caching • Multiply-accessed data over time • No required participation of apps/network • Exploit existing characteristics of network • HTTP Caching • Packet-level caching Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 3
Caching vs. Multicast • Caching • Cannot handle rapidly changing data • Data w/close temporal proximity • Easy deployment • No global participation • Multicast • Deployment problems • Global participation • Addressed by ALM • Delay-sensitive traffic, rich user base • Economic incentive • Bandwidth glut, ISP benefit • Can handle close temporal data • Group-oriented activities - synchrony is an issue Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 4
Current State • Caching: Yes Multicast: ?? • Several recent studies [2000, 2003] • Lackluster adoption 150 groups (1999) -> 250 (2001) • Most groups are single source (SSM) • Why have *, G, CBTs, etc.? • Harder form of multicast anyway • Key lesson from caching • Incremental deployment is key • Big-bang theory is impossible • Transition as easy as possible (FUD inertia) • Immediate benefit • Large benefit with minimal investment • Directable economic benefit • Avoid “If you build it, they will come…” Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 5
Motivation • Research premise • Transparent bandwidth conservation technique • Change the paradigm of multicast • Incremental deployment • Zero dependence on external forces • Immediate benefit • Exploit the redundancy in the network • Economics • Offer a significant and quantifiable benefit • Stealth Multicast • Dynamically convert packets to/from multicast • Target • Small to medium group-oriented apps 5-500 users • Delay-sensitive apps • On-line gaming, video streaming • Improve ALM-based apps Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 6
Stealth Multicast • Two governing principles • Externally transparent • Zero modification - application (server/client) • Zero modification - external Internet • Seamless operation • Negligible QoS impact? • Should not noticeably impact QoS • What are noticeable QoS changes? • Depends upon application • Large buffer - streaming video • On-line game - zero buffer • Informal definition • Additional delay should not make the applicationunusable versus separate unicasts Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 7
Stealth Multicast Model Conversion Other Domains Servers ISP Domain Clients Company LAN (Content Provider) Unicast Multicast Unicast Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 8
Multicast Detection VGDM - Virtual Group Detection Manager Virtual Group Mgr Disp Checksum Calculation Tree Construction H State Management Rules Filter Edge Router Incoming Traffic (Unicast only) Outgoing Traffic (Unicast+Multicast) Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 9
Further Examination • Benefits • Dynamically convert • Zero modification • Multicast transport via virtual groups • Exact billing • Drawbacks • Non-zero queuing delay • Aggregation effects • Imperfect virtual groups • Not a universal solution Benefit Delay Virtual Group Delay Minimum gain Maximum delay Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 10
Multicast Transition Options Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 11
Talk Overview • Information Dissemination • Motivation • Stealth Multicast • Basic Architecture • Example: MYDEKI • Preliminary Results • Future Research • Inter-domain Peering • Network stack enhancement Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 12
MYDEKI Architecture • Implementation of stealth multicast • Multicast and You Don’t Even Know It • Three variations • ISP • Local • Application-assisted • Defines key issues of stealth multicast • Triggers- Virtual group release • Transport - Dynamic groups • State management - Where to place state Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 13
Virtual Group Triggers • Trigger • Dilemma: Gain for waiting • When to release the virtual group • MHT - Maximum Hold Time • TSW - Time Search Width • PSW - Packet Search Width Target packet MHT TSW PSW time Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 14
Triggers - Continued • Triggers/thresholds • MinGS - Minimum group size • MaxGS - Maximum group size • MVG - Maximum virtual groups New group Multicast Unicast VG 0 .. MVG MaxGS MinGS VG N Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 15
System Balance • VGDM Limit • MVG - Maximum Virtual Groups • Hard limit - should be avoided • No multicast benefit - overloaded • Inputs • Filter effectiveness • Eliminate non-candidate traffic • Triggers - dispatch • PSW, TSW, MHT • MaxGS • Tradeoff • Capacity, QoS vs. efficiency Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 16
Multicast Transport • Issue • Members (clients) not known a priori • Dynamically construct tree • Approaches • Exhaustive tree construction • All variations, all egress points • Problem - failure and tree reconstruction • Broadcast/hold • Costly - queuing at edge • Depends upon client distribution • Encapsulation-based • Embed tree inside the packet • Use DSMCast - DiffServ Multicast Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 17
Why Encapsulation? • Benefits • Dynamically construct trees • Dynamic routing - QoS • Heterogeneous QoS • Stateless core • Transport only - hardware • Simplified billing • Know tree, know cost • Tradeoff • Deployment - upgrade core • Additional bandwidth • Save 16x vs. 18x vs. None • Excellent starting point for evaluation Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 18
State Management • Issue • Unique portions of packet • Compress multiple packets for different destinations into a single packet • Dest port, dest IP • Who is responsible for exporting? • Egress A vs. Egress B vs. Egress C • Approaches • Include in packet • Similar to encapsulation-based approach • Distributed knowledge • Egress points share knowledge Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 19
Why Packet-based? • Benefits • Simple • No timing/state issues • Good first step • No problem with dynamics • Imprecise matching algorithms • Weaknesses • Bandwidth cost • Limitations on clients per group • MTU violations Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 20
Example - State Management IP DSM State UDP Payload Edge 5 5 10 15 3 Dest IP 129.186.5.4 129.186.6.20 143.24.6.4 102.67.8.25 50.6.8.20 Dest Port 7894 2004 5003 5796 6901 Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 21
Application-Assisted Method • Virtual group detection • Imprecise nature - best guess • Application-assist • Application knows about VGDM • Application sends 1 packet w/state to VGDM • VGDM constructs tree • Benefits • No change to the client - deployment • Precise group construction • Issues • Billing • Requires change to server app Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 22
Other Issues - TCP, IPSec, IPv6 • TCP • Limited benefit • Why? • Extra state • Retransmit of lost packets • Potential benefit • Web serving - initial request • Assume no cookies • CNN on 9/11 • IPSec / VPNs • IPv6 Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 23
Simulation Studies • Simulation setup • Ns-2 simulator • Freely available simulator • GenMCast module for ns-2, GRIM - simulation management • Network setup • Medium-sized multicast groups • On-line gaming apps - 8 to 64 clients • UDP traffic - 40 server apps • Compare various approaches • Based on VGDM location + others • Local, Stealth, None, App-Assist, ALM • Evaluation metrics • Bandwidth savings • End-user QoS Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 24
Effect of Clients - Link BW No savings, unicast Higher up-link cost Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 25
Effect of clients - Domain BW Increasing savings vs. unicast Trades B/W for client B/W Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 26
Effect of Clients - QoS (Delay) Limited impact of queuing Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 27
Other Results • Other aspect • Out of order delivery • VGDM Overload • Traffic aggregation • OS/app effect • Spacing between packets Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 28
Talk Overview • Information Dissemination • Motivation • Stealth Multicast • Basic Architecture • Example: MYDEKI • Preliminary Results • Future Research • Inter-domain Peering • Network stack enhancement Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 29
Immediate Research Areas • Practical transport • Encapsulation - interesting but academic • Compare various approaches • Fixed grouping w/hierarchy • How to find the group that maps to the egress points • Combination of groups • Broadcast w/hold • Impact of egress point sparsity • ALM • Apply ALM on a domain-wise level • Fixed vs. dynamic groups Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 30
Future Research Areas • Inter-domain peering • Transparent bandwidth conservation • Packet caching and stealth multicast • Edge routers of domains exchange info • Stealth multicast • Avoid conversion to/from multicast/unicast • Construct tree for new domain • Packet caching • Share cache in other domains • Issues • Billing, QoS • Resource management • Protocol / security Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 31
Future Research Areas • Network stack modification • Present: Minimize overhead • Avoid extra IP/TCP or IP/UDP headers • Premise • Can we increase redundancy but increase overall system performance? • Enhance network stack • Add End of Data marker - TCP • Modify sendmail / Apache to use • Issues • Benefit to the network • Downstream impact -> net system impact Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 32
Conclusions • Stealth multicast • New paradigm for multicast • Offers several key benefits • Solves multicast deployment issue • Zero modification outside of the domain • Inherent resource management • Offers directable economic benefit • Interesting research problems • Transport, state management • Inter-domain peering, stack optimization Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 33
Questions? striegel@cse.nd.edu http://www.cse.nd.edu/~striegel GenMCast Package (ns-2) http://www.cse.nd.edu/~striegel/GenMCast Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 34
Why Multicast? • Premise • Distribute same information to large number of users • Simple solution • Separate unicasts • Highly inefficient • N users -> N transmissions • Example: • ND Football Game - Streaming audio • 5,000 listeners - 56k modem - 4kB/s • Total BW: 20 MB/s • Videoconference - audio + video • 50 participants - 250 kB/sec • Total BW: 12.5 MB/s Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 35
Multicast • Operation • Reduces packet transmissionto an efficient tree • Relies on network state forreplication • Benefits • Reduced bandwidth • N receivers << N bandwidth • Bottleneck relief • Relief close to source • Simplifies sender management • Send to group vs. individuals Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 36
Obstacles/Issues • Why is multicast being adopted so slowly? • Chicken or the egg? • Development/deployment/demand circle • Global efficiency • Efficiency - adoption - global scale • Metcalfe’s Law - Network benefit • Additional infrastructure • Killer app • Does not offer a fundamentally new service • No killer app - 10x, 100x improvement • Depends upon deployment to become a killer app • ISP Economics Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 37
Multicast - ISP Economics • Questionable benefit • ISPs sell bandwidth • Multicast reduces bandwidth consumption • ISP perspective • Pay significantly, sell less • Billing • How to charge for multicast • How to get billing info • Distributed state of multicast • Other concerns • Internet growth myth - investment inertia • Problem can be solved by more bandwidth Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 38
DSMCast Operation C A B D E Node A B Replicate B D,E Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 39
Other Issues • IPSec • Problem • Can’t see UDP header - encrypted • Match checksum - OK • IPv6 • Two issues • Security headers • Address size • Force egress state Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 40
Other Research Projects • Grid computing - GRIM • Grid Resource Interface & Manager • Managing simulations • Script generation, stat management, grid operation • Scalable datacenters • Scale datacenter to 10-40 Gb/s+ • Manage train wreck of devices • FW, LB, IDS, etc. • DiffServ Multicast • Heterogeneous receivers • Resource management Striegel, Guest Lecture - UIUC (striegel@cse.nd.edu) 41