Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Applications and Cheetah Malathi Veeraraghavan University of Virginia [email protected] 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 1 Circuit/Virtual-Circuit technologies eScience networks Commercial networks Raison d'etre High-throughput connectivity between a few facilities Moderate-throughput connectivity between millions of users Key goal QoS guarantees Bandwidth sharing (different style from TCP based sharing) Call Long-held duration Short-duration Reach Partial (HOV lanes) End-to-end 2 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 3 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" 4 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 callinitiation time or call holding time in protocols) Call accepted or rejected: "call blocking" 5 Understanding call blocking mode of BW sharing Input parameters Link capacity: e.g. 10Gbps Traffic load Express this as m channels If per-call BW is 1Gb/s, m = 10 m is comparable to the number of bank tellers 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 6 Strong dependence on m: if m=10, to run link at an 80% 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 7 For high-throughput, m is small 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 8 But BW sharing does depend on mean call holding time if m is small Large m Moderate throughput Small m High throughput immediate-request with call blocking Short calls call queueing Bank teller Long calls Doctor's office book-ahead Mean waiting time is proportional to mean call holding time Can afford to have a queueing based solution if calls are short 9 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 BookAhead (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) 10 Call blocking probability 0.35 0.3 BA-1 Call blocking probability P B Erlang-B 0.25 IR 0.2 BA-3 0.15 BA-5 0.1 BA-10 0.05 BA-all 0 0.01 0.015 0.02 0.025 0.03 0.035 Call Arrival Rate 0.04 0.045 0.05 (m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9) 11 Xiangfei Zhu, [email protected] Utilization 1 BA-all BA-10 BA-5 0.9 0.8 Utilization U 0.7 BA-3 IR & Erlang-B 0.6 BA-1 0.5 0.4 0.3 0.2 0.01 0.015 0.02 0.025 0.03 0.035 Call Arrival Rate 0.04 0.045 0.05 (m=10, K=2000, l=2, h1=100, h2=300, r1=0.1, r2=0.9) 12 Xiangfei Zhu, [email protected] 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 13 Xiangfei Zhu, [email protected] 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) 14 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 15 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) 16 Applications Large-m applications High-quality video-telephony (10Mbps) at every desk (3 min. average durations) 100MB to GB range file transfers: 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 lowercost graphics cards for a lower-lag experience? OfficeLive, "network is the computer" model, old dumb-terminal model through web (Red Hat Linux distribution) GridFTP, PVFS, NFS/XFS web caching 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 17 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 18 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 19 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 20 Tyson Baldridge, [email protected] 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? 21 Tyson Baldridge, [email protected] 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? 22 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 23 File transfer application Two CHEETAH solutions Web file transfers across CHEETAH (end-to-end) Web caching (partial-path circuits) 24 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, [email protected] 25 WebFT Architecture Web server Web client Web Browser (e.g. Mozilla) URL Response RSVP-TE daemon Web Server (e.g. Apache) CGI scripts (download.cgi & redirection.cgi WebFT sender WebFT receiver RSVP-TE API C-TCP API Control messages via Internet Data transfers via a circuit Cheetah end-host software APIs and daemons OCS API RD API OCS daemon RSVP-TE API RD daemon C-TCP API RSVP-TE daemon Cheetah end-host software APIs and daemons OCS: Optical connectivity service RD: Routing Decision C-TCP: Circuit TCP 26 Xiuduan Fang, [email protected] Experimental Testbed and Results for WebFT--cont. Internet IP routers IP routers NIC I NIC I zelda3 NIC II wukong CHEETAH Network Sycamore SN16000 Atlanta, GA NIC II Sycamore SN16000 MCNC, NC 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. 27 Xiuduan Fang, [email protected] Experimental Results for WebFT--cont. The web page to test WebFT Test parameters: Test.rm: 1.6 GB, circuit rate: 1 Gbps Test results throughput: 680 Mbps, delay: 19 s 28 Xiuduan Fang, [email protected] Web caching (partial-path circuits) Uses the web proxy software package, squid, to make CHEETAH accessible to nonCHEETAH 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 29 Xiuduan Fang, [email protected] The Framework for using web caching and partial-path circuits Internet Original HTTP messages HTTP messages Web client HTTP messages squid squid CHEETAH CHEETAH Application Gateway (CAG) HTTP and ICP messages Web server CHEETAH Application Gateway (CAG) 30 Xiuduan Fang, [email protected] Experimental Testbed Web server Web client Ballstein.cs.virginia.edu CHEETAH CAG wuneng at MCNC NIC I: 128.109.34.22 NIC II: 152.48.249.103 CAG zelda1 at Atlanta NIC I: 130.207.252.131 NIC II: 10.0.0.11 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 31 Xiuduan Fang, [email protected] Experimental Results for Web Partial CO Transfer Web server parameters name RTT (ms) with location zelda1 ballstein total RTT (ms) through CHEETAH file size (MB) delay (s) through CHEETAH, cached? No Yes Intern et path www.kernel.org Ashland, Oregon 61.6 86.0 14.6 + 8.9 + 61.6 = 85.1 48 33 18 70 internap.dl.sour ceforge.net Atlanta, GA 6.0 32.0 14.6 + 8.9 + 6.0 = 29.5 113 140 36 520 www.cs.virginia. edu Charlot tesville, VA 25.0 <1 14.6 + 8.9 + 25.0 = 48.5 113 50 30 14 32 Xiuduan Fang, [email protected] 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 33 Xiuduan Fang, [email protected] Thanks for listening! Conclusions: Add MPLS and/or SONET to create large-m (moderateBW) 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: [email protected] 34 CHEETAH Network NYC HOPI Force10 UVa UVa host H ORNL 1G Compute-0-2 152.48.249.4 1GFC UCNS 1G 1G 1G H H H WASH Abilene T640 H CUNY host CUNY OC192 Centuar FastIron FESX448 1G 1G 1G H Compute-0-1 152.48.249.3 H Compute-0-0 152.48.249.2 Wukong 152.48.249.102 H X1(E) OC192 1G 2x1G MPLS tunnels WASH HOPI Force10 Orbitty Compute Nodes Compute-0-4 152.48.249.6 Compute-0-3 152.48.249.5 Force10 E300 switch 1G UVa Catalyst 4948 1G NCSU M20 NC CUNY Foundry 3x1G VLAN GbE 1G 1G GbE Zelda4 10.0.0.14 H Zelda5 10.0.0.15 H 1G 1G 1-8-33 1-8-34 1-6-1 1-7-1 1-8-35 1-8-36 1-8-37 1-6-17 1-7-17 1-8-38 10GbE OC192 1-7-33 1-7-34 1-7-35 1-7-1 1-6-1 1-7-36 1G 1G 1G 1G 1G 1G 1-8-39 Cheetah-ornl MCNC Catalyst 7600 H Wuneng 152.48.249.103 cheetah-nc Juniper T320 Atlanta OC-192 lamda Zelda1 10.0.0.11 H Zelda2 10.0.0.12 H Zelda3 10.0.0.13 H 1G 1G 1G 1G 2x1G MPLS tunnels Juniper T320 1G GbE 10GbE OC192 1-7-33 1-7-34 1-7-35 1-6-1 1-7-36 1-7-1 1-7-37 1-7-38 1-6-17 1-7-39 Direct fibers VLANs MPLS tunnels 35 Cheetah-atl Xuan Zheng, [email protected] 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 36