xmsf network group status

14
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

Upload: tyrell

Post on 05-Jan-2016

41 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 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

• 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

Page 2: XMSF Network Group Status

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

Page 3: XMSF Network Group Status

• 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

Page 4: XMSF Network Group Status

• 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

Page 5: XMSF Network Group Status

• 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*

Page 6: XMSF Network Group Status

• 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

Page 7: XMSF Network Group Status

• 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

Page 8: XMSF Network Group Status

• 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)

Page 9: XMSF Network Group Status

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”

Page 10: XMSF Network Group Status

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

Page 11: XMSF Network Group Status

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

Page 12: XMSF Network Group Status

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?

Page 13: XMSF Network Group Status

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

Page 14: XMSF Network Group Status

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