CURRENT MEETING REPORT Reported by Michael Benson Minutes of the Distributed Interactive Simulation (DIS) BOF The meeting was opened by the co-chairs with a round of introductions. 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 by Mark Pullen traced the evolution of DIS from the BBN "Simulator Networking" project (SIMNET). In DIS multiple simulators share state of virtual world via network. DIS is real-time simulation with human in loop. Its goal is to have a seamless simulation environment, reaching ou 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 many thousands of hosts at this rate is a network load of huge proorotions. The sending rate and accuracy must be proportional to the application - training, testing, etc. An important simulation element is semi-automated forces - umanned entities. This is to allow for simulation of larger forces or to provide a virtual enemy. WIth introduction of SAF 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, environmental modeling (NRL is doing). So there is potenttially a big market for IETF products. DIS requirements - - Real-Time: low latency and jitter (jitter can be reduced by buffering so long as the latency is under 100 ms for "tightly coupled" applications such as aircraft in formation. - - Multicasting: each simulator sends to many others - - Resource reservation for shared use of real-time network - - Security for classified exercises / rehersals The above is easy to do on a LAN - hard in a WAN The goal of 100K entities in simulation is highly stressful. Multicast Groups Simplest case: one group per exercise Large Exercises use multiple groups, possibly thousands of them) to reduce tail circuit loading, reduce simulator input Organize groups such that they have common sensor inputs 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: - - Multicast with resource reservation - - Compatible resource sensitive multicast routing - - Use of ATM multicast link layer - - Mixture of unreliable and reliable transport (collision PDUs need to be reliable, multicast may or may not need to be reliable - possible reliable multicast from a paper from Stanford University. RTP / RTP2 doesnt seem to be solution - - Real-time network management (Managing real time networks) - - Session protocol - - Integrated security architecture RFC 1667 Modeling & Simulation Requirements for IPng DoD wants to use commercial networking systems in shared defense nets for M&S -availability, cost and multivendor support Wide geographic dispersion Voice traffic in same network Latency of 100-300ms required worldwide 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 - is it credible for the people involved, seperate accuracy needed for weapons simulation Question about the heteogeneous network traffic delivery -- what does 98% mean? Answer: It means delivering 98% of the packets to the receiver that they are intended for. RFC 1667 Specific Requirements Real-Time (100/300ms with jitter filtered out) Multicast Scalable to hundreds of sites Thousands of groups with thens of thousands of members, each host in hundreds of groups Rapid group membership change (under 1s) Sender and receiver initiated join Resource reservation protects low latency and jitter. Greg Troxel Time synchronization Hosts are time-synched so packets received late are then put into place. DIS has standard of absolute time to UTC. Needs of simulation & Difficulty DIS is not like teleconferencing applications - - all hosts send and receive - - secure environement - - larger number of groups (10^5 is goal) groups could be bounding boxes or grid areas - - indivudual hosts could join many groups - - requires small join time - - relatively few sites A recent test had 7 sites and 1K groups Average number of joins in 1 join/sec DIS QOS requirements - - All receivers are also senders - - Sender needs to know QOS that was obtained application specific backoff preferable to policing or best effort service - - Individual simulators are rapidly switched between groups Desire to gain benefits of statisical mutiplexing across senders and multicast groups (believe 50xBWsim> BW50xsim) - - Fast reservcation setup/teardown time (Steve Deering points out fastest join possible is round trip of a packet; Pullen suggests number of groups may affect join latency; also if sender initiated joins are insisted upon, situation can be worse) DIS QOS Difficulties In RSVP sender doesn't know the true status of the reservation RSVP Session definition doesn't allow sharing across multicast groups Possible extensions: - - Allow multiple sessions to have a single reservation - - Extend session definition to address/prefix instead of address/32 - - RSVP PATH message could keep track of current reservation (ADSPEC?) - - Shared-explicit filter with address/prefix could help make shared reservation across many members of a network, but wouldn't solve sharing across mutiple destination groups. Question: Does reservation latency need to be 100-300ms? Answer: Could have bi-level rerservation... 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, not sure. The IDMR groups provide some data that may be helpful to determining whether or not these ideas are aggregatable. 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 at major modeling and simulation conference, shows growing concern from that community for network issues. M&S Network protocol architecture model description -- Defense applications will be ATM or ride on top of ATM. This approach is network is ATM and to use ATM multicast with IP multicast for local area distribution IP rides over the ATM end to end by achieves effect packet replication by ATM Multicast; requires effective integration of ATM Multicast and IP Multicast IPmc (characteristics) ATMmc 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 for large scale M&S Work ongoing in IETF IP/ATM group. Group pointed out that there will be some testing between CBT and MARS with perhaps PIM - results will be made available. Michael Myjak Simulation Network Management Manage Multiple Interoperable applications Applications: Multipoint to Multipoint Multicast Managers are point to multipoint communications environment - - Highly interconnected LANS connected to WANs - - Typically 1 simulation management and logger per site - - Multiple (sometimes) viewers (stealth, wav) Logging in DIS - - Easy to do on a LAN - Dump to disk - - This does not leave the ability to filter non-dis traffic off the LAN. Logger now evaluates every packet. Problem is time used in encodding means it misses packets. Another problem is that when this is connected to a WAN then you will miss packets from other sites and logs from other sites can not be integrated because of loss packets and timing mis-matches. A working type solution may be to use absolute time-stamp. Audience comments: latest demos are showing this is true (Troxel); need to filter technology down to users (Pullen) Need to work on manager to manager solutions -- agreement for time to start, etc. 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). How should IETF and DIS-CAS work together (group discussion) Discussion of ATM vs IP / IP Multicast. DoD is using ATM as a global 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 in IETF is needed, including which Area it would fall into. Because this BOF was organized on short notice it will be necesary to do this at a future meeting, March or June. A reasonable goal would be producing infomrational RFCs showing how DIS can use IETF poroducts as they emerge. DIS-CAS is doing this now under IEEE standards but the products are two years behind the technologies due to the slowness of standards porocess. DIS might choose to turn RFC's into IEEE stanrad but the IETF products would happen first. Some working group is needed to do this, DIS-CAS does not have enough networking talent. However DIS-CAS could bring the defense applications expertise to IETF, if they are funded to attend teh DIS working group then they can also attend various groups that concern them such as RSVP, INTSERV, IP/ATM, etc. This would be a reasonable thing to try, bu tthere must be a defined output for the working group. It is very easy to disband working group if there is not enough interest (commenbt by Deering). Agreed to set up an email alias ietf-dis@gmu.edu, will advertise it to attendees at this BOF. An archive and a possible web site for this group will also be considered. Consnsus of working group is to proceed with a more structured BOF NOT on a Friday, advertise also non-military uses (ie gaming business medical).