1 / 36

Applications and Cheetah

Applications and Cheetah. Malathi Veeraraghavan University of Virginia mv5g@virginia.edu. Outline eScience vs. commercial networks Three modes of bandwidth sharing large-m small-m, long-held calls small-m, short-duration calls Applications. MCNC meeting, April 10, 2006.

kaya
Download Presentation

Applications and Cheetah

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. Applications and Cheetah Malathi Veeraraghavan University of Virginia mv5g@virginia.edu • Outline • eScience vs. commercial networks • Three modes of bandwidth sharing • large-m • small-m, long-held calls • small-m, short-duration calls • Applications MCNC meeting, April 10, 2006

  2. Circuit/Virtual-Circuit technologies

  3. Goal of eScience networks • On previous slide, we said "QoS guarantees" • But usage of the term "networks" implies bandwidth sharing • If bandwidth is not shared, we have a "link" • Leased line service

  4. What's the difference? • leased line service • service provider is given enough lead time to add interface modules to meet request • eScience networks being designed today • above is not true • requests are handled by an automated scheduler and granted or denied within a short lead time • this is bandwidth sharing • this is "book-ahead" or "advance reservations"

  5. GMPLS control plane • How useful is it to these two types of networks? • Purpose of GMPLS control plane • Bandwidth (BW) sharing (dynamic& distributed) • Provisioning (threading the circuits/VCs) • BW sharing mode • Immediate request (can't specify a future call-initiation time or call holding time in protocols) • Call accepted or rejected: "call blocking"

  6. Understanding call blocking mode of BW sharing • Input parameters • Link capacity: e.g. 10Gbps • Express this as m channels • If per-call BW is 1Gb/s, m = 10 • m is comparable to the number of bank tellers • Traffic load • measure of call arrival rate (calls/sec) and mean call holding time (seconds/call) • Measure of success of BW sharing mode • Call blocking probability (% of calls blocked) • Link utilization

  7. Strong dependence on m: if m=10,to run link at an80% utilization level, call blocking probability will be a high 23.62% Call blocking probability vs. m Utilization m is a measure of high-throughput vs. moderate-throughput difference between eScience and commercial networks For high-throughput, m is small

  8. Dependence on call duration?(eScience: long-held; commercial: short-duration) • Consider traffic load • Typically, if mean call duration (holding time) is high, call arrival rate is low • Traffic load is a product of these two parameters • For a given call blocking probability, link utilization and m, the required traffic load is a fixed value • Dependence on call duration unclear

  9. But BW sharing does depend on mean call holding time if m is small • Mean waiting time is proportional to mean call holding time • Can afford to have a queueing based solution if calls are short Large m Moderate throughput Small m High throughput immediate-request with call blocking Short calls Bank teller Long calls Doctor's office call queueing book-ahead

  10. eScience: small-m, long-held • Does a book-ahead BW sharing mechanism help with the high call blocking probability problem? • We analyzed and simulated two types of Book-Ahead (BA) mechanisms • BA-n: caller specifies n call-start time options • BA-all: caller is willing to accept any open time slot • Parameters: • K: reservation time horizon (in timeslots): 2000 • Two call classes: • class-1 holding time: 100 (h1); 10% of calls (r1) • class-2 holding time: 300 (h2); 90% of calls (r2)

  11. Call blocking probability (m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9) Xiangfei Zhu, xz4p@virginia.edu

  12. Utilization (m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9) Xiangfei Zhu, xz4p@virginia.edu

  13. Observations • BA-n/BA-all performs better than IR • eg., if we want to achieve 80% utilization, the call blocking probabilities using different mechanisms are • IR, 22.6% • BA-3, 8.3% • BA-5, 4% • BA-10, 2% • BA-all, almost 0% • BA-1 performs worse than IR • because of the interaction between the two call classes • if class-1 calls reserve timeslots with gaps, class-2 calls are denied Xiangfei Zhu, xz4p@virginia.edu

  14. Third type of BW sharing • Calls with small-m, short-duration • Call queueing mode • Have a couple of ideas, but need to study • delayed start • distributed queueing at callers (like CSMA-CD)

  15. Status check • Outline • eScience vs. commercial networks • Three modes of bandwidth sharing • large-m • small-m, long-held calls • small-m, short-duration calls • Applications

  16. Applications (small-m, long-held) • Cheetah project supports TSI (Terascale Supernova Initiative) • Very large dataset (TB) transfers • Ensight for remote visualization • Other apps with high-throughput long-duration calls (good for book-ahead) • Other eScience applications • e-Learning (small-USBs at each desk - better quality) • Access Grid, Videnet video conferencing, teleimmersion • Distributed Grid computing - MPI apps, e.g. blast (recruit clusters - 6 hours) • IPTV/VOD/HDTV/Triple-play video streaming (entertainment) • Asynchronous Storage Area Network support (nightly backups)

  17. Applications • Large-m applications • High-quality video-telephony (10Mbps) at every desk (3 min. average durations) • 100MB to GB range file transfers: • through web (Red Hat Linux distribution) • GridFTP, PVFS, NFS/XFS • web caching • Remote storage: LORS IBP Depots, synchronous SAN operations • Gaming (warcraft, battlenet) • currently written for low-BW; need good Graphics cards • if higher-BW is available can more information be moved with simpler lower-cost graphics cards for a lower-lag experience? • OfficeLive, "network is the computer" model, old dumb-terminal model • lower admin costs • Others? Suggestions? • Small-m (high-throughput), short-duration calls • 100MB to GB range file transfers • Want to give 1Gbps per transfer to lower delays

  18. Status check • Outline • eScience vs. commercial networks • Three modes of bandwidth sharing • large-m • small-m, long-held calls • small-m, short-duration calls • Apps for large-m • video-telephony • web downloads and caching

  19. Video telephony • Paul Sijben writes: "Today, video telephony usually implies that a group of people gather around a table and watch a TV showing a similar group of people around another table. Personal video telephony usually means watching postage stamp sized people in a PC screen, whose image is refreshed occasionally." • Also, "As has been known for quite some time, the nuances of face, body and arm gestures add a wealth of information to communication." • Can we exploit higher-speeds (10Mbps, OC1, OC3 rates) for better TV-like video-telephony? • Delay requirement: 150ms one-way • Compress less, use more bandwidth for lower latency and higher quality

  20. Sony SNC-RZ30 Camera • Ethernet output: • 640 x 480 @ 30 FPS • ~ 8Mb/s using Motion-JPEG • Built-in web server • Total system latency • ~109ms(90-160ms observed) • Timer courtesy of www.Auvidea.com Tyson Baldridge, tyson@virginia.edu

  21. Video Products Group – VPG5720 • Maps video signal onto a Sonet OC3 • I/O Connections: • Video: SDI or NTSC/PAL • Audio: AES/EBU or analog • A/V Sync within 10mS • Unidirectional: need a TX & RX module at both endpoints. • Need one chassis per endpoint: VPG6200 • Esoteric solution, but ideal for testing best-case performance • Any experience? Tyson Baldridge, tyson@virginia.edu

  22. Other issues • Automating "camera-man," "director" roles • Movement sensor based positioning of camera? • Lighting issues • Eye contact • Placement in offices • LCD projectors on to walls? • Multiple camera feeds - hence the director role? • Not really teleimmersion but a better experience to improve remote communications (save energy costs, less travel!) • Suggestions?

  23. Status check • Outline • eScience vs. commercial networks • Three modes of bandwidth sharing • large-m • small-m, long-held calls • small-m, short-duration calls • Apps for large-m • video-telephony • web downloads and caching

  24. File transfer application • Two CHEETAH solutions • Web file transfers across CHEETAH (end-to-end) • Web caching (partial-path circuits)

  25. Web File Transfer on CHEETAH Consists of a software package, called WebFT • Leverages CGI for deployment without modifying web client and web server software • Integrated with CHEETAH end-host software APIs to provide use of CHEETAH network in a mode transparent to users Xiuduan Fang, xf4c@virginia.edu

  26. WebFT Architecture Web server Web client URL CGI scripts (download.cgi & redirection.cgi Web Browser (e.g. Mozilla) Web Server (e.g. Apache) Response RSVP-TE daemon WebFT sender OCS daemon OCS API RD API WebFT receiver Control messages via Internet RD daemon RSVP-TE API RSVP-TE API Data transfers via a circuit RSVP-TE daemon C-TCP API C-TCP API Cheetah end-host software APIs and daemons Cheetah end-host software APIs and daemons OCS: Optical connectivity service RD: Routing Decision C-TCP: Circuit TCP Xiuduan Fang, xf4c@virginia.edu

  27. Experimental Testbed and Results for WebFT--cont. Internet • Zelda3 and Wukong: Dell machines, running Linux FC3 and ext2/3, with RAID-0 SCCI disks • RTT between them: 24.7ms on the Internet path, and 8.6ms for the CHEETAH circuit. IP routers IP routers zelda3 NIC I wukong NIC I NIC II CHEETAH Network NIC II Sycamore SN16000 Atlanta, GA Sycamore SN16000 MCNC, NC Xiuduan Fang, xf4c@virginia.edu

  28. Experimental Results for WebFT--cont. • Test parameters: • Test.rm: 1.6 GB, circuit rate: 1 Gbps • Test results • throughput: 680 Mbps, delay: 19 s The web page to test WebFT Xiuduan Fang, xf4c@virginia.edu

  29. Web caching (partial-path circuits) • Uses the web proxy software package, squid, to make CHEETAH accessible to non-CHEETAH hosts. • Improves web performance by • Breaking up the long-distance connectionless (CL) path into a partial circuit through CHEETAH, and two low-RTT CL sub-paths • Leverages web caching protocols Xiuduan Fang, xf4c@virginia.edu

  30. The Framework for using web caching and partial-path circuits Internet HTTP messages Original HTTP messages HTTP messages squid squid CHEETAH Web client Web server CHEETAH Application Gateway (CAG) CHEETAH Application Gateway (CAG) HTTP and ICP messages Xiuduan Fang, xf4c@virginia.edu

  31. Experimental Testbed • Configure caching hierarchy such that zelda1’s NIC II is wuneng’s parent. • Configure CAGs to cache file with the size < 4 GB • RTT for the Internet path: • ballstein and wuneng: 14.6 ms • RTT for the CHEETAH path • wuneng and zelda1: 8.9 ms Xiuduan Fang, xf4c@virginia.edu

  32. Experimental Results for Web Partial CO Transfer Xiuduan Fang, xf4c@virginia.edu

  33. Future Work • Decide whether to use a partial-path circuit by examining the client’s geographic location relative to server • Use squid to connect multiple circuit/VC networks to further reduce RTT • Test the scalability and reliability of squid • Model, analyze and measure performance improvement by using a partial-path circuit Xiuduan Fang, xf4c@virginia.edu

  34. Thanks for listening! • Conclusions: • Add MPLS and/or SONET to create large-m (moderate-BW) mode of sharing • Enable partial-path circuits - through Policy Based Routing to isolate flows (trigger signaling from host) • Avoiding BW partitioning for IR and BA is hard because IR calls have unlimited holding time while BA needs specified holding time • Centralized scheduler per domain is acceptable if BA load is low • Suggestions, comments, thoughts? • email address: mv5g@virginia.edu

  35. CHEETAH Network NYC HOPI Force10 CUNY Foundry UVa 1G UVa Catalyst 4948 WASH HOPI Force10 1G UVa host H H CUNY host CUNY NCSU M20 WASH Abilene T640 2x1G MPLS tunnels NC ORNL Orbitty Compute Nodes 1G Centuar FastIron FESX448 Compute-0-4 152.48.249.6 H 1G Compute-0-3 152.48.249.5 H 1G Force10 E300 switch Compute-0-2 152.48.249.4 1G H 1GFC 1G UCNS X1(E) Compute-0-1 152.48.249.3 H 1G Compute-0-0 152.48.249.2 H 1G Wukong 152.48.249.102 H 3x1G VLAN OC192 OC192 GbE 1G 1G 1G MCNC Catalyst 7600 1-8-33 GbE 10GbE OC192 1G 1-8-34 1-7-33 1-6-1 1-7-1 1G 1G 1-8-35 Zelda4 10.0.0.14 1-7-34 H 1G 1G 1-8-36 1-7-35 Zelda5 10.0.0.15 1-7-1 1-6-1 1G H 1-8-37 1-7-36 1-6-17 1-7-17 1-8-38 1G 1G Wuneng 152.48.249.103 Cheetah-ornl 1-8-39 H cheetah-nc Juniper T320 Atlanta OC-192 lamda Direct fibers GbE OC192 10GbE 1G Zelda1 10.0.0.11 1-7-33 H 1G VLANs Zelda2 10.0.0.12 1-7-34 H 1G Zelda3 10.0.0.13 1-7-35 1-6-1 H MPLS tunnels 1-7-36 1G Juniper T320 1-7-1 1-7-37 2x1G MPLS tunnels 1G 1-7-38 1-6-17 1-7-39 Cheetah-atl Xuan Zheng, xuan@virginia.edu

  36. Current status • Thanks to HOPI: UVA and CUNY connectivity to CHEETAH almost done • Software completed • RSVP-TE end host clients • C-TCP transport protocol • OCS - DNS based solution to check connectivity • C-VLSR for Ethernet switches • WebFT application • Current focus: • TSI support + growth of network + large-m applications

More Related