NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Jon Crowcroft <jon.crowcroft@cs.ucl.ac.uk>
Michael Myjak <myjak@ist.ucf.edu>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore+iesg@cs.utk.edu>
Technical Advisor(s):
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion: lsma@gmu.edu
To Subscribe: lsma-request@gmu.edu
Archive:
Description of Working Group:
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 WG 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 WG 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:
Dec 96 |
|
Meet at San Jose IETF review charter, review initial drafts of Scenarios and Limitations documents |
Mar 97 |
|
Substantially complete internet-drafts ready for review; work will be presented in Spring SISO workshop for feedback. |
May 97 |
|
Internet-drafts ready for WG Last Call |
Jun 97 |
|
Close group. |
Jun 97 |
|
Submit documents to the IESG for publication as Informational documents. |
Internet-Drafts:
· Scenarios and Appropriate Protocols for Distributed Interactive Simulation
· Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment
· Taxonomy of Communication Requirements for Large-scale Multicast Applications
No Request For Comments
Minutes of Large Scale Multicast Applications Working Group
Reported by WG Co-Chair, Jon Crowcroft
[Apologies from other Co-Chair, Mike Myjak]
WG E-mail list: lsma@gmu.edu / lsma-request@gmu.edu / [web and archive, TBA]
Agenda
I. Agenda Bashing
II. Charting the Course
III. Document Deployment
(a). Review requirements Draft <draft-ietf-lsma-requirements-00.txt>
IV. AOB
I. Introduction
Jon Crowcroft gave a brief history and restated the purpose of the WG. He suggested that the recent work, as illustrated by the draft i-d in the next section, represented a broader take on our work than the original membership and charter. The DIS (and share dealing networks) have timeliness requirements that suggest network provisioning/over-engineering or int-serv and rsvp deployment, which then make the requirements on reliability, timeliness, latency and so on easier to achieve in the application and middleware domains. The broader remit, in the "public" or "open" Internet environment today, without deployed int-serv/rsvp, means that tradeoffs need to be assimilated into the middleware/application levels. This is beyond our original intention, where we had a goal of pushing back on the other WGs in the IETF (RSVP, Int-Serv, IDMR, ION, Mboned, and recently, the IRTF RM group), a set of fairly well defined protocol scaling and performance requirements (as documented in the Scenarios and Limitations drafts.
Mark Pullen agreed that the HLA had moved on from the specifics of DIS, and that perhaps this broader view was needed.
II. Presentation of draft-ietf-lsma-requirements-00.txt Peter Bagnall [Other Author: R Briscoe]
Slides available at http://www.labs.bt.com/people/bagnalpm/lsma/munich.ppt
[html and ppt 4 version TBA on the WG email list]
Expiration: 29 January 1998 BT 29 July 1997
Taxonomy of Communication Requirements for Large-scale Multicast Applications
Peter presented an overview of the excellent (well received) requirements i-d. Dave Oran raised a number of points (regarding idea of fairness property, relative delays, errors and jitter seen by different receivers in heterogeneous delivery). His is a nice definition of the problem where the parameters are defined specifically at each receiver (or sub set of receivers) and the differences defined as a separate characterization of requirement. The following then become application-specific: how we add new receivers and whether we degrade average performance, or allow lower quality reception to some, or reject new receivers somehow (at the middleware application level) if we cannot tolerate group degradation or a wide variation (or any variation) or support it through resource reservation. The view was expressed that the API should be able to express and control all these (and other) options for behavior.
Kirstein mentions Air Traffic Control as another strong requirements pull in this area (akin to the HLA/DIS one).
The requirements on security for LSMA were briefly discussed. Two nice applications were mentioned: Games with large prizesm and database synchronization - these put a lot of stress on current Internet Security mechanisms (in fact, large scale multicast with good secure timeliness to avoid _cheating_ appears to be a research topic, rather than something ripe for IETF standardization work - ed.]
Tony Ballardie (IDMR co-wg chair) asked what application requirement pushback on IDMR there was. There was a discussion about interaction between application performance requirements and tree types (symmetric, shared/source based changes etc.). Dave Oran and Mark Pullen commented that this is a key working area of the group so far, that we seem to be moving up a level as well though. Christopher Bonatti asked about general APIs and the re-usability of techniques for LSMA.
The WG Chair asked for feedback, and commented on the usefulness of the general notion (especially the fairness v. heterogeneity, and scaling questions). Dave Oran commented on the "big picture" requirements to _reduce_ the black box nature of the Internet architecture.
Ken Carlberg asked about the difference between Intranet and Internet requirements...
III. Document Deployment
draft-myjak-lsma-scenarios-00.txt
draft-pullen-lsma-limitations-00.txt
It was agreed that these should go to WG last call between now and the next meeting, and, if ok, try to progress to Informational RFC.
IV. AOB
None
V. Actions
Jon Crowcroft to pursue with Area Director(s) whether LSMA should stay with current charter and wrap up, or complete current business at Washington IETF (40th!) and re-charter with broader (or narrower) remit to include less DIS, and more general HLA and other LSMA (in the natural interpretation of the words) form along the lines presented in the draft-ietf-lsma-requirements-00.txt document.
None Received