Subject: [mmox] A tentative top-down analysis

From: Jesrad <[email-masked]>
Date: Thu, 26 Feb 2009 16:34:30 +0100

As an answer to Catherine's call for more top-down views of the MMOX
project to complement the bottom-up approach, here is a collection of
thoughts on MMOX as viewed from afar:

What exactly, deep down to the bottom line, is the function that a VW executes ?

=> it establishes data links (or at the very least signals links to be
established) between virtual entities residing on a vast number of
networked machines so they can interact.

At the core, a VW is a ROUTER. A number of these special routers also
include their own "network endpoints" supporting entities specific to
the VW (like a combat stats database, an inventory server, etc.), for
specific forms of interaction, but as far as interoperability goes
these are particular cases of a more general layout (for example SL
residents may set up their own combat stats databases for other SL
residents to use, the case which will interest us later is whether
access to a VW combat stats server should be uniform across all
interoperable grids).

In the context of interoperability of grids, we must treat each grid
itself as a node of a relatively small P2P network. There is no
"supergrid" nor any central "interoperability to go" service for
existing grids to plug into as registered clients, nor will the be in
any foreseeable future. Thus, the interoperability protocol has to be
a decentralized protocol.

(this means it will need decentralized discovery, for one, since we
probably do not want to limit the protocol to hand-coded, static
cross-grid links)

The routing mechanism of this protocol is dictated by the inner
routing that the VWs realize on their own inner network. In many cases
a Virtual World mimicks functions of the real world in the way it
opens and destroys links between entities, for example entities each
have a location in the virtual world, and if two entities have
locations that are close enough then a link of "mutual presence" is
opened between them (whether this "presence routing" is done centrally
or is distributed has no impact at the interoperability level, since
centralized VWs will use a central gateway while P2P VWs will
implement it in the nodes - only the MMOX endpoints change here). This
is the minimal interaction which is universal to all "worldy"
entities. There are other forms of interaction that not all entities
are capable of, like collision, chat, left-mouse click, edition
request or Fire Magic attack, and the set differs between VWs.

(because it extends this mechanism, the interoperability protocol has
to transport the universal, common interaction "routing" services like
this "mutual presence": it must provide the necessary signalling for
opening and closing down relevant links between the entities across
grids - and though that sounds a very pedantic way of stating the
obvious it still goes better with actually saying it)

VWs also have non-realistic mechanism of establishing routes/links
between entities: entire kinds of interaction are disconnected from
the consideration of world "physical" presence. Instant messaging and
other forms of real-time, synchronous or asynchronous communication
(be it IM, monetary transfer or VoIP streams) between entities are
social-based instead of geography-based.

(this fully justifies the decision to split Agent and Region domains,
so that forms of interaction based on presence don't get mixed up with
interaction forms based on social ties: each kind follows a different
routing model. So far I see no other domains than these two, but then
maybe Delivery could be one if MMOX also defines the exchange or
push-through of content, identity and money between grids - that would
make HyperGrid the first example of a Delivery Domain service)

Of course, there needs to be some way to distinguish between the
entities that constitute a VW in order to address them at the MMOX
level and authenticate/accept their transmissions. For those entities
that represent people (us invaders from meat space) this implies a
general identity authentication system. That one was a given already,
but it's worth mentioning here because it fits as a particular case of
a wider mechanism that also identifies all the other (non-meat space)
entities of the VW: this consideration should remain in our minds when
we discuss OpenID, OAuth and other schemes - servers/objects/Scripts
may want to chat/transfer inventory/animate objects cross-grid, too !

To sum up so far, if I'm not mistaken:
- MMOX is a decentralized P2P routing protocol with automatic
discovery and at least two different routing schemes for Agent/social
and Region/geo domains of interaction, and possibly a third for
Delivery/Exchange,
- the routes established by the MMOX protocol will tunnel the VW's
services encapsulated in MMOX datagrams through the grids' limits
(whatever the centralization/distribution of those services inside
each grid, which only changes the endpoints)
- MMOX datagrams address specific entities of specific grids in a
uniform way (with auth) so significant work is needed to come up with
a good common denominator of an addressing scheme, that works well
with the discovery service(s) retained
- PDUs of Region/geo services are transported to all the relevant
entities that are mutually present (hence the seperate routing
scheme), while PDUs of Agent/social services are routed according to
specific social info (groups, etc.) and PDUs of other domains
(Delivery ?) are treated in yet another way.

Question: do each domain (Agent, Region, Delivery) requires its own
distinct discovery service ? I tend to think yes, but I'm unsure and
confused.

---

From: Morgaine <[email-masked]>
Date: Thu, 26 Feb 2009 17:33:04 +0000

A very good top-down analysis, Jesrad.

> probably do not want to limit the protocol to hand-coded, static

The above deserves underlining in red, because pre-interop VW providers
(especially large ones) typically think of themselves as operating
centralized services of the web kind, but this mental model actually breaks
down in the expanded metaverse.

As the interoperating metaverse grows, providers can no longer think of
customers' clients as performing short-lived accesses to their servers and
then going away to access someone else's servers.  Instead, N providers may
be supplying continual object state updates for the items owned by an agent
who is not registered with any of them.

What's more, those updates will often need to continue even when (i) the
avatar is currently offline, and when (ii) the items are dispersed across
many other worlds, and when (iii) the avatar is currently in a world with
which they do not have direct interop.

The last point is particularly revealing:  provider A may have an explicit
agreement to interoperate with provider B, and provider B may have an
agreement with provider C, without A and C having any direct agreement
whatsoever.  Yet, an avatar registered on B and wearing an unencumbered
object from A will naturally be visiting world C, and the worn object must
continue to fulfil its normal purpose or interop has failed.

The pattern of activity seen by VW providers is clearly going to be very
different to that seen in centralized web scenarios where consumers and
communication endpoints have a 1:1 mapping.  Instead it will be much closer
to the random mesh of connectivity typical of P2P networks.

> make HyperGrid the first example of a Delivery Domain service)

I see several other domains that should operate independently to free
metaverse inhabitants from the tyranny of tied choices.  Starting with the
first two for completeness, my minimum list would be:

   1. Agent Domain (entry point for some agent-oriented services)
   2. Region Domain (stateless world simulation services)
   3. Communication Domain (groups, IM, PM, various transports)
   4. Object Domain (storage of interoperable objects and avatars)
   5. Execution Domain (delivery of power to OD objects)
   6. Geographical Domain (terrain and topology services)
   7. Fiscal Domain (everything to do with VW currencies)

Decoupling the various services in this way means that all parties involved
can pick and choose the best providers in each category, instead of having
to live with the misery of (say) failing IM or non-scalable regions that
another party could do better.  This is as much a benefit for VW providers
as for VW inhabitants, because subcontracting a service to a specialist can
very often be more cost effective than reinventing the wheel in-house and
poorly.

Morgaine.

On Thu, Feb 26, 2009 at 3:34 PM, Jesrad <[email-masked]> wrote:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 11:07:25 -0800

Morgaine wrote:
> As the interoperating metaverse grows, providers can no longer think 
> of customers' clients as performing short-lived accesses to their 
> servers and then going away to access someone else's servers.  
> Instead, N providers may be supplying continual object state updates 
> for the items owned by an agent who is not registered with any of them.

That's right! Incidentally, this matches almost exactly the "connected 
server peers" model that I've been proposing.

However, the objects themselves are owned by one of those N providers 
(or else why is the provider supplying authoritative state for it?)

>
> What's more, those updates will often need to continue even when (i) 
> the avatar is currently offline, and when (ii) the items are dispersed 
> across many other worlds, and when (iii) the avatar is currently in a 
> world with which they do not have direct interop.
>

Saying that the object update persists in the simulation when you don't 
have interop with the viewer is like saying that you can browse the 
YouTube video library when you have disconnected your Internet 
connection. I don't think that would be realistic.

> The last point is particularly revealing:  provider A may have an 
> explicit agreement to interoperate with provider B, and provider B may 
> have an agreement with provider C, without A and C having any direct 
> agreement whatsoever.  Yet, an avatar registered on B and wearing an 
> unencumbered object from A will naturally be visiting world C, and the 
> worn object must continue to fulfil its normal purpose or interop has 
> failed.
>

Agreed!

> metaverse inhabitants from the tyranny of tied choices.  Starting with 
> the first two for completeness, my minimum list would be:
>

I think this grouping is as good as any I've seen on this list so far. 
Thank you for putting it in reasonably clear terms, which I feel I have 
not managed to do myself!

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Fri, 27 Feb 2009 00:22:01 +0100

> (or else why is the provider supplying authoritative state for it?)

But I want to own my data :-) I might give you a license though to host 
it for me. But actually I should also be able to host my own inventory 
and simply give you the URL to it (which in fact might be a simple web 
server).
So there could even be simple hosting servers which are dumb regarding 
the whole VW thing and simply host objects without ever doing any 
simulation.
And I can simply put those URLs into my users's service catalogue to be 
discovered by some simulator.

> connection. I don't think that would be realistic.

Well, I can browse my podcast collection. It's just a question of how 
you define caching.

>> worn object must continue to fulfil its normal purpose or interop has 

Well, we thought a bit about this chaining of trust (if it comes to the 
creator's will) and it might be problematic depending on what choices 
you want to give the user and the creator. As a creator you then can 
never be sure where that object goes. But it's maybe mainly a question 
if you allow it to leave the originating VW or not. If you choose not to 
you are more safe apparently than if you choose to allow it (but might 
make more sales).
But of course from a technical perspective I agree. It should 
potentially work in C.

-- Christian

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 15:33:37 -0800

Christian Scholz wrote:
> Jon Watte schrieb:
>
>> That's right! Incidentally, this matches almost exactly the 
>> "connected server peers" model that I've been proposing.
>>
> But I want to own my data :-) 

Sorry, I'm confusing the terminology here. The server "owns" the object 
in the sense that it is the authoritative source of property values for 
that object. I did not mean to imply any ownership in the IP sense, 
because that discussion does not apply to the particular technical 
details we're talking about; it's handled at a different layer.

> And I can simply put those URLs into my users's service catalogue to 
> be discovered by some simulator.
>

Unfortunately, simulators use different scripting languages, execution 
environments, APIs and architectures. Thus, you may be able to have a 
dumb server (like a web server), but it could only serve an object to, 
say, a Second Life-compatible server, or a Metaverse-compatible server, 
unless the behavior of the object was re-developed for each simulation 
platform.

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Fri, 27 Feb 2009 00:37:36 +0100

> details we're talking about; it's handled at a different layer.

Ok, we should define some terminology at some point anyway.

> unless the behavior of the object was re-developed for each simulation 

Or it could provide different versions. Sort of like content negotiation.

-- Christian