[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.