Transcript SimulationAsAServicex

Simulation as a Service,
Scalability, and
Network
Architectures
Don McGregor
Research Associate
MOVES Institute
[email protected]
Simulation Deployment Models
• How are simulations currently deployed?
• How will they be deployed?
• What are the impacts on scaling
simulations?
2
Simulation Deployment: Now
3
Simulation Deployment: Now
• Compiled C++/Java code installed on a
desktop
• The desktops are mostly local network, or
possibly multiple-site but connected via
TCP/IP
• Can exploit broadcast and multicast—the
networking gear helps scalability
4
Current Problems
• It’s expensive and inflexible to deploy
desktop applications
• It’s expensive to upgrade or even just
update
• High management costs
• Upgrades are slow to come because of the
above (often multi-year product life cycles)
5
Web Applications
Web Browser
Cloud Lives Here
6
Web Applications
• The business trend is to use web-based applications rather
than desktop applications
– Fast deployment of new software—update once on server, use on
web browser, faster life cycles (sometimes days or hours)
– Much cheaper
– Exploit cloud on server side
– Mobile devices welcome, agile across multiple architectures
(Linux/Windows/Android/IOS etc)
• But
– Less capable than compiled applications (not as bad as you might
think)
– Some UI issues since it’s running inside a web browser
7
Web Applications
• The economics of this are compelling, as a
quick survey shows
– Few write desktop mail applications anymore—
gmail, Google Calendar, etc
– Enterprise apps are mostly web based
– Google Docs & Office Online vs. MS Office
Desktop (limitations of the genre)
8
Cloud
• One thing that makes web apps compelling
is the cloud
9
Cloud
• There are economies of scale for data
centers, which drives the cost of compute
cycles and storage down
• At the limit, CPU and disk are free and
infinite on the cloud (OK, not quite, but close
and trending that way)
• Able to flexibly get more when needed,
scale down when not needed
10
Simulation as a Service
• So, change the business model. Enables
rental of simulation services from the cloud
instead of buying & installing applications on
the desktop
– Can still do it the old way if you like, and own
the server software, run on a government cloud
• Analogous to Software as a Service
– MS Exchange, Office Web Apps, Google Docs
11
Scalability for Simulations
• Simulations are different from office
applications
• If you send an entity position update,
potentially that has to go to all other
simulation participants
– In a virtual world “My position is (17, 23, 42)”
may have to be sent to every other participant
12
Network Updates
(x,y,z)
On a LAN or some WANs we can use broadcast or multicast
to prevent having to send out N-1 repeats of the message
13
Scalability
• In web networking technologies there is no
broadcast or multicast. Everything is unicast
– Websockets (TCP), WebRTC (UDP) Javascript
in the web page
• This means we need other techniques for
what is called Area of Interest Management
(AOIM) or Data Distribution Management
(DDM)
• We can’t rely on the networking gear to do
this for us, as with bcast or mcast
14
Scalability
• This moves the needle away from peer-to-peer
architectures (classically DIS and HLA) and
towards client-server architecture, since P2P often
relies on bcast and mcast
15
Scalability
All the packets are flowing through the server a
single server probably can’t handle it. That’s the bad
news. But:
• We have infinite CPU and disk on the server side,
because that’s on the cloud, if we parallelize across
multiple hosts
• We can examine each packet and make decisions
about what to send to each client. This reduces the
bandwidth used and client load
16
Scalable Client-Server
Application servers
(clustered) do DDM
Databases
Web Server
(can be clustered)
Web Resources
(maps, open
source data, etc)
Existing Simulations
Clients
Cloud (server side, free and infinite CPU and storage)
17
Scalable Client-Server
• The clients connect over unicast, send and receive all
updates unicast
• All updates go through the server side and can be
examined on the server side
• Existing simulations and protocols can be gateway’d
• The DDM/AOIM can be spread across multiple CPUs on
the cloud side. This lets us do elaborate and
computationally expensive DDM on the server side. 
CPU efficiency is not important on the cloud side
• This doesn’t address latency
18
Server-Side DDM Thoughts
• Flexibility is more important than efficiency
• Scripting languages such as JavaScript are
flexible; use this for a DDM language?
NodeJS? Javascript executed from Java?
• Perhaps the client can generate the filter
scripts for the packets it desires and send
these to the server
• Unknown: what is the effect on latency?
Needs an instrumented example to
investigate
19
Server-Side DDM Thoughts
• This is oriented towards DIS, but exactly the
same problems occur in HLA; RTI
implementations for the web will face the
same issues
• Likewise with WebLVC
• The economic benefits of cloud-based
simulation are likely to be so compelling that
25 year old assumptions about P2P DoD
protocols may need to be rethought
20
Server-Side DDM
• In general, the superior economics of the cloud and webbased simulation drive simulation to client/server over
peer-to-peer
– Possible issues with bandwidth, latency mean likely limited to
ashore and small-to-medium virtual environments
– Mashups with open source internet data sources—live feeds, map
data, GIS data….
• Optional changes to business model—buy vs. rent
simulation software
• Plenty of techniques for having existing and web-based
sims co-exist
• It’s a worthwhile research topic
21