[Nfd-dev] Clarification of 'repo' definition

[christian.tschudin at unibas.ch]

The chilled water example is a nice study case, the two research questions that come to mind are NACK and mount:

- asserting the non-existence of an item in distibuted systems is notoriously hard, in this case across repos or caches

- mounting a tree into the routing fabric, with the possibility to delegate mount points to one or more (!) repos, is exactly what publishing is about.

Having generations of repos with increasing sets of features would be useful to have (and the routing layer being aware of them). The current 2016 repo generation would be full subtree and not replicated, next year's generation adds replication, exclusion for later etc, backwards compatible all the time. Researchy for sure ;-)

best, c


On Fri, 9 Sep 2016, Lixia Zhang wrote:

>
>       On Sep 8, 2016, at 7:18 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
> Hi,
> 
> (Sorry for these messages all at once, and let me know if this should go to ndn-interest.)
> 
> Through an earlier conversation with Lixia this week, I realized that the definition / expectations
> of a ‘repo’ may be more specific than I previously understood.  In particular, she mentioned that
> repos storing and registering the same namespace should (eventually) have the same data for that
> namespace, presumably via sync.
> 
> 
> I'll start by saying that this is all researchy: we are walking into a new territory that we are yet to
> fully explore.
> So what I said, before or here, is just to share ideas with others.
> 
> It is easy to see why a desire of all repos for the same name prefix being sync'ed up: an interest for that
> prefix may be forwarded to any of the repos, if all repos have the same data, anyone can answer it;
> otherwise routers have to handle NACKs and reroute the interest to try other repos.
> 
>
>       A few related questions:
> 
> 1) Is this attempt at eventual consistency of what’s stored for a given namespace a requirement to be
> called a ‘repo’? 
> 
> 
> see the above explanation.
> I wont call it a requirement, but desirable for performance concerns.
>
>       2) Practically, if such sync is ultimately required behavior for a repo, will/should repo-ng
>       itself incorporate some basic synchronization features? 
> 
> 
> as I mentioned, there was a piece of work done on repo sync 2 years back (but I dont know its
> implementation status)
>
>
>       3) Does opportunistic caching behavior (without sync) mean that the storage is not a ‘repo’?
> 
> 
> My own view: no.
> my explanation to others:
> - caching: opportunistic 
> - (managed) repo: managed storage
>
>
>       4) Would, for example, network-attached storage that stores everything for a prefix but only up
>       to a given depth in the tree not qualify as a repo? 
> 
> 
> everything is attached to the network :)
> so I am not sure what "network-attached storage" really means.
> 
> if your question is "what if a managed repo for a name prefix only contains incomplete data under that
> prefix" -- that still works, and *may* even work OK if one understands the traffic patterns so that most of
> the Interests forwarded to that repo can be satisfied, without having to zigzagging to other places seeking
> for data.
>
>
>       5) Or, for example, in the BMS case, if I use a repo to store all of the electrical current
>       samples for the UCLA campus, but not chilled water, it will have only have some of the tree for
>       the campus bms prefix.  Is the storage not a repo?  Should it not be registering the root bms
>       prefix?   Should I have / what do I call storage that is filling in part of the tree but don’t
>       need to or can’t store all of it? 
> 
> 
> 1/ if chilled water has its own prefix announcement, maybe one can find a way to attract all interests for
> chilled water data to the place for chilled water.
> 3/ again one needs to think not just what one wants to put where, but also how forwarding can work well.
> 
>
>       6) What are other requirements to be a ‘repo’?  (Alternatively, is there a canonical reference
>       in the literature for the type of storage that constitutes a repo?)
> 
> 
> it does not really matter what we want to call something.
> there is no arbitrary requirement. 
> as I said already, this is research, we have not done much playing with repo up to now.  It is all about
> figuring out how to make the system work in the best way it can.
> 
> my 2 cents,
> Lixia
> 
> 
>