Re: [vwrap] [wvrap] Simulation consistency

[Morgaine <[e-mail]>]

Every design choice results in a trade-off, Vaughn, improving one thing at
the expense of something else.  If every time we offered a service we had to
inform its users about the downsides of all the trade-offs we have made,
they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.  A region
that proxies all content has the "benefit" of acquiring control from the
asset servers over the items in the region, so that it can ensure that
everyone in the region not only obtains the items but obtains the
*same*items as everyone else.  That does indeed provide a greater
guarantee of
consistency than a deployment in which the region only passes asset URIs to
clients who then fetch the items from asset services separately.  As always
though, it's a trade-off, since the proxied design has very poor scalability
compared to the distributed one.

If we're going to warn users of the potential for inconsistency in the
distributed deployment as you suggest, are we also going to warn them of
non-scalability in the proxied one?  I really don't see much merit in the
idea of warning about design choices.  Many such choices are technical, and
the issues are quite likely to be of little interest to non-technical users
anyway.  In any case, the better services are likely to provide such
information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to accept the risk
of inconsistency.  Well that will happen anyway, when services fail and
users get annoyed.  If some asset services refuse to send the requested
items to some users, those services will get a bad reputation and people
will choose different asset services instead.  Likewise, if a world service
proxies everything and so it can't handle a large number of assets or of
people, users will get annoyed at the lag and will go elsewhere.  This user
evaluation and "voting with their feet" happens already with online services
all over the Internet, and I am sure that this human process will continue
to work when the services are asset and region services.

Back in September 2010, I wrote this post which proposes that we use in
VWRAP a form of asset addressing that provides massive scalability at the
same time as a very high degree of resilience --
http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .  It is
based on the concept of the URI containing a host part and a hash part,
where the hash is generated (once, at the time of storage to the asset
service) using a specified digest algorithm over the content of the asset
being referenced.  You may wish to note that if this design were used, the
failure of an asset service to deliver a requested item would result in a
failover request for the item to one or more backup services, using the same
hash part but with a different host address.

This can go some way towards overcoming the problem that you think might
occur when assets are fetched by clients from asset services directly.
Although it won't help when the missing item is available from only a single
asset service, it will help in many other cases, and it will compensate for
service failures and network outages automatically at the same time.

PS. This design for hash-based asset addressing is already being tested by
Mojito Sorbet in her experimental world and client.  It would give
VWRAP-based worlds an improved level of service availability, so I think it
should be a core feature of our protocol.


Morgaine.




===========================

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <[e-mail]>wrote:

> This is a question i discussed with Morgaine off-list a while ago (I
> intended to send it to the list but pushed the wrong button...) I
> think we need to address this problem, and decide how to deal with it.
>
>  In Davids deployment draft, section 7.3.1.1 an overview is given van
> ways to deliver content to the region. One way is only passing a
> capability that allows access to (part of) the resource:
>
>           7.3.1.1.  Content delivery models
>           A range of possible represenations can be passed to a region for
>           simulation. [...] The other end of the delivery spectrum involves
> passing
>           only a URI or capability used to access the rendering
> information and a
>           collision mesh,and related data for physical simulation.
>           In such a model, the client is responsible for fetching the
> additional
>           information needed to render the item's visual presence from a
> separate
>           service.  This fetch can be done *under the credentials of the
> end user*
>           viewing the material [my emphasis--VD] , and divorces the
> simulation from
>           the trust chain needed to manage content.  Any automation
> is done on a
>           separate host which the content creator or owner trusts,
> interacting with the
>           object through remoted interfaces.
>
>  I can see the need for such a setup, however, i feel we are
> unpleasantly close to a situation were the coherence of the simulation
> falls apart.
> In this deployment pattern the region advertises the presence of the
> asset, and *some* clients will be able to get it as expected, while
> -based on the arbitrary whims of the asset service- others might not.
>
> My hope would be that after the asset server provides the region with
> the capability to get the asset, it gives up control. That would mean
> that if the client finds the inventory server is unwilling to serve
> the content - in spire of the region saying it is present-, the client
> should be able to turn around ask the *region* for the asset, (and get
> is after all).
>
>  If that is not the case, -and there are probably good reasons for the
> deployment pattern as described-  shouldn't we *warn* clients that the
> region might be inconsistent, so the users behind the client can vote
> with their feet, (or take the risk)?
>
> --Vaughn
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>