Re: [vwrap] [wvrap] Simulation consistency

[Dahlia Trimble <[e-mail]>]

I can see another reason to allow the region to proxy assets, or at least
some service to proxy assets in the same domain as the region. "Sandboxed"
clients such as those which may be based on products as Unity3d or Adobe
Flash may be subject to a "same origin" policy (1), where they may be
restricted from making network connections outside of the domain from which
the application is served. There are workarounds but they may require
additional administration overhead for both asset and region service
providers, or a separate provider which proxies all traffic. I would hope a
VWRAP protocol definition would include the possibility of regions proxying
assets so such sandboxed clients can play a part in a VWRAP multiverse.

(1) http://en.wikipedia.org/wiki/Same_origin_policy



On Sat, Apr 2, 2011 at 8:09 AM, Morgaine <[e-mail]>wrote:

> Vaughn, I left your final (and very important) point for the end of my
> response, and then I fired off my email without addressing it ...  Sorry. :P
>
>
> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[e-mail]>wrote:
>
>>  So I want methods to prevent breaking my highly emergent world as much as
>> possible.
>>
>
>
> Yes indeed!!!
>
> You have a perfectly reasonable requirement for the service that you want
> to operate, and you need some means of meeting it.  I agree with that
> wholeheartedly.  I only begin to disagree when you hint that your
> requirement must be imposed on everyone, whether they want it or not.  That
> I cannot support, and I expect that you did not mean it that way anyway.
> After all, some of my requirements are probably not of interest to you
> either, and you would not wish me to impose them on you.  It cuts both ways.
>
> So, how can we enable you to offer a service with many 9's of simulation
> consistency, without imposing that requirement on those who prefer a
> different trade-off?  You hinted at the solution yourself, so I'll merely
> elaborate on it.  You wrote:
>
>
>
> I would like to argue that the region *should* get the capability to fetch
>> all details. [...]  Note that this does not mean that the region *has* to
>> proxy the asset, just that in case the asset service refuses to serve a
>> client it does not like, the region can insist on delivery  based on the
>> capability it originally got.
>>
>
>
>
> Perfect.  All you need then is an optional query in the protocol that
> allows a region to ask each asset service referenced by assets carried by
> newly arriving avatars the following question:
>
> QUERY: "*Do I have your permission to fetch from your asset service the
> assets normally reserved for client fetches, and to distribute these assets
> to clients directly in the (unexpected) event that I want to?*"
>
>
> That easily maps to an optional capability request of course.  If the asset
> service answers "No" to you, then you can deny the incoming avatar entry to
> your region, returning a status that indicates
>
> RESPONSE: "*Asset service X referenced by asset Y does not meet the
> re-distribution requirement requested for entry to region Z*".
>
>
> Your requirement is then satisfied (I believe) without imposing that
> requirement on a region operator who does not need it because they desire a
> different trade-off.  Those who don't have your requirement simply won't
> request the capability.
>
> For example, it would be pointless to even ask an asset service founded
> entirely around Creative Commons assets that question, since all CC content
> is perpetually and non-revocably redistributable by anyone and to anyone.
> By not issuing the query we can save ourselves the round-trip time and allow
> faster entry to the region.
>
> Would something like that get the nod from you?
>
>
> PS. You need to note that when an asset service answers "Yes" to your
> query, this does not mean that it will necessarily honor its promise when
> you actually attempt to fetch items.  David's very important point about
> independent parties not having control over each other applies here.  You
> can at most hope that it will behave well, and perhaps test the promise by
> fetching something.  However, if you truly want as many 9's of consistency
> as is obtainable then you will have to fetch all the assets yourself prior
> to allowing entry to the avatar, and that would be a dreadful overhead.
> Most people will probably settle for "*best effort*" approaches, which are
> quite likely to succeed.
>
>
> Morgaine.
>
>
>
>
>
> =====================
>
>
> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <[e-mail]>wrote:
>
>> Morgaine, Meadhbh,
>>
>> Thanks for the answers, but i see that i have not been clear enough.
>> I think the protocol should demand certain things to prevent the
>>  deterioration of the simulation to an unacceptable level. We need to be
>> more precise to prevent problems and i think we can.
>>
>> I was arguing from the perspecive of a region service without making that
>> explicit. Note i was *not* advocating the region proxies everything, just
>> that it lives up to its promises about object presence. Also note that i do
>>  *not* always have the option to pick another high quality asset service,
>> since I normally do not own the assets. I will use Prokofy as an example
>> just for the fun of it.  He is highly worried about content theft, so (in
>> the unlikely case he wants to start selling stuff outside of SL) he might
>> use this deployment pattern.  Assume he sells wonderful sexy dresses to two
>> customers, that can only be fetched from his own asset service for
>> rendering. Both customers go off to "Vaughns highly immersive world" were a
>> party is given.  My region receives some physics properties of the dresses
>> for simulation and an address of Proks asset service for high-res details
>> and textures. In this case the region does not even get the capability to
>> fetch the assets, just a link to the asset service and its up to viewer to
>> request the details and show credentials to get them. The two girls meet,
>> both their viewers request the details of the other dress, and Proks asset
>> service grants those requests. They girls admire their dresses and
>> compliment each other with their good taste. Now when i arrive and my viewer
>> request the dress details, Prok's asset service recognises me as the
>> copyleftists that i am. It refuses to serve the asset details -and depending
>> on my viewers behaviour i might get to view two girls in sexy underwear -or
>> wearing even less- instead of party dresses. From a consistency point of
>> view this is a highly undesirable situation, it breaks immersion, and
>> depending on the circumstances might also be embarrassing to the people
>> involved.
>>
>> The key question is if we want to allow this situation to arise within
>> VWRAP compliant worlds.
>> I would like to argue that the region *should* get the capability to fetch
>> all details. In other words, Prokofy would have to give up some control over
>> the asset in case he allows it to be used by my region. Note that this does
>> not mean that the region *has* to proxy the asset, just that in case the
>> asset service refuses to serve a client it does not like, the region can
>> insist on delivery  based on the capability it originally got. If that fails
>> Proks asset service can not be called VWRAP compliant.
>>
>> If Prokofy does not want to relinquish  that level of control, fine, it is
>> his right not to, but in that case the dresses should not be allowed to get
>> into my region in the first place.  If people visit my region and find
>> themselves naked in the eyes of some others *I* will get the blame.  As
>> Morgaine says, the technical details of my innocence will not convince the
>> general public. So I want methods to prevent breaking my highly emergent
>> world as much as possible.
>> My proposal would be that the whatever the region gets MUST be guaranteed
>> by protocol to be delivered to  anybody within the region requesting it. If
>> the asset service does not want to serve a cryptocomunist copyleftist, fine,
>> but IF it has given the region a capability, it MUST serve the full asset to
>> be VWRAP compliant. Its *my* choice as a region deployer to download the
>> full asset to be able to guarantee region consistency if I want to. I will
>> try to avoid that as much as possible, but if my customers complain, i will
>> be forces to start doing this for certain asset services that i know show
>> discriminatory behaviour against for instance copyleftist.
>>
>> Finally Morgaine, you keep hammering on the fact that proxying by the
>> region does not scale. (I tend to disagree, but that is beside the point
>> here). I do agree the asset should not be needlessly transfered, but i
>> strongly feel we must insist in the protocol on transferring the *rights* to
>> view the asset. If that leads to to the region not getting the asset at all,
>> so be it, it can warn visitors that their assets will not be visible and
>> even offer to serve simple replacements (1). This in turn will encourage the
>> end users to avoid this type of asset service, and Prokofy will go out of
>> business, as should be the case given the behaviour of the service. And if
>> he pulls it off, thats fine with me also, as long as i do not have to suffer
>> from it due to lack of rigour in the protocol specs.
>>
>> So, in summary, I very well see that there is no way to enforce consistent
>> serving behaviour but it should at least be clear that it is non-standard
>> and not conform the protocol. The way I am understanding you now, your
>> argument seems to be just one step to far in the direction of anarchy.
>> Or am i misreading you?
>>
>> --Vaughn
>>
>>
>> (1) I just realise that the region might cheat and advertise its own asset
>> brands claiming the competitions assets  could not be rendered... Oh well,
>> one might hope that if there is enough choice in worlds such regions will be
>> forced  out of business as well.
>>
>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <[e-mail]>wrote:
>>
>>> Further to my last post, it's worth noting that if you find that you
>>> suffer poor quality behavior from a particular asset service and it is
>>> breaking the consistency of your simulation, with hash-based item addressing
>>> you can also automatically use an alternative asset service *in
>>> preference* to the one specified in a given URI.
>>>
>>> Your client could be configured to attempt the item fetch at a known good
>>> quality asset service *first* (perhaps one that you paid to use because
>>> of its better service), automatically, and maybe even dynamically depending
>>> on the type of item.
>>>
>>> The scheme has a long list of benefits, and overcoming (to some extent)
>>> poor quality asset services is just one of them.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>> ===================
>>>
>>>
>>> On Sat, Apr 2, 2011 at 4:55 AM, 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
>
>