Version of 5 October 1997
This is a working document for I2 members. Comments to:
Ted Hanss
Director, Applications Development
Internet2
3025 Boardwalk Suite 100
Ann Arbor, MI 48108
+1.734.913.4256
ted@internet2.edu
Introduction
Applications are the reason for Internet2. And it will take the
combined Internet2 member community's efforts to develop those
applications. The project mission and goals outline our strategic
efforts:
Application Goals
Major challenges
We face many challenges while working to develop and deploy Internet2
applications. For example, we must build compelling scenarios that
ignite the interest and imaginations of applications developers. We
must help them see not the bits and bytes of I2 but the promise for
qualitative and quantitative enhancements in their research and
education activities.
The challenges are in part a chicken-and-egg situation with the process of connecting universities and individuals on campuses to the network. Therefore, it will be an iterative process, with the engineering effort enabling network connectivity while the applications developers establish requirements for the engineering team.
Our initial focus will be on applications that will run in the "release 1.0" I2 environment, comprised of a best effort IPv4 service. Then, we will focus on exploiting additional functionality. Determining which new features we will explore will be one of our tasks.
Establishing a common infrastructure among applications, to enable interoperability and portability, must come from both up-front efforts, which set expectations before applications are built, and through funded enhancement efforts that extend existing applications to support common infrastructure technologies. Having the campuses infrastructures ready is a major challenge. To understand where we are and how far we have to go to a full-featured, standards-based environment across the I2 universities, we initiated a campus middleware/infrastructure survey in September 1997.
Increased bandwidth is a major component of the engineering effort, but bandwidth alone will not lead to all of the possible new applications. Also necessary is establishing a differentiated services network that allows applications to ask for and obtain defined qualities of service. We will build network-aware applications that can interact with the network, requesting services and receiving feedback. The applications must be adaptive, responding to changes in network conditions (particularly as the range of data bandwidth spans several orders of magnitude).
Many of the currently demonstrable high-end applications depend, in part or in-whole, on native ATM services, including provision of dedicated PVCs for wide area demonstrations. As this approach will not scale to internet-wide solutions, one imperative is establishing QoS based on IP protocols and exploiting those services in I2 applications.
Topics
This paper consists of several sections, each addressing a major
area of the applications effort: role of the campus applications leads,
training, training and outreach, demonstrations, requirements,
architecture, partnerships, applications development lab, working
groups, quality of service, and deploying multicast applications.
There is a timeline near the end of the document, along with proposed measures of success, URL references, and definitions of terms used in the document.
The applications lead serves as the point person to his or her campus on applications issues. This individual is appointed by the Campus Executive Contact and with the Executive Contact and Campus Engineering Lead compose the team representing their university to I2. (Corporate members, sponsors, and partners are invited to appoint applications lead people, but it is not required.)
The applications lead is responsible for such actions as:
While the Campus Applications Lead is the official point person, he or she need not be the sole participant in I2 applications efforts from his or her campus. Others can participate in working groups, be on the apps@internet2.edu mailing list, etc.
We must inform faculty and researchers about both the potential of I2 and the means by which they can enhance their applications. Making people at the universities aware of the potential of I2 applications is one purpose of the demonstrations activities. Helping them attain the knowledge necessary to build their own I2 applications is the purpose of the training activity. It is the process by which we disseminate the results of I2 efforts to the applications developers and users who will exploit those results.
We must build a set of compelling scenarios that, in effect, market the potential of advanced internet services. We must appeal to application developers not solely through descriptions of how we overcome bandwidth*delay product challenges or the wonders of OC-12 networks. Instead, we must speak to their desires to effect qualitative and quantitative improvements in how they teach, conduct research, and collaborate. They will want to know what's in it for them, as developers, to build interoperable I2 applications. Therefore, the scenarios must describe a value proposition that appeals to the individual applications developer and results in benefits for the broader R&E community.
For most faculty and researchers, we must go to them directly. For example, we could attend discipline-specific conferences and host campus "Internet2" days with demos and tutorials.
We will establish a seminar series that includes the following topics (not an exhaustive list):
These seminars will be delivered through:
We will also bring the working group mailing lists and web pages to the attention of faculty.
An area of future discussion will be on how we introduce Internet2 related information into the curriculum, bringing this knowledge to the students who are the next generation of application developers.
Beyond faculty and researchers, we won't succeed unless people use the applications we develop, internet service providers adopt the technologies we find successful, and we have access to advanced applications developed by people outside the I2 community. Broader technology and knowledge transfer activities could include:
Demonstrations will illustrate the potential of the future Internet to have a dramatic effect on how universities conduct research and engage in teaching and learning. A portfolio of demonstrations will cover a representative sample of disciplines. In addition, the demonstrations will showcase how we are addressing such technology challenges as quality of service, security, multicast, etc.
For the October 1997 I2 Member Meeting, I2 staff identified the demonstration applications. In the future, the solicitation and evaluation of demonstrations will involve the applications working groups. The schedule and process for defining the next round of demonstration applications will be set after the October member meeting.
Sources for demos will come from calls to the membership. In addition, we will search through the meritorious applications included in the NSF connection grant proposals. This list could also be used to prompt collaborations among researchers at various universities.
The next major demonstration will be at the April Member Meeting, again in D.C. In addition, we intend to identify applications that will be available "on call" for demonstration purposes (e.g., by campuses for internal use or at conferences/trade shows).
Beyond April, we intend to work with the PACI program participants to develop a major applications showcase in the next 18 months or so.
In 1997 and 1998, we will demonstrate applications that feature these attributes:
Beyond 1998, the applications must feature:
Our efforts focus on a portfolio of applications, representative of those developed on our campuses. It will not be an exhaustive survey and there are overlaps among the categories. For structure we characterize I2 applications by the following classifications:
A valuable aspect of the I2 effort is the combined focus on applications and engineering challenges. To benefit from that structure, it's necessary for the applications teams to generate requirements for review and implementation by the network engineers. The requirements gathering process will pass on details to the engineering team on such things as:
These requirements will be gathered through working groups, surveys, and other means. They will be consolidated and validated by the I2 membership.
As a part of the requirements and planning process, we intend to undertake application-level analytic modeling efforts, where appropriate, to scope the impact of applications on the network.
We must establish a base level applications architecture for I2. This architecture must embrace goals of interoperability and portability, for it is our objective to increase the deployment of advanced applications. It should be a modular architecture, that recognizes that standards change and evolve quickly in the network world. It must accommodate future change in either technology or in how technology is used. For example, I2 applications should consider mobility implications even if mobility isn't practical for specific applications today. We must avoid a future where our energies go to re-architecting I2 applications for a much more fully mobile world.
The architecture should establish an understanding of accepted middleware standards upon which developers will build their applications. This common protocols and APIs will include security services (identification, authentication, authorization, encryption), directory services (white pages, yellow pages, traders/brokers, applications binding), streaming media, etc.
The Internet2 community won't develop standards per se; those efforts will continue, for example, through the IETF (in which many I2 members are extremely active). We will, though, within the I2 community, establish best practices and common conventions for building, deploying, and managing our applications environments. This includes such areas as managing authentication, access controls, accounting and charging, and making QoS requests. A major role of the I2 Project is to enable the discussions that result in agreement. The I2 Project will publicize and promote the identified, agreed-to norms of the members.
Two of the highest priority areas for identifying technical and policy standards and practices are security (for inter-realm authentication and access control) and quality of service. I2 will need to take a leadership role, working with such groups as CAUSE, The Coalition for Networked Information (CNI), Association of Research Libraries (ARL), Common Solutions Group, etc.
Establishing the right partnerships is necessary as it is not I2's objective or ability to solve all application area problems. We benefit significantly from the research and development efforts of our corporate members, sponsors, and partners. Through other partnerships we can share knowledge and technology with those developing software and content in such fields as entertainment, manufacturing, and crisis response.
Funding for applications development will come from a number of sources. The I2 project can assist in promoting opportunities for funding coming from industry and government and available to university faculty and researchers. We will do this through links to information about funding sources and in communications to the membership.
Other network research efforts are underway, in the U.S. and internationally. We seek to partner with those efforts to extend the scope of end-to-end applications interoperability.
We will create an applications development lab for testing and evaluating hardware and systems software with I2 applications. Testing aspects we will target include interoperability and portability of applications and middleware, enhancing applications with new functionality, scaling trials, and exploiting new network features.
The lab will be a distributed service, with testing supported across Internet2. For experimentation with core features, like router functionality, we will have test network links. In addition, on-site access will be available in locations, such as Ann Arbor, for internships or visits by those I2 members without vBNS connectivity or looking to work closely with consulting software developers.
To organize the I2 member community efforts, we are creating working groups. Coordination of the working groups will include looking for common issues across both technology and discipline areas. The working groups will utilize mailing lists, web pages (at www.internet2.edu/wg/ [to be developed]), audio and video tele-conferences, online forums, and face-to-face meetings to accomplish their tasks. Volunteer working group chairs will provide the leadership for these efforts, supported by I2 staff.
Not all of the working groups will have chairs or ongoing membership. Some will primarily be used for communications and coordination or for calling "birds-of-feather" sessions as needed. If you are interested in playing a leadership role in any topic, or in introducing a new topic, contact Ted Hanss.
Issues in this area include identifying requirements for delivering content that meet the aesthetic goals of the artists, which may be a very good design point for other I2 applications as well. There is also a concern about how vBNS access will be allocated among disciplines and whether those in the arts and humanities will gain access on par with those in the sciences. (This latter issue involves investment on the campus in connectivity upgrades, investment in applications development, etc., not necessarily acceptable use policies.)
It was noted at the I2 applications workshop that artists are experts in media-based communications, and humanists are experts in the analysis of human relations and interactions. Just as interdisciplinary teams of artists, scientists, and programmers invented new visualization paradigms at the supercomputing centers in the 1980's, it is expected that including artists and humanists in the I2 mix will lead to breakthrough networking applications.
Per the conversation at the applications workshop, we will use a web page to communicate issues regarding arts and humanities applications. We will not start with a separate mailing list or working group.
Components of collaboration environments include audio, video, shared whiteboards, and visualization tools that support synchronized views. Challenges include delivering audio, video, and data streams with variable data rates and service guarantees. Collaborative applications users express a desire for high data rates and bounded delay. Some applications will require very low packet loss. Collaborative environments will rapidly become critical applications which require reliable service and rapid diagnosis and repair of problems.
Data rates will run from very low speed (i.e., 1-50 Kbs), to low speed (i.e., 50-500 Kbs), to medium speed (500-2,000 Kbs), to high speed (i.e., greater than 2 Mbs), to very high speed (i.e., greater than 100 Mbs). One applications workshop participant mentioned a need for data streams with over one gigabit per second.
Security is a big problem. Individual and group authentication is required so you know who you are communicating with and that the data you access is from the organization you think it comes from. Another aspect of security is privacy, particularly person information privacy and access controls.
Support is required for a middleware toolkit to encourage the development of novel collaboration applications. These toolkits must support rapid creation and management of media streams.
A difficult element of the shared data environments is the particular type of data being shared (e.g., large visualization data sets, complex 2D and 3D virtual worlds, and simple 2D drawings) and the maintenance of shared state and multiple views of the data (synchronized and unsynchronized).
The collaboration working group will create a web page and a mailing list for communicating among interested members.
The coordination steps will be setting up a web page for sharing information, with pointers to available API sets from standards organization, commercial vendors, and higher education.
At the July 1997 I2 Applications Workshop, members of a digital library breakout session identified the issues that were most important or should take priority. What rose to the surface were security, better distribution of information, and quick access/browsing. I2 members involved in developing digital libraries could explore those issues more fully and decide if there's a role for an I2 effort to address them.
Issues and areas for investigation include:
The next steps are to pursue identified efforts (e.g., PACI) and inform ourselves about the status of the projects (via web page and mailings lists) and to look at possible follow-on efforts for the open issues/opportunities
Applications in health care cover a variety of clinical, research, and educational contexts in health care. Requirements these applications have include much greater bandwidth (due to the size of many medical images), security, integration with legacy environments, compression, collaboration tools, quality of service parameters (e.g., latency, bandwidth reservation), and last mile issues (for rural health care).
Next steps are to set up a mailing list and a web page for sharing information. There is also the desire to identify appropriate medical organizations for approaching with the I2 message (e.g., Radiology Society of North America in December).
The I2 "value add" includes virtual reality, visualization, multi-party collaborations, distributed simulations (using lots of small machines), real-time adjustments to large-scale simulations, record and replay of simulations with new events/parameters, time series analysis (with access to very large archives), and rich content (e.g., audio, video, high resolution maps).
Some of the issues include middleware standards, wide-scale synchronization, exploiting new display techniques, training the next generation of applications developers, and technical challenges of shared state, scaling the number of participants and the amount of data, and network reliability.
The next steps are to search for exemplar simulations, look for existing, sharable software libraries, document "how does I2 change things", and define "simulation middleware".
Primary areas of interest are:
Some of the issues include locality of reference for cache access, I2-wide support for a distributed file system, network-attached storage devices, scaling to very large data repositories, security, common data formats, data mining and warehousing, and accounting and charging.
Next steps are to set up a mailing list and web page for this effort.
A web site is under development covering the National Tele-Immersion Initiative at http://www.advanced.org/tele-immersion.
Building and deploying a quality of service-enabled environment is necessary to support advanced applications, such as those utilizing continuous media (audio/video streams). Doing this on an end-to-end basis must be based on protocols and APIs supported across multiple platforms. The APIs must support requesting service levels. The underlying network must deliver feedback on its ability to meet those requests through numerous network elements.
We intend to hold a "QoS implementors" workshop in the first half of 1998. The agenda is to understand the state of the art in quality of services and lay out the action plan for end-to-end deployment of QoS functionality. The challenges we face are both technical, How are packets and flows differentiated on an end-to-end basis? and policy-based, Where and how are the decisions on allocating bandwidth made?
Multicast-enabled networks will lead to new applications currently not possible or not even conceived. The coincidence in time of the maturation of multicast and the deployment of Internet2 gives us the opportunity to help speed the deployment of multicast-enabled applications.
A simple first step could include establishing a turnkey multicast broadcast configuration (hardware/software) to use within the project and agreement to broadcast all public meetings on the MBONE.
Other efforts could establishing "I2 sponsored data channels" for multicast delivery. That is, along the lines of a national television broadcaster like PBS that develops or acquires content and then schedules and promotes content.
October 1997
December 1997
January 1998
March 1998
April 1998
June 1998
July 1998
September 1998
December 1998
2000
The following are proposed metrics that could be used to show progress of the I2 applications efforts.
This section will define certain terms used in the document, more to come.