One document matched: draft-ietf-lsma-limitations-01.txt

Differences from draft-ietf-lsma-limitations-00.txt

INTERNET DRAFT                                       J.M.Pullen
Expiration: 25 September 1997                          George Mason U.
                                                     M.Myjak
                                                       U.of Central Florida
                                                     C.Bouwens
                                                       SAIC, Inc.
                                                     24 March 1997


    Limitations of Internet Protocol Suite for Distributed Simulation
                 in the Large Multicast Environment

                 draft-ietf-lsma-limitations-01.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).


Abstract

The Large-Scale Multicast Applications (LSMA) working group was chartered to 
produce two Internet-Drafts aimed at a consensus-based development of the 
Internet protocols to support large scale, real-time distributed simulation.  
This draft defines aspects of the Internet protocols that LSMA has found may 
need further development in order to meet that goal.


1.  The Large Multicast Environment

The Large-Scale Multicast Applications working group (LSMA) was formed 
to create a consensus-based requirement for Internet Protocols to support 
Distributed Interactive Simulation (DIS), its successor the High Level 
Architecture for simulation (HLA), and related applications.  The 
applications are characterized by the need to distribute a real-time 
application over a shared wide-area network in a scalable manner such that 
numbers of hosts from a few to tens of thousands are able to interchange
state data with sufficient reliability and timeliness to sustain a three-
dimensional virtual, visual environment containing large numbers of moving 
objects.  The network supporting such an system necessarily will be capable 
of multicast.

Distributed Interactive Simulation is the name of a family of protocols 
used to exchange information about a virtual environment among 
hosts in a distributed system that are simulating the behavior of objects 
in that environment.  The objects are capable of physical interactions 
and can sense each other by visual and other means (infrared, etc.).  
DIS was developed by the U.S. Department of Defense (DoD) to 
implement system for military training, rehearsal, and other purposes.
More information on DIS can be found in the references.

The feature of DIS that drives network requirements is that it is 
intended to work with output to and input from humans across 
distributed simulators in real time. This places tight limits on latency 
between hosts.  It also means that any practical network will require 
multicasting to implement the required distribution of all data to all 
participating simulators.  Large DIS configurations are expected to 
group hosts on multicast groups based on sharing the same sensor 
inputs in the virtual environment.  This can mean a need for hundreds 
of multicast groups where objects may move between groups in large 
numbers at high rates.  The overall total data rate (the sum of all
multicast groups) is bounded, but the required data rate in any particular
group cannot be predicted, and may change quite rapidly during the
simulation. 

DIS real time flow consists of packets of length around 2000 bits at 
rates from .2 per second per simulator to 15  per second per simulator.  
This information is intentionally redundant and is normally 
transmitted with a best-effort transport protocol (UDP), and in some 
cases also is compressed.  Required accuracy both of latency and of 
physical simulation varies with the intended purpose but generally 
must be at least sufficient to satisfy human perception, for example in 
tightly coupled simulations such as high performance aircraft 
maximum acceptable latency is 100 milliseconds between any two 
hosts.  At relatively rare intervals events (e.g. collisions) may occur 
which require reliable transmission of some data on a unicast basis, to 
any other host in the system.

DoD has a goal to build DIS systems with up to 100,000 simulated 
objects, many of them computer-generated forces that run with 
minimal human intervention, acting as opposing force or simulating 
friendly forces that are not available to participate.  DoD would like to 
carry out such simulations using a shared WAN.  Beyond DoD many 
people see a likelihood that DIS-like capabilities may be 
commercialized as entertainment.  The scope of such an entertainment 
system is hard to predict but conceivably could be larger than the DoD 
goal of 100,000.

The High Level Architecture (HLA) is a development beyond DIS that aims
at bringing DIS and other forms of distributed simulation into a unifying 
system paradigm.  Thus HLA has network requirements at least as 
demanding as DIS.  HLA is still under development, however it is clear that
its network requirements will be similar to those of DIS because it must
achieve the same functions as DIS.


2.  DIS network requirements.

a.  real-time packet delivery, with low packet loss (less than 2%), 
predictable latency on the order of a few hundred milliseconds, after
buffering to account for jitter (variation of latency) such that less
than 2% of packets fail to arrive within the specified latency, in
a shared network

b.  multicasting with thousands of multicast groups that can sustain 
join/leave in less than one second at rates of hundreds of join/leaves 
per second

c.  multicasting using a many-to-many paradigm in which 90% or more
of the group members act as receivers and senders within any given 
multicast group

d.  support for resource reservation because of the impracticality
of over-provisioning the WAN and the LAN; it is important to be able 
to reserve an overall capacity that can be dynamically allocated among
the multicast groups
 
e.  support for secure networking, needed for classified military 
simulations


3.  Internet Protocol Suite facilities needed and not yet available 
for large-scale DIS in shared networks.  These derive from the need 
for real-time multicast with established quality of service in a 
shared network.

3.1 Resource reservation available in production systems

The standardized portion of the Internet protocol suite has featured 
only best effort protocols, which do not entail a commitment on the 
part of the network to perform particular quality of service. It is 
likely that simulation exercises using the Internet protocols would 
need to reserve a maximum overall networking capacity that would 
could be dynamically shared among various groups of information 
flows. Information flows will need to be dynamically grouped in 
relation to multicast groups, regions of interest, or some possibly 
some other paradigm as the exercise evolves.  

The Resource reSerVation Protocol (RSVP) is aimed at providing setup 
and flow-based information for managing information flows at pre-
committed performance levels.  This capability is generally seen as 
needed in real-time systems such as the HLA Run Time Infrastructure 
(RTI).  However, RSVP is not fully available in production routers, 
nor has the current experimental version been approved as a Proposed 
Standard protocol within the IETF. The current experimental version of 
RSVP that is available in some routers does not support aggregation 
of reservation resources for groups of flows, nor does it support 
highly dynamic flow control changes.

3.2  Resource-sensitive multicast routing

RSVP provides support only for communicating specifications of the 
required information flows between simulators and the network, and
 
within the network.  Distributing routing information among the 
routers within the network is a different function altogether, 
performed by routing protocols such as Multicast Open Shortest 
Path First (MOSPF). In order to make the overall network function, 
it may be necessary to have a routing protocol that determines paths 
through the network within the context of a quality of service 
requirement.  An example is the proposed Quality Of Service Path 
First (QOSPF) routing protocol.


3.3  IP multicast that is capable of taking advantage of all 
multicast-capable data link protocols

Multicast takes advantage of the efficiency obtained when the network 
can recognize and replicate information packets that are destined to a 
group of locations. Under these circumstances, the network can take on 
the job of providing duplicate copies to all destinations, thereby 
greatly reducing the amount of information flowing into and through 
the network.  

When IP multicast operates over Ethernet in a LAN and all subnets are 
interconnected using the Internet Group Management Protocol (IGMP), 
this is exactly what happens.  However, with the new high performance 
wide-area technology Asynchronous Transfer Mode (ATM), the ability to 
take advantage of data link layer multicast capability is not yet 
available beyond a single LIS.  This appears to be due to the fact 
that (1) the switching models of IP and ATM are sufficiently different 
that this capability will require a rather complex solution, and (2) 
there has been no clear application requirement for IP multicast over 
ATM multicast that provides for packet replication across multiple Logical 
IP Subnets (LIS).

3.4  A hybrid transmission protocol 

In general the Internet protocol suite uses the Transmission Control 
Protocol (TCP) for reliable end-to-end transport, and the User 
Datagram Protocol (UDP) for best-effort end-to-end transport, 
including all multicast transport services.  The design of TCP 
is only capable of unicast use. 

In the HLA environment, three different transport needs have 
been identified: best-effort multicast of most data, lightweight 
reliable multicast of critical reference data, and low-latency, 
reliable unicast of occasional data among arbitrary members of 
the multicast group.  All this takes place with in the same 
large-scale multicasting environment.  Cohen has shown the need 
for these capabilities, while Pullen and Laviano have showed 
the value of integrating these three transport types into a 
single Selectively Reliable Transmission Protocol (SRTP) for 
DIS multicast. Recently the IETF has seen proposals for several 
reliable multicast transport protocols.  A general issue with 
reliable transport for multicast is the congestion problem 
associated with delivery acknowledgments, which has made 
real-time reliable multicast transport infeasible to date.  
Of the roughly 15 attempts to develop a reliable multicast 
transport, all have shown to have some problem relating to 
datagram receipt acknowledgments (ACK), or requesting datagram 

retransmissions through the selected use of negative acknowledgments 
(NAK).  Approaches involving distributed logging seem to hold 
promise for the distributed simulation application.  In any 
event, its seems clear that there is not likely to be a single 
solution for reliable multicast, but rather a number of solutions 
tailored to different application domains.

3.5  Network management for distributed systems 

Coordinated, integrated network management is one of the more 
difficult aspects of a large distributed simulation exercise.  The 
Internet network management techniques have been used successfully to 
support the growth of the Internet for the past several years.  The 
technique is based on a primitive called a Management Information Base 
(MIB) being periodically polled at very low data rates.  The receiver 
of the poll is called an Agent and is collocated with the remote 
process being monitored. The agent is simple so as to not absorb 
very many resources.  The requesting process is called a Manager, 
and is typically located elsewhere on a separate workstation.  The 
Manager communicates to all of the agents in a given domain using 
the Simple Network Management Protocol (SNMP). It appears that SNMP 
is well adapted to the purpose of distributed simulation management, 
in addition to managing the underlying simulation network resources.  
Creating a standard distributed simulation MIB format would make it 
possible for the simulation community to make use of the collection 
of powerful, off-the-shelf network management tools that have been 
created around SNMP.

3.6  A session protocol to start, pause, and stop a distributed 
simulation exercise in an IP network 

Coordinating start, stop, and pause of large distributed exercises 
is a complex and difficult task.  The IETF has developed the 
Multiparty MUltimedia Session Control (MMUSIC) protocol which 
serves a similar purpose for managing large scale multimedia 
conferences.  It is possible that MMUSIC's work could be adapted 
to distributed simulation, although it was designed around a 
multicast environment which requires principally a one-to-many 
transport service.  If MMUSIC adaptation does not prove possible, 
surely the lessons learned in developing MMUSIC could help to 
develop a similar protocol for distributed simulation exercises.

3.7  An integrated security architecture 

A shortcoming of the current Internet Protocol (IPv4) implementation 
is the lack of integrated security. The new IPv6  protocol requires 
implementers to follow an integrated security architecture that 
provides the required integrity, authenticity, and confidentiality 
for use of the Internet by communities with stringent security 
demands, such as the financial community.  The possibility 
that the IPv6 security architecture may meet military needs, 
when combined either with military cryptography or government-
certified commercial cryptography, merits further study.


4.  References

Cohen, D., "Back to Basics", Proceedings of the 11th Workshop on 
Standards for Distributed Interactive Simulation, 1994

DIS Steering Committee, "The DIS Vision", Institute for Simulation 
and Training, University of Central Florida, May 1994

IEEE 1278.1-1995, Standard for Distributed Interactive Simulation - 
Application Protocols 

IEEE 1278.2-1995, Standard for Distributed Interactive Simulation - 
Communication services and Profiles

Pullen, J. and V. Laviano, "A Selectively Reliable Transport 
Protocol for Distributed Interactive Simulation" Proceedings 
of the 13th Workshop on Standards for Distributed Interactive 
Simulation, 1995

RFC1667, "Modeling and Simulation Requirements for IPng"
August 1994

Seidensticker, S., W. Smith and M. Myjak, 
draft-ietf-lsma-scenarios-00.txt, "Scenarios and Appropriate 
Protocols for Distributed Interactive Simulation", work in progress 
(companion Internet Draft)

Zhang, Z., C. Sanchez, W. Salkecicz, and E. Crawley, 
draft-zhang-qos-ospf-00.txt, "Quality of Service Path 
First Routing Protocol", work in progress


5.  Authors' Addresses

  J. Mark Pullen
  Computer Science/4A5
  George Mason University
  Fairfax, VA 22032

  Michael Myjak
  Institute for Simulation and Training
  University of Central Florida
  Orlando, FL

  Christina Bouwens
  ASSET Group, SAIC Inc.
  Orlando FL

Expiration: 25 September 1997