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, 6 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<mailtomailto:
>> 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
>
>