Re: [vwrap] [wvrap] Simulation consistency

Dzonatas Sol <dzonatas@gmail.com> Sun, 03 April 2011 03:20 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CED53A690F for <vwrap@core3.amsl.com>; Sat, 2 Apr 2011 20:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level:
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4FREr-Arn9m for <vwrap@core3.amsl.com>; Sat, 2 Apr 2011 20:20:16 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CECCB3A690B for <vwrap@ietf.org>; Sat, 2 Apr 2011 20:20:14 -0700 (PDT)
Received: by iwn39 with SMTP id 39so5475207iwn.31 for <vwrap@ietf.org>; Sat, 02 Apr 2011 20:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IRpxK8WiyCnF3c1WN+YPF661KaK6rjYt/3A1XBrFe+4=; b=Fvb001ENJKK/l8cxhxL5juT6HvD6a56jFZKJMwAeLZKw2oW7gkvLZRKX8K3fczK1v5 dLUiNWAvf/N6gS3PBXteeISF5kREWo6/DoZzPzT8LGMk72njsy7N0GDd2oN6sJ3jEWR2 kmOAuWNkM0q3RkYTMx/crir/QSWLp3BVggVnE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MMpOz1LJ401OSwKoZ742NC1aW60GQHn9VMDk3htzIbQRvF/57+XFkM/RfEp3TRBgQH NHkMQYRnh0xMFaa4UUuykjuVUody4QXJiyWLpJth0SJ8fGp5obnSVa4qF4452iIsGeoU p/KH67HGc5yR+Mw/3gF62EiVOF/jpYQr+Qn8Y=
Received: by 10.42.131.6 with SMTP id x6mr3641886ics.30.1301800914364; Sat, 02 Apr 2011 20:21:54 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm2441186icb.4.2011.04.02.20.21.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 20:21:53 -0700 (PDT)
Message-ID: <4D97E7FE.7010104@gmail.com>
Date: Sat, 02 Apr 2011 20:22:38 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: Israel Alanis <izzyalanis@gmail.com>
References: <BANLkTint6CiMRZWj59sEYM2j7VoKgz4-Bw@mail.gmail.com> <AANLkTimuVubm5Becx8cg_Uq2Gdj8EjHL7maMyqWOeYCJ@mail.gmail.com> <AANLkTi=0iBKxo0_yv2LWsExzrKUjJLqP5Ua2uHB=M_7d@mail.gmail.com> <AANLkTi=QH+c-19PvavnXU+pgWyaqpAA0F5G5SMd6h4JR@mail.gmail.com> <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com>
In-Reply-To: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: vwrap@ietf.org
Subject: Re: [vwrap] [wvrap] Simulation consistency
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Apr 2011 03:20:18 -0000

Somehow I feel the basic asset server being able to login and download 
assets is now priority, yet I also wondered the best way to patch this 
into the current mode of viewers.

Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) that 
either of these two are optional and neither are mandatory for now. 
Thoughts?

Israel Alanis wrote:
>
> > when designing for scalability, the model to bear in mind is ...
>
> Well, there are a lot of different models to keep in mind, and many 
> different use cases. One particular use case to keep in mind is: "User 
> acquires new outfit, and wants to 'show it off' in a highly populated 
> region".
>
> > Both worlds and asset services may include commercial, community, 
> and personal services
>
> Yes, yes and yes. I'm particularly concerned about how the model 
> affects the ability to host personal asset services.
>
> > a proxying region, which would get slammed for every asset worn by 
> every avatar present.
>
> Granted the collection of services that are provided by the region 
> need to be scaled to meet the demands of that region. That's all part 
> of capacity planning.
>
> > regions run many different CPU-intensive tasks, including physics 
> simulation and server-side scripting, and absolutely cannot afford to 
> serve assets too 
>
> Well... who said the same CPU's have to do proxying, physics 
> simulation and server-side scripting? Asset proxying is a different 
> service than physics simulation and can be on separate hardware, could 
> make use of geographically distributed caching, and in certain 
> deployment patterns, the same caching services could be shared by 
> different regions. (Server-side scripting is a discussion for another 
> day).
>
> > This is why we have to go parallel...
>
> Totally agree, and a proxying model could and should also take 
> advantage of parallelism.
>
> > I think you're wrong that it has to cost much money. 
> ?vs?
> > It costs money to host a high performance and scalable asset service 
> and a high bandwidth network to handle the traffic.  A *lot* of money. 
>
> I think what you're saying is: "It costs a lot of money to build a 
> scalable asset service, but if assets are spread throughout the 
> internet they don't have to be scalable." But that's not quite right. 
> You're opening up every asset server to the VW equivalent of being 
> slashdotted, so are you sure you're not forcing *every* asset service 
> to be scalable and handle a lot of bandwith and network traffic? It's 
> the exact opposite of your intention, but I think that's the result, 
> all the same.
>
> This particular design decision has a big effect on the economics of 
> the VW infrastructure. I'd rather the economics to work out such that 
> a region provider who wishes to build a region that supports a small 
> population, can do so economically. A region that wants to host a 
> *large* population has to bear that cost of providing that scalable 
> asset service. 
>
> I want the economics of hosting a small asset service to be a 
> non-issue (as to best promote creation and creativity). Creating a 
> high bar to provide asset services will mean that service will cost 
> money and people shouldn't have to pay money just to create or own VW 
> objects (I'm using 'own' here to refer to maintaining their existence, 
> I'm not trying to make a 'leftist'/'communist' statement about 
> ownership ;)
>
> - Izzy
>
>
> On Apr 2, 2011, at 3:58 PM, Morgaine wrote:
>
>> Izzy, when designing for scalability, the model to bear in mind is 
>> that of seasoned virtual world travelers whose inventories contain 
>> assets from many different worlds, those assets being served by many 
>> different asset services.  Both worlds and asset services may include 
>> commercial, community, and personal services, and as the metaverse 
>> grows, that set is highly likely to become progressively less 
>> clustered and more diverse.
>>
>> When those seasoned travelers click on an advertised VW link and 
>> perform an inter-world teleport to one particular world's region to 
>> share an experience, their "worn" assets (the only ones of interest 
>> to the region) will contain references to asset services spread 
>> widely across the Internet.  The fetches by the travelers' clients 
>> occur over many parallel paths from clients to asset services, so one 
>> can reasonably expect reduced network contention and reduced asset 
>> server loading because they are both spread out over however many 
>> asset services are being referenced by the overall set of assets in 
>> the region.
>>
>> This is very different to the case of a proxying region, which would 
>> get slammed for every asset worn by every avatar present.  In our 
>> current architecture, regions run many different CPU-intensive tasks, 
>> including physics simulation and server-side scripting, and 
>> absolutely cannot afford to serve assets too unless your scalability 
>> requirements are very low indeed, ie. just a few dozen avatars of 
>> today's kind.  We've hit the ceiling already on region scalability 
>> done that way.  There is nowhere to go in that direction at all 
>> beyond improving the code like Intel demonstrated, and that work is 
>> subject to a law of diminishing returns.
>>
>> This is why we have to go parallel, and I think you're wrong that it 
>> has to cost much money.  As we spread the load across more and more 
>> asset services, we are simply better utilizing all the hardware 
>> that's already out there on the Internet, at least in respect of 
>> community and private resources.  But add to the community and 
>> private resources the commercial asset services that are likely to 
>> appear to exploit this opportunity, and not only will the number of 
>> asset services leap, but the power of each one will rocket too, 
>> because, after all, these businesses will be heavily optimized for 
>> the job.
>>
>> As to why a world would want clients to access external asset 
>> services instead of providing its own implementation, that's an easy 
>> question.  It costs money to host a high performance and scalable 
>> asset service and a high bandwidth network to handle the traffic.  A 
>> *lot* of money.  In contrast, it costs a world nothing to let others 
>> serve the assets to clients.  And that matters to the bottom line.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ======================
>>
>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com 
>> <mailto:izzyalanis@gmail.com>> wrote:
>>
>>     > 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
>>     <morgaine.dinova@googlemail.com
>>     <mailto:morgaine.dinova@googlemail.com>> 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
>>     <vaughn.deluca@gmail.com <mailto:vaughn.deluca@gmail.com>>
>>     > 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
>>     >> vwrap@ietf.org <mailto:vwrap@ietf.org>
>>     >> https://www.ietf.org/mailman/listinfo/vwrap
>>     >
>>     >
>>     > _______________________________________________
>>     > vwrap mailing list
>>     > vwrap@ietf.org <mailto:vwrap@ietf.org>
>>     > https://www.ietf.org/mailman/listinfo/vwrap
>>     >
>>     >
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant