Re: [vwrap] [wvrap] Simulation consistency

[Izzy Alanis <[e-mail]>]

> As always though, it's a trade-off, since the proxied design has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated region,
every other client is going to (could and should be trying to) hit the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally).  Every asset server has to be scaled up
to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of simultaneous
users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard?  It's going to cost $, but is
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.




On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
<[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>