Re: [vwrap] [wvrap] Simulation consistency

[Vaughn Deluca <[e-mail]>]

I wrote:
>The region can now tells the agent service which of the assets agent
service requested transfer the avatar can bring.

I meant to say:

The region can now tell the agent service which of the assets the agent
service requested transfer for, can actually be transfered.

(its late here...)

On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca <[e-mail]>wrote:

> Morgain, all,
>
> Ahha!, i was halfway my reply explaining that i was *not* asking for the
> impossible, and did *not* want to impose my rules on others, but that i just
> wanted to be able to know that stuff that i get into my region will be
> visible to everybody present, and now i see that you got that. Good!
> We are on the same page again :)
>
> The way the draft relating tot the tourist model is now written i can
> *never* be sure my visitors all get the same data, because i just juggle the
> crude physics representation, and the viewers negotiate about anything else
> with the asset service, fully out of my control.
>
> You formulated a solution (requesting the transfer rights explicitly).
> I was originally thinking of a solution where the protocol specifies that
> the capability to get the crude physics representation of the asset in my
> region would be *automatically* give me the right to download the full asset
> (if I asked for that).  After reading your replies i now see that requesting
> the transfer rights, just like like the viewers will do, is a better
> solution. The same protocol messages could even be used, The region present
> its credentials and either gets the capability or not.  The region can now
> tells the agent service which of the assets agent service requested transfer
> the avatar can bring. Its up to the viewer to deal with that information, it
> might simply ignore it. In the latter case the avatar will be simulated by
> the region without the offending asset. The asset service will subsequently
> get requests from all viewers connected to the region for the assets in the
> region. Some of those might not pass trust checks of the asset service. Bad
> luck for the asset service, it has given a capability to the region and the
> region will use that to get the asset. If the asset service has second
> thoughts to often - causing download costs and lag, it will eventually end
> up on the black list of the region service, and next time around the region
>  might tell the agent service it can't allow asset Y from servivce X becasue
> it does not trust assert service X.
> It all sounds logical and transparent to me.
>
> It also fits what meadhbh said:
> >my recommendation has always been... "define mechanism, not policy."
> As far as i can see that is what we do here.
>
> Now, this brings me to a point of order. In september Kevin Tweedy made
> this observation:
>
> "<kevin.tweedy at xrgrid.com>
> Date: Wed, 22 Sep 2010 13:40:15 -0400
> May I suggest we stop arbitrarily trying to define things in emails and
> come up with some kind of process into how to define what the first draft
> specification should include?  Doesn’t W3C have a process on how this works?
>  I think this is the fundamental problem of this group; we are mixing
> vision, requirements, and design in the same email.  We are making design
> decisions when we haven’t even defined the requirements."
>
> I fully agree. We used to brainstorm in the group and assumed the editors
> of the drafts would incorporate the generated ideas in new versions of the
> draft.  At times that worked really well, at other times it did work not so
> well. But currently we have no editors, so we need to do something new....
>
> My question to the group is how do we consolidate this bit of discussion?
>
> In general it seems to me we have managed to generate new enthusiasm in the
> group, and we are on -or close to- the  point were we have enough critical
> mass to continue. In my view we would really benefit from a true editor, and
> it seems nobody is willing to take that responsibility yet. Can we really do
> it collectively on the wiki? It would be a break with the way i think ietf
> groups normally work, but i might be  kind off fitting for this highly
> diverse group  :)
>
> So will it work? What alternatives do we have?  comments please.
>
> --Vaughn
>
> On Sat, Apr 2, 2011 at 5:09 PM, 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>