1 / 33

A Multi-Path Routing Service for Immersive Environments

A Multi-Path Routing Service for Immersive Environments. Sherlia Shi, Lili Wang, Kenneth L. Calvert, and James Griffioen Laboratory for Advanced Networking University of Kentucky. Supported by NSF, DARPA, and Intel. The Metaverse.

berk-bird
Download Presentation

A Multi-Path Routing Service for Immersive Environments

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 Multi-Path Routing Service for Immersive Environments Sherlia Shi, Lili Wang, Kenneth L. Calvert, and James Griffioen Laboratory for Advanced Networking University of Kentucky Supported by NSF, DARPA, and Intel

  2. The Metaverse • Goal: design, implement, deploy, use and evaluate networked, collaborative, visualization environmentsthat act as portals into theMetaverse*. • Basic Problem: Visualize and interact with 3D models, simulated objects, time-dependent data, image data, avatars, and video streamsin collaboration with remote users across the Internet • Research Areas: computer vision, graphics, networking protocols and services * Neil Stephenson, Snowcrash, 1997. CCGrid: Workshop on Grids and Advanced Networks

  3. Example Fire Whirl Data An Example Metaverse App A CFD Example - Visualize a 3D animated simulation - Interact with the model - Collaborate with colleagues or students at remote metaverse portals CCGrid: Workshop on Grids and Advanced Networks

  4. Model Server Model Server Model Server Network Metaverse Components CCGrid: Workshop on Grids and Advanced Networks

  5. Network Metaverse Portal CCGrid: Workshop on Grids and Advanced Networks

  6. Metaverse Portal Immersive Display Environment Based on inexpensive, commodity, self-configuring, networked components CCGrid: Workshop on Grids and Advanced Networks

  7. Metaverse Portal Immersive Display Environment • rendering engines CCGrid: Workshop on Grids and Advanced Networks

  8. Metaverse Portal Immersive Display Environment • rendering engines • projectors • cameras Driven by cheap, commodity, graphics and video cards CCGrid: Workshop on Grids and Advanced Networks

  9. Metaverse Portal Immersive Display Environment • rendering engines • projectors • cameras • motion sensors CCGrid: Workshop on Grids and Advanced Networks

  10. Metaverse Portal Immersive Display Environment • rendering engines • projectors • cameras • motion sensors • local area network CCGrid: Workshop on Grids and Advanced Networks

  11. Metaverse Portal Immersive Display Environment • rendering engines • projectors • cameras • motion sensors • local area network • control processors CCGrid: Workshop on Grids and Advanced Networks

  12. Immersive, Multiprojector rendering(18 projectors) Walkthrough 1 View 1 Walkthrough 2 View 2 CCGrid: Workshop on Grids and Advanced Networks

  13. Metaverse Data • Data consists of multiple components • Texture maps • Polygonal meshes • Volumetric Data • User Control Data (position tracking, 3D mouse) • Same data may be represented in arbitrary ways • Resolutions – potentially variable resolution • Encodings • Time Series Data (=> video-like) • Generated Data CCGrid: Workshop on Grids and Advanced Networks

  14. Metaverse Applications • Goal:Offer the most compelling immersive experience possible! • Assumptions: • Massive amounts of complex data to be transmitted • Cannot assume over-provisioning or QoS guarantees • User’s definition of compelling depends on several factors • Application can design for these factors • Application does not want to know details of transport • Implications: • Not all data can/needs to be sent • Data that is “the most important” to send depends on the user and the network. • Communication channel must support cooperation between the network and the applications. • Need to maximize bandwidth subject to (good “net citizen”) constraints CCGrid: Workshop on Grids and Advanced Networks

  15. Transport API Requirements • Feedback: about transport capabilities. • Single end-to-end communication channel: need a simple “session” abstraction -- App is not interested in implementation details. • Data “importance”: App specifies what data to transmit to achieve “compelling” • Sender / Receiver Cooperation: sender specifies data, receiver defines quality • Reliability: data transmitted reliably CCGrid: Workshop on Grids and Advanced Networks

  16. Feedback • Feedback could describeany “aspect” of the service • Feedback “aspects” may be network-dependent • Feedback could be at many levels of detail. • Apps don’t want to deal with the above complexity! • Apps have no desire to control the transport service (i.e., twist transport knobs). Understanding and mapping knobs to user satisfaction is too hard. • Simply want to know “what if” answers! Let transport service figure out the mapping! CCGrid: Workshop on Grids and Advanced Networks

  17. New Service Abstraction Sender • Specify “important” data • Change definition of “important” as needed Receiver • Specify a prioritized delivery plan • Let service map the delivery plan onto the underlying network • Provide predictions of how well the service will perform • Goto 1 CCGrid: Workshop on Grids and Advanced Networks

  18. Prioritized Data • Specified as a hierarchy of nodes • Leaf nodes represent a semantically meaningful data unit, called an “object”. Objects are the smallest logical unit and are delivered as a whole • Internal nodes represent groups of objects and define the percentage of bandwidth to give to each subtree. • Each tree denotes a priority level • Children nodes may require ordered delivery CCGrid: Workshop on Grids and Advanced Networks

  19. Example Transmission Specification Priority 0 Priority j 1 1 0.6 0.4 0.2 0.5 0.3 c 0.5 0.3 b a 0.2 Unordered, No weights Ordered CCGrid: Workshop on Grids and Advanced Networks

  20. Metaverse Transport Service API • int open_session(struct sockaddr* svrAddr) • intclose_session(int sessId) • int set_recv_handle(int sessId, int objId, void *buf, int len, CallBackFunction* call_back) • MetaInfo*schedule_objects(int sessId, MetaInfo* objects, int modified) CCGrid: Workshop on Grids and Advanced Networks

  21. A Multi-path Transport Service • Goal: • Maximize throughput • Find independent paths • Distribute load across paths • Minimizing network load • Limit the hops and delay • Share bandwidth across “links” fairly • Need a sharing policy • Implication: • Need more control: Use Overlay/Grid • Control routing • It becomes a “Shared Service” CCGrid: Workshop on Grids and Advanced Networks

  22. 12 Mbps! 21 Mbps! 714 Kbps 3 Mbps PlanetLab Example Improving Throughput (v2)! • Improving Throughput (v1) • use TCP unfriendly protocols • use multiple TCP flows CCGrid: Workshop on Grids and Advanced Networks

  23. Transport Service Tasks • Discover network characteristics to find high-bandwidth communication channel(s) between source and destination • Select a set of routes subject to constraints limiting the load imposed on the network • Dynamically map object hierarchy to paths (i.e., distributed load across the selected paths). CCGrid: Workshop on Grids and Advanced Networks

  24. Residual Bandwidth Discovery • Each overlay node passively monitors current bandwidth usage to other overlay nodes • Avoids active probing (ping, iperf, traceroute,…) • Record two variables for an active “virtual link” • Peak bandwidth • Average measured bandwidth • Difference is an estimate of residual bandwidth • Information built up over time and shared among nodes CCGrid: Workshop on Grids and Advanced Networks

  25. Path Selection • Selection algorithm must choose multiple paths to optimize some objective function, subject to various constraints. • How many paths should be selected? • What is the maximum length of a path? • Are some paths preferred over others? • Are the paths disjoint? • We evaluated three path selection algorithms CCGrid: Workshop on Grids and Advanced Networks

  26. Random Path Selection • Randomly select paths from the source to the destination. • Start from source and randomly select a link that satisfies the constraints, otherwise backtrack and try another link • Only guarantees that the virtual paths are disjoint, not the physical paths CCGrid: Workshop on Grids and Advanced Networks

  27. Closest First Path Selection • Closest First Multipath (CFM) routing uses a breadth-first approach to select paths with the shortest hop count. • Start from the source and select all edges • For each selected node, select all edges • When destination is reached, add path to feasible set • If more feasible paths than allowed, select from feasible set randomly. CCGrid: Workshop on Grids and Advanced Networks

  28. Widest First Path Selection • Widest First Multipath (WFM) routing selects the paths with the highest bandwidth • Start with the source, following the widest path • If the destination is reached, the widest path edges are removed, and the algorithm restarts • If there are more feasible paths than allowed, paths are selected from the feasible set randomly CCGrid: Workshop on Grids and Advanced Networks

  29. Mapping Data to Paths • A variety of mappings possible • Our approach sends all fragments of an object over the same path to minimize fragmentation effects • Our goal is to minimize the “finish time” (adhering to the data prioritization plan), while satisfying the buffering constraints at the receiver. CCGrid: Workshop on Grids and Advanced Networks

  30. Experimental Results • Alpha = sharing policy (% of residual for local traffic) • When alpha is 0 (no protection) and network load is high, all algorithms perform poorly • Medium values of alpha produce good throughput at low load and converge to the shortest path at high load • Random tends to pick paths that are unnecessarily long and have low bandwidth Random Closest First Widest First CCGrid: Workshop on Grids and Advanced Networks

  31. 5th Percentile Results CCGrid: Workshop on Grids and Advanced Networks

  32. Correlated Paths • Are hard to identify, because topology info is not readily available • Traceroute is not sufficient • Not clear how important it is to know if paths are correlated or not • We developed two passive techniques to identify correlated links – each has its own advantages. CCGrid: Workshop on Grids and Advanced Networks

  33. Summary • Metaverse-like applications require a new API • We proposed an API that allows application and network to work together • Proposed a passive monitoring approach to estimate available bandwidth • Designed and evaluated three algorithms for path selection • Developed an algorithm to load balance across paths – based on the data priority spec. CCGrid: Workshop on Grids and Advanced Networks

More Related