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

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

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Jim Whitehead: "Mailbox of ietf-dis: another DIS transport protocol..."
Previous message: Jim Whitehead: "Networking and Telecommunications Area Exam Reading List (Draft)"
Next in thread: Eve Schooler: "Re: Minutes from the IETF DIS BOF, Dallas - 12/95"

This is a multi-part message in MIME format.

--------------4D67308020B1
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
Handley.

Eve, why didn't you say something?

Architectural Considerations for a New Generation of Protoc
-------

--------------4D67308020B1
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
tml"

<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 (mpullen@cne.gmu.edu) 
Fri, 9 Feb 96 15:20:15 EST

<ul>
<li> Messages sorted by: <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>

<li> Next message: <a href="0003.html">MML : "subscribe"</a>
<li> Previous message: <a href="0001.html">Mark Pullen: "Test"</a>

</ul>

For those who missed this draft earlier: 
====================================================================== 
DRAFT MINUTES, IETF Distributed Interactive Simulation 
(DIS) BOF 
Dallas IETF Meeting, 8 December 1995 0900-1130 
Mark Pullen and Michael Myjak, Co-Chairs 
Minutes: Michael Benson 

NOTE 
This is a rather long set of minutes but because the BOF was the 
last session held on the last day of the IETF meeting, we expect there 
may be people who could not attend and would appreciate this level of 
detail. 

The meeting was opened by the co-chairs with a round of introductions. 

The people attending were: 

William Babson 
Michael Benson 
Steven Blake 
Carsten Bormann 
Ken Carlberg 
Steve Deering 
Dino Farinacci 
Ross Finlayson 
Walter Lazear 
John Linn 
David Marquardt 
Michael Myjak 
Alan O'Neill 
Kazuhiro Okanoue 
Mark Pullen 
Michael St. Johns 
Gregory Troxel 
Theodore Wolf 
 
The following agenda was proposed and accepted: 

1. What is DIS and why should the IETF care - Mark Pullen 
2. What Internet technologies does DIS need? 
- IP multicast/RSVP/IntServ - Greg Troxel 
- IPmc/ATMmc Mark Pullen (for Susan Symington) 
- Simulation Network Management - Michael Myjak 
3. How should IETF and DIS-CAS work together - general discussion 

The first presentation was made by Mark Pullen and traced the 
evolution of DIS. Mark began with a discussion of the BBN "Simulator 
Networking" project known as SIMNET. In DIS, multiple simulator hosts 
share a common state of the virtual world interconnected via a 
communications network. DIS is a real-time "Virtual World" simulation 
typically characterized as having a "human in loop". A goal of the 
DIS community is to have a seamless simulation environment, reaching 
out to include "constructive" command post simulations and "real 
world" instrumented ranges. DIS requires a constant stream of packets 
from each simulator in the range of .5 pps to 15 pps. Even with 
compression, connecting many thousands of hosts at this data rate 
generates a network load of huge proportions. The sending rate and 
accuracy must be proportional to the application - training, testing, 
etc. 

An important simulation element is semi-automated forces or SAF. SAFs 
are unmanned entities which interact with other entities. This is to 
allow for the simulation of larger forces (then would be feasible in 
person) or to provide a virtual enemy to interact with. With the 
introduction of SAFs, it is possible for network loads to reach 50 to 
100 million bits per second over a wide area, potentially worldwide. 

A lot of people feel DIS is likely to be commercialized as 
entertainment; it also could also be used in FAA, medical simulations, 
or environmental modeling (NRL is doing this). So there is potentially 
a big market for IETF products in this area. 

DIS requirements : 

o Real-Time: low latency and jitter (jitter can be reduced by 
buffering so long as the latency is under 100ms for "tightly 
coupled" applications such as aircraft information.) 

o Multicasting: each simulator sends to many others 

o Resource Reservation for shared use of real-time network 

o Security for classified exercises and/or rehearsals 

The above is easy to do on a LAN - but very hard to do in a WAN 
environment. The goal of 100K entities in simulation is highly 
stressful. 

Multicast Groups: 

The simplest case is one group per exercise. This is essentially the 
small broadcast-based environment under which SIMNET was developed. 
However, large exercises require the use of multiple groups (possibly 
thousands of them) to reduce simulator input and reduce tail circuit 
loading. Groups may be organized in a variety of different ways (for 
example: one group may have common sensor inputs, while another may be 
terrain-based). 

Receiver initiated joins are considered a security problem (there was 
audience interaction here, pointed out that an authenticated receiver 
join may solve the problem, others felt that an authenticated join may 
not be sufficient. Problem is the security issue is imposed by federal 
security agencies, may not be the solution IETF would generate. Under 
some circumstances group joins may happen at rates of hundreds per/min 
In some cases security requires sender-initiated multicast group join. 

DIS needs advances from IETF: 

o Multicast with resource reservation 

o Compatible resource sensitive multicast routing 

o Use of ATM multicast link layer 

o Mixture of unreliable and reliable transport (collision PDUs need 
to be reliable, multicast may or may not need to be reliable). 

o possible reliable multicast from a paper from Stanford University. 
RTP / RTP2 doesn't seem to be solution 

o Real-Time network management (Managing real time networks) 

o Session protocol 

o Integrated security architecture 

References to RFC 1667 were made. 

Modeling & Simulation Requirements for IPng 
DoD wants: 

o to use commercial networking systems in shared defense nets for 
M&S because of availability, cost and multi-vendor support 

o Wide geographic dispersion 

o Voice traffic in same network 

o Latency of 100-300ms required worldwide 

o 98% packet delivery 

Question: What to do for 2% of lost packets? 

Answer: Send full state in every packet, smooth at the receiver using 
dead reckoning. 

When used for training, the question is whether it is credible for the 
people (the interactors) involved. There is also the issue of a 
separate accuracy needed for weapons simulation then for other 
entities. 

Question: What about the heterogeneous network traffic delivery and 
what does 98% mean? 

Answer: It means delivering 98% of the packets to the receiver that 
they are intended for within some predefined time frame (say, 
100milliseconds). 

RFC 1667 documents some of the specific requirements, others are 
listed in the IEEE 1278.2 standard, such as Real-Time communications 
with 100/300ms with jitter filtered out. Multicast address groups for 
DIS need to be scaleable to hundreds of sites, supporting thousands of 
groups with tens of thousands of group members. Each host can maintain 
membership in hundreds of groups. Rapid group membership change 
(under 1s, prefer under .5s) need to be supported. 

Note that these are Sender and Receiver initiated joins, not just 
receiver initiated as in current RSVP protocol work. Resource 
reservation should prevent low latency and jitter. 



Next Presentation: Greg Troxel on Time synchronization; 

Hosts are time-synched so that packets received late can be put into 
place; in the order intended. DIS has a standard of absolute time 
which is synchronized to UTC. Needs of modeling & simulation 
community are not without some degree of difficulty. 

DIS is not like teleconferencing applications (!) 

o All hosts send and receive 

o DIS optionally requires a secure environment 

o Larger number of host groups (10^5 is goal) 

o Host groups could be based on bounding boxes or grid areas or other<?> 

o Individual hosts could join many groups 

o Group interaction requires small join time (<< 1sec) 

o Generally relatively few WAN sites participating 


A recent test had 7 sites and 1K groups (for example) with the average 
number of joins running about 1 join/sec (note: data was computed from 
recent RITN work). 


DIS QoS requirements: 

o All receivers are also senders 

o Sender needs to know QoS that was obtained 

o Application-specific backoff preferable to policing or best 
effort service 

o Individual simulators are rapidly switched between groups 

o Desire to gain benefits of statistical multiplexing across 
senders (i.e. aggregation) 

o and multicast groups (believe 50xBWsim> BW50xsim) 

o Fast reservation setup/tear-down time also necessary 

Note: Steve Deering points out that the fastest join possible is the 
round trip time of a packet. Mark Pullen suggests that the number of 
host groups may affect join latency (as tables grow large); also if 
sender initiated joins are insisted upon, then the situation can 
possibly become worse. 

DIS QoS Difficulties: 

In RSVP sender doesn't know the true status of the reservation. RSVP 
Session definition doesn't allow for sharing across multicast groups. 
Some possible extensions are: 

o Allow multiple sessions to have a single reservation 

o Extend session definition to address/prefix instead of address/32 

o RSVP PATH message could keep track of current reservation (ADSPEC?) 

o Shared-explicit filter with address/prefix could help make shared 
reservation across many members of a network, but wouldn't solve 
sharing across multiple destination groups. 

Question: Does what does reservation latency need to be? 
Question: Is 100-300ms adequate? 

Answer: Could have bi-level reservation... or lots and lots of 
reservations. Question: (Dino Farinacci) Using group state -- is DIS 
it able to aggregate group state? No good answer for this: hard to do, 
in general, we're not sure. The IDMR groups provide some data that 
may be helpful to determining whether or not these ideas are 
aggregated. 

IETF Multicast / ATM Multicast 

Slides by Susan Flynn Symington of MITRE, presented briefly by Mark 
Pullen. 

Example application: Distributed Interactive Modeling and Simulation 

This talk was presented recently (by Susan Symington) at a major 
Modeling and Simulation conference. It shows growing concern from the 
M&S community for network issues. The M&S network protocol 
architecture model description provides that defense applications will 
be ATM (or ride on top of) ATM. The initial ATM network approach is 
to use ATM multicast with IP multicast for local area distribution. 
IP datagrams will ride over the ATM infrastructure "end to end". The 
desire is to achieve effective packet replication by using ATM 
Multicast. This does however, require effective integration of ATM 
Multicast and IP Multicast. 

Mark then showed the following slide, which indicates the disconnect 
between IPmc and ATMmc: 

IPmc (characteristics) ATMmc (characteristics) 
Omnidirections Unidirectional 
Multipoint to Multipoint Point to Multipoint 
Peer Group Oriented Root/leaf Oriented 
Connectionless Connection Oriented 
Group Addressing Individual ATM Endpoint Addressing 

Need IPmc / ATMmc Interface to be compatible for large and small scale 
M&S usage. 

Noted: Work is ongoing in IETF IP/ATM group, but consensus on these 
issues is not a given (nor clear). 

The group pointed out that there will be some testing between CBT and 
MARS with perhaps PIM (sparse mode) - results will be made available. 


Next Presentation: Michael Myjak on Simulation Network Management 

Requirement: To manage multiple interoperable applications 

Simulation applications can be viewed as a multipoint to multipoint 
multicast communication source. Simulation network managers are point 
to multipoint communications Environment. 

Typically, simulation network management includes: 

o Highly interconnected LANs connected to WANs 

o Typically 1 simulation management and logger per site 

o Multiple (sometimes) viewers (stealth, wav) 

o Also controls simulation applications (simulators, loggers, etc.) 


Example simulation management problem: Logging in DIS - Easy to do on a LAN: 

simply dump ethernet to disk. Problems: This does not leave the 
ability to filter non-DIS traffic off the LAN. 

Example application for SIMAN: Data Loggers. Loggers currently 
evaluate every packet; which is wasteful. Problem is time used in 
encoding means logger generally misses a few packets (potentially 
critical ones). Another problem is that when this is connected to a 
WAN then you will miss packets from other sites due to dropped-packet 
filtering. in addition, logs from other sites may not be integrated; 
requires absolute time references and better throughput efficiency. A 
working prototype solution may be to use absolute time-stamp as 
documented in the DIS standard, IEEE-1278.2. 

Audience comments: latest demos are showing absolute timestamping can 
solve logger problem (Troxel); need to filter this technology down to 
users (Pullen). 

Comment: Still need to work on the manager to manager solutions -- 
agreement for time to start, stop, resume, etc. needs to be handled at 
lower layers. 

Comments from group: the telephone works all the time and ATM does not 
(Troxel); Internet is no longer doing dynamic routing --for this 
reason multicast tends to work better than unicast (Deering) because 
dynamic routing is still being explored/experimented. 

How should IETF and DIS-CAS work together (group discussion)? 

Discussion of the ATM vs IP / IP Multicast. 

DoD is using ATM as a global COTS solution, so DIS is challenged to 
find a way to use ATM. Some felt DoD should try buying an IP solution 
but there was general recognition this is probably beyond the DIS 
community's influence. Discussion led to conclusion that an organized 
approach to DIS within the IETF is needed, including which area DIS 
participation would fall into. 

Because this BOF was organized on short notice it will be necessary to 
repeat this BOF at a future meeting, March or June. (note: June in 
Montreal was the consensus). 

A reasonable goal for a DIS WG would be to produce informational RFCs 
showing how DIS can use IETF products as they emerge. DIS-CAS is 
doing this now under IEEE standards process but the products are two 
years behind the IETF technologies due to the slowness of standards 
process. DIS might choose to turn RFCs into IEEE standards but the 
IETF products would still happen first. 

Some working group is needed to do this; DIS-CAS does not have enough 
networking talent within to accomplish these goals. However DIS-CAS could 
bring the defense applications expertise to IETF, if they are funded to 
attend the DIS working group within the IETF. Then they can also attend the 
various other groups that are a concern to the DIS community (such as RSVP, 
INTSERV, IP/ATM, etc.). This would be a reasonable thing to do/try, but 
there must be a defined output from the IETF DIS working group. (Note that 
it is very easy to disband a working group if there is not enough interest 
(comment by Deering). 

The DIS BOF members agreed to set up an email alias ietf-dis@gmu.edu, 
and will advertise it to attendees at this BOF. An announcement will 
also be posted through regular IETF channels. An archive and a 
possible web site for this group will also be considered. Consensus of 
the working group is to proceed with a more structured BOF NOT on a 
Friday, and to advertise this through non-military uses (i.e. gaming, 
entertainment, business, medical, etc.). 


<ul>

<li> Next message: <a href="0003.html">MML : "subscribe"</a>
<li> Previous message: <a href="0001.html">Mark Pullen: "Test"</a>

</ul>

--------------4D67308020B1--

Next message: Jim Whitehead: "Mailbox of ietf-dis: another DIS transport protocol..."
Previous message: Jim Whitehead: "Networking and Telecommunications Area Exam Reading List (Draft)"
Next in thread: Eve Schooler: "Re: Minutes from the IETF DIS BOF, Dallas - 12/95"