Minutes from the IETF DIS BOF, Dallas - 12/95

Jim Whitehead (ejw@ICS.uci.edu)
Wed, 21 Jan 1998 15:57:15 -0800

This is a multi-part message in MIME format.

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In case anyone's wondering, this is actually Roy and Roy (well, if you
insist, Rohit) digging at hits related to Application Level Framing
(ALF), a Dave Clark (TM) concept. But we're using Jim's computer...

This is fascinating, because I never knew there was consideration of an
IETF working group -- it was later birthed as Large Area Multicast
Environemnt (abbreviated as LSMA, for reasons unknown :-).

Here is the initial meeting minutes; the next message will have a nifty
summary of distributed VR protocol requirments co-authored by Mark

Eve, why didn't you say something?


Architectural Considerations for a New Generation of Protoc

Content-Type: text/html; charset=us-ascii; name="0002.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="0002.html"
Content-Base: "http://www.nac.gmu.edu/ietf-dis/0002.h

<BASE HREF="http://www.nac.gmu.edu/ietf-dis/0002.html">

<!-- received="Fri Feb 9 16:21:22 1996 EST" -->
<!-- sent="Fri, 9 Feb 96 15:20:15 EST" -->
<!-- name="Mark Pullen" -->
<!-- email="mpullen@cne.gmu.edu" -->
<!-- subject="Minutes from the IETF DIS BOF, Dallas - 12/95" -->
<!-- id="9602092020.AA24274@cne.gmu.edu" -->
<!-- inreplyto="" -->
<title> Mailbox of ietf-dis: Minutes from the IETF DIS BOF, Dallas - 12/95</title>
<h1>Minutes from the IETF DIS BOF, Dallas - 12/95</h1>
Mark Pullen (<i>mpullen@cne.gmu.edu</i>)<br>
<i>Fri, 9 Feb 96 15:20:15 EST</i>
<li> <b>Messages sorted by:</b> <a href="date.html#2">[ date ]</a><a href="index.html#2">[ thread ]</a><a href="subject.html#2">[ subject ]</a><a href="author.html#2">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0003.html">MML : "subscribe"</a>
<li> <b>Previous message:</b> <a href="0001.html">Mark Pullen: "Test"</a>
<!-- nextthread="start" -->
<!-- body="start" -->
For those who missed this draft earlier:<br>
====================================================================== <br>
DRAFT MINUTES, IETF Distributed Interactive Simulation<br>
(DIS) BOF<br>
Dallas IETF Meeting, 8 December 1995 0900-1130<br>
Mark Pullen and Michael Myjak, Co-Chairs<br>
Minutes: Michael Benson<br>
This is a rather long set of minutes but because the BOF was the<br>
last session held on the last day of the IETF meeting, we expect there<br>
may be people who could not attend and would appreciate this level of<br>
The meeting was opened by the co-chairs with a round of introductions. <br>
The people attending were:<br>
William Babson <br>
Michael Benson <br>
Steven Blake <br>
Carsten Bormann <br>
Ken Carlberg <br>
Steve Deering <br>
Dino Farinacci <br>
Ross Finlayson <br>
Walter Lazear <br>
John Linn <br>
David Marquardt <br>
Michael Myjak <br>
Alan O'Neill <br>
Kazuhiro Okanoue <br>
Mark Pullen <br>
Michael St. Johns <br>
Gregory Troxel <br>
Theodore Wolf <br>
The following agenda was proposed and accepted:<br>
1. What is DIS and why should the IETF care - Mark Pullen<br>
2. What Internet technologies does DIS need?<br>
- IP multicast/RSVP/IntServ - Greg Troxel<br>
- IPmc/ATMmc Mark Pullen (for Susan Symington)<br>
- Simulation Network Management - Michael Myjak<br>
3. How should IETF and DIS-CAS work together - general discussion<br>
The first presentation was made by Mark Pullen and traced the<br>
evolution of DIS. Mark began with a discussion of the BBN "Simulator<br>
Networking" project known as SIMNET. In DIS, multiple simulator hosts<br>
share a common state of the virtual world interconnected via a<br>
communications network. DIS is a real-time "Virtual World" simulation<br>
typically characterized as having a "human in loop". A goal of the<br>
DIS community is to have a seamless simulation environment, reaching<br>
out to include "constructive" command post simulations and "real<br>
world" instrumented ranges. DIS requires a constant stream of packets<br>
from each simulator in the range of .5 pps to 15 pps. Even with<br>
compression, connecting many thousands of hosts at this data rate<br>
generates a network load of huge proportions. The sending rate and<br>
accuracy must be proportional to the application - training, testing,<br>
An important simulation element is semi-automated forces or SAF. SAFs<br>
are unmanned entities which interact with other entities. This is to<br>
allow for the simulation of larger forces (then would be feasible in<br>
person) or to provide a virtual enemy to interact with. With the<br>
introduction of SAFs, it is possible for network loads to reach 50 to<br>
100 million bits per second over a wide area, potentially worldwide.<br>
A lot of people feel DIS is likely to be commercialized as<br>
entertainment; it also could also be used in FAA, medical simulations,<br>
or environmental modeling (NRL is doing this). So there is potentially<br>
a big market for IETF products in this area.<br>
DIS requirements :<br>
o Real-Time: low latency and jitter (jitter can be reduced by<br>
buffering so long as the latency is under 100ms for "tightly<br>
coupled" applications such as aircraft information.)<br>
o Multicasting: each simulator sends to many others<br>
o Resource Reservation for shared use of real-time network<br>
o Security for classified exercises and/or rehearsals<br>
The above is easy to do on a LAN - but very hard to do in a WAN<br>
environment. The goal of 100K entities in simulation is highly<br>
Multicast Groups:<br>
The simplest case is one group per exercise. This is essentially the<br>
small broadcast-based environment under which SIMNET was developed.<br>
However, large exercises require the use of multiple groups (possibly<br>
thousands of them) to reduce simulator input and reduce tail circuit<br>
loading. Groups may be organized in a variety of different ways (for<br>
example: one group may have common sensor inputs, while another may be<br>
Receiver initiated joins are considered a security problem (there was<br>
audience interaction here, pointed out that an authenticated receiver<br>
join may solve the problem, others felt that an authenticated join may<br>
not be sufficient. Problem is the security issue is imposed by federal<br>
security agencies, may not be the solution IETF would generate. Under<br>
some circumstances group joins may happen at rates of hundreds per/min<br>
In some cases security requires sender-initiated multicast group join.<br>
DIS needs advances from IETF:<br>
o Multicast with resource reservation<br>
o Compatible resource sensitive multicast routing<br>
o Use of ATM multicast link layer<br>
o Mixture of unreliable and reliable transport (collision PDUs need<br>
to be reliable, multicast may or may not need to be reliable). <br>
o possible reliable multicast from a paper from Stanford University.<br>
RTP / RTP2 doesn't seem to be solution<br>
o Real-Time network management (Managing real time networks)<br>
o Session protocol<br>
o Integrated security architecture<br>
References to RFC 1667 were made.<br>
Modeling &amp; Simulation Requirements for IPng<br>
DoD wants:<br>
o to use commercial networking systems in shared defense nets for<br>
M&amp;S because of availability, cost and multi-vendor support<br>
o Wide geographic dispersion<br>
o Voice traffic in same network<br>
o Latency of 100-300ms required worldwide<br>
o 98% packet delivery<br>
Question: What to do for 2% of lost packets?<br>
Answer: Send full state in every packet, smooth at the receiver using<br>
dead reckoning. <br>
When used for training, the question is whether it is credible for the<br>
people (the interactors) involved. There is also the issue of a<br>
separate accuracy needed for weapons simulation then for other<br>
entities. <br>
Question: What about the heterogeneous network traffic delivery and<br>
what does 98% mean? <br>
Answer: It means delivering 98% of the packets to the receiver that<br>
they are intended for within some predefined time frame (say,<br>
RFC 1667 documents some of the specific requirements, others are<br>
listed in the IEEE 1278.2 standard, such as Real-Time communications<br>
with 100/300ms with jitter filtered out. Multicast address groups for<br>
DIS need to be scaleable to hundreds of sites, supporting thousands of<br>
groups with tens of thousands of group members. Each host can maintain<br>
membership in hundreds of groups. Rapid group membership change<br>
(under 1s, prefer under .5s) need to be supported.<br>
Note that these are Sender and Receiver initiated joins, not just<br>
receiver initiated as in current RSVP protocol work. Resource<br>
reservation should prevent low latency and jitter.<br>
Next Presentation: Greg Troxel on Time synchronization;<br>
Hosts are time-synched so that packets received late can be put into<br>
place; in the order intended. DIS has a standard of absolute time<br>
which is synchronized to UTC. Needs of modeling &amp; simulation<br>
community are not without some degree of difficulty.<br>
DIS is not like teleconferencing applications (!)<br>
o All hosts send and receive<br>
o DIS optionally requires a secure environment<br>
o Larger number of host groups (10^5 is goal)<br>
o Host groups could be based on bounding boxes or grid areas or other&lt;?&gt;<br>
o Individual hosts could join many groups<br>
o Group interaction requires small join time (&lt;&lt; 1sec)<br>
o Generally relatively few WAN sites participating<br>
A recent test had 7 sites and 1K groups (for example) with the average<br>
number of joins running about 1 join/sec (note: data was computed from<br>
recent RITN work).<br>
DIS QoS requirements:<br>
o All receivers are also senders<br>
o Sender needs to know QoS that was obtained<br>
o Application-specific backoff preferable to policing or best<br>
effort service<br>
o Individual simulators are rapidly switched between groups<br>
o Desire to gain benefits of statistical multiplexing across<br>
senders (i.e. aggregation)<br>
o and multicast groups (believe 50xBWsim&gt; BW50xsim)<br>
o Fast reservation setup/tear-down time also necessary<br>
Note: Steve Deering points out that the fastest join possible is the<br>
round trip time of a packet. Mark Pullen suggests that the number of<br>
host groups may affect join latency (as tables grow large); also if<br>
sender initiated joins are insisted upon, then the situation can<br>
possibly become worse.<br>
DIS QoS Difficulties:<br>
In RSVP sender doesn't know the true status of the reservation. RSVP<br>
Session definition doesn't allow for sharing across multicast groups.<br>
Some possible extensions are:<br>
o Allow multiple sessions to have a single reservation<br>
o Extend session definition to address/prefix instead of address/32<br>
o RSVP PATH message could keep track of current reservation (ADSPEC?)<br>
o Shared-explicit filter with address/prefix could help make shared<br>
reservation across many members of a network, but wouldn't solve<br>
sharing across multiple destination groups.<br>
Question: Does what does reservation latency need to be? <br>
Question: Is 100-300ms adequate?<br>
Answer: Could have bi-level reservation... or lots and lots of<br>
reservations. Question: (Dino Farinacci) Using group state -- is DIS<br>
it able to aggregate group state? No good answer for this: hard to do,<br>
in general, we're not sure. The IDMR groups provide some data that<br>
may be helpful to determining whether or not these ideas are<br>
IETF Multicast / ATM Multicast<br>
Slides by Susan Flynn Symington of MITRE, presented briefly by Mark<br>
Example application: Distributed Interactive Modeling and Simulation<br>
This talk was presented recently (by Susan Symington) at a major<br>
Modeling and Simulation conference. It shows growing concern from the<br>
M&amp;S community for network issues. The M&amp;S network protocol<br>
architecture model description provides that defense applications will<br>
be ATM (or ride on top of) ATM. The initial ATM network approach is<br>
to use ATM multicast with IP multicast for local area distribution.<br>
IP datagrams will ride over the ATM infrastructure "end to end". The<br>
desire is to achieve effective packet replication by using ATM<br>
Multicast. This does however, require effective integration of ATM<br>
Multicast and IP Multicast.<br>
Mark then showed the following slide, which indicates the disconnect<br>
between IPmc and ATMmc:<br>
IPmc (characteristics) ATMmc (characteristics)<br>
Omnidirections Unidirectional<br>
Multipoint to Multipoint Point to Multipoint<br>
Peer Group Oriented Root/leaf Oriented<br>
Connectionless Connection Oriented<br>
Group Addressing Individual ATM Endpoint Addressing<br>
Need IPmc / ATMmc Interface to be compatible for large and small scale<br>
M&amp;S usage. <br>
Noted: Work is ongoing in IETF IP/ATM group, but consensus on these<br>
issues is not a given (nor clear).<br>
The group pointed out that there will be some testing between CBT and<br>
MARS with perhaps PIM (sparse mode) - results will be made available.<br>
Next Presentation: Michael Myjak on Simulation Network Management<br>
Requirement: To manage multiple interoperable applications<br>
Simulation applications can be viewed as a multipoint to multipoint<br>
multicast communication source. Simulation network managers are point<br>
to multipoint communications Environment.<br>
Typically, simulation network management includes:<br>
o Highly interconnected LANs connected to WANs<br>
o Typically 1 simulation management and logger per site<br>
o Multiple (sometimes) viewers (stealth, wav)<br>
o Also controls simulation applications (simulators, loggers, etc.)<br>
Example simulation management problem: Logging in DIS - Easy to do on a LAN: <br>
simply dump ethernet to disk. Problems: This does not leave the<br>
ability to filter non-DIS traffic off the LAN.<br>
Example application for SIMAN: Data Loggers. Loggers currently<br>
evaluate every packet; which is wasteful. Problem is time used in<br>
encoding means logger generally misses a few packets (potentially<br>
critical ones). Another problem is that when this is connected to a<br>
WAN then you will miss packets from other sites due to dropped-packet<br>
filtering. in addition, logs from other sites may not be integrated;<br>
requires absolute time references and better throughput efficiency. A<br>
working prototype solution may be to use absolute time-stamp as<br>
documented in the DIS standard, IEEE-1278.2.<br>
Audience comments: latest demos are showing absolute timestamping can<br>
solve logger problem (Troxel); need to filter this technology down to<br>
users (Pullen).<br>
Comment: Still need to work on the manager to manager solutions --<br>
agreement for time to start, stop, resume, etc. needs to be handled at<br>
lower layers.<br>
Comments from group: the telephone works all the time and ATM does not<br>
(Troxel); Internet is no longer doing dynamic routing --for this<br>
reason multicast tends to work better than unicast (Deering) because<br>
dynamic routing is still being explored/experimented.<br>
How should IETF and DIS-CAS work together (group discussion)?<br>
Discussion of the ATM vs IP / IP Multicast.<br>
DoD is using ATM as a global COTS solution, so DIS is challenged to<br>
find a way to use ATM. Some felt DoD should try buying an IP solution<br>
but there was general recognition this is probably beyond the DIS<br>
community's influence. Discussion led to conclusion that an organized<br>
approach to DIS within the IETF is needed, including which area DIS<br>
participation would fall into.<br>
Because this BOF was organized on short notice it will be necessary to<br>
repeat this BOF at a future meeting, March or June. (note: June in<br>
Montreal was the consensus).<br>
A reasonable goal for a DIS WG would be to produce informational RFCs<br>
showing how DIS can use IETF products as they emerge. DIS-CAS is<br>
doing this now under IEEE standards process but the products are two<br>
years behind the IETF technologies due to the slowness of standards<br>
process. DIS might choose to turn RFCs into IEEE standards but the<br>
IETF products would still happen first.<br>
Some working group is needed to do this; DIS-CAS does not have enough<br>
networking talent within to accomplish these goals. However DIS-CAS could<br>
bring the defense applications expertise to IETF, if they are funded to<br>
attend the DIS working group within the IETF. Then they can also attend the<br>
various other groups that are a concern to the DIS community (such as RSVP,<br>
INTSERV, IP/ATM, etc.). This would be a reasonable thing to do/try, but<br>
there must be a defined output from the IETF DIS working group. (Note that<br>
it is very easy to disband a working group if there is not enough interest<br>
(comment by Deering).<br>
The DIS BOF members agreed to set up an email alias ietf-dis@gmu.edu,<br>
and will advertise it to attendees at this BOF. An announcement will<br>
also be posted through regular IETF channels. An archive and a<br>
possible web site for this group will also be considered. Consensus of<br>
the working group is to proceed with a more structured BOF NOT on a<br>
Friday, and to advertise this through non-military uses (i.e. gaming,<br>
entertainment, business, medical, etc.).<br>
<!-- body="end" -->
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0003.html">MML : "subscribe"</a>
<li> <b>Previous message:</b> <a href="0001.html">Mark Pullen: "Test"</a>
<!-- nextthread="start" -->