Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_j_p/draft-ietf-lsma-scenarios-00.txt

Text File | 1997-01-07 | 19KB | 382 lines

Internet Engineering Task Force   Large-Scale Management of Multicast Groups
WORKING INTERNET-DRAFT                            Steve Seidensticker, ed.,
draft-myjak-lsma-scenarios-00.txt                 [e-mail]
13 June 1996                                      W. Garth Smith,
                                                  [e-mail]
                                                  Michael Myjak
                                                  [e-mail]
                          Expires in 6 months


                 Scenarios and Appropriate Protocols for
            Distributed Interactive Simulation

                    draft-ietf-lsma-scenarios-00.txt

Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

     Distribution of this document is unlimited.  The current
     working draft is located at the following URL:

     http://www.tasc.com/simweb/ietf/draft-DISscenarios-00.txt


     Current schedule:

     June  1996. Meet in Montreal, approve charter, refine goal
     documents and finalize the appoint of editors for
     documents.

     Sept. 1996.  Produce initial draft.

     Dec.  1996.  Review document drafts and accept changes and
     comments on the documents.

     March 1997.  Publish documents as Informational RFCs Close group.

     Mailing lists for comments:
     [e-mail]
     [e-mail]



Abstract

We describe Distributed Interactive Simulation (DIS) scenarios from
the vantage point of hardware and software vendors who would need to
address the network implications and requirements to enable large
scale networked multiplayer virtual worlds.  This document is meant to
migrate the heuristic knowledge of the traditional Department of
Defense (DoD) modeling and simulation community into tangible design
metrics for the commercial networking community [2].

0. Introduction

Distributed Interactive simulation (DIS) [1] is being extensively used
by the DoD as a means providing multi-player virtual worlds for large
scale military simulations.  A large body of folk knowledge has been
accumulated as to the types of scenarios that are possible within the
DIS community given the state of network hardware and software.  The
authors attempt to describe this hueristic knowledge of network
requirements in the form of anecdotal scenarios such that the general
community be able to characterize simulation requirements from their
perspective.  This paper provides a series of example scenarios with
the details of the required network infrastructure for entity passing
among simulation hosts.  This initial version of the document is meant
to pass through successive iterations.  These scenarios may initially
be described in a general manner but ultimately may be delivered in a
more quantified manner based ob feedback from the June 1996 IETF, in
Montreal.

DIS simulations are collections of individual simulations linked at a
peer level.  That is, there is no client/server or centralized kernel.
Each simulation application maintains it's own copy of a common
virtual environment.  Representations of this environment
(e.g. terrain databases) are distributed by various means to all
simulation applications prior to any real time operation.  Issues
associated with the distribution of the description of the static
environment are not within the scope of this discussion.

During real time operation each simulation application models the
behavior of the simulated entity(s) for which it is responsible.
Whenever specific events occur in the virtual environment or when the
state of the simulated entities have changed significantly, the
simulation application transmits this new information to the other
simulation applications on the network.  This information is
encapsulated in standard packets, the content and format of which are
defined in IEEE standard 1278.1 [1].  These packets are transmitted
via the UDP/IP datagram service.  Anomalies and lack of precise
causality due to dropped packets are tolerated in order to get the
latency needed to support real time operations.

A next-generation approach to simulation standards is in development
which does not explicitly define packets.  However, for the purpose of
exploring the communication issues identified in this paper, the
requirements are similar.

Effective DIS simulation depends on low latency between the time a new
state/event occurs for a simulated entity to the time that that
state/event is perceived by another entity that must react to it
(e.g. two high performance aircraft maneuvering to get in position to
launch weapons at each other).  In event driven simulations increased
latency merely slows the simulation down but causality is maintained.
In real time simulations excessive latency destroys interactions and
the simulation collapses.

The DIS recommended practice for communications architecture (IEEE 1278.2)
indicates that the underlying communications structure should provide 100
ms or less latency for packet exchange for closely coupled interactions
between simulated entities (e.g. high performance aircraft in a dog fight).
This requirement is based on human reaction times that have been the basis
of human-in-the-loop (HITL) flight simulator designs for many years.  This
requirement eases to 300 ms for loosely coupled interactions (simulated
voice radio).

To some extent DIS compensates for excessive latency by extrapolating
continuously changing values (e.g. deduced reckoning of entity
movement based on initial position plus velocity and
acceleration). However, discrete events (e.g. voice exchanges between
humans on a simulated radio net) cannot be predicted and therefore no
latency compensation is possible.

Types of Data Exchanged

The IEEE 1278.1 standard identifies 27 different kinds of packets and
provides an extension mechanism to handle new data types.  Only a few of
these tax network services.  They are:

Entity State -- Information includes appearance, location, velocity,
orientation, accelerations, and position/movement of articulated parts of
simulated entities.  Location and movement are dead reckoned and this
packet is only sent to correct dead reckoned parameters.  It also is sent
periodically, even if the dead reckoned parameters have not changed, as a
heartbeat.  Radically maneuvering entities transmit up to 15
packets/second.  An average rate is two/sec for land vehicles and five/sec
for aircraft.

Emissions -- Information includes point of origin, power, frequency,
direction, scan pattern, and other parameters of electronic or acoustic
emissions.  This information is used to stimulate simulated sensors capable
of detecting and responding to such information.  In electronic warfare
(EW) environments these parameters change frequently.  In an active EW
environment emission packets are sent as frequently as entity state packets.

Signal -- This packet carries bit streams representing voice samples,
computer-to-computer communications, or any other digital bit stream.  It
is heavily used in simulations that include voice radio or computer based
tactical command and control systems.

Environment -- Atmospheric data is broken up into a series of packets to
describe weather conditions in the simulated environment.  The update rate
is relatively low, but the number of packets needed to represent complex
weather patterns induces a significant network load.

Fire & Detonation -- Packet pairs carry the information needed to describe
the firing of a ballistic (unguided) weapon and the detonation of the
projectile.  The amount of information per packet is modest and the total
packets are limited to the amount of ammunition the participants can carry,
but weapon firing tends to come in bursts and those bursts can impact
network performance.


Multicasting

In early DIS simulations all applications simply broadcast DIS packets
to all other applications in the exercise using the IP broadcast
address in UDP datagrams.  More recent DIS simulations use static
multicast addresses to segregate different kinds of packets
(e.g. entity state, emissions, signal).  This reduces the processing
required to throw away packets by those applications that cannot
process them.

While static multicasting is a significant improvement over
broadcasting, it is not adequate for the large scale simulations that
the DIS community needs to build (100,000 simulated entities modeled
by simulation applications at 50 sites).  For that a mechanism must be
found that can efficiently route packets only when and where they are
needed.  Dynamic multicasting is the key.  But to use dynamic
multicasting it must be supported by the communications community.

Much has been said and written about dynamic multicasting.  There is
no single view of it.  Dynamic multicasting can have many
characteristics.  Different applications will emphasize different
characteristics.  Those most important to the DIS community are:

* Many groups
* Many members in a group
* Receiver initiated joins and leaves
* Rapid joins and leaves
* Single member belonging to many groups


1. This scenario is a description of a relatively current small scale
DIS simulation.

A dedicated 10 megabit/second Ethernet 10Base-T Local Area Network
(LAN) has been established for a 200 entity exercise.  The simulation
platforms are Silicon Graphics (SGI) Indigo 2 Extremes running IRIX
5.3, SGI Maximum Impacts, and SUN Solaris 5.4 SPARC Ultra UNIX
workstations.  Three stand-alone hosts running an embedded real-time
operating system are functioning as high speed aircraft simulators.
The aircraft simulators provide high resolution out-the window views
of the virtual world.  All simulations are using the IEEE 1278-1993
DIS 2.0.4 protocol for entity to entity interaction.  Primary entity
information is being passed as UDP/IP datagrams via the UNIX UDP port
3000.  All simulation hosts are located on the same subnetwork on the
LAN.  All simulations are using a 20 X 20 kilometer terrain database
so as to orient in a common virtual world.  All UNIX workstations are
configured with Internet Group Management Protocol (IGMP) and all
simulations are using static IP multicast.  No reliability via
retransmissions is provided at the network transport protocol level as
no standard for reliable multicast has yet been adopted by the
community [3].  A small number of predefined multicast groups are
being used to delineate network traffic to interested users.  These
groups do not change during the course of the exercise.  As in typical
DIS scenarios, all simulation applications are acting like senders and
receivers.  Some simulation applications emit multiple entities (up to
40) while others are responsible for only a single entities behavior.

The majority of entities are low speed ground vehicles transmitting
DIS 2.0.4 Entity State Protocol Data Units (PDUs) of 1152 bits at an
average of two packets per second.  These ground entities are
controlled by a rule based system that mimics behavior of
transportation on four of the SGI simulation hosts.  One of the
rule-based simulation applications is generating six high speed rotory
wing aircraft generating on average six Entity State packets per
second.  Occasionally, these rotory wing entities emit bursts of 704
bit Fire PDUs with subsequent emission of 832 bit Detonation PDU's (on
the order of 20 to 100 packets a second for both Detonation and Fire
PDUs).  All Entity state based information must arrive at all the
designated receivers at the 100 millisecond constraint to remain
real-time.

The three high speed aircraft simulation emit from 5 to 10 Entity
State PDUs per second.  Additionally, the aircraft are using
experimental radio communication packets for transmitting voice
between the users.  Pregenerated background voice traffic is being
transmitted along with the pilot communications.  An air-born control
aircraft simulation transmitting voice to the pilots is also issuing
the voice DIS packets.  These packets are on the order of several
hundred bytes and are randomly dispersed through the exercise with
occasional bursting.  To limit the impact of the voice traffic on
simulation applications that cannot process such traffic, a predefined
static multicast group is used for all voice communications.

One of the simulation applications is providing weather forecasts to
exercise participants via a predefined static multicast group.  These
packets are multicast transmitted at 10 minute intervals due to the
very large size of the precipitation and wind data (a total of five
megabits of data broken up as individual transmissions of 1500 Byte
packets).  As fragmentation and reassembly are not provided in the
multicast transport layer, the applications fragments the data into
manageable packet sizes (i.e., up to the Ethernet Datalink size
limitation).  The weather data need only arrive at the specified users
host at 10 minute intervals to remain real-time.

The scenario is periodically compromised when the network traffic
exceeds the 10 megabit/second rate.  This usually occurs when the
radio and weather packets and detonations are all simultaneously
occurring.  Other loss of network information occurs when the host
receiver buffers get overloaded and drop packets when receiving bursts
of voice and weather data simultaneously.  Exercises that experience
such loss are considered invalid and are replayed.


2. This scenario represents a DIS environment maintained by a company
as an Intranet using a commercial Wide Area Network (WAN) provider.

...

3. This scenario is an example of a large exercise conducted over the
DSI and multiple LAN and WAN segments.

...

Scenario 4.  Recreations of Historic Battles

The year is 2020 or thereabout.  The world's major powers have been at
peace since the resolution of the Balkans conflict in 1997.  Several
generations have grown up without the taste of battle.  But there is
something in the psyche of these generations that yearns for the
excitement of engaging an enemy with skill and determination, but
without the shedding of their own blood.  This yearning has been
behind the development of more and more realistic real time
simulations.  It has culminated in the simulated recreation of
historic battles on a grand scale.

A culture has grown up around these simulations.  Above all they
strive for historic accuracy.  The simulated planes, ships, tanks,
horses, and weapons have the same capabilities as the original.
Logistics, planning, and initial conditions are the same.  The
participants are trained to the same point as their original
counterparts.  They are tested and qualified before they can
participate.  Some take on the names and habits real characters.  Many
assemble at annual conventions to exchange tales and see the latest in
simulation equipment.

These simulations have become a very popular spectator sport.
Millions of viewers watch the battles unfold from any vantage point
that they choose.  They can go into the command centers.  They can
tether themselves to any participant and see and hear what he sees and
hears .  They can tune in to various commentators in different
languages for an explanation or critique of what is going on at
various points.  The recreations are both scheduled and reported on
the popular net sport pages.

The scenario described below is the recreation of a series of B-17
raids that the US Eighth Air Force made over Europe in 1943.  These
raids were fiercely and effectively defended by the Luftwaffe and
German anti-aircraft artillery (the dreaded flak).

The participants are a mix of humans and software models.  The humans
tend to take the more interesting roles.  The software models are
sophisticated enough that they cannot be easily distinguished from
human participants.  Total number of participants roughly corresponds
to the number of participants in the original battle and varys between
100,000 and 500,000.  Number of spectators ranges in the tens of
millions and is governed by the factors that control the watching of
any sport.

The simulation equipment ranges from simple VR goggles to elaborate
cockpits and gun turrets with sophisticated motion and sound cuing.
All simulations share visual cues that are indistinguishable from what
the unaided eye can see.  The participants own or rent the hardware
and software.  As with any avocation the cost varies depending on
taste and finances.  Participation is not governed by cost but by the
dedication and capability of individuals.

The participants and spectators are located throughout the world and
are connected on a virtual net that reaches into each participant's
and spectator's home.  Crew station simulations that are part of one
simulated platform (e.g. a single B-17) are themselves distributed.

Sophisticated multicasting schemes, clever interest management
algorithms, and simulation tricks have effectively removed any limits
to the potential scale of distributed simulations.  Local bandwidth
limitations sometimes restrict what a spectator can see.  Dropped
packets and latency spikes occasionally cause anomalies, but they are
seldom serious enough to effect the outcome of the simulation.



Things to do:
1. get feedback on appropriateness of approach
2. Additional descriptive scenarios



Acknowledgements:

The authors are working under the direction of Michael Myjak
([e-mail]) and Chris Bouwens ([e-mail])
of the DIS Communications Architecture Subgroup (CAS) to produce this
informational RFC.

References:

[1] IEEE Standard for Information Technology - Protocols for
Distributed Interactive Simulation Applications, IEEE Std. 1278-1993.

[2]  http://www.herring.com/mag/issue30/games.html

[3]  http://www.tascnets.com/mist/doc/mcpCompare.html