Report of the LHC Computing Grid Project RTAG 12 Collaborative Tools

Report of the LHC Computing Grid Project RTAG 12: Collaborative Tools Tony Doyle, David Foster, Philippe Galvez, Steven Goldfarb (Chair), Christian Helft, Peter Hristov, Roger Jones, Ian McArthur, Alberto Pace, Gerhard Raven, Mick Storr, Bolek Wyslouch CERN Version 0.2 – 12 October 2004 Architecture Blueprint RTAG - Final Report Editing History Draft 1, 6-Apr-04: First outline (S. Goldfarb). Draft 2, 12-Oct-04: Inserted test from WiKi (S. Goldfarb) –2– Architecture Blueprint RTAG - Final Report Table of Contents 1 Executive Summary 1.1 1.2 2 Introduction Findings of the RTAG 5 5 5 7 7 7 7 7 7 7 7 9 9 9 10 11 12 12 12 13 22 22 24 24 24 24 26 26 26 26 26 –3– Mandate to the RTAG by the PEB 2.1 2.2 2.3 2.4 Motivation Mandate Composition of the RTAG RTAG Activities 3 Introduction 3.1 3.2 3.3 The LHC Collaborations Collaborative Tools The Scope of This Document 4 Specific Needs of the LHC Experiments 4.1 4.2 4.3 Introduction Usage Scenarios The LHC Timetable 5 Assessment of Current Collaborative Tool Usage in the LHC 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Introduction Audio Conferencing Video Conferencing Document Sharing Application Sharing Web Casting Web Archiving E-Mail and Instant Messaging [AP] Computer Supported Conference Management 6 Infrastructure and Implementation Issues [DF] 6.1 6.2 6.3 Integration with the Grid [TD] Networking [PG] Security [DF] 7 Synergy with Existing Initiatives [CH] Architecture Blueprint RTAG - Final Report 7.1 7.2 8 9 RCWG CSMM 26 27 28 28 28 28 28 28 28 28 28 28 28 28 28 29 Financial Scenarios [SG] Recommendations to the PEB 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 Coordination and Management Audio Conferencing Video Conferencing Document Viewing Application Sharing Web Casting Web Archiving E-Mail and Instant Messaging Computer Supported Conference Management Conference Rooms and Other Facilities 10 10 References Appendix A – ATLAS Collaborative Tool Survey Results –4– Architecture Blueprint RTAG - Final Report 1 Executive Summary 1.1 Introduction This document is the final report of the LHC Computing Grid (LCG) Project’s Requirements and Technical Assessment Group (RTAG) on Collaborative Tools. It presents a summary of the requirements of the LHC collaborations for Collaborative Tools, assesses the current status of those tools in common use, discusses likely relevant future development, and provides recommendations for action by the LCG, the collaborations, and CERN for the immediate and long-term future. The requirements were assembled from formal and informal interactions between members of the RTAG, representatives of the LHC collaborations, CERN IT, and experts in the various fields of Collaborative Tools. 1.2 Findings of the RTAG The RTAG has found a large and growing gap between the requirements of the four LHC Collaborations for high quality, robust collaborative tools, and the availability of these tools at CERN and at the participating institutes. This gap is the result of an increasing need for and popularity of the tools, as the experiments enter a critical stage of commissioning, assembly, and software development, and a shortcoming on the part of the participants to address this demand. The shortcoming appears at all levels of organization, from the running and maintenance of existing audio and video conferencing facilities, to the planning and implementation of facilities at CERN and other participating institutes, to the coordination of activities between the institutes and other HENP (High Energy and Nuclear Physics) activities. It could be viewed as a natural consequence of the low priority given to this issue relative to the other urgent and pending activities for the LHC, such as the completion of detector production; commissioning, testing and integration at CERN; and the ramping of software development, to name a few. Yet, it is our belief that the cost of developing and maintaining quality collaborative tools for the LHC would be modest and that a well-coordinated program would most likely result in significant long-term savings, due to improvements in communication, training and coordination, in support of those programs. The basic requirements of the LHC collaborations, summarized in Section 3.2, are neither extensive nor complex. Concerning video conferencing, there is a need for more facilities at CERN, with an emphasis on reliability and ease of use, not necessarily the latest technology. The same is true for audio conferencing, where demands include operator-free 24/7 availability, a web-based booking system, and integration with video conferences. Other synchronous collaborative technologies, such as application sharing or document sharing are not yet widely used, but popularity and need are growing, and they present a serious potential for facilitating collaboration. Asynchronous tools, such as web archives of lectures, meetings and tutorials, have been in use for some time, but lack central support and coordination. Minimal support and poor infrastructure at CERN have had the effect of discouraging potential users from taking advantage of the collaborative tools at hand. Users have become frustrated by the lack of tools (many rooms are still not equipped for audio or video conferencing) or by the unreliability or complexity of the existing tools. More importantly, the absence of well-defined –5– Architecture Blueprint RTAG - Final Report management and coordination of collaborative tool activities among the LHC experiments has the effect of discouraging potential resource providers from contributing manpower, equipment, and/or funding to solve the existing problems. Various well-intended efforts have been and are still being made by individual LHC participants to try to solve localized problems. But, without central coordination, these efforts risk to fail, further discouraging the resource providers, or to result in incoherent solutions, which can tax the limited support and add to the overall problem in the long term. In the following section, we provide a list recommendations assembled during the course of our research, including detailed recipes concerning the technology we believe could be useful for the LHC collaborations now and in the future. We would like emphasize here, however, a few very important general recommendations, which must be considered first and foremost: 1. 2. 3. 4. The LHC collaborations must recognize the need for high-quality, robust collaborative tools as a high priority item. The most urgent issue to be addressed is that of the creation, mandate, and funding of an LHC-wide Collaborative Tool Service. For practical reasons, this service ought to be CERN-based, but the coordination, manpower and resources ought to come from the experiments, as well as CERN. The primary focus of the service would be on installation, maintenance and running of facilities at CERN. However, it must be open to external institutes 4. Separation of R&D with production service 5. Review of R&D recommendations before production LHC experiments to recognize the priority. Below is a list of recommendations. Most importantly, we recommend that CERN should take on a leadership role in this initiative, with close communication and oversight by the LHC experiments. Without CERN taking on this role, any proposed project risks to ... This does not necessarily imply that CERN must take on all costs, even concerning facilities and support at CERN. In fact, in many cases, these costs would be better off shared by the LHC experiements in an equitable manner. However, the core effort, because it involves infrastructure at CERN, must be supported by CERN. Balance of CERN/LCG Project Two reasons for CERN involvement and usage of CERN resources: 1. CERN infrastructure, firewalls, rooms, licenses, etc. 2. Usefulness for experiments, projects at CERN, but not in the LHC –6– Architecture Blueprint RTAG - Final Report 2 Mandate to the RTAG by the PEB 2.1 Motivation 2.2 Mandate 2.3 Composition of the RTAG The RTAG comprised one or two representatives from each of the four LHC experiments, representatives from CERN IT, several specialized experts in collaborative tool usage and research in HENP, and the LCG PEB chairperson. The complete list of participants is presented in Table 1. Participant Peter Hristov Steven Goldfarb (chair) Roger Jones Bolek Wyslouch Ian McArthur Gerhard Raven Alberto Pace David Foster Mick Storr Mick Draper Tony Doyle Philippe Galvez Christian Helft Les Robertson (ex-officio) Institute CERN-PH/AIP University of Michigan Lancaster University MIT University of Oxford NIKHEF CERN-IT/IS CERN-IT/CS CERN-HR/PMD CERN-IT/UDS University of Glasgow CalTech? LAL - IN2P3 (Orsay) CERN-IT/DI Representation / Expertise ALICE ATLAS ATLAS CMS LHCb LHCb CERN-IT/IS CERN-IT/CS CERN Training CERN Video Conference Facilities GridPP VRVS / Video Conferencing HTASC-CSMM / Video Conferencing LCG-PEB Chairperson Table 1. List of RTAG participants. Blue highlighting indicates LHC representatives; green highlighting indicates CERN IT representatives; orange highlighting indicates specialized collaborative tool experts. 2.4 RTAG Activities The RTAG convened on March 31 and held weekly meetings until…. 3 Introduction 3.1 The LHC Collaborations 3.2 Collaborative Tools It is mean to be an introduction. It should address: –7– Architecture Blueprint RTAG - Final Report 1. What are Collaborative Tools 2. What Collaborative Tools are generally used in HEP The section before will briefly describe the LHC collaborations and their needs for communication, training, outreach, etc. This should set the stage for your section. The following section explains what requirements and tools we decided to address in this document and what we did not. ================== Text below from Roger ================== The technical complexity, scale and world-wide distributed nature of the LHC experiments present new challenges in their working models and collaborative environments. These challenges are already upon us during the construction phase of the experiment and will only become worse once the data-taking begins. Several typical use-cases can be considered: _ The construction team finds a problem in the physical assembly of the detector. The team that build the component is 12 hours displaced from CERN. Meetings must be arranged to resolve the problem giving full access to the design documents and visual inspection of the actual component, as well as audio-video communication within the team. _ A physics team is considering a physics study by a member. They are globally distributed, with facilities ranging from V/C suites to laptops & cameras to telephones. They must meet on as even a basis as possible, with access to the presentations and where possible interactive shared data handling. _ The management team of an experiment must meet, being globally distributed. _ The management team wishes to distribute electronic documents to targeted groups of people, with controlled access. These cases are illustrative and by no means exclusive. They all share the common need to intelligible communications by audio and/or audio/video over a range of platforms within the same meeting. No single technology may be assumed. Layered over these are various different interactive functionalities: real-time visualisation of objects, shared control over computational models etc. Underpinning it are document repositories and exchanges (mailing lists, web pages and archives, EDMS etc.) [How about remote monitoring and/or control of a detector or accelerator component?] [remove EDMS reference] Perhaps the biggest challenge in the above list the admixture of technologies. Not only must telephone inter-work with audio-video systems and web pages, but even within a single system, the technologies are mixed: H323 with VIC/RAT, VRVS with AccessGrid?, IP telephony with –8– Architecture Blueprint RTAG - Final Report standard telephony. The problem is further compounded by the different physical technologies. For example, while AccessGrid? standard bridges exist, they are only provided for fixed-IP sites of proven audio and video quality. This does little to address the most common use case of the mobile physicist connecting via a DHCP laptop with portable camera and headset in a variable environment. Experience has shown it is often these more basic admixtures that prove the most troublesome. Clearly, many tools already exist and are used to greater or lesser extents. Unfortunately, no tool currently satisfies all users, and so there is a large scope and need for evaluation, development and deployment. Unfortunately, while there are disparate groups working in these areas, they are not (and are hard to present as) a coherent whole. This is also true within the teams under CERN’s control. This is not only potentially wasteful; it makes it very difficult to lever resources from other sources such as the EU. Further, such funding opportunities are typically directed at evaluation and development, not the running of a service. While the primary focus of the CERN activity has been running a service, there have been aspects of development; it is important that these be identified and presented in a coherent manner. 3.3 The Scope of This Document In the next chapter the needs of the experiments are described in detail. Usage scenarios are described along with timescales for the implementation of the required facilities. The needs are focused entirely on the LHC experiments although many of the scenarios will be commonplace in other distributed collaborations. This is followed by an assessment of appropriate collaborative technologies and a view to what role each might play in fulfilling the LHC requirements. A wide range of tools have been considered including audio and video conferencing and document and application sharing. Distribution of multimedia material in real time and provision of on-demand access to archived material is also assessed. The role of more familiar tools such as telephone, email and instant messaging is also included. Is this the right place to say that proprietary solutions are unlikely to meet basic requirements of platform independence, costs? More as the rest of the document develops. 4 Specific Needs of the LHC Experiments 4.1 Introduction Ad-hoc meetings (1 to 1) consulting off-site (subdetector) experts Scheduled meetings (many to many) agenda systems sharing/publishing agendas/schedules room booking, –9– Architecture Blueprint RTAG - Final Report phone/video conference booking presentation archiving equipping conference rooms remote participants: recording seminars, tutorials (1 to many) 4.2 Usage Scenarios In case you're not aware of it, there is much material in http://www.nesc.ac.uk/technical_papers/VCReport_FINAL_Oct2.pdf (CH) Collaborative tools in HEP We will consider several possible usage scenarios where remote physicists collaborate in LHC related activities. Most user scenarios involve conducting meetings and discussion with simultaneous dissemination of electronic content. In most cases the presentation materials need to be archived for future reference. The various user scenarios differ significantly in the requirements and complexity of required tools. We will present several typical types of meetings and give examples of tools that are available today. We will also propose useful additions that would improve the quality of collaborative experience. For simplicity we will usually adopt a CERN-centric model with the main meeting or activity taking place at CERN with remote participants observing and contributing. A) Person to person meeting B) Small to medium size meeting 1) Single remote person joins the meeting 2) Several remote people join the meeting 3) Meeting of several small to medium remote groups or individuals C) Large conference or meeting with multiple remote observers A) Person to Person meeting This is an extension of a traditional phone conversation or visit in the neighboring office. Usually not scheduled, often leads to interactive work on code, figures, equivalent of blackboard work or work in front of a computer terminal. It requires rapid exchange of small chunks of data, contents of screens, simultaneous editing of source code or text. There are several commercial examples of systems that facilitate such interactions: AIM, Windows Messenger, Person-to-person VRVS, direct connection between e.g. Polycom video – 10 – Architecture Blueprint RTAG - Final Report machines. They differ in the reliability of connection, dependence on specific operating system and the availability of the features. The LHC community would profit from a set of suggestions for the specific choice of software or platform that users would follow. The tools would be easier to use if there is a LHC user directory, central software repository and community specific documentation and setup instructions. B) Single or several remote people joining a small to medium group meeting or a meeting with several remote groups. This is an extension of a usual small or medium group meeting. Most activity is taking place in a physical meeting room somewhere (e.g. at CERN). Formal talks are followed by discussions. Remote participants may give talks or simply participate in comments and discussions. Good audio connections and access to transparencies is essential. The meetings are scheduled and usually have prepared agenda and minutes. The archival of agenda and talks is important. The number of remote participants or remote groups affects the level of complication of audio and video transmission (switching streams, phone connections, management of discussions). At present most of such videoconferences at CERN are done using VRVS. VRVS provides important capabilities: multi-site participation, scheduling and capability to merge video and audio streams from a variety of platforms and operating systems. The system was designed by the members of LHC community and as such it fits quite well the way of working. The performance is quite acceptable and it is continually improving. There are several possible extension that should be considered. In particular it would be helpful to have integrated agenda and archival database for materials connected to the meeting. The system should also provide user-accessible network and capacity monitoring displays. Since the quality of network connections cannot be always guaranteed a well defined interface between VRVS and the regular phone system should be established. A possibility of making reasonably local phone calls to join VRVS conference has been an ongoing request. C) Conference, seminar with contents broadcast live to local and remote audience. It requires wide bandwidth transmission of video and audio, simultaneous transmission of transparencies. Need for an operator to manage camera, local sound. There is only limited need for ability of remote participants to ask questions. Archival of audio, video and transparencies is very important. There are several commercial systems that allow creation of broadcasting servers (Microsoft, RealAudio?). While using a commercial broadcasting system is likely to guarantee good quality and compatibility with multiple clients the scheduling and archival should use the same system as the other conferencing systems. 4.3 The LHC Timetable Text from Bolek Wyslouch expected here. – 11 – Architecture Blueprint RTAG - Final Report 5 Assessment of Current Collaborative Tool Usage in the LHC 5.1 Introduction In this chapter, we will try to describe all the different, but inter-connected, tools which are being used to carry out collaborative work. Given the mandate of this RTAG, we will concentrate on video-conferencing technologies and tools although technologies linked to collaborative writing will also be described. 5.2 Audio Conferencing 5.2.1 Existing Facilities Audio conferencing exists today under the technology called "telephone". Peer to peer phone communications exists since tenth of years and are well known to everybody. If we include satellite communications, we can affirm that telephones are is available everywere on earth using wired or wireless technologies. All telephone recent exchanges (less than 10 years old) have also able to have phone conferences with multiple users involved. According to the software available in the telephone exchange, it is possible for end users to schedule phone conferences and for attendees to join/leave the conference themselves without requiring the intervention of any manual operator. If the user is able to locate a gateway between Voice Over IP (VOIP) and the standard telephone network, there are no technical reasons which would prevent “soft phones” running on computer to be used as telephones. However, this is not widely possible because the "free" communication model of the internet cannot be mapped to the "pay per call" model of traditional telephones. Bridging VOIP and the standard telephone network is straightforward in one direction (telephone -> internet) because it is free. But in the direction "internet -> telephone" there is such a heavy accounting procedure (pay per call, registering users, billing users, etc) that users who have internet access normally prefers alternate communication technologies that the internet provides for free (Email, chat, instant messaging, voip to voip) rather than paying often exorbitant costs. 5.2.2 Future Development The direction were audio conferencing seems to be going is towards VOIP. Local wired telephones will continue to exist but they will be only connected to the nearest VOIP gateway from where they will be able to place long distance calls to any VOIP connected phone. The present phone conference services are however still based on traditional pabx system and telephones. Audio conferencing using VOIP will require equivalent services and the most significant example of existing audio conferencing services on the internet is VRVS. All what said for audio conferencing is also valid for video conferencing if you consider video an additional attribute of the communication stream. However, this is an over-simplification as the bandwidth required for video may not be enough on traditional systems designed for voice only – 12 – Architecture Blueprint RTAG - Final Report 5.2.3 Recommendations 5.3 Video Conferencing 5.3.1 Existing Systems There are 3 major videoconferencing systems used today within the Research and Academic Community which are namely the VRVS service (The Virtual Room Videoconferencing System) developed and maintained by Caltech, the H.323 videoconferencing service (based on the I.T.U videoconferencing standard over IP networks) and the AccessGrid? initially developed by the Argonne Laboratory. Below is a more detailed description about these 3 systems: 5.3.1.1 The VRVS Videoconferencing Service VRVS (Virtual Room Videoconferencing System) is a unique, globally scalable next-generation system for real-time collaboration by small workgroups, medium and large teams engaged in research, education and outreach. VRVS operates over an ensemble of national and international networks. The system was initially built as a limited-scale prototype-production system serving the high energy and nuclear physics (HENP) community and some other data-intensive science and engineering sectors. Since then, it has been continuously extended the system by adding more functionality and by redesigning the architecture to benefit from the latest software developments, so providing the collaboration infrastructure and Web-enabled user interfaces required to meet the research and education needs of many fields. VRVS is global in scope: it covers the full range of existing and emerging protocols and the full range of client devices for collaboration, from mobile systems through desktops to installations in large auditoria. The VRVS software will be integrated with the Grid-enabled Analysis Environment (GAE) now under development at Caltech in partnership with the GRIDs? projects in the US and Europe. Since it went into production service in early 1997, VRVS has become a standard part of the toolset used daily by a large sector of HENP, and it is used increasingly for other DoE?/NSFsupported programs. Today, the VRVS Web-based system is regularly accessed by more than 38,500 registered hosts running the VRVS software in more than 103 countries. There are currently 82 VRVS “reflectors” that create the interconnections and manage the traffic flow, in the Americas, Europe and Asia. New reflectors recently have been installed in Brazil, China, Pakistan, Australia and Slovakia. The VRVS system is managed by the Caltech CMS group. Every year, the number of multipoint collaborative sessions (national and international) using VRVS increased by 300%. The last major version release February 2003, improved dramatically the scalability and usability of the system and brings new features and capabilities which include: permanent virtual rooms, NAT (network address translation) access, Multi-OS support (Linux, Macintosh, and Windows). The VRVS system offers a practically unlimited set of virtual rooms is available where collaborative sessions are performed This high adoption rate confirmed the need within the Research and Academic community for easy-to-use collaborative tools with high performance. Integration with the AccessGrid technology has been also successful, and the VRVS/AG gateway (VAGRID, or “Virtual Access Grid”), where one can join any Access Grid Virtual Venue from a desktop or laptop, is heavily used by the community. – 13 – Architecture Blueprint RTAG - Final Report 5.3.1.2 The H.323 Videoconferencing Service H.323 is a communication standard produced by the ITU, initiated in late 1996, and aimed at the emerging area of multimedia communication over LAN's (local area networks). It is an outgrowth of the traditional H.320 technology but optimized instead for the Internet. H.323 has since been revised to include voice-over IP and IP telephony, as well as gatekeeper-to-gatekeeper communications and other data communications that involve packet-based networks. These networks include IP-based networks like the Internet, Internet Packet Exchange (IPX) LAN's, and WAN's. H.323 is widely supported by many commercial vendors and used throughout the world in commercial and educational markets. The H.323 standard specifies a great deal of information about the properties and components that interact within an H.323 environment. It specifies the pieces that combine to provide a complete communication service:     terminals, either PC or stand alone devices: these are the endpoints of the communication lines; gatekeepers, the brains of the network, providing services like addressing/identification, authorization, and bandwidth management; gateways, which serve as translators when connecting to a dissimilar network (such as an H.324, for example); MCU's (multipoint control units) which allow multipoint conferencing, or communication between more than two parties at once (much like a traditional conference call on a telephone). In addition to component types, H.323 also describes protocol standards, permissible audio and video codecs, RAS (registration, admission, and status), call signaling, and control signaling. H.323 specifies a mandatory level of compliance and support for the above specifications for all terminals on the network. More detailed information about H.323 is available through several links shown in the appendices. 5.3.1.3 The AccessGrid Videoconferencing Service The Access Grid is an ensemble of resources including multimedia large-format displays, presentation and interactive environments, and interfaces to Grid middleware and to visualization environments. These resources are used to support group-to-group interactions across the Grid. For example, the Access Grid (AG) is used for large-scale distributed meetings, collaborative work sessions, seminars, lectures, tutorials, and training. The Access Grid thus differs from desktop-to-desktop tools that focus on individual communication. The Access Grid is now used at over 150 institutions worldwide. Each institution has one or more AG nodes, or "designed spaces," that contain the high-end audio and visual technology needed to provide a high-quality compelling user experience. The nodes are also used as a research environment for the development of distributed data and visualization corridors and for the study of issues relating to collaborative work in distributed environments. The AG technology was developed by the Futures Laboratory at Argonne National Laboratory and is deployed by the NCSA PACI Alliance. The Futures Lab continues to conduct research into – 14 – Architecture Blueprint RTAG - Final Report ways to improve the Access Grid, for example, to increase the scalability and to enhance the user interfaces. 5.3.2 Current LHC Usage 5.3.2.1 VRVS The main tool/service used today by the LHC experiments is the VRVS service. Today, around 12,000 users has been registered to the system and around 800 worldwide collaborative sessions are performed per month between 3000 users representing a cumulative time of 4700 hours of research collaboration over the Internet per month. VRVS became a commodity within the LHC experiments and it is not uncommon to have physicist mentioning that they need or will have a VRVS meeting in the same way they organize a simple conference call. The principal advantage of the system is that it is software based and so easily upgradeable). Also, the infrastructure built on 82 reflectors (Linux servers that manage, optimize and direct the traffic VRVS media streams) deployed world wide make the system very scalable. The VRVS system provides videoconferencing client that run in all the Operating System (Windows, Macintosh and Linux). It is entirely web-based, so very user-friendly. It has a scheduler for organizing collaboration meetings but could also create permanent virtual rooms. It supports all the common standards (H.323, Mbone and SIP). It is developed in partnership with Grid projects and incorporated latest Grid monitoring software into the VRVS infrastructure. It has an innovative technical development roadmap that will be very beneficial for the end user. This Videoconferencing service is operated by Caltech and free of charge for the users. The principal disadvantages are that the system is very dependant of the local hardware installation. It goes from the desktop up to the conference rooms. Because the system supports all type of OS, Camera, videoconferencing software and hardware, a bad configured node could disturbed the entire conference. It is in particular true for mixed conferences with Mbone tools and H.323 clients in the same meeting. While VRVS is NOT the hardware/software/PC used by the end client, users tend to believe that it is part of VRVS and could complain about it. The main purpose of VRVS is to provide an efficient and reliable real-time network infrastructure to facilitate collaboration meeting over Internet. 5.3.2.2 ECS The second largest tool/service used by the LHC experiments is the ESnet? Collaboration Service (ECS). The H.323 videoconferencing service is included in the ECS offering. In order to be authorized to use this service (for free), the user should conformed to the ESnet Acceptable policy where the general guideline is the following “The ESnet ECS is a multi-way digital collaboration service/resource program managed and funded by the Department of Energy (DOE), Office of Science (OS) for the explicit purpose of supporting its scientific research programs. In general, usage in support of the DOE/OS mission, or as authorized by arrangement with DOE/OS, is considered acceptable. Any restriction of use, contained within this Acceptable Use Policy (AUP), is intended to protect this OS resource for its intended use and for which funding is appropriated.” According to ESnet documentation, acceptable usage of DCS includes: – 15 – Architecture Blueprint RTAG - Final Report    official communication among Office of Science (OS) funded principal investigators and their collaborators, regardless of location; approved usages for the purpose of conducting OS funded and/or approved research and education activities; any digital collaboration that either originates or terminates within an approved ESnet site and that is also compliant with the other rules and regulations of this (AUP). Since several years, the ESnet collaboration services offered videoconferencing service to the researchers who have their research affiliated with a DOE program. This service has been (and continue to be) very successful in providing a H.320 (ISDN) MCU (Multiple Control Unit) facility for the authorized community to connect and perform a multi-site collaboration meeting free of charge. Only the ISDN communication cost was (is) in charge of the user. The last few years, pushed by the emergence of the H.323 protocol, videoconferencing hardware equipments used in the conference room has been updated to support the new H.323 protocol. In the same time, the ESnet collaborative group has acquired several MCUs? H.323 capable that allow multisite collaboration between H.323 devices in the same way they performed the H.320 service. After several months of testing and configuration among a limited beta test community, the H.323 service was offered to the entire DOE/OS related community. For the users or groups who initially used the H.320 ESnet service, this new H.323 appears to be very well adapted since it doesn't change the way they collaborate. For new users, the support for H.323 protocol is certainly more appealing than the old H.320 protocol. We can found today relatively cheap H.323 desktop devices. With the recent new upgrade of software/hardware MCU, the users have the possibility to start had-hoc conference without the need to schedule the meeting in advance. This videoconferencing service is gaining in momentum since it has been put in production several months ago. Within the LHC community, the physicists or groups that were using the previous H.320 ESnet (ISDN) service, tend to continue to rely on the ESnet H.323 videoconference service to host their collaborative sessions. [SG Question: Was there an official statement by CDF, D0, Fermilab?] The main advantage of such service is that he is based purely on the I.T.U standard so make the compatibility with device build from different manufacturers interoperable. Also, because they are usually hardware based, these devices have good performances and are reliable. In addition, with additional H.323/H.320/POTS gateway, one can connect a normal phone user or H.320 node to an H.323 conference. The disadvantage is that because the H.323 infrastructure is hardware based, it is usually expensive to deploy, not very scalable and difficult/expensive to upgrade. Because of its history, the H.323 protocol is still very complex and does not well adapt to a pure IP network infrastructure. A centralize MCU (as it is within ESnet) do not scale for offering a service to the LHC at large due to limited number of port available. To scope with the IP network topology architecture it implies that others MCUs has to be deployed and managed in several locations worldwide, with add additional complexity of cascading between MCUs, distributed scheduling, distributed ports resource allocations, etc… – 16 – Architecture Blueprint RTAG - Final Report 5.3.2.3 AccessGrid The last tool/Service which is AccessGrid is not widely used within the LHC experiment while it is used by a lot of Grid projects. They may be several factors to it:  It is recognized that we need a permanent dedicated support for all AccessGrid meetings. This is most of the time not acceptable for the Physics community. We see already how difficult it is to get local technical support in the Physics laboratories for technology like VRVS or H.323 on the basic conference rooms. The need for multicast deployment. Except few cases, most of the physics department do not support multicast in the LAN. Nevertheless, several techniques to bridge a Multicast Access Grid meeting into a unicast tunnel have been developed. One of such bridge is provided by the VRVS service where users just have to log into the VRVS server and click to access an AG meeting. The current VRVS AG Gateway (PC/Linux) is located in Ann Arbor, Michigan, USA. We have to note that because of the high bandwidth usage during an Access Grid meeting, the multicast/unicast bridge is not highly scalable (e.g. a 10 Mbps AG meeting could overload a 100BaseT connection (100Mbps) with few unicast connections. The installation of an AccessGrid node has a significant cost that will prevent large deployment within the Physics groups. AccessGrid deployment and usage address just one particular need of the LCH collaboration which is group to group.    5.3.2.4 Other Video Conferencing Tools in Use What has been described above focused not only on the different technology but principally on the different Videoconferencing Services offers for the community. All the 3 services described have an independent scheduler and an independent method to join/leave a conference. There are also other videoconferencing tools used by the community in an ad-hoc fashion. Among these tools we found:    iChat eConf etc… 5.3.2.5 More Information There are two main documents/study that describe pretty well the current technologies used for videoconferencing, as well as their advantages and limitations. For general information on Videoconferencing, "the Videoconferencing Cookbook" developed by ViDe?? is very well done and can be download at: http://www.videnet.gatech.edu/cookbook – 17 – Architecture Blueprint RTAG - Final Report A second document prepared by the e-science Grid program in UK which is much deeper technically and addressed more closely the collaboration tools needed for the LHC experiments. The document can be fund at: http://www.nesc.ac.uk/technical_papers/VCReport_FINAL_Oct2.pdf 5.3.3 Assessment and Comparison of VRVS and H.323 Services (ECS) 5.3.3.1 VRVS The main strengths of VRVS are:  It is very affordable (not expensive nor too technically complex) for an individual to set up an equipment ready to work in this environment; with the recent support of the Macintosh platform, virtually every reasonably recent personal computer (with common operating system like Linux, Window or MacOS?) can be used effectively as a VRVS end point, at the cost of a simple webcam if high video/audio quality is not required Its functionality beyond audio/video is very good: being able to watch simultaneously every site engaged in a conference, to chat privately or publicly and to share his screen with other participants provides a very rich videoconferencing experience to the VRVS user. H323 systems support enables to use state of the art, industry supported end points and hence leverage the added benefits of any peripheral equipment that are often found around them in videoconferencing rooms for instance The deployment of the infrastructure part of the system is at the same time inexpensive or at least cost-efficient (a standard modern PC/Linux makes a good reflector) and easy: a new reflector installation is done remotely by the VRVS team without requiring local expertise; Whereas the system is already available in every place in the world where HEP physicists can be found, the next generation architecture, although yet to be validated by effective deployment, seems to guarantee virtually endless scalability, thanks to a well thought out load balancing and self configuring routing mechanism. VRVS provides a streaming facility for all the meetings. The user just need to use either the Mbone tools or QuickTime? to watch and listen any conference from anyplace with any devices (i.e. PocketPC?). Others participants could use Mbone, H.323 or SIP for their interactive discussion. VRVS provides an elegant and unique firewall solution. One need to install a VRVS reflector within the secure site and all the internal users will be able to join a VRVS conference using all supported protocols (H.323, SIP, and Mbone). The traffic will cross the firewall using only one known port (UDP or TCP) to/from the peer external reflector (i.e. as deployed at CERN, BNL, JLAB, etc...) VRVS works in a NAT (Network Address Translation) environment which is the default set-up for users connected from home with xDSL or Cable Modem. – 18 –        Architecture Blueprint RTAG - Final Report The main weaknesses of VRVS are:  The principal disadvantage is that the system is very dependant of the local hardware installation. It goes from the desktop up to the conference rooms. Because the system supports all type of OS, camera, videoconferencing software and hardware, a bad configured node could disturbed the entire conference. It is in particular true for mixed conferences with Mbone tools and H.323 clients in the same meeting. While VRVS system does not include the hardware/software/PC used by the end client, users tend to believe that it is part of VRVS and could bring confusion on the scope of the VRVS responsibility. As a reminder, the main purpose of VRVS is to provide an efficient and reliable real-time overlay network infrastructure to facilitate collaboration meeting over Internet and not to develop the end user device/software. VRVS offers the basics H.323 MCU functionalities but it is not a replacement of the latest. It can not compete with a dedicated hardware H.323 MCU in term of quality and functionality which appears to be better suite for a conference limited with H.323 hardware end-point only. Because VRVS is built using a complete distributed architecture and associated with the large diversity of configurations the system supports, it is very difficult for the end user to diagnose a potential problems (local system configuration, network, Java virtual machine version, new OS upgrade, etc…) and often need the expertise of the VRVS team to locate the problem. Because VRVS team provides only recommendation on software and hardware to use and does not impose a limited set of this hardware/software/protocol, it results on a situation where everybody can connect with anything and expect to have the system working seamless. It raises the user’s expectations and could conduct to user disappointment. Some features are still missing. Among them, one of the most requested is the ability to easily join a conference by telephone. Other features that would be welcome by users can be briefly mentioned: more scheduling paradigms (point to point sessions, i.e. capability to call by name another party, and this implies user access to the VRVS internal address book, i.e. private auto-opening conferences), interoperability with standard H323 MCUs? (namely ESnet? infrastructure), recording of sessions.     5.3.3.2 H.323 Services (ECS) Several institutions offer what can be called standard H323 infrastructure service to the LHC community, generally at the country level (ESnet for the US, IN2P3? in France, INFN in Italy, JANET in the UK, DFN in Germany…). These facilities vary in offered services, both in capacity, performance and scheduling systems. Only the ESnet Collaboration Services (ECS), which is by far the most used by LHC experiments, will be assessed here. The main strengths of ECS are:  A stable service of MCUs and gatekeeper; this infrastructure is based on three production MCUs (two Radvision for H323, and one Accord, which will be phased out within the next months, for mixed H320-H323 sessions) – 19 – Architecture Blueprint RTAG - Final Report  The quality achieved in H.323 multipoint sessions is more or less equivalent to that of point to point session, which can be qualified as fairly adequate for international collaborations as ours. The importance of very good audio and video can’t be overemphasized in contexts where all participants are not native English speakers, which can take advantage of some clues available only by video that can compensate for insufficient fluency in spoken English. The availability of ad-hoc (non scheduled) mode of operation, making accessibility to videoconferencing on par with that provided by the telephone. The capacity to upgrade installed facilities at a pace that allows to offer to the community reasonable “state of the art” technology: examples are the support of the emerging H264 video codec, and the installation for evaluation of a new MCU that sports user friendly features such as streaming of on-going conferences, and choice of continuous presence mode on a per user basis. Significant, although not infinite, room for growth: the 70 H323 ports available at present on the main MCU (between 50 to 60 users can be counted during busy hours) could easily be upgraded to 140 or even 210 by adding one or two cards; as corresponding networking bandwidth and gatekeeper capacity are already, or could easily be, available, this guarantees that in theory about 500 users could be served with the same quality of service at the only price of the required hardware. The mere fact that every service is based on industry provided H.323 technology: adequate funding alone would allow ECS to leverage for its users the many improvements that this industry is about to deliver on audio/video quality, ease of use and functionality.     The main weaknesses of ECS are:    Address only the H.323 videoconferencing environment It is not build to support the desktop environment and so the scope of user’s deployment, usage and user’s flexibility is very limited. Restriction of access to DOE funded or approved programs, as this could limit its use in LHC and yield to the strange situation where an individual could use his videoconferencing equipment for one of his activities and not for another. It is a centralize architecture and so very vulnerable in term of reliability. The obvious lack of manpower dedicated to this service (1,5 FTE) The small range of continuous presence modes available today (full screen or quarter of screen only). One should not that quarter screen split the screen with 4 video at QCIF format (176x144) with is half of the usual resolution and 4 times less than TV resolution. Therefore, in practice any modes of continuous presence provide low quality resolution. The video receives is limited to one TV screen and do not offer immersive feeling where all video received can be displayed at the same time with their native resolution. – 20 –     Architecture Blueprint RTAG - Final Report   The impossibility to know how many and which participants have joined the conference beyond the four ones that are visible on the screen at a given time The total lack of remote document presentation facility; a web conferencing system that can be used for application or desktop sharing is provided, but is not integrated with the videoconferencing part of the system. The inadequacy of the present scheduling system. Does not offer solutions for Firewall and NAT environment The cost to deploy, maintain and operate is significant. Coordination/integration with other H.323 services is extremely difficult. There is no advanced network monitoring and troubleshooting functions.      5.3.3.3 General Comments: It is striking to observe that those in the community that use one of the two systems (VRVS or industry provided H323) don’t use the other. The main reasons are:  The respective strengths of the two systems fulfill at least partially the needs of two different patterns of videoconferencing usage: one is a heritage of the older ISDN style meeting with a centralize MCU and conference room equipment dialing a common phone number. The second extend the videoconferencing functionality to the desktop allowing the users to stay in his workspace environment while participating to a collaborative session which is certainly a new paradigm. CERN never really advertised ESnet collaborative services, so many LHC experiments members simply do not know they exist and can be used. People generally are reluctant to maintain even low expertise in two different and sometimes incompatible systems. No significant effort is done to make both systems more integrated. It is certainly due to the limited manpower available for both services as well as the own development priority and schedule.    5.3.4 Recommendations Rec 1-1 CERN should provide an official support of both systems, and set up a steering committee to closely monitor their progress and coordination. – 21 – Architecture Blueprint RTAG - Final Report 5.4 Document Sharing 5.4.1 Document Presentation [CH] During face-to face meetings, speakers often use some sort of document presentation system, video projection of (personal) computer rendered slides replacing rapidly the traditional overhead projection that has been used for years. For remote meetings, new challenges appear. Present Practices Discussion on using a personal computer to browse Web available presentations out of synch with speaker. Without computers. Camera pointing to the locally projected document Feeding output of a computer screen to video stream H239 With computers Web conferencing Screen sharing. VNC. Application sharing. Trends and future. 5.4.2 Document Writing 5.4.3 Recommendations 5.5 Application Sharing 5.5.1 Introduction The possibility to share a window, application or a user’s desktop is an extremely useful feature in a collaborative environment. It is a excellent addition to a video conferencing session. We find several tools offering this capability today in the market but no one really immerge as being the killer tool in the application sharing area. All these tools offer a set of nice and proprietary functionality but are not fully addressing the complete set of issues which are interoperability, easy of use, easy of operate and deploy, scalability, multi OS support. These are the primary reason why the feature is rarely used within the research and academic community and more precisely by the LHC experiments. – 22 – Architecture Blueprint RTAG - Final Report Here we describe the two most commonly used technologies for application sharing, based on the T.120 protocol and VNC. 5.5.2 The T.120 Protocol T.120 is the I.T.U. (International Telecommunication Union) standard covering the data collaboration (including application sharing) over IP networks. This protocol has been driven by Microsoft with its Netmeeting software client. Although, several other vendors claim to be T.120 compliant, they use in fact a subset of the Netmeeting application which they integrated in the own application. Other hardware manufacturers (i.e. Radvision, MeetingPlace?/Lattitude) integrated the T.120 protocol in the offering but with a relatively low success up to now. What is appealing about T.120 is that because it is an I.T.U protocol it could be the base for large interoperability between vendors but unfortunately since this standard emerged around 10 years ago, it didn’t really take-off. In addition, Microsoft decided to not support anymore Netmeeting and does not include anymore in its last OS (Window XP) which makes the proliferation of this protocol even more difficult. 5.5.3 VNC VNC, the Virtual Network Computer, has been initially developed by AT&T Laboratories in Cambridge. The open source version of VNC has been freely available since 1998 which helped a lot to enhance the technology and spread it over the Internet. It is actively used by a lot of people in industry, commerce, education and at home. The main force of this technology is that it is available for all the OS, in all languages (MacOS?, Linux, Windows, Java, PalmOS?, etc...). The main technical focus was to be able to control a remote desktop/device from any location but very quickly people realized that it could become an ideal sharing application tool. It allows multiple remote clients to control or only see a desktop or part of it. Because, it has not been designed per nature to be an application sharing tool, it misses some “commercial” grade user interface or advanced session management features. VNC is not a finite application sharing tool but a lot of external developers, commercial companies, software projects used it as the based of their application sharing offering by modifying, customizing, enhancing the VNC based software. We should note that VNC technology is used within the VRVS system to provide the application sharing functionality. A VNC/VRVS multipoint software has been developed and runs on the VRVS web site to provide multi site connectivity. The VRVS user that wishes to share his desktop needs first to start the VNC server on his desktop. Then, using the VRVS control applet when connected to a Virtual Room, he just needs to select the sharing mode and click on “SHARE”. The remote user(s) will just have to click on the SHARE button (on the VRVS applet) to download automatically a JAVA applet (no need to install any software) to see and/or control the shared desktop. We should mention also that Tandberg which is a major videoconference manufacturer adopted the VNC technology for its application sharing offering. – 23 – Architecture Blueprint RTAG - Final Report 5.5.4 Recommendations 5.6 Web Casting 5.7 Web Archiving 5.8 E-Mail and Instant Messaging [AP] 5.8.1 Introduction Email exist today since almost 20 years and is widely used worldwide. Access to email is not as easy as access to a telephone but it is probably the second communication tool just after the telephone, at least in the scientific community. Email is not a technology for video conferencing but it is an important player in the collaborative tools arena into which it must be integrated. Integration of email into collaborative tools means that the "email client" is no longer a monolithic standalone application which allows the user to send/receive electronic messages. Email is just "one of the many" channels that can be used to communicate between people. 5.8.2 Future Developments The scenario for future communication is that the end-user applications would integrate several communication technologies (Mail, videoconferencing, mobile and fixed telephones, instant messaging, ...). This application would benefit from "presence information" that would indicate availability of recipients and their preferred comunication media at a given point in time: The recipient of messages will have the possibility to indicate to the senders of their choice, their online availability for instant messaging or their out-of office status. Needless to say is the fact that each person should be in total control of the presence information that is published concerning himself and he should have also the possibility to segment the information by group of users. For example, member of the same working group would see that this person is reacheable online by instant messaging or by GSM, while unknown contacts would only see this person offline reacheable only by email. The evolution of collaborative e-mail clients are going in this direction. While standards for presence information are not yet consolidated, it is important to prefer applications that integrates not only email but also VOIP (for fixed and mobile telephone communications), instant messaging (which includes peer-to-peer video conferences), shared applications and shared whiteboards. 5.8.3 Recommendations 5.9 Computer Supported Conference Management 5.9.1 CDS Agenda The CDS Agenda software was initially developed in 1999 by the CDS team following a request by the ATLAS experiment. The initial software has been greatly enhanced and improved since – 24 – Architecture Blueprint RTAG - Final Report the first version thanks to the comments and feedback from its users. CDS Agenda v4.2.7 is the current version and is in wide sprwad use within CERN and at several other external sites. CDS Agenda allows you to create, modify and store agendas of meetings, conferences or workshops together with all the documents (transparencies, minutes, pictures, videos, etc.) associated with them. The CDS Software suite, of which CDS Agenda is a part, is free software, licensed under GNU General Public Licence (GPL). Currently there are > 10,000 agendas inside CERN's CDS Agenda system with some 70,000 associated talks. At CERN, CDS Agenda has doubled in usage every year since its introduction. 5.9.2 InDiCo In 2002, the InDiCo project was approved as an IST (Information Society Technologies) project under the auspices of the 6th Framework Programme of the European Union. The aim of this project was to build on the experience of CDS Agenda to develop a more general tool which would be able to provide a complete conference management system on top of the CDS agenda software while at the same time satisfy the needs of CDS Agenda users. 5.9.2.1 Key features of InDico         create and maintain your conference web site, be it a single talk or a whole workshop schedule sessions and contributions attach material to conferences and contributions, be it text or multimedia content make categories to organise conferences according to a hierarchy review papers with the web application and email notifications protect items based on user authentication delegate responsibilities to others according to roles archive your conference to specialised repository services, currently being developed by partners within the frame of InDiCo The tool is aimed at being easily extensible, so as to handle all aspects of conferences in the future, including participant registration, reservations, etc. As an important organiser of lectures and conferences, CERN also provides partners with audio and video content for the part of the project dealing with multimedia analysis. An experimental, yet important part of InDiCo is the automatic indexing of multimedia content using voice and pattern recognition technologies. This is done in the Netherlands at TNO TPD, TNO TM and the University of Amsterdam. See the official web site (http://indico.sissa.it)for contacts in these institutions. – 25 – Architecture Blueprint RTAG - Final Report InDiCo has been adapted by CHEP'04 - a major conference on Computing in HEP. You can see how InDico looks by going to the CHEP home page (http://chep2004.web.cern.ch/chep2004/) or by going directly to (http://indico.cern.ch/conferenceTimeTable.py?confId=0). 6 Infrastructure and Implementation Issues [DF] 6.1 Integration with the Grid [TD] 6.2 Networking [PG] 6.3 Security [DF] 7 Synergy with Existing Initiatives [CH] We identified two more or less parallel initiatives to this RTAG, whose main focus was also on deployment of collaborative work infrastructure within HEP: RCWG and HTASC-CSMM. 7.1 RCWG RCWG (Remote Collaboration Working Group) is a long term established working group which monitors VC infrastructure deployment within the US HEP community since its inception in the 90’s. The central part of this infrastructure is operated by ESNet? Collaboration Service (http://www.ecs.es.net/index.html). RCWG is presently chaired by Ed May, from ANL. The working group meets every week via videoconferencing, alternating a formal (with prepared agenda) session and a technical session, where every participant freely presents what could be of interest for the others (information, test report, user feed-back, suggestions on improvements or evolutions…). RCWG ccasionally organizes and preforms debugging and integration testing of new ESnet? VC services. Members of RCWG are generally in charge of providing VC support at main HEP institutions (among which FNAL, LBL, SLAC). ESNet collaboration Service staff and European institutions (LAL, DESY, CERN) representatives regularly attend. This RTAG and RCWG have been presented one to each other by their respective chairmen during regular meetings of each group. The fact that one member of RTAG12? usually attends RCWG meetings has ensured that no hot topic addressed by one group could have been missed by the other. RTAG12 had the opportunity to use ESNet facilities during one of its meetings, where it was recognized that industry provided H323 central infrastructure yield a significantly better audio and video quality than those usually provided by VRVS. RCWG is very interested in being informed of RTAG12 conclusions and follow-up. – 26 – Architecture Blueprint RTAG - Final Report 7.2 CSMM HTASC (HEP-CCC Technical Advisory Sub-Committee) has set up a working group about a year ago with the following mandate ; « The HTASC CSMM Subgroup should advise HTASC and HEPCCC on current and future needs for CSMM within the HEP community. “CSMM” in this context refers to all means used to enhance traditional meeting experience with digital technologies, notably scheduling, video conferencing video streaming and document sharing. For this purpose, the current situation with respect to available technologies and trends in this area as well as usage profiles should be reviewed. As a first step the specific topic of videoconferencing should be addressed. The group should    survey present practices within the HEP community; review available technologies and their use and applicability within HEP; make recommendations concerning coordination between different laboratories and institutes. The group should report back to HTASC and HEPCCC on the topic of videoconferencing within no more than one year and produce a written report. » The scope of this working group is broader than RTAG12’s one, as it covers the whole HEP community, and is more technically oriented. Membership includes representatives from UK, France, Germany, Spain, Italy, US and CERN.Three 1,5 day meetings have been held and input received from presentations by DFN (Germany), RedIRIS? (Spain), Renater (France), ViDe? (USA), numerous discussions with industry and VC end users – 27 – Architecture Blueprint RTAG - Final Report 8 Financial Scenarios [SG] 9 Recommendations to the PEB 9.1 Coordination and Management 9.2 Audio Conferencing 9.3 Video Conferencing 9.4 Document Viewing 9.5 Application Sharing 9.6 Web Casting 9.7 Web Archiving 9.8 E-Mail and Instant Messaging 9.9 Computer Supported Conference Management 9.10 Conference Rooms and Other Facilities 10 References – 28 – Architecture Blueprint RTAG - Final Report Appendix A – ATLAS Collaborative Tool Survey Results – 29 –