1 / 14

XMSF Network Group Status

XMSF Network Group Status. Working assumptions: The simulation will not be confined to individual networks either private networks individual ISPs Application should not be media-aware Must be able to run over the public Internet

tyrell
Download Presentation

XMSF Network Group Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. XMSF Network Group Status • Working assumptions: • The simulation will not be confined to individual networks • either private networks individual ISPs • Application should not be media-aware • Must be able to run over the public Internet • without this, can’t achieve the benefits of XMSF to commercial industry • so defense can’t enjoy them either! • Scalability and resilience are essential in XMSF

  2. Precondition for Success • Leaders and workers from the three major technical areas (Web, Internet, M&S) must work as a coordinated team • with effective (human) interfaces among all elements • we have learned that it does not work to “throw it over the wall” ! • solutions need to work end-to-end

  3. Network QoS: meets a specified or negotiated standard for: • capacity, latency, jitter, loss in a statistical sense • can be done today in general terms within individual ISP networks • also Internet-wide by proactive path selection • a workable approach to defining consistency needs of applications * • e.g. does the application need to know order of sending • this requires translation from application requirements to network capabilities • must define acceptable tradeoff between reliability and latency in a parameterized form * • if a negotiated solution, mechanism(s) for negotiation needed • could be different for global and local negotiation • we don’t know how to do Internet-wide QoS negotiation * early work project

  4. M&S needs to be able to characterize network requirements • and the impact if the requirements are not met • this implies they must be measured and understood * • cannot assume any-to-any communication • firewalls and network address translation (NAT) get in the way • application or middleware should be able to adapt to take advantage of changing network capacity* • implies higher layer must be aware of available capacity • must define security requirements: • authentication • denial of service protection • confidentiality • auditing • integrity

  5. Many-to-many multicast • trend is away from providing this as a network layer capability • no good business model • one-to-many may become available • must define requirements for reliability* • e.g. selectively reliable/real-time, fully reliable/non-real-time • it is impossible to have fully reliable/real-time multicast • identifying and responding to congestion is a requirement • it will be necessary to support M&S needs for networked group communication over non-multicast network layer*

  6. In general the simulation network could be an overlay network* • for example, virtual private network (VPN) • allows an ISP or the Internet to meet specialized requirements of M&S • Need a capability for end-to-end network status & performance monitoring* • this also can be done in an overlay network • Standardize on over-the-net protocols • riding over standard Internet protocols • proven basis for enabling interoperability

  7. Need capabilities to deal with multi-sensor systems: • streaming with low buffering latency • coordinating groups of sources • Need a mechanism for dealing with policy-based filtering technology • firewalls and Network Address Translation (NAT) • routing policy filters • possibly a well-known port that can be approved by management

  8. Missing/problematic critical middleware • real-time object request broker • authentication/authorization services • real-time directory services • group coordination/synchronization • session coordination likely is not a problem • Session Initiation Protocol does signaling • automated setup/teardown still needs attention • XML needs a mechanism for network transfer • e.g., Simple Object Access Protocol (SOAP)

  9. Implementation Questions • NTP and/or GPS will be needed to provide synchronized network time for XMSF • GPS is more accurate and can be used to synchronize a local NTP master • We believe that Grid and Cluster style network computing will accommodate XMSF without modifications • as long as network capacity is sufficient • A dedicated and monitorable test environment would accelerate development of an XMSF community • use Next Generation Internet networks (Abilene, DREN, etc.) • must be adequately funded for operation • don’t try to take it “out of hide”

  10. What We Believe is Available • QoS and multicast can be provided on a private-network basis (probably in NGI) • Performance available off-the-shelf: • individual flows to ~100 Mbps • latency under 100 ms one-way in North America • jitter manageable by buffering, increases latency ~10% • packet loss <1% • High performance end-to-end with instant startup is practical as long as reliable delivery is not needed • TCP does not scale well to wide-area flows above 100 Mbps • Good global synchronization via NTP/GPS • secure NTP may be required in some cases

  11. What We Believe is Achievable • QoS on a multi-network basis (but not Internet wide) • the problem is the business case, not the technology • Multicast through overlay networks • VPN • middleware providing application-transparent multicast • Enhanced performance for digital libraries through caching • individual flows ~1 Gbps by localizing access • does not apply to dynamic data exchanged by simulations • Reliable multicast for bulk data transfer

  12. Questions for the Symposium at GMU • Who owns the problem of taking up the XMSF challenge? • What sort of forum is best for communication among Web, Net, M&S? • how do you get the right mix of people to participate? • How can distributed learning environments be exploited to help? • What industry and academic activities are ongoing in XMSF? • What sort of DoD programs are likely to engage the XMSF opportunity?

  13. Models for Cooperation Among Web, Net, and M&S • Organization model: • A new organization that incorporates all of them • Government program model: • A major DoD program that funds them to work together to create solutions • Conference model: • A forum for cooperation and exchange of information • Focus on solving real problems in XMSF

  14. A “Hello World” Exemplar for XMSF • Distribute a Java-based HLA simulation over the Web • Web group provides interface technology and setup/scenario coordination • Net group provides connectivity • despite firewalls • M&S group provides the simulation • Demonstrate at a highly visible event • Make the pieces available for the community experimentation

More Related