CURRENT MEETING REPORT Reported by Mark Pullen, George Mason University Minutes for the Distributed Interactive Simulation BOF (DIS) 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? o IP multicast/RSVP/IntServ-Greg Troxel o IPmc/ATMmc-Mark Pullen (for Susan Symington) o 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 the loop. Its goal 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 many thousands of hosts at this rate is 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-unmanned 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 and even a potentially worldwide area. A lot of people feel DIS is likely to be commercialized as entertainment; it also could also be used in FAA, medical simulations, and environmental modeling (NRL is doing). So there is a potentially big market for IETF products. DIS requirements o 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) o Multicasting: each simulator sends to many others o Resource reservation for shared use of real-time network o Security for classified exercises/rehearsals 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 and to reduce simulator input. Groups should be organized so that they have common sensor inputs. Receiver initiated joins are considered a security problem (there was audience interaction here, and it was pointed out that an authenticated receiver join may solve the problem. Others felt that an authenticated join may not be sufficient). One problem is the security issue is imposed by federal security agencies, thus it may not be the solution that the IETF would generate. Under some circumstances, group joins may happen at rates of hundreds per minute. 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-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 RFC 1667 Modeling & Simulation Requirements for IPNG o DoD wants to use commercial networking systems in shared defense nets for M&S availability, cost and multivendor 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. Question: What does 98% mean in relation to heterogeneous network traffic delivery? Answer: It means delivering 98% of the packets to the receiver for whom they are intended. RFC 1667 Specific Requirements: o Real-Time (100/300ms with jitter filtered out) o Multicast Scaleable to hundreds of sites o Thousands of groups with tens of thousands of members, each host in hundreds of groups o Rapid group membership change (under 1s) o Sender and receiver initiated join o Resource reservation protects low latency and jitter. Greg Troxel noted that in relation to 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 o all hosts send and receive o secure environment o larger number of groups (10^5 is goal) o groups could be bounding boxes or grid areas o individual hosts could join many groups o requires small join time o relatively few sites A recent test had 7 sites and 1,000 groups o Average number of joins in 1 join/sec DIS QOS Requirements o All receivers are also senders o Sender needs to know QOS that was obtained 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 and multicast groups (believe 50xBWsim> BW50xsim) o Fast reservation 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, the sender doesn't know the true status of the reservation. The RSVP Session definition doesn't allow sharing across multicast groups. Possible extensions: 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 reservation latency need to be 100-300ms? Answer: Could have bi-level reservation...or lots and lots of reservations. Question: (Dino Farinacci_) In relation to using group state, is DIS able to aggregate group state? Answer: There seems to be no good answer for this: it is hard to do. 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, which was presented recently at a major modeling and simulation conference, shows growing concern from the community for network issues. o 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 o Need IPmc/ATMmc Interface for large scale M&S o Work ongoing in IETF IP/ATM group. The Working Group pointed out that there will be some testing between CBT and MARS with perhaps PIM. These results will be made available. Simulation Network Management This was a presentation by Michael Myjak discussing the management of multiple interoperable applications and multipoint to multipoint multicast. Managers are point to multipoint communications environment o Highly interconnected LANS connected to WANs o Typically 1 simulation management and logger per site o Multiple (sometimes) viewers (stealth, wav) Logging in DIS o Easy to do on a LAN - Dump to disk o 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. Comments included how the latest demos are showing this is true (Troxel). Also noted was the need to filter technology down to users (Pullen). The need to work on manager-to-manager solutions was discussed and the agreement for time to start, etc. was noted. Comments from the group included the fact that the telephone works all the time and ATM does not (Troxel) and also how Internet is no longer doing dynamic routing. For this reason multicast tends to work better than unicast (Deering). o How should IETF and DIS-CAS work together? (group discussion) Various other discussion points included: o ATM vs IP/IP Multicast o DoD is using ATM as a global solution, so DIS is challenged to find a way to use ATM o DoDŐs attempt to buy an IP solution-something that this is probably beyond the DIS community's influence Discussion led to the conclusion that an organized approach to DIS in IETF is needed, and there was additional discussion as to which area this would fall under. Because this BOF was organized on short notice, it will be necessary to do this at a future meeting. A reasonable goal would be producing informational RFCs showing how DIS can use various IETF products as they emerge. However, because of the slowness of the standards process, DIS-CAS is now doing this under IEEE standards which are two years behind the technologies. DIS might choose to turn RFC's into IEEE standard, but the IETF products would occur first. A working group is needed to do this, for 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 the 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, but there must be a defined output for the working group. Other comments o It is very easy to disband working group if there is not enough interest. o Agreed to set up an email alias ietf-dis@gmu.edu, will advertise it to attendees at this BOF. o An archive and a possible Web site for this group will also be considered. o Consensus of working group is to proceed with a more structured BOF NOT on a Friday, and to also advertise also non-military uses such as gaming business medical.