NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Michael Myjak <myjak@ist.ucf.edu>
Jon Crowcroft <jon.crowcroft@cs.ucl.ac.uk>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Allison Mankin <mankin@isi.edu>
General Discussion:lsma@gmu.edu
To Subscribe: lsma-request@gmu.edu
Archive:
Note: Allyn Romanow <allyn@eng.sun.com is also an Area Technical Advisor.
This group focuses on the needs of applications that require real-time or near real-time communications to support a large number of simulation processes (virtual entities). These applications have been analyzed by the U.S. Department of Defense to require IP multicast support for 10K simultaneous groups, for upwards of 100K virtual entities in a global sized WAN by the year 2000.
The concrete example application is the Distributed Interactive Simulation work of the DIS Interoperability and Standards workshops and standardized as IEEE 1278 - 1995.
The concrete example application is the Distributed Interactive Simulation work of the DIS Interoperability and Standards workshops and standardized as IEEE 1278 - 1995. Future simulation implementations will use the High Level Architecture (HLA) work sponsored by the U.S. Defense Modeling and Simulation Office, and which is currently being standardized by the newly formed Simulation Interoperability Standards Organization (SISO).
The Working Group aims to provide documentation on how the IETF multicast protocols, conference management protocols, transport protocols and multicast routing protocols are expected to support the example application. The result of this Working Group will be two Informational documents that we hope will be used as input and advice by a number of IETF working groups, among them IDMR, ION, MBONED, MMUSIC, and by working groups being developed on Reliable Multicast Applications and QoS Routing.
The document editors for the informational documents will be Steve Seidensticker for "Scenarios" and Mark Pullen for "Limitations".
The Scenarios document will describe the environment in which distributed simulation applications operate. It will provide realistic example scenarios of small, medium and large simulation exercises. The Limitations product will document the limitations of current IETF products as they pertain to distributed applications. This document will offer concise examples of how distributed applications demonstrate these limitations and to the extent possible, offer potential solutions to the identified limitations.
The documents will attempt to provide specific numbers for the demands placed on protocol or infrastructure, and for the limits that protocols impose on the applications.
The group will assess the need for new protocols to support the requirements it identifies, and the Limitations document will report on this assessment. One recommendation it expects to document is for development of a virtual reality transfer protocol.
Goals and Milestones:
· Scenarios and Appropriate Protocols for Distributed Interactive Simulation
· Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment
On Thursday, the Large Scale Multicast Application working group met. Michael Myjak opened the Session and the day's agenda was presented. Two changes were made to the scheduled presentations: the Synthetic Theater Of War (STOW) presentation by Dan Van Hook, and the Internet Games and Active X presentations were not going to be made. Similarly, Steve Seidensticker was not available to make the presentation on the Scenarios draft, although he left his slides so Michael could make that presentation instead.
Mark Pullen made the first presentation, an update on the "Limitations" draft. The draft addresses the shortfalls of the existing protocols, with emphasis on problems where other working groups are not known to be near to providing solutions. It has been expanded considerably from the outline presented in San Jose.
When the new draft was sent to the LSMA list, dissatisfaction was expressed that it did contain more quantitative descriptions of the limitations. Mark acknowledged the need for quantitative requirements and offered to include in the next draft estimates for numbers such as:
· Aggregate flow size for simulation data · Numbers of individual and aggregated groups · Bandwidth-delay product for group updates · Acceptable resource reservation delay
He pointed out the difficulty of defining these numbers crisply with no working examples of large-scale multicast programs. The report on STOW would have provided examples in this area for medium scale. Mark noted that it is possible to divide the problem into three areas:
· Small < 1,000 active objects at < 5 sites · Medium < 10,000 active objects at < 20 sites · Large 100,000 active objects at < 50 sites
In this example, Mark identified a site as a separate Local Area Network (LAN). It was suggested and agreed that Point of Presence (POP) is a useful alternative to LAN.
After Mark's presentation, Michael Myjak presented Steve's Scenarios slides. This presentation covered the existing state of the draft version 0.2. However, after some discussion and email correspondence, Steven and Michael decided that the current version of the scenarios draft does not provide an adequate relationship with the Limitations draft being led by Mark Pullen.
Several solutions were recommended and the final approach taken was to rework the Scenarios draft to concentrate on application scenarios. In addition to Distributed Interactive Simulation applications, time-stepped and even driven simulation applications needed to be addressed. In addition, there are several other applications, such a network news distribution, Internet Relay Chat, and live multicast news feeds, which were not addressed in the existing draft. The next version of the Scenarios draft will remove the section on requirements and address a broader range of multicast applications.
The second issue raised was the need to provide input into another document, called the LSMA Requirements draft. This new draft was proposed the various multicast applications identified in the scenarios draft, and provide a concise quantitative identification of their requirements. This would be a new product for LSMA. The LSMA charter would need to be updated accordingly.
Since our STOW presentation was canceled, the next presentation was to be made by Joe Macker, of NRL. Since Joe could not be here, he asked Don Brutzman of NPS to give his presentation for him. Don said that Joe was indirectly involved with the STOW architecture, so began with a brief description of the architecture. STOW is a dedicated ATM network using FASTLANE encryption devices to provided cell-by-cell data encryption. The project is funded by DARPA as the Real Time Information Transfer and Networking (RITN) project. RITN is chartered with demonstrating the scalability of 10K active entity processes in a single simulation exercise.
Don said that Joe described his work with simulation multicasting technology as "smoke tests." Don noted that no specific data could be made available as this testing is done under Non-Disclosure Agreements and typically performed using Alpha-release test cost. That being said, he indicated that the tests always proved less operational then they would have hoped. In summary, many off-the-shelf devices experienced some difficulty with multicast usage, although most vendors were willing to make changes necessary to make them more operational.
There was great variability between the various vendors. Using the M-Gen tool Joe developed, he was able to provide multicast generators that could drive the devices into overload. More information can be obtained from the following web page: HTTP://www.ait.nrl.navy.mil/modsaf/modsaf.html.
The next presentation was made by Christophe Diot, and was entitled Multi-User Games on the Internet. Chris presented his work with the MiMaze, 2-D labyrinth 3D game. (See http://www.inria.fr/ for more information.) Chris described how each sender in MiMaze is also receiver, which is typical for many Distributed Interactive Simulation exercises. Data was distributed via RTP/UDP/IP, so only unreliable-best-effort transports were used and measured. Chris noted that this distributed verses centralized approach provided for a robust and scalable environment requiring a minimum amount of development time.
Chris also gave a brief overview of the French Mbone architecture, and the layout they used for this DIS exercise. He noted that participants did not suffer concerning group size or network delay, although he did note hosts were very sensitive to delays longer than clock update rates using NTP. They found that a GPS receiver was really needed at every side due to inconsistencies in NTP stratum servers.
The next presentation was given by Don Brutzman on DIS, JAVA, and VRML. These will be the foundations for a new experimental testbed Don is starting at NPS, and invites anyone interested to participate. This testbed is envisioned to be widely used, provide physics-based Entity State PDUs, and be built on a robust, DIS standard protocol. The types of experiments run will involve large scale applications, many-to-many communication streams, and utilize a bandwidth up to several Mbps on the LAN and typically tens of Kbps on the MBone, going higher as appropriate on a not-to-interfere basis.
Don noted that JAVA will be used to handle VRML scenes, and with JDK1.1, future releases will be multicast capable. The big motivation is that these components exist today. These are based on Open-standards, they are portable, physics-based and now web-based.
Don mentioned that the VRML Consortium was forming the DIS/JAVA/VRML working group, membership is open, software is freely available and more information could be gathered at the following Web address: http://stl.nps.navy.mil/dis-java-vrml. Don also asked for folks to consider participating in this open network experiment in order to contribute to experimental results that could be reported through the LSMA forum.
The next presentation was given by Jim Boyle on RSVP CIDR extensions. These changes are recommended to reserve bandwidth used to estimate traffic generation and identify network services. Using multicast, existing implementations require an explicit shared reservation of more bandwidth that was actually used. The only way to improve it is to identify host-specific data requirements. Current host-specific usage does not allow sharing of data between one (1) bursty flow, and one flow that is not. Using CIDR, one (1) packet classifier per LAN can be used to provide fixed-filtered link flows.
Jim noted that LAN multicast group aggregation is not most efficient when it applies to LANs. Rarely do the source and destination LAN multicast group collections equate to one another. This difference in group usage between source and destination LANs may not be limited to a single exercise, but may also indicate flows between otherwise mutually exclusive applications, further compounding the problem.
The next presentation was given by Steve Berson of USC/ISI on Aggregation of Integration Services. The problem Steve addressed was that the amount of state (IS) information associated with a given flow tends to grow linearly with respect to the session. The question is whether we need mechanisms that do not require per-flow state (IS) information.
The objective of aggregation is to reduce (eliminate) the state scheduling, classifier state, a separate State Setup protocol, and maintain multicast routing protocol state. The cost is to lose "per-flow" isolation state. This is possible if one assumes that flow aggregation is just an Intra- Domain issue. By managing intradomain state information at the border routers only, the amount of state information maintained within the region is reduced. This approach is based on using configuration server classes, tagged packets, and policy identification on the Border Router edges only. Configure Service Classes provide for bounded scheduling state at the interior of the region, and no RSVP state or classifier state.
Steve indicated that some open issues are how to configure service classes and how to do admission control. How to police the region is also an open issue.
Following Steve, Michael Myjak provided a short presentation on the state of the LSMA documents. Michael noted that the limitations draft was becoming rather firm. There has not been much discussion regarding this draft and it appeared that only a few areas might have yet to be addressed. Everyone is asked to review the limitations draft and identify any other major areas missing. On the other hand, the scenarios draft, which was intended to identify large-scale multicast application scenarios, is in need of a total rewrite. The current draft focused on Distributed Interactive Simulation applications almost entirely. Furthermore, the draft was supposed to bridge the gap between application scenarios and Internet limitations by identifying the application's requirements. In light of the Reliable Multicast Research Group meeting the previous weekend, and discussed with LSMA's new Transport Area director, we are now proposing that a third product, Projected LSMA Requirements RFC, be developed.
Projected LSMA Requirements will identify the requirements being placed on the network by large-scale multicast applications. These requirements may be specific to unique application scenarios, such as bulk data delivery for newsgroups or dynamic environments, or many-to-many stream connections such as in DIS or Internet Relay Chat applications. In short, the group appeared to be in agreement. One comment was made that we might want to include the Internet Service Provider (ISP) requirements as well.
This concluded the LSMA meeting.
Attendees List
No Roster Received