Re: [vwrap] Statements of Consensus. Flexibity First.
Morgaine <morgaine.dinova@googlemail.com> Wed, 06 April 2011 00:59 UTC
Return-Path: <morgaine.dinova@googlemail.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 23C413A6834 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.803
X-Spam-Level:
X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ARzgGisiJNsz for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:59:21 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 24DAA3A682D for <vwrap@ietf.org>; Tue, 5 Apr 2011 17:59:21 -0700 (PDT)
Received: by qwc23 with SMTP id 23so694610qwc.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 18:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1hlem1NJ+RSTA+veNd6fg0zjODxjs2xUdKf2p11ytcc=; b=wFuBNI0fekMOrOdeVG9iZ2DhU+21xLHhVe66vTYXrSnz8XuMYxsqqI0PIlO2yDj/rM psY/46wB8FUliTUavgJuHl11VSNh4+gi4a4fWs43o84vtkGDdJTIPcsPC47FXEdH9XDX KssNO97qL0Fs2ydgQUXxWpu4jKXTDwdMV7L7A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=USA0WmkRFGZYx+rBgUJaHj+GIuN16/e7OKeF066lnnZ4P2/awpoQRWfAlCuwWj2d6p d1Q8um8pr8T76aFobfoyPIrjKynjHCI/YKLmlUJ3Zfnl5Olw9tOKiSqBwA+ecJUq7Q+0 WMhWxHjI7tIs6NSvDoD/Wcejp9cM+FaWqpb9g=
MIME-Version: 1.0
Received: by 10.229.78.22 with SMTP id i22mr301084qck.33.1302051663400; Tue, 05 Apr 2011 18:01:03 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 18:01:03 -0700 (PDT)
In-Reply-To: <4D9BB342.7020607@gmail.com>
References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <AANLkTimcMbrJzXYTvs0cszn+rhH4ygEPvzvLwu94gr-4@mail.gmail.com> <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com> <4D9B73D5.4000809@gmail.com> <BANLkTikO5qY+ZOJuMkBfMRT2Y3HjtPCLYw@mail.gmail.com> <4D9B8ADA.9000106@gmail.com> <BANLkTimgdU6mzu+Vz-yUU_33cm9VrdHR0w@mail.gmail.com> <4D9B937C.1040403@gmail.com> <BANLkTik+V6xfbrx07eQO-zNq9r1v03j6CQ@mail.gmail.com> <4D9B9D4A.7050006@gmail.com> <BANLkTi=zpAKKDzGiiNLG_Q=SDCgrS0t48w@mail.gmail.com> <4D9BB342.7020607@gmail.com>
Date: Wed, 06 Apr 2011 02:01:03 +0100
Message-ID: <BANLkTik-eYv2ih+aJ395Sex4amnKY7Xtvw@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary="00235429d8f4e0524a04a0358691"
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
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: Wed, 06 Apr 2011 00:59:24 -0000
*"Facts and documents*": Link already provided. Hash-based asset addressing is just one protocol design element out of many hundreds in VWRAP, and it would appear as a small technical detail in a future VWRAP document, not a VWRAP document in its own right. "*Many orders of magnitude*": Performance Gain = (time to fetch an asset over the network) / (time to fetch an asset from client cache with no network access required) . This could easily be 5 orders of magnitude under normal operation, and a lot more under conditions of service congestion. Morgaine. ==================== On Wed, Apr 6, 2011 at 1:26 AM, Dzonatas Sol <dzonatas@gmail.com> wrote: > We were and still are in discussion about VWRAP documents. > > As someone that implements, they don't want to read anything like "many > orders of magnitude" or "the best idea" or such exaggerated adjectives. > Don't expect your ideas ever to get implemented based on such language. > > Need just the facts, and the documents. Please, stop with how great you > think your idea is and produce the documents! Please include specific use of > the resources, LLIDL, DSD, etc. > > If this continues to be just discussion and neither documentation nor > implementation than I'm with the chair(s) to disband. > > Morgaine wrote: > >> The asset fetch performance gain of a protocol in which asset identifiers >> make cross-world assets cacheable versus a protocol whose asset identifiers >> do not allow this is an extremely large factor of *many orders of magnitude* >> on all but the first occurrence of an asset. For all intents and purposes, >> avoiding the need to fetch an asset over the network represents a gain of >> infinity, and this gain may be repeated many times over. >> >> I think it's pretty uncontestable that giving VWRAP an asset addressing >> scheme which is orders of magnitude more efficient than any other scheme >> that has yet been proposed would be an important benefit for the protocol, >> and highly likely to make it popular. Conversely, if it lacks this benefit >> then another protocol will use it and will hugely out-perform VWRAP. >> >> We were talking about designing for the future. Hash-based asset >> addressing is a case in point, and how we handle this proposal is apparently >> our first test case. >> >> >> Morgaine. >> >> >> >> >> >> =============================== >> >> >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <dzonatas@gmail.com<mailto: >> dzonatas@gmail.com>> wrote: >> >> And... still local cache.. not vwrap. >> >> I think it would be more wise to go with the implementations of >> Google's and/or Siemens object identification to RFID codes. At >> least we know this part won't exploit content. >> >> It has further advantages than just that. I went into detail >> awhile ago, yet with basic QM: >> >> http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html >> >> No, even given the possibilities presented, I don't think your >> idea comes close to anything new in regards to the best. It's just >> your preference. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol >> <dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote: >> >> >> Your approach, besides exploitations, has the typical >> problem to >> assume asset IDs are only needed and are hash-able. >> >> >> >> Asset IDs are not hash-able, it is the asset data that is >> hashed. The asset identifier is the hash of the asset data >> using a defined hash digest algorithm. The asset identifier >> is not guessable unless you already have access to the asset. >> >> >> Morgaine. >> >> >> >> >> ============================= >> >> >> >> ================== >> >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol >> <dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> wrote: >> >> Again Morgaine, your appeals alone don't support >> themselves, and >> your ridicule is unwelcome. If you can not honestly >> make any >> serious response, please move on and don't reply to my >> posts just >> to further ridicule. It's very RUDE. >> >> If you have any implementation of your hash-based >> idea or >> actual >> technical detailed documentation ready for >> implementation, then >> introduce it. Until then, it's stuck in your head, >> and sounds >> other's ideas just with your name on it. Plus >> security by >> obscurity makes it as moot point. >> >> Documentation... ? >> >> Remember people tried to take one temp variable away >> from the >> JPEG2000 int multiple/divide routine because the >> idea it looks >> good (on paper) with one less variable. Actual >> implementation >> reveals, with timed tests, it is slower when anybody >> takes away >> that one temp variable. >> >> Morgaine wrote: >> >> Unfortunately your response was devoid of technical >> content, >> Dzonatas. >> >> If you have something technical to say about >> hash-based >> addressing, I would love to hear it. >> >> I have detailed in some depth the many benefits of >> hash-based >> addressing in the article I linked, and >> subsequently. If >> other good schemes exist, we should of course >> analyze >> them for >> technical merit and compare their benefits >> against those of >> hash-based addressing. >> >> That's the engineering process for making VWRAP >> as good >> as it >> can be. >> >> >> Morgaine. >> >> >> >> >> ========================= >> >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol >> <dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> >> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>> wrote: >> >> Morgaine, we mooted your hash-based idea. >> This does >> nothing to >> help implement asset services. The only >> significant >> point >> you made >> is some expression for optimization, not correct >> functionality, >> which is needed first >> >> As for your other two, we can summarize those >> with >> public >> resources and flow (forward/reverse). Any more >> specific network >> topology than that only makes it harder to >> address. The >> only thing >> to worry about is already custom resources >> that overlap >> with newer >> public resources. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >> <dzonatas@gmail.com >> <mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> >> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> >> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> >> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com >> <mailto:dzonatas@gmail.com>> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com> >> <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>>> wrote: >> >> >> Do you think we are ready to implement >> some asset >> services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing >> concept is an >> extremely >> important >> matter, almost certainly the most >> important >> matter >> of all, >> because that determines how robust and >> scalable our >> worlds will >> be.� I've already examined >> alternatives for >> that >> in some >> depth, >> and the design with the best engineering >> properties so >> far seems >> to be universal hash-based >> addressing.� I first >> described >> that >> approach on the list here --- >> >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various >> subsequent >> discussions. >> >> * Defining the data flows between regions, >> clients, >> and asset >> services and which parameters >> control the flows >> needs to >> be done >> before a test asset service can be >> implemented.� >> Without >> that, >> an asset service is just a >> network-accessible storage >> service, >> not an asset service in the VWRAP >> sense.� >> Network >> storage >> services exist already, so just >> implementing one >> of those >> would >> not advance VWRAP. >> >> * We need to examine how various >> deployment >> patterns >> will >> use the >> asset services, and how the >> /multiple/ asset >> services that >> interop introduces are handled.� I am >> working on this >> currently. >> >> >> None of the above is particularly hard.� >> I think it >> won't be >> long before we have a scheme worked out >> and are >> ready >> for some >> implementation work. >> >> >> Morgaine. >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>>> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> -- --- >> https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, >> Virtual Reality, >> Consultant >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org <mailto:vwrap@ietf.org> >> <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org <mailto:vwrap@ietf.org> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > >
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dickson, Mike (ISS Software)
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- [vwrap] Statements of Consensus. Flexibity First. Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis