Distributed Interactive Simulation
DIS-Java-VRML Working Group


click for Dis-Java-VRML home page

Meeting Minutes: November 20, 1997

  1. Location.
    Alturus Inc. Broadcast VR. 408.557.6743 office
    NASA ATCC 408.557.6786 fax
    650 Saratoga Avenue www.alturus.com
    San Jose, California 95129 ... Thanks Alturus for break refreshments and lunch!

  2. Attendees.
    Don Brutzman Naval Postgraduate School brutzman@nps.navy.mil 408.656.2149
    Bill Enright Y Is Up bill@yisup.com 510.758.7292
    Ronan Fauglas Naval Postgraduate School fauglas@stl.nps.navy.mil 408.656.4970
    Nermeen Ismail Philips Research nermeen@pipa.philips.com 415.864.4233
    Mark Jean Alturus mjean@alturus.com 408.557.6743
    Mike McCarthy Naval Postgraduate School mccarthy@cs.nps.navy.mil 408.656.4077
    Don McGregor Naval Postgraduate School mcgredo@stl.nps.navy.mil 408.656.3680
    Mark Pullen George Mason University mpullen@gmu.edu
    Mike Smithwick Alturus smithwick@alturus.com 408.557.6716
    Marcy Stahl ThoughtLink mstahl@thoughlink.com 650.949.0716
    Scott Riggins Alturus riggins@alturus.com 408.557.6770
    Harry Taxin TEN/Alturus hmtaxin@ix.netcom.com 650.962.9696

  3. Overview of DJV objectives. An extended discussion about DIS, the dis-java-vrml (DJV) library, motivations and group goals. Primary points:

  4. Related VRML Consortium (VRMLC) working groups (WGs). Lots!

  5. Intellectual Property (IP) policy. Because NPS is part of the U.S. Government, we have unique copyright status: government works can not be copyrighted, by NPS or any other company. Thus NPS code can't be "hijacked" away from DJV users.

    Our IP policy is pretty simple: free for academic, private or commercial use, as long as the NPS and the DJV group receives acknowledgement, and no money is charged to users. Essentially the same as Gnu CopyLeft.

    We will not add any contributed code to the DJV library that can't abide by these restrictions. Therefore no licenses or encumbrances will be permitted.

  6. Status of code library. Don McGregor provided a PowerPoint slide set. Summary follows.

    bridging multicast into the browser

    We talked about current problems with CLASSPATH inconsistencies between browsers. An interesting point was brought up: if the DJV work eventually becomes a VRML Recommended Practice (RP), the class path might change from mil.navy.nps.dis.* to vrml.dis.*. This would suggest that a consistent directory structure for all vrml.* classes is important. This comment has been passed to vrml-script working group.

    Although scheduled, the timetable for a RP proposal was not discussed. Basically we need to get everything running and a lot of testing started first. Conceivably a RP proposal might be ready for the VRB by next summer.

  7. PDU relay server demo. Mike McCarthy provided an Entity State PDU (ESPDU) multicast-unicast relay server demo - receiving PDUs from Monterey - and a corresponding PowerPoint slide set.

    His PDU generator provides multicast PDUs, with world-wide scope (time-to-live ttl=127) from Monterey, at a rate of 1 PDU per 2 seconds (0.5 Hz). Mike then showed a multicast <=> unicast relay bridge: he dialed up via modem from Alturus over a standard (unicast-only) PPP link phone line, connected to the relay bridge server, which converted multicast PDUs from the campus backbone and sent them down the phone line as unicast PDUs. It worked very well!

    The relay bridge technique gives us a lot of flexibility. We can use multicast when directly connected to the Internet multicast backbone (MBone), or use unicast over other links (such as modems and LANs not connected to the MBone). So far, Mike has gotten twenty simultaneous read-only clients connected to the server without utilization problems, which is a good start. Server-based approaches often can scale to the low hundreds (but rarely much more).

    We will also look at having multiple groups running at once, where a group = (multicast address + port) combination. Mike has configured half a dozen 386/486 PCs with Linux to act as PDU generators and multicast-unicast PDU relay servers. It is worth noting that these bridging and relaying techniques are similar in functionality to an area-of-interest manager (AOIM) which handles group management. This will be an important area for future work when we start scaling up.

    Next steps: getting this program to work both reading and writing, and making the PDU relay bridge the default connection technique for new users visiting the DJV site. Note that this approach sidesteps the entire signed applet issue (which is good). We expect that users and authors will be able to connect to a multicast scene without installing the DJV library. Only software developers will need the software distribution.

    A diagram showing the multicast-unicast PDU relay server follows.

    multicast-unicast PDU relay server

  8. Streaming. Possibilities for streaming VRML via DIS were discussed several times. Interesting ideas include:

  9. Time and timestamp issues. There are several time and timestamp-related problem areas. Simultaneity/cheating is a semantics issue, getting clocks synchronized is a deployment chore, and deciding on timestamp payload formats is a representation issue.

    Specification Data type Payload Start time Reference
    DIS   32 bits microseconds since top of hour (?!), but start time varies widely in practice IEEE 1278.1 (DIS spec) section 5.3.31
    Java java.util.Date (long) 32 bits milliseconds since January 1 1970 00:00:00 GMT java.util.Date
    VRML 97 SFTime (double) 64 bits seconds since January 1 1970 00:00:00 GMT VRML 97 5.10 SFTime
    ISTP   32 bits milliseconds since start of week ISTP section 12.1
    NTP / SNTP two unsigned fixed-point numbers (integral and fractional) 64-bit seconds relative to 0h on 1 January 1900 RFC-1305, RFC-2030 section 3
    RTP   32 bits related to NTP, but actually is media dependent RFC-1889 sections 4 and 5.1
    RTSP   32 bits related to RTP/NTP, but actually is media dependent draft-ietf-mmusic-rtsp-05.txt

    The Interactive Shared Transfer Protocol (ISTP) at www.meitca.com/opencom/istp.html is a virtual world communications API recently issued by Mitsubishi Electric Research Laboratory (MERL). Originally designed in parallel with the Scalable Platform for Large Interactive Networked Environments (SPLINE) project, ISTP is intended for large-scale virtual world communications. The ISTP time convention is a pretty good one since representing a week's worth of milliseconds requires 31 bits. Thus different hosts can still establish valid timestamp ordering despite clocks with errors up to 3 days apart.

    NTP and SNTP are the primary references for time data used on the Internet. From SNTP RFC-2030 section 3: "Since NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established. NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order can be set to 0."

    The Real-time Transport Protocol (RTP) at ds.internic.net/rfc/rfc1889.txt is a light-weight header prepended to most multicast streams running on the MBone. It is likely we will need to devise an RTP Profile for DIS. This probably needs to be a user-selectable feature to provide legacy interoperabity (after all, DIS is an over-the-wire protocol that is completely concerned with bit formats). Addition of an RTP header can provide compatibility with multicast network monitoring tools for performance measurement and troubleshooting. Within restrictions posed by sections 4 and 5.1 of the RTP RFC, media-dependent variations are allowed. Perhaps the 32-bit RTP time field can be used, in combination with the 32-bit DIS timestamp and a suitable start-time convention, in order to provide a reasonable conversion into 64-bit VRML SFTime.

    The draft Real-Time Streaming Protocol (RTSP) at ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-05.txt is essentially a protocol that passes commands similar to a VCR remote control for starting/stopping/pausing/resuming media streams. RTSP is usually (but not necessarily) associated with RTP. RTSP has a variety of time formats and for absolute time specifies ISO 8601 (??) timestamps using Universal Time Code (UTC) Greenwich Mean Time (GMT).

    A few additional details can be found in earlier e-mail messages by Don McGregor. The big challenge here will be resolving differences between DIS and VRML in a way that is compliant with both specifications.

  10. Recent ADI work plus JVerge. Chris Thorne and Justin Couch provided two excellent overview messages on recent work by ADI and recent progress with JVerge, specifically commenting on applicability to DJV. Surprisingly, we ran out of time to discuss them. Sorry guys. The messages are forwarded to the DJV list for comment and archiving.

  11. VRML 98. At the VRML Symposium in Monterey next spring, Don Brutzman & Don McGregor plan to provide a half-day tutorial on DJV followed by a half-day DJV working group meeting. Likely date: Monday February 16. A multiuser DJV demo is planned for the Wednesday night Demo SIG - we will want some PDUs arriving from remote sites around the world. VRML 98 registration is now open on the VRML 98 home page at ece.uwaterloo.ca/vrml98/

  12. IETF LSMA. Mark Pullen of George Mason University presented a PowerPoint slide set on the Internet Engineering Task Force (IETF) Large-scale Multicast Applications (LSMA) working group. This is an important area of related work. (Thanks for flying out from Washington, Mark!)

    Three pertinent IETF Draft Request For Comments (RFCs) of interest are

    Another pertinent area of work is the Internet Research Task Force (IRTF) www.irtf.org. The Reliable Multicast (RM) research group www.east.isi.edu/rm/ is working on transport-layer distribution mechanisms that might be useful for DIS traffic.

    DJV is a candidate for building large-scale multicast application (LSMAs) that may also benefit from reliable multicast (RM). Our future testing results will likely be interesting to a variety of network research engineers.

  13. Web site, documentation and configuration management. Ronan Fauglas presented a PowerPoint slide set (also in PostScript) about his planned work as a visiting student at NPS over the next two months.

  14. Future research. Don Brutzman discussed virtual reality transfer protocol (vrtp) and dial-a-behavior protocol (DBP) using a PowerPoint slide set prepared for the recent VRMLC Summit meeting.

  15. DJV library testing holes and testing plans. Discussion deferred.

  16. Schedule plans.

    Dates Times Event Location Details
    Tuesday DEC 16 1-5 PM DJV Working Group Alturus
    San Jose
    New demonstrations, how sites can get MBone connectivity, test plans, VRML 98 preparations, etc.
    Tuesday DEC 16 7-9:30 PM VRML SIG Bay Area 15-minute presentation on DJV
    Thursday DEC 18   Conformance / Interoperability WG Bay Area Work expected on CLASSPATH problem
    January ?   DJV Working Group Alturus
    San Jose
     
    Monday FEB 16 8:30-12 AM DJV Tutorial VRML 98 Monterey "How to DIS your VRML"
    Monday FEB 16 1-5 PM DJV Working Group VRML 98 Monterey  
    Wednesday February 18 8-10 PM Demo SIG VRML 98 Monterey 5-minute multiuser demo

  17. Action items and planning. We had a stimulating extended discussion. Mark Jean will write this up, possibly as a Functional Requirements Document. He'll use the perspective of DJV group members (not just us NPS maniacs).

    Corrections and comments regarding these minutes are welcome.

    All in all, a great and productive day. Thanks everybody for contributing.

    Respectfully submitted, Don Brutzman


12 January 98
URL: devo.stl.nps.navy.mil/dis-java-vrml/meetings/97november20/minutes.html
feedback: brutzman@nps.navy.mil & mcgredo@stl.navy.mil