[vwrap] Client-side caching, URIs, and scene scalability

[Morgaine <[e-mail]>]

We've discussed the structure of caps, URIs and asset addressing here many
times in the past.  I would like us to examine this issue in the specific
context of *client-side caching* and *scene growth*, which we have not
previously addressed.  Scalability is a matter of huge importance (as well
as being part of the IETF mission statement), and I'm particularly
interested in making sure that VWRAP standards are scalable in key
dimensions.

Scenes will inevitably rise in size and complexity with the passage of
time.  In quite a short while we can expect millions of assets in a scene
within the field of view of an agent, and further orders of magnitude not
long after.  While some may be tempted to call this "sci fi", observing the
increase in memory, disk, and other computing resources over time suggests
otherwise.  From kilo to mega, giga and tera, it's only when we look back
that we realize that our inability to visualize exponential growth is epic.

This becomes relevant when deciding on URI formats.  It's no use defining an
elegant URI format if it doesn't scale as scene complexity rises.

What this means for us when we are designing the structure of URIs is that
we need to focus on what the URI is for, namely data access, both local and
remote.  When designing for scalability through good use of caching, our
goal is to avoid a client having to perform each remote access if at all
possible.  If our elegant URI format results in clients needing to access
data remotely despite it already being cached locally, then our elegant
addressing scheme has failed.  "Elegant but non-scalable" is not the mark of
success, so let's check against this requirement.

When a region tells the client about the items it current holds (narrowed
down by an interest list in an optimized implementation), it does so by
listing the items in the scene using item identifiers of some kind.  The
client can then use each identifier as an index into its local cache, and
then request from the relevant asset services only those items that are not
already cached.  This is easy in an isolated world where identifiers can be
world-global.  Where it breaks down is when worlds interoperate, and those
arbitrary identifiers (eg. UUIDs or URIs based on them) become useless for
deciding whether an item common to multiple worlds is actually in the cache
or not.  Done wrongly, it can easily result in repeat downloading on a
massive scale.

Local or global identifiers will work poorly unless they're an intrinsic
property of the actual data being indexed.  The reason they won't work well
is because the same data used in two different worlds won't have a common
URI-based cache index unless it happens to be supplied by the same asset
service.  The same item replicated in thousands of worlds would end up being
stored thousands of times in the cache.  While the storage cost may be of
little consequence, the repeated access cost is not, because round-trip
times have very limited downward scalability.

The engineering solution to this is pretty obvious:  scene component
identifiers should include a *hash or digest over the data*, this
information being separable from other parts of the identifier/URI so that
it can be used as a key into the cache.  The cache is king, and terabyte
caches should be regarded as normal now, with petabyte caches not so many
years down the line.  The goal of "Never download the same thing twice" is
already reasonable with terabyte drives today, never mind tomorrow.  VWRAP
needs to embrace this, if it is to be a scalable interop standard.

Note that in the above, my reference to "data" *excludes metadata* by
intent.  Two objects may be quite separate, with totally different metadata,
yet denote exactly the same data, which would give them the same hash digest
and hence share a cache index.  This situation is likely to be extremely
common, especially for environmental items such as trees, vegetation and
other natural elements.  We can easily foresee a situation in which people
create their brand new world by unpacking a region archive and releasing
another few million items into the metaverse.  If those items were cached
the first time that they were seen in one world, they would not need to be
loaded again from this new world, if we design our URIs with good
engineering properties and foresight.

Cache scalability as the number of worlds with common assets rises is one
issue, but there is also another related one on the horizon.  As we move
away from SL's primitive assets and 1-level linksets towards *hierachical
objects* that allow object composition, the number of virtual obects made
from reusable components will skyrocket, because builders will be riding on
the shoulders of giants, just like in RL engineering.  This again will
result in massive cross-world sharing of replicated components.

In summary:  The asset identifiers supplied by a region to a client should
contain an *explicit hash/digest over the data* (calculated *ONCE* by the
relevant asset service of course, not by each region), to allow client-side
caches to be highly effective at eliminating unnecessary network traffic.
This will be very important in a metaverse of countless worlds, huge amounts
of shared data, and massive scenes.


Morgaine.

PS. Hash digests in asset URIs deliver two other important benefits as well,
beyond scalability:


   - They provide the interesting property of *near-universal asset
   addressing*.  This may appeal to those who focus on social aspects of
   digital content such as imposing property semantics, in which case using a
   URI format that almost uniquely identifies assets can kill several birds
   with one stone.


   - They provide isolation from host and network outages.  Near-universal
   asset addressing means that when an asset service fails to respond or
   returns an error code, a new URI containing the same hash digest could be
   manufactured and sent to a second asset service as fallback.  The benefits
   of this for *virtual world resilience* are of course immense.  Resilience
   is so important that I suggest it should be a protocol requirement.  The
   fact that we would gain resilience automatically as a mere side-effect of
   digest-based addressing highlights the rather nice properties of this
   design.


-- End.