[ogpx] Decoupling simulation services from land for VWRAP scalability

Morgaine <morgaine.dinova@googlemail.com> Thu, 11 March 2010 18:59 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFB43A6BE0 for <ogpx@core3.amsl.com>; Thu, 11 Mar 2010 10:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.087
X-Spam-Level:
X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j5+AFDaqaQd for <ogpx@core3.amsl.com>; Thu, 11 Mar 2010 10:59:32 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 883B03A6F8C for <ogpx@ietf.org>; Thu, 11 Mar 2010 10:33:40 -0800 (PST)
Received: by wwb29 with SMTP id 29so239560wwb.31 for <ogpx@ietf.org>; Thu, 11 Mar 2010 10:33:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8MgH8ds+3cmNlOORAZPEHfT/KWoT2HxfID+eI9518DU=; b=RkCn05/1WuLd1Vr6kuUZWllIcIYopoVaD8Yo+hvOsc3IWW5UauZchs8w9W83b0Ywbt QqgEIjVzNTou4XPTmjMs0RKOd3cBtswou5y8FugK58m1cqIRzWt51Sn3Dl1ADnq9VeO7 4Cik1hpO9Py0gMudHpbkEklQHzSa3ukrnw3n0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=p/vR/uZ1v3AeZa//6cJ3p4DuGM9NFHnCObUOKcJJEM76GfB6TO2nQiq8kilPzEdf41 +xWkBQaHU8pxOHc/NUTwaXK/77Aj+KsI6XUX0qQ+qkCpSdsMzrSH56awP3zytxHQ6rgA McfzDc4gvrGVXZt9QfZnYlJIaIEvqzt6u1t6Y=
MIME-Version: 1.0
Received: by 10.216.86.16 with SMTP id v16mr2254699wee.162.1268332421687; Thu, 11 Mar 2010 10:33:41 -0800 (PST)
Date: Thu, 11 Mar 2010 18:33:41 +0000
Message-ID: <e0b04bba1003111033s6289daf7tc477fb1a4315085e@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="0016e6d588b973aa3704818aa79b"
Subject: [ogpx] Decoupling simulation services from land for VWRAP scalability
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 18:59:34 -0000

After a very interesting presentation on the
MXP<http://www.bubblecloud.org/>protocol given to us by Ben Lindquist
/ Arkowitz Jonson in-world in Second
Life yesterday, we were discussing in the AW Groupies IM channel how
simulations in VWRAP-compatible worlds might be made more scalable.
Intriguing MXP'ish ideas kept appearing in the discussion, as I'll describe.

VWRAP has *decoupling of services* at its core.  This gives it the
flexibility to offer multiple deployment patterns, as well as the
scalability that stems from distributing load across multiple remote
services instead of centralization.  Unfortunately, so far most VWRAP
discussion has implicitly held to an SL-like region model in which *land
service* is tightly coupled to *simulation service*, which has a negative
impact on the scalability of regions.  In the worst case scenario that we
have today, regions are completely non-scalable over the number of
*actors*in the region, because region simulators are monolithic in
their current
implementation.  There has to be a better way.

(I'm using "*actor*" to mean anything that is subject to physical
simulation, hence mainly agent/avatars and in-world objects.)

MXP has "perfect scalability" proportional to the number of actors in a
region, because it has no centralized simulation.  Instead it employs the
notion of "participants" that each do their own simulation locally, plus
central "hubs" which reflect or replicate the contribution of each
participant to all other participants in the shared space.  It should be
noted that while MXP's hubs are conceptually a shared resource, they are
stateless and hence present no practical barrier to achieving high
scalability in the simulation.  (Limits to actual scaling imposed by network
bandwidth continue to apply of course.)

Although MXP's local participant simulation is hugely scalable in this way,
it clearly lacks an essential ingredient that we have come to expect of VWs,
namely environmental simulation / physics in the shared space.

Our AW Groupies discussion led rather naturally to service decoupling.  Why
not make *simulation* a VWRAP service as well, and decouple it from the
region's *land* service?  This could open up a number of opportunities for
more scalable deployments.

If simulation were a VWRAP service, we could split simulation into two
parts, independently scalable:


   - *Actor simulation service* which allows each actor to simulate its
   internal state.  This actor simulation could be running on a supercomputer
   cluster for scientific research applications, or on an agent's PC to
   simulate the avatar's mannerisms or dance (*agent actor*), or on a world
   provider's machinery for persistent in-world behaviour (*object actor*).
   A flexible region would typically provide access to at least two actor
   simulation services, one for agent actors and one for object actors.  The
   choice of where the actor simulations run would be a matter of world
   deployment policy and user selection.  This correlates quite well with the
   MXP notion of "participants".


   - *Environment simulation service* which handles simulation of the
   environment in the shared space.  This is most concerned with physical
   simulation in traditional regions that emulate the real world, and deals
   only with the bounding box and centre of gravity of actors, *NOT with
   their inner actor simulations*.  Non-physical types of environment
   simulations would also fit in this category --- for example
*magic*simulation might well be very popular in some types of virtual
world.  Since
   this simulation is performed as a service, it doesn't need to run as an
   integral part of a VWRAP region, but instead could be performed externally
   in a distributed manner if higher scalability is required --- that would be
   a deployment choice.


Being independently scalable, these two service types (three actual
services) would no longer be restricted by the resources available within
the region.  *Agent actor simulation* would scale perfectly 1:1 with the
number of online clients, *object actor simulation* would scale in whatever
manner the chosen object service provides, and the scalability of *environment
simulation* would depend on the deployment pattern and services chosen by
the region provider.

It's worth noting that Second Life and Opensim already have a slight hint of
an *agent actor simulation service* --- they call it animation! :-)  This is
a terribly limited facility though, being based on replay of pre-packaged
pose and animation files.  Replacing animation by local simulation reflected
by the region (with animation as a subset) would open up the doors for
hugely more powerful types of expression using the full local power of
multiple cores as well as OpenCL.  Noteworthy projects such as the IEEE's AI
Learning Center <http://ailc.agstechnet.com/>and many others in education
would benefit greatly, as would accessibility work and "bots" in general.

On the *object actor simulation* front, opening up object simulation as a
service would remove the need for regions to run their own object simulation
/ scripting infrastructure.  It would also remove the constraints imposed by
regions running a standard beginner-friendly object simulation service
alone, so scientific, industrial and educational simulation would benefit
greatly.  It is worth mentioning that Opensim provides a range of
alternative scripting / programming systems, including MRM Script, MRM
Loader and Region
Modules<http://maimedleech.com/2009/05/12/opensim-programmability/>which
can take object actor simulation into very ambitious territory.

Factoring out simulation from land services would allow advances on all
these fronts, independent of advances in region technology.


Morgaine.