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
Computer network wikipedia , lookup
Distributed firewall wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Video on demand wikipedia , lookup
Serial digital interface wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Evaluation of Digital Video Transmission via DVTS Software over NYU-NET between NYU Washington Square and NYU Medical Center Campuses Jimmy Kyriannis Senior Technology Architect NYU Information Technology Services, C&CS Fall, 2005 Introduction A technology trial of a high-quality, high-bandwidth digital video transmission over the NYU campus network (NYU-NET) was conducted for the first time. The goal of this trial was to determine the feasibility of using Digital Video Over IP (DVIP) between the NYU School of Medicine (the NYU SoM) and its collaborators, both at the Washington Square (NYU) campus and elsewhere at Internet- and Internet2- connected institutions. One possible application of DVIP at the NYU SoM is instructional in nature, where three audio/video sources are streamed to an audience, while one stream is transmitted back to provide audience feedback to the instructor. Though successful, a few difficulties were faced during the tests, which served to distinguish high-bandwidth DVIP technology as one which requires greater attention to its use than do more common client-server network applications. Technology Overview DVIP is a technology by which coordinated audio and video are encoded into a digital format by a dedicated system or a computer with video capabilities, and then delivered to one or more receivers via IP communications over a conventional data network. The amount of network bandwidth used for the transmission is typically a function of the quality of the conveyed content and the characteristics of the codec(s) used to present it. Very low data rate audio/video (A/V) transmissions used by conferencing software characteristically delivers low to average quality images, albeit in small size formats to reduce the amount of data transmitted and conserve bandwidth on slow network links. On the opposite end of the spectrum, high-quality video – especially high definition - can easily consume tens or hundreds of megabits per second of bandwidth. A substantial amount of network infrastructure is required to support such transmissions, which can be quite costly to implement, especially if outside the confines of a local area network (LAN). DVTS (Digital Video Transport System, http://www.sfc.wide.ad.jp/DVTS) is an application which accepts DV25-encoded (typical digital camcorder output) video, and transmits it over an IP network at roughly 30Mbps per stream. The DVTS software is freely available for use on Windows, MacOS X and various UNIX platforms; it only accepts video input for encoding via a digital FireWire interface connection, and can output received IP video either directly to a FireWire video output device or (with lesser quality) into a display window on the computer’s desktop. DVTS can transmit and receive IP video via IPv4 unicast or multicast, as well as IPv6 unicast or multicast. Since a significant amount of computing power is required to process digital video at 30Mbps, it is noteworthy that a computer with a clock rate of less than 1 GHz is likely too slow for practical use with DVTS. Nonetheless, DVTS was chosen for a DVIP trial at the NYU SoM since its excellent video output successfully conveys fine detail, a requisite for usefully transmitting video material of surgical procedures. DVTS Test Process Testing of the DVTS application took place during the summer and early fall of 2005, and were divided into four phases; 1) tests of DVTS software use and its viability on the local networks of both the NYU SoM and NYU campuses; 2) live transmission tests between the NYU SoM and NYU; 3) live transmission test between NYU in New York, NY and UC Berkeley (UCB) campus in Berkeley, CA; and 4) a final live transmission test between the NYU SoM (New York, NY) and UC Berkeley. These tests were conducted with IPv4 unicast, over UDP ports 8000 and 8001 (default settings). The fairly straightforward first phase of the DVTS testing was done largely to overcome any configuration difficulties with the software, to confirm the viability of DVTS, and confirm that the local networks could support the demand of such high bandwidth applications. Once completed, as a prelude to the second phase of testing, a fairly rigorous set of network benchmark and stress tests were conducted between the NYU SoM and Warren Weaver Hall at the NYU campus. This set of preliminary tests was designed to determine the amount of usable bandwidth between the two campuses, and help identify any bottlenecks imposed by network infrastructure such as routers or firewalls. Iperf (http://dast.nlanr.net/Projects/Iperf/), a common network benchmarking tool, was used to conduct performance tests between the two campus networks during off-hours. Initial tests demonstrated about 220Mbps of usable bandwidth between them, however, it was later determined that a firewall security setting was in place to impede high bandwidth activity. When that setting was adjusted to support the DVTS test, the amount of bandwidth available for an individual data stream jumped to 559 Mbps for a sustained 1-minute TCP transmission, and 613 Mbps for a 1-minute UDP transmission. The lesser performance of TCP was attributed to the processing overhead associated with it at high data rates. With DVTS requiring 30Mbps of bandwidth per video transmission, the performance numbers confirmed that the network could safely support the application, even during business hours. The live DVTS transmission tests between the NYU SoM and NYU, though successful, revealed a number of points regarding its use: - - - A fair amount of coordination is required with firewall admin staff, as any static NAT translations for inbound transmissions must be set beforehand and coordinated, and support for inbound transmissions on UDP ports 8000 and 8001 must be similarly configured in access rules. Any rate limiters the data path must be adjusted to accommodate DVTS on the network. During initial tests, at least, network staff should be available to monitor and characterize network usage and performance. To the DVTS user, it’s entirely unclear whether software difficulties are rooted in a network problem or an issue with DVTS itself. Ample computers for testing purposes should be available on either side of the test, with reasonable processing power and ample free memory. Ultimately, four DVTS streams were transmitted simultaneously, for a total of 120Mbps of DVIP data being sent in the form of two bidirectional streams. Prior to the third phase of testing to an Internet2-connected site, iperf and DVTS trials were conducted with our Internet2 service provider, NYSERNet. Though receipt of network data from NYSERNet was reliable, receipt of NYU data by NYSERNet was poor and lossy. DVTS video received by NYSERNet, in particular, was non-functional. By virtue of these tests, a single strand of NYU fiber optic cable on the path to Internet2 was found to exhibit a very low level of errors. Since DVTS uses UDP for transmission of its video stream, it is not readily able to recover from errors and as a result is very sensitive to packet loss even at such low levels. The majority of campus applications which use Internet2 resources are TCP-based, and use lower amounts of bandwidth. Since TCP can recover from errors, routine applications were not visibly affected by the fiber problem. Once the fiber issue was resolved, however, DVTS transmissions to and from NYSERNet functioned well, in fact, over the four major IP protocols: IPv4 unicast, IPv4 multicast, IPv6 unicast and IPv6 multicast The third phase of testing, a DVTS transmission in each direction between NYU and UCB, was successful and ran without difficulty, though a bit of burstiness was experienced in receipt of the NYU video. That issue was later identified as a behavior unique to DVTS under the FreeBSD platform in use. In the final set of tests, a complete simulation of the distance learning experience was established, where three 30Mbps DVTS streams were sent to UCB, while one return stream was sent back to the NYU SoM. Prior to the onset of the tests, the external IP address of the one statically-mapped NAT’ed receiver at the NYU SoM was provided to UCB staff, and the IP address of that UCB source streaming into the NYU SoM was configured into NYU firewalls. A credit to the amount of testing and preparatory work done ahead of time by staff at both NYU and UCB, the four simultaneous DVTS streams came up immediately with no difficulties. The quality of each stream was excellent, especially when FireWire cameras were used as sources, despite the fact that the test constituted a 6,000 mile round-trip from sourced instructional video to receipt of the audience feedback return stream. For a brief period of time during the tests, some packet loss was experienced on the stream to New York, however, UCB networking staff were able to identify a congestion point in Internet2 infrastructure at Indianapolis, which resolved itself within a few minutes. Given the distributed nature of Internet2, brief periods of heavy use of the Abilene Network can occur from time to time, which may cause difficulties for applications such as DVTS which are intolerant of jitter or loss. The four streams in the final test consumed an aggregate amount of 120Mbps of bandwidth over Internet2: 90Mbps from NYU SoM to UC Berkeley, 30Mbps from UCB to NYU SoM. The network utilization graph in Figure A documents receive and transmit levels at the time of the test, which began at 5pm EDT. Figure A: Network utilization levels during the final test (1700 hours EDT; X-axis depicts time) `Daily' Graph (5 Minute Average) Max In: 109.9 Mb/s (11.0%) Average In: 16.5 Mb/s (1.7%) Current In: 13.8 Mb/s (1.4%) Max Out: 46.6 Mb/s (4.7%) Average Out: 15.5 Mb/s (1.5%) Current Out: 9420.3 kb/s (0.9%) Trial Results Though the DVIP tests successfully demonstrated the use of DVTS over the NYU campus network and on Internet2, it was not accomplished without significant effort from technical staff expert in both networking and digital video at both NYU and UC Berkeley. Technology components of the trial, including firewall configuration, network monitoring and troubleshooting, A/V hardware configuration and support, and DVTS host computer performance tuning, were stressed far beyond what is experienced with routine on-campus and Internet client-server applications. The intellectual capital expended for this trial was considerable. Though DVTS offers high quality video at no software cost, it does not, in fact, come without a price. At least two DVTS-capable systems are necessary at each end of a two-way conversation, as a system cannot reasonably transmit and receive DVTS video simultaneously. Low-cost video cameras are not compatible with DVTS; FireWire video sources are required for transmitting video, although received video can be output either directly on a receiver’s monitor or on a FireWire video output device. At 30Mbps per stream, switched fast ethernet is the minimum network capable of supporting a bidirectional DVTS session, and routers with hardwareaccelerated packet switching are best capable of supporting the conveyed network traffic. Given the high bandwidth and low tolerance for loss and jitter, DVTS proved to be excellent at identifying networks not operating reliably and entirely error-free. The DVTS software itself is rather stable on the Windows XP platform, while the GUI-based MacOS X implementation isn’t as reliable. Still, both versions are fairly processor-intensive, performing best on systems with clock rates greater than 1 GHz. The windows XP implementation, in particular, appeared to have difficulty recovering from severe processor loads, network jitter or data loss. In many cases, a restart of the receiver application was the only way to recover lossless video stream receipt in a reasonable amount of time. Also noteworthy was a perceptible sub-second latency associated with a one-way video stream, as compared with simultaneous and parallel phone conversations. A two-way interactive stream would obviously suffer from this behavior. The inherent latency of the DV25 encoding process itself has been quantified at approximately 140ms, and factors such as computer processor load, network performance characteristics and FireWire input/ouput hardware latencies contribute to a DVTS unidirectional latency of roughly between 200ms and 400ms. (Some DVTS latency numbers are documented in a discussion thread on the the Internet2 bigvideo mailing list, which is archived at: http://mail.internet2.edu/wws/arc/bigvideo/2005-11/msg00014.html) Summary DVTS’ support needs are not necessarily representative of all DVIP applications, however, its free-source nature and support for high-quality DV25 video make it attractive for a distance learning application which requires conveyance of fine video detail over IP. Though the initial tests required significant attention from a number of technical staff, as the testing continued, use of the software became more routine. Nonetheless, given the high-bandwidth characteristics of DVTS, its use on a campus requires very clean networks and coordination with network and firewall support staff, at least during an initial period of use. Similarly, use of DVTS for a production-level event across Internet2 is best served by coordination with Internet2/Abilene network operations staff in advance, to reduce the chance of conflict with other Internet2 activities. Despite the free nature of the DVTS software, it does require multiple well-powered computers with FireWire interfaces and FireWire video devices for practical use. As the latter are not necessarily off-the-shelf components in every environment, DVTS tends to be somewhat less of an install-and-go application, often requiring a bit of assistance from a computer hardware expert. The Windows and Macintosh GUI interfaces to DVTS are still in the early stages of software release, and as a result, significant testing is required before confidence is at a level where it could be considered for live event use (it is the author’s understanding that the UNIX commandline version of DVTS is somewhat more reliable, though more unwieldy to use.) As a result, DVTS is best handled by computer and A/V experts, and less advanced computer users may experience difficulty with its use. For that reason, a DVTS-based service may be difficult to operationalize, and an instructor or lecturer is advised to have one or more support technicians on-hand during a streamed presentation. Overall, the quality of the DV25 video streamed by DVTS is excellent, and its ability to receive input from a FireWire digital camera and output to a FireWire device lends DVTS readily to a bidirectional presentation environment. Latencies experienced with the receipt of DVTS audio and video, even if not exacerbated by network congestion, can be slightly disorienting, and should be understood before attempting a live interactive streaming event. Certainly, institutions may differ on the degree to which the support issues are sufficiently significant that they become burdensome. Therefore, ample testing as described above should help organizations determine whether DVTS is supportable for production use. Acknowledgements Jon Weider initiated and coordinated this project at the NYU SoM. Joe Frey was responsible for supporting A/V technologies, the DVTS application, and coordinated the testing at the NYU SoM. Eric Ruiz and Yiwen Tan provided network support, and Joshua Hart provided network benchmark assistance at the NYU SoM. The author was responsible for supporting DVTS and the network at NYU. Bill Owens from NYSERNet graciously offered considerable assistance in testing and troubleshooting both DVTS and network communications. Michael Sinatra and Ken Lindahl generously offered their time and assistance in support of the DVTS application and networking at UC Berkeley, and the author would like to thank them for their assistance and time.