[Ndn-interest] any comments on naming convention?

[Ignacio.Solis at parc.com]

On 9/27/14, 10:19 PM, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:

>The concern is that the table of content is not confirmed by the
>original provider; the cache server's data is "trusted with some other
>chains". This trust model works but brings restriction. It basically
>requires build another trust model on "cache server"; otherwise,
>nothing discovered can be trusted, which also means that you discover
>nothing.

I’m not sure what you mean by trust to the cache.  NDN has no trust to the
cache and no way to trust that a selector match is the correct match.

As I know, a cache can have

/foo/1
/foo/2
/foo/3

At could reply with /foo/2 and not give you /foo/3 as the “latest”.  You
have no way to trust that a cache will give you anything specific.  You
can’t really require this because you can’t require cache nodes to have a
specific cache replacement policy, so as far as you know, the cache could
have dropped /foo/3 from the cache.

As a matter of fact, unless you require signature verification at cache
nodes (CCN requires this), you don’t even have that.  From what I’ve been
told,  it’s optional for nodes to check for signatures. So, at any point
in the network, you never know if previous nodes have verified the
signature.

So, I’m not sure what kind of “trust model” you refer to.  Is there some
trust model has that this Selector Protocol breaks at the nodes that run
the Selector Protocol?  If so, could you please explain it.


>Another critical point is that those cache servers are not
>hierarchical, so we can only apply flat signing (one guy signs them
>all.) This looks very problematic. An quick fix is that you just use
>impose the name hierarchy, but it is cumbersome too.

Nobody really cares about the signature of the reply. You care about
what’s encapsulated inside, which, in fact, does authenticate to the
selector request.  Every node running the Selector Protocol can check this
reply and this signature.

>Here is our discussion so far:
>exact matching -> ... needs discovery protocol (because it is not lpm)
>-> discovery needs table of content -> restrictive trust model
>My argument is that this restrictive trust model logically discourages
>exact matching.

I’m not sure what to make of this.

Every system needs a discovery protocol.  NDN is doing it via selector
matching at the forwarder.  CCN does it at a layer above that.  We don’t
believe you should force nodes to let their caches be discoverable and to
run the computation needed for this.

There is no restrictive trust model.  In CCN we don’t do anything of what
I’ve described because we don’t do Selector Protocol. The Selector
Protocol I’m just described is meant to give you the same semantics as NDN
using exact matching. this includes the security model. Just because the
“layer underneath” (aka CCN) does not do the same security model doesn’t
mean that the protocol doesn’t deliver it to you.

It seems to me that you’d be hard pressed to find a feature difference
between NDN selectors and the CCN nodes running the Selector Protocol I
described.


Let me go over it once again:


Network:

A - - - B - - C - - D
E - F - +


A, B, D, E and F are running the Selector Protocol. C is not.

D is serving content for  /foo
B has a copy of /foo/100, signed by D

Node A wants something that starts with /foo/ but has a next component
greater than 50



A issues an interest:
Interest: name = /foo/hash(Sel(>50))
Payload = Sel(>50)


Interest arrives at B. B notices that it’s a Selector Protocol based
interest.
It interprets the payload, looks at the cache and finds /foo/100 as a
match.
It generates a reply.

Data:
Name = /foo/hash(Sel(>50))
Payload = ( Data: Name = /foo/100, Signature = Node D, Payload = data)
Signature = Node B

That data is sent to node A.

A is running the Selector Protocol.
It notices that this reply is a Selector Protocol reply.
It decapsulates the Payload.  It extracts /foo/100.
It checks that /foo/100 is signed by Node D.

A’s interest is satisfied.


A issues new interest (for something newer, it wasn’t satisfied with 100).

A issues an interest:
Interest: name = /foo/hash(Sel(>100))
Payload = Sel(>100)

Sends interest to B.

B knows it’s a Selector Protocol interest.
Parses the payload for the selectors.  It looks at the cache, finds no
match.

B sends the interest to C


C doesn’t understand Selector Protocol. It just does exact matching. Finds
no match.
It forwards the interest to node D.


D is running the Selector Protocol.
D looks at the data to see what’s the latest one.  It’s 200.
D creates encapsulated reply.

Data:
Name = /foo/hash(Sel(>100))
Payload = ( Data: Name = /foo/200, Signature = Node D, Payload = data)
Signature = Node D


Forwards the data to C.

C doesn’t know Selector Protocol.  It matches the Data to the Interest
based on exact match of the name
/foo/hash(Sel(>100)). It may or may not cache the data.

C forwards the data to B.

B is running the Selector Protocol.  It matches the data to the interest
based on PIT.  It then proceeds to check that the selectors actually
match.  It check that /foo/200 is greater than /foo/100.  The check
passes.  It decides to keep a copy of /foo/200 in its cache.

Node B forwards the data to Node A, which receives it. Node A is running
the Selector Protocol. It decapsulates the data, checks the authenticity
and hands it to the app.



Node E wants some of the /foo data, but only with the right signature.

Node E issues an interest:
Interest: name = /foo/hash(Sel(Key=NodeD))
Payload = Sel(Key=NodeD)



Sends it to Node F.


F receives the interest. It knows it’s a Selector Protocol interest.
Parses payload, looks in cache but finds no match.

F forwards the interest to node B.

B receives the interest. It knows it’s a Selector Protocol interest.
Parses payload, looks in the cache and finds a match (namely /foo/200).
/foo/200 checks out since it is signed by Node D.

Node B creates a reply by encapsulating /foo/200:
Name = /foo/hash(Sel(Key=NodeD))
Payload = ( Data: Name = /foo/200, Signature = Node D, Payload = data)
Signature = Node B

It sends the data to F.

Node F is running the Selector Protocol.  It sees the reply. It
decapsulates the object inside (/foo/200).  It knows that this PIT entry
has selectors and requires that the signature come from Node D. It checks
that the signature of /foo/200 is from node D.  It is. This is a valid
reply to the interest, so it forwards the data along to node E and
consumes the interest.  Node F keeps a copy of the /foo/200 object.

Node E receives the object. Matches it to the PIT. Decapsulates the data
(since E is running the Selector Protocol), matches it to the selectors
and once checked sends it to the application.



Done.

In this scenario, most nodes were running the Selector Protocol.  But it’s
possible for some nodes not to run it.  Those nodes would only do exact
matching (like node C).   In this example, Node C kept a copy of the
packet /foo/hash(Sel(>100))  (which encapsulated /foo/200), it could use
this as a reply to another interest with the same name, but it wouldn’t be
able to use this to answer a selector of /foo/hash(Sel(>150)) since that
would require selector parsing.  That request would just be forwarded.


To summarize, nodes running the Selector Protocol behave like NDN nodes.
The rest of the other nodes can do regular CCN with exact matching.

Again, we are not advocating for this discovery protocol, we are just
saying that you could implement the selector functionality on top of exact
matching. Those nodes that wanted to run the protocol would be able to do
so, and those that did not want to run the protocol would not be required
to do so.

Nacho



>On Sat, Sep 27, 2014 at 12:40 PM,  <Ignacio.Solis at parc.com> wrote:
>> On 9/27/14, 8:40 PM, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:
>>
>>>> /mail/inbox/selector_matching/<hash of payload>
>>>
>>>So Is this <hash of payload>  implicit?
>>
>> No.  This is an explicit hash of the interest payload.
>>
>> So, an interest could look like:
>>
>> Interest:
>> name = /mail/inbox/selector_matching/1234567890
>> payload = “user=nacho”
>>
>> where hash(“user=nacho”) = 1234567890
>>
>>
>>>BTW, I read all your replies. I think the discovery protocol (send out
>>>table of content) has to reach the original provider ; otherwise there
>>>will be some issues in the trust model. At least the cached table of
>>>content has to be confirmed with the original provider either by key
>>>delegation or by other confirmation protocol. Besides this, LGTM.
>>
>>
>> The trust model is just slightly different.
>>
>> You could have something like:
>>
>> Interest:
>> name = /mail/inbox/selector_matching/1234567890
>> payload = “user=nacho,publisher=mail_server_key”
>>
>>
>> In this case, the reply would come signed by some random cache, but the
>> encapsulated object would be signed by mail_server_key.  So, any node
>>that
>> understood the Selector Protocol could decapsulate the reply and check
>>the
>> signature.
>>
>> Nodes that do not understand the Selector Protocol would not be able to
>> check the signature of the encapsulated answer.
>>
>> This to me is not a problem. Base nodes (the ones not running the
>>Selector
>> Protocol) would not be checking signatures anyway, at least not in the
>> fast path. This is an expensive operation that requires the node to get
>> the key, etc.  Nodes that run the Selector Protocol can check signatures
>> if they wish (and can get their hands on a key).
>>
>>
>>
>> Nacho
>>
>>
>>>On Sat, Sep 27, 2014 at 1:10 AM,  <Ignacio.Solis at parc.com> wrote:
>>>> On 9/26/14, 10:50 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
>>>>wrote:
>>>>
>>>>>On Sep 26, 2014, at 2:46 AM, Ignacio.Solis at parc.com wrote:
>>>>>> On 9/25/14, 9:53 PM, "Lan Wang (lanwang)" <lanwang at memphis.EDU>
>>>>>>wrote:
>>>>>>
>>>>>>> How can a cache respond to /mail/inbox/selector_matching/<hash of
>>>>>>> payload> with a table of content?  This name prefix is owned by the
>>>>>>>mail
>>>>>>> server.   Also the reply really depends on what is in the cache at
>>>>>>>the
>>>>>>> moment, so the same name would correspond to different data.
>>>>>>
>>>>>> A - Yes, the same name would correspond to different data.  This is
>>>>>>true
>>>>>> given that then data has changed. NDN (and CCN) has no architectural
>>>>>> requirement that a name maps to the same piece of data (Obviously
>>>>>>not
>>>>>> talking about self certifying hash-based names).
>>>>>
>>>>>There is a difference.  A complete NDN name including the implicit
>>>>>digest
>>>>>uniquely identifies a piece of data.
>>>>
>>>> That’s the same thing for CCN with a ContentObjectHash.
>>>>
>>>>
>>>>>But here the same complete name may map to different data (I suppose
>>>>>you
>>>>>don't have implicit digest in an effort to do exact matching).
>>>>
>>>> We do, it’s called ContentObjectHash, but it’s not considered part of
>>>>the
>>>> name, it’s considered a matching restriction.
>>>>
>>>>
>>>>>In other words, in your proposal, the same name
>>>>>/mail/inbox/selector_matching/hash1 may map to two or more different
>>>>>data
>>>>>packets.  But in NDN, two Data packets may share a name prefix, but
>>>>>definitely not the implicit digest.  And at least it is my
>>>>>understanding
>>>>>that the application design should make sure that the same producer
>>>>>doesn't produce different Data packets with the same name prefix
>>>>>before
>>>>>implicit digest.
>>>>
>>>> This is an application design issue.  The network cannot enforce this.
>>>> Applications will be able to name various data objects with the same
>>>>name.
>>>>  After all, applications don’t really control the implicit digest.
>>>>
>>>>>It is possible in attack scenarios for different producers to generate
>>>>>Data packets with the same name prefix before implicit digest, but
>>>>>still
>>>>>not the same implicit digest.
>>>>
>>>> Why is this an attack scenario?   Isn’t it true that if I name my
>>>>local
>>>> printer /printer that name can exist in the network at different
>>>>locations
>>>> from different publishers?
>>>>
>>>>
>>>> Just to clarify, in the examples provided we weren’t using implicit
>>>>hashes
>>>> anywhere.  IF we were using implicit hashes (as in, we knew what the
>>>> implicit hash was), then selectors are useless. If you know the
>>>>implicit
>>>> hash, then you don’t need selectors.
>>>>
>>>> In the case of CCN, we use names without explicit hashes for most of
>>>>our
>>>> initial traffic (discovery, manifests, dynamically generated data,
>>>>etc.),
>>>> but after that, we use implicit digests (ContentObjectHash
>>>>restriction)
>>>> for practically all of the other traffic.
>>>>
>>>> Nacho
>>>>
>>>>
>>>>>>
>>>>>> B - Yes, you can consider the name prefix is “owned” by the server,
>>>>>>but
>>>>>> the answer is actually something that the cache is choosing. The
>>>>>>cache
>>>>>>is
>>>>>> choosing from the set if data that it has.  The data that it
>>>>>>encapsulates
>>>>>> _is_ signed by the producer.  Anybody that can decapsulate the data
>>>>>>can
>>>>>> verify that this is the case.
>>>>>>
>>>>>> Nacho
>>>>>>
>>>>>>
>>>>>>> On Sep 25, 2014, at 2:17 AM, Marc.Mosko at parc.com wrote:
>>>>>>>
>>>>>>>> My beating on “discover all” is exactly because of this.  Let’s
>>>>>>>>define
>>>>>>>> discovery service.  If the service is just “discover latest”
>>>>>>>> (left/right), can we not simplify the current approach?  If the
>>>>>>>>service
>>>>>>>> includes more than “latest”, then is the current approach the
>>>>>>>>right
>>>>>>>> approach?
>>>>>>>>
>>>>>>>> Sync has its place and is the right solution for somethings.
>>>>>>>>However,
>>>>>>>> it should not be a a bandage over discovery.  Discovery should be
>>>>>>>>its
>>>>>>>> own valid and useful service.
>>>>>>>>
>>>>>>>> I agree that the exclusion approach can work, and work relatively
>>>>>>>>well,
>>>>>>>> for finding the rightmost/leftmost child.  I believe this is
>>>>>>>>because
>>>>>>>> that operation is transitive through caches.  So, within whatever
>>>>>>>> timeout an application is willing to wait to find the “latest”, it
>>>>>>>>can
>>>>>>>> keep asking and asking.
>>>>>>>>
>>>>>>>> I do think it would be best to actually try to ask an
>>>>>>>>authoritative
>>>>>>>> source first (i.e. a non-cached value), and if that fails then
>>>>>>>>probe
>>>>>>>> caches, but experimentation may show what works well.  This is
>>>>>>>>based
>>>>>>>>on
>>>>>>>> my belief that in the real world in broad use, the namespace will
>>>>>>>>become
>>>>>>>> pretty polluted and probing will result in a  lot of junk, but
>>>>>>>>that’s
>>>>>>>> future prognosticating.
>>>>>>>>
>>>>>>>> Also, in the exact match vs. continuation match of content object
>>>>>>>>to
>>>>>>>> interest, it is pretty easy to encode that “selector” request in a
>>>>>>>>name
>>>>>>>> component (i.e. “exclude_before=(t=version, l=2, v=279) &
>>>>>>>>sort=right”)
>>>>>>>> and any participating cache can respond with a link (or
>>>>>>>>encapsulate) a
>>>>>>>> response in an exact match system.
>>>>>>>>
>>>>>>>> In the CCNx 1.0 spec, one could also encode this a different way.
>>>>>>>>One
>>>>>>>> could use a name like “/mail/inbox/selector_matching/<hash of
>>>>>>>>payload>”
>>>>>>>> and in the payload include "exclude_before=(t=version, l=2,
>>>>>>>>v=279) &
>>>>>>>> sort=right”.  This means that any cache that could process the “
>>>>>>>> selector_matching” function could look at the interest payload and
>>>>>>>> evaluate the predicate there.  The predicate could become large
>>>>>>>>and
>>>>>>>>not
>>>>>>>> pollute the PIT with all the computation state.  Including “<hash
>>>>>>>>of
>>>>>>>> payload>” in the name means that one could get a cached response
>>>>>>>>if
>>>>>>>> someone else had asked the same exact question (subject to the
>>>>>>>>content
>>>>>>>> object’s cache lifetime) and it also servers to multiplex
>>>>>>>>different
>>>>>>>> payloads for the same function (selector_matching).
>>>>>>>>
>>>>>>>> Marc
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sep 25, 2014, at 8:18 AM, Burke, Jeff <jburke at remap.ucla.edu>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://irl.cs.ucla.edu/~zhenkai/papers/chronosync.pdf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>https://www.ccnx.org/releases/ccnx-0.7.0rc1/doc/technical/Synchron
>>>>>>>>>iz
>>>>>>>>>at
>>>>>>>>>io
>>>>>>>>> nPr
>>>>>>>>> otocol.html
>>>>>>>>>
>>>>>>>>> J.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/24/14, 11:16 PM, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> However, I cannot see whether we can achieve "best-effort
>>>>>>>>>>*all*-value"
>>>>>>>>>> efficiently.
>>>>>>>>>> There are still interesting topics on
>>>>>>>>>> 1. how do we express the discovery query?
>>>>>>>>>> 2. is selector "discovery-complete"? i. e. can we express any
>>>>>>>>>> discovery query with current selector?
>>>>>>>>>> 3. if so, can we re-express current selector in a more efficient
>>>>>>>>>>way?
>>>>>>>>>>
>>>>>>>>>> I personally see a named data as a set, which can then be
>>>>>>>>>>categorized
>>>>>>>>>> into "ordered set", and "unordered set".
>>>>>>>>>> some questions that any discovery expression must solve:
>>>>>>>>>> 1. is this a nil set or not? nil set means that this name is the
>>>>>>>>>>leaf
>>>>>>>>>> 2. set contains member X?
>>>>>>>>>> 3. is set ordered or not
>>>>>>>>>> 4. (ordered) first, prev, next, last
>>>>>>>>>> 5. if we enforce component ordering, answer question 4.
>>>>>>>>>> 6. recursively answer all questions above on any set member
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 24, 2014 at 10:45 PM, Burke, Jeff
>>>>>>>>>><jburke at remap.ucla.edu>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> From: <Marc.Mosko at parc.com>
>>>>>>>>>>> Date: Wed, 24 Sep 2014 16:25:53 +0000
>>>>>>>>>>> To: Jeff Burke <jburke at remap.ucla.edu>
>>>>>>>>>>> Cc: <Ignacio.Solis at parc.com>, <tailinchu at gmail.com>,
>>>>>>>>>>> <ndn-interest at lists.cs.ucla.edu>
>>>>>>>>>>> Subject: Re: [Ndn-interest] any comments on naming convention?
>>>>>>>>>>>
>>>>>>>>>>> I think Tai-Lin’s example was just fine to talk about
>>>>>>>>>>>discovery.
>>>>>>>>>>> /blah/blah/value, how do you discover all the “value”s?
>>>>>>>>>>>Discovery
>>>>>>>>>>> shouldn’t
>>>>>>>>>>> care if its email messages or temperature readings or world cup
>>>>>>>>>>> photos.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is true if discovery means "finding everything" - in which
>>>>>>>>>>>case,
>>>>>>>>>>> as you
>>>>>>>>>>> point out, sync-style approaches may be best.  But I am not
>>>>>>>>>>>sure
>>>>>>>>>>>that
>>>>>>>>>>> this
>>>>>>>>>>> definition is complete.  The most pressing example that I can
>>>>>>>>>>>think
>>>>>>>>>>> of
>>>>>>>>>>> is
>>>>>>>>>>> best-effort latest-value, in which the consumer's goal is to
>>>>>>>>>>>get
>>>>>>>>>>>the
>>>>>>>>>>> latest
>>>>>>>>>>> copy the network can deliver at the moment, and may not care
>>>>>>>>>>>about
>>>>>>>>>>> previous
>>>>>>>>>>> values or (if freshness is used well) potential later versions.
>>>>>>>>>>>
>>>>>>>>>>> Another case that seems to work well is video seeking.  Let's
>>>>>>>>>>>say I
>>>>>>>>>>> want to
>>>>>>>>>>> enable random access to a video by timecode. The publisher can
>>>>>>>>>>> provide a
>>>>>>>>>>> time-code based discovery namespace that's queried using an
>>>>>>>>>>>Interest
>>>>>>>>>>> that
>>>>>>>>>>> essentially says "give me the closest keyframe to 00:37:03:12",
>>>>>>>>>>>which
>>>>>>>>>>> returns an interest that, via the name, provides the exact
>>>>>>>>>>>timecode
>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>> keyframe in question and a link to a segment-based namespace
>>>>>>>>>>>for
>>>>>>>>>>> efficient
>>>>>>>>>>> exact match playout.  In two roundtrips and in a very
>>>>>>>>>>>lightweight
>>>>>>>>>>> way,
>>>>>>>>>>> the
>>>>>>>>>>> consumer has random access capability.   If the NDN is the
>>>>>>>>>>>moral
>>>>>>>>>>> equivalent
>>>>>>>>>>> of IP, then I am not sure we should be afraid of roundtrips
>>>>>>>>>>>that
>>>>>>>>>>> provide
>>>>>>>>>>> this kind of functionality, just as they are used in TCP.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I described one set of problems using the exclusion approach,
>>>>>>>>>>>and
>>>>>>>>>>> that
>>>>>>>>>>> an
>>>>>>>>>>> NDN paper on device discovery described a similar problem,
>>>>>>>>>>>though
>>>>>>>>>>> they
>>>>>>>>>>> did
>>>>>>>>>>> not go into the details of splitting interests, etc.  That all
>>>>>>>>>>>was
>>>>>>>>>>> simple
>>>>>>>>>>> enough to see from the example.
>>>>>>>>>>>
>>>>>>>>>>> Another question is how does one do the discovery with exact
>>>>>>>>>>>match
>>>>>>>>>>> names,
>>>>>>>>>>> which is also conflating things.  You could do a different
>>>>>>>>>>>discovery
>>>>>>>>>>> with
>>>>>>>>>>> continuation names too, just not the exclude method.
>>>>>>>>>>>
>>>>>>>>>>> As I alluded to, one needs a way to talk with a specific cache
>>>>>>>>>>>about
>>>>>>>>>>> its
>>>>>>>>>>> “table of contents” for a prefix so one can get a consistent
>>>>>>>>>>>set
>>>>>>>>>>>of
>>>>>>>>>>> results
>>>>>>>>>>> without all the round-trips of exclusions.  Actually
>>>>>>>>>>>downloading
>>>>>>>>>>>the
>>>>>>>>>>> “headers” of the messages would be the same bytes, more or
>>>>>>>>>>>less.
>>>>>>>>>>>In
>>>>>>>>>>> a
>>>>>>>>>>> way,
>>>>>>>>>>> this is a little like name enumeration from a ccnx 0.x repo,
>>>>>>>>>>>but
>>>>>>>>>>>that
>>>>>>>>>>> protocol has its own set of problems and I’m not suggesting to
>>>>>>>>>>>use
>>>>>>>>>>> that
>>>>>>>>>>> directly.
>>>>>>>>>>>
>>>>>>>>>>> One approach is to encode a request in a name component and a
>>>>>>>>>>> participating
>>>>>>>>>>> cache can reply.  It replies in such a way that one could
>>>>>>>>>>>continue
>>>>>>>>>>> talking
>>>>>>>>>>> with that cache to get its TOC.  One would then issue another
>>>>>>>>>>> interest
>>>>>>>>>>> with
>>>>>>>>>>> a request for not-that-cache.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm curious how the TOC approach works in a multi-publisher
>>>>>>>>>>>scenario?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Another approach is to try to ask the authoritative source for
>>>>>>>>>>>the
>>>>>>>>>>> “current”
>>>>>>>>>>> manifest name, i.e. /mail/inbox/current/<nonce>, which could
>>>>>>>>>>>return
>>>>>>>>>>> the
>>>>>>>>>>> manifest or a link to the manifest.  Then fetching the actual
>>>>>>>>>>> manifest
>>>>>>>>>>> from
>>>>>>>>>>> the link could come from caches because you how have a
>>>>>>>>>>>consistent
>>>>>>>>>>> set of
>>>>>>>>>>> names to ask for.  If you cannot talk with an authoritative
>>>>>>>>>>>source,
>>>>>>>>>>> you
>>>>>>>>>>> could try again without the nonce and see if there’s a cached
>>>>>>>>>>>copy
>>>>>>>>>>> of a
>>>>>>>>>>> recent version around.
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 24, 2014, at 5:46 PM, Burke, Jeff
>>>>>>>>>>><jburke at remap.ucla.edu>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/24/14, 8:20 AM, "Ignacio.Solis at parc.com"
>>>>>>>>>>> <Ignacio.Solis at parc.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/24/14, 4:27 AM, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> For example, I see a pattern /mail/inbox/148. I, a human being,
>>>>>>>>>>>see a
>>>>>>>>>>> pattern with static (/mail/inbox) and variable (148)
>>>>>>>>>>>components;
>>>>>>>>>>>with
>>>>>>>>>>> proper naming convention, computers can also detect this
>>>>>>>>>>>pattern
>>>>>>>>>>> easily. Now I want to look for all mails in my inbox. I can
>>>>>>>>>>>generate
>>>>>>>>>>> a
>>>>>>>>>>> list of /mail/inbox/<number>. These are my guesses, and with
>>>>>>>>>>> selectors
>>>>>>>>>>> I can further refine my guesses.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think this is a very bad example  (or at least a very bad
>>>>>>>>>>> application
>>>>>>>>>>> design).  You have an app (a mail server / inbox) and you want
>>>>>>>>>>>it
>>>>>>>>>>>to
>>>>>>>>>>> list
>>>>>>>>>>> your emails?  An email list is an application data structure.
>>>>>>>>>>>I
>>>>>>>>>>> don’t
>>>>>>>>>>> think you should use the network structure to reflect this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think Tai-Lin is trying to sketch a small example, not
>>>>>>>>>>>propose
>>>>>>>>>>>a
>>>>>>>>>>> full-scale approach to email. (Maybe I am misunderstanding.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Another way to look at it is that if the network architecture
>>>>>>>>>>>is
>>>>>>>>>>> providing
>>>>>>>>>>> the equivalent of distributed storage to the application,
>>>>>>>>>>>perhaps
>>>>>>>>>>>the
>>>>>>>>>>> application data structure could be adapted to match the
>>>>>>>>>>>affordances
>>>>>>>>>>> of
>>>>>>>>>>> the network.  Then it would not be so bad that the two
>>>>>>>>>>>structures
>>>>>>>>>>> were
>>>>>>>>>>> aligned.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I’ll give you an example, how do you delete emails from your
>>>>>>>>>>>inbox?
>>>>>>>>>>> If
>>>>>>>>>>> an
>>>>>>>>>>> email was cached in the network it can never be deleted from
>>>>>>>>>>>your
>>>>>>>>>>> inbox?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is conflating two issues - what you are pointing out is
>>>>>>>>>>>that
>>>>>>>>>>>the
>>>>>>>>>>> data
>>>>>>>>>>> structure of a linear list doesn't handle common email
>>>>>>>>>>>management
>>>>>>>>>>> operations well.  Again, I'm not sure if that's what he was
>>>>>>>>>>>getting
>>>>>>>>>>> at
>>>>>>>>>>> here.  But deletion is not the issue - the availability of a
>>>>>>>>>>>data
>>>>>>>>>>> object
>>>>>>>>>>> on the network does not necessarily mean it's valid from the
>>>>>>>>>>> perspective
>>>>>>>>>>> of the application.
>>>>>>>>>>>
>>>>>>>>>>> Or moved to another mailbox? Do you rely on the emails
>>>>>>>>>>>expiring?
>>>>>>>>>>>
>>>>>>>>>>> This problem is true for most (any?) situations where you use
>>>>>>>>>>>network
>>>>>>>>>>> name
>>>>>>>>>>> structure to directly reflect the application data structure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not sure I understand how you make the leap from the example to
>>>>>>>>>>>the
>>>>>>>>>>> general statement.
>>>>>>>>>>>
>>>>>>>>>>> Jeff
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nacho
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 23, 2014 at 2:34 AM,  <Marc.Mosko at parc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Ok, yes I think those would all be good things.
>>>>>>>>>>>
>>>>>>>>>>> One thing to keep in mind, especially with things like time
>>>>>>>>>>>series
>>>>>>>>>>> sensor
>>>>>>>>>>> data, is that people see a pattern and infer a way of doing it.
>>>>>>>>>>> That’s
>>>>>>>>>>> easy
>>>>>>>>>>> for a human :)  But in Discovery, one should assume that one
>>>>>>>>>>>does
>>>>>>>>>>>not
>>>>>>>>>>> know
>>>>>>>>>>> of patterns in the data beyond what the protocols used to
>>>>>>>>>>>publish
>>>>>>>>>>>the
>>>>>>>>>>> data
>>>>>>>>>>> explicitly require.  That said, I think some of the things you
>>>>>>>>>>>listed
>>>>>>>>>>> are
>>>>>>>>>>> good places to start: sensor data, web content, climate data or
>>>>>>>>>>> genome
>>>>>>>>>>> data.
>>>>>>>>>>>
>>>>>>>>>>> We also need to state what the forwarding strategies are and
>>>>>>>>>>>what
>>>>>>>>>>>the
>>>>>>>>>>> cache
>>>>>>>>>>> behavior is.
>>>>>>>>>>>
>>>>>>>>>>> I outlined some of the points that I think are important in
>>>>>>>>>>>that
>>>>>>>>>>> other
>>>>>>>>>>> posting.  While “discover latest” is useful, “discover all” is
>>>>>>>>>>>also
>>>>>>>>>>> important, and that one gets complicated fast.  So points like
>>>>>>>>>>> separating
>>>>>>>>>>> discovery from retrieval and working with large data sets have
>>>>>>>>>>>been
>>>>>>>>>>> important in shaping our thinking.  That all said, I’d be happy
>>>>>>>>>>> starting
>>>>>>>>>>> from 0 and working through the Discovery service definition
>>>>>>>>>>>from
>>>>>>>>>>> scratch
>>>>>>>>>>> along with data set use cases.
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>> On Sep 23, 2014, at 12:36 AM, Burke, Jeff
>>>>>>>>>>><jburke at remap.ucla.edu>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Marc,
>>>>>>>>>>>
>>>>>>>>>>> Thanks ­ yes, I saw that as well. I was just trying to get one
>>>>>>>>>>>step
>>>>>>>>>>> more
>>>>>>>>>>> specific, which was to see if we could identify a few specific
>>>>>>>>>>>use
>>>>>>>>>>> cases
>>>>>>>>>>> around which to have the conversation.  (e.g., time series
>>>>>>>>>>>sensor
>>>>>>>>>>> data
>>>>>>>>>>> and
>>>>>>>>>>> web content retrieval for "get latest"; climate data for huge
>>>>>>>>>>>data
>>>>>>>>>>> sets;
>>>>>>>>>>> local data in a vehicular network; etc.)  What have you been
>>>>>>>>>>>looking
>>>>>>>>>>> at
>>>>>>>>>>> that's driving considerations of discovery?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Jeff
>>>>>>>>>>>
>>>>>>>>>>> From: <Marc.Mosko at parc.com>
>>>>>>>>>>> Date: Mon, 22 Sep 2014 22:29:43 +0000
>>>>>>>>>>> To: Jeff Burke <jburke at remap.ucla.edu>
>>>>>>>>>>> Cc: <tailinchu at gmail.com>, <ndn-interest at lists.cs.ucla.edu>
>>>>>>>>>>> Subject: Re: [Ndn-interest] any comments on naming convention?
>>>>>>>>>>>
>>>>>>>>>>> Jeff,
>>>>>>>>>>>
>>>>>>>>>>> Take a look at my posting (that Felix fixed) in a new thread on
>>>>>>>>>>> Discovery.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-Septemb
>>>>>>>>>>>er
>>>>>>>>>>>/0
>>>>>>>>>>>00
>>>>>>>>>>> 20
>>>>>>>>>>> 0
>>>>>>>>>>> .html
>>>>>>>>>>>
>>>>>>>>>>> I think it would be very productive to talk about what
>>>>>>>>>>>Discovery
>>>>>>>>>>> should
>>>>>>>>>>> do,
>>>>>>>>>>> and not focus on the how.  It is sometimes easy to get caught
>>>>>>>>>>>up
>>>>>>>>>>>in
>>>>>>>>>>> the
>>>>>>>>>>> how,
>>>>>>>>>>> which I think is a less important topic than the what at this
>>>>>>>>>>>stage.
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>> On Sep 22, 2014, at 11:04 PM, Burke, Jeff
>>>>>>>>>>><jburke at remap.ucla.edu>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Marc,
>>>>>>>>>>>
>>>>>>>>>>> If you can't talk about your protocols, perhaps we can discuss
>>>>>>>>>>>this
>>>>>>>>>>> based
>>>>>>>>>>> on use cases.   What are the use cases you are using to
>>>>>>>>>>>evaluate
>>>>>>>>>>> discovery?
>>>>>>>>>>>
>>>>>>>>>>> Jeff
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/21/14, 11:23 AM, "Marc.Mosko at parc.com"
>>>>>>>>>>><Marc.Mosko at parc.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> No matter what the expressiveness of the predicates if the
>>>>>>>>>>>forwarder
>>>>>>>>>>> can
>>>>>>>>>>> send interests different ways you don't have a consistent
>>>>>>>>>>>underlying
>>>>>>>>>>> set
>>>>>>>>>>> to talk about so you would always need non-range exclusions to
>>>>>>>>>>> discover
>>>>>>>>>>> every version.
>>>>>>>>>>>
>>>>>>>>>>> Range exclusions only work I believe if you get an
>>>>>>>>>>>authoritative
>>>>>>>>>>> answer.
>>>>>>>>>>> If different content pieces are scattered between different
>>>>>>>>>>>caches
>>>>>>>>>>>I
>>>>>>>>>>> don't see how range exclusions would work to discover every
>>>>>>>>>>>version.
>>>>>>>>>>>
>>>>>>>>>>> I'm sorry to be pointing out problems without offering
>>>>>>>>>>>solutions
>>>>>>>>>>>but
>>>>>>>>>>> we're not ready to publish our discovery protocols.
>>>>>>>>>>>
>>>>>>>>>>> Sent from my telephone
>>>>>>>>>>>
>>>>>>>>>>> On Sep 21, 2014, at 8:50, "Tai-Lin Chu" <tailinchu at gmail.com>
>>>>>>>>>>>wrote:
>>>>>>>>>>>
>>>>>>>>>>> I see. Can you briefly describe how ccnx discovery protocol
>>>>>>>>>>>solves
>>>>>>>>>>> the
>>>>>>>>>>> all problems that you mentioned (not just exclude)? a doc will
>>>>>>>>>>>be
>>>>>>>>>>> better.
>>>>>>>>>>>
>>>>>>>>>>> My unserious conjecture( :) ) : exclude is equal to [not]. I
>>>>>>>>>>>will
>>>>>>>>>>> soon
>>>>>>>>>>> expect [and] and [or], so boolean algebra is fully supported.
>>>>>>>>>>> Regular
>>>>>>>>>>> language or context free language might become part of selector
>>>>>>>>>>>too.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Sep 20, 2014 at 11:25 PM,  <Marc.Mosko at parc.com> wrote:
>>>>>>>>>>> That will get you one reading then you need to exclude it and
>>>>>>>>>>>ask
>>>>>>>>>>> again.
>>>>>>>>>>>
>>>>>>>>>>> Sent from my telephone
>>>>>>>>>>>
>>>>>>>>>>> On Sep 21, 2014, at 8:22, "Tai-Lin Chu" <tailinchu at gmail.com>
>>>>>>>>>>>wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yes, my point was that if you cannot talk about a consistent
>>>>>>>>>>>set
>>>>>>>>>>> with a particular cache, then you need to always use individual
>>>>>>>>>>> excludes not range excludes if you want to discover all the
>>>>>>>>>>>versions
>>>>>>>>>>> of an object.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I am very confused. For your example, if I want to get all
>>>>>>>>>>>today's
>>>>>>>>>>> sensor data, I just do (Any..Last second of last day)(First
>>>>>>>>>>>second
>>>>>>>>>>>of
>>>>>>>>>>> tomorrow..Any). That's 18 bytes.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [1]http://named-data.net/doc/ndn-tlv/interest.html#exclude
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Sep 20, 2014 at 10:55 PM,  <Marc.Mosko at parc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Sep 21, 2014, at 1:47 AM, Tai-Lin Chu <tailinchu at gmail.com>
>>>>>>>>>>>wrote:
>>>>>>>>>>>
>>>>>>>>>>> If you talk sometimes to A and sometimes to B, you very easily
>>>>>>>>>>> could miss content objects you want to discovery unless you 
>>>>>>>>>>>avoid
>>>>>>>>>>> all range exclusions and only exclude explicit versions.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could you explain why missing content object situation happens?
>>>>>>>>>>>also
>>>>>>>>>>> range exclusion is just a shorter notation for many explicit
>>>>>>>>>>> exclude;
>>>>>>>>>>> converting from explicit excludes to ranged exclude is always
>>>>>>>>>>> possible.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, my point was that if you cannot talk about a consistent 
>>>>>>>>>>>set
>>>>>>>>>>> with a particular cache, then you need to always use individual
>>>>>>>>>>> excludes not range excludes if you want to discover all the
>>>>>>>>>>>versions
>>>>>>>>>>> of an object.  For something like a sensor reading that is
>>>>>>>>>>>updated,
>>>>>>>>>>> say, once per second you will have 86,400 of them per day.  If
>>>>>>>>>>>each
>>>>>>>>>>> exclusion is a timestamp (say 8 bytes), that’s 691,200 bytes of
>>>>>>>>>>> exclusions (plus encoding overhead) per day.
>>>>>>>>>>>
>>>>>>>>>>> yes, maybe using a more deterministic version number than a
>>>>>>>>>>> timestamp makes sense here, but its just an example of needing 
>>>>>>>>>>>a
>>>>>>>>>>>lot
>>>>>>>>>>> of exclusions.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You exclude through 100 then issue a new interest.  This goes 
>>>>>>>>>>>to
>>>>>>>>>>> cache B
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I feel this case is invalid because cache A will also get the
>>>>>>>>>>> interest, and cache A will return v101 if it exists. Like you
>>>>>>>>>>>said,
>>>>>>>>>>> if
>>>>>>>>>>> this goes to cache B only, it means that cache A dies. How do 
>>>>>>>>>>>you
>>>>>>>>>>> know
>>>>>>>>>>> that v101 even exist?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I guess this depends on what the forwarding strategy is.  If 
>>>>>>>>>>>the
>>>>>>>>>>> forwarder will always send each interest to all replicas, then
>>>>>>>>>>>yes,
>>>>>>>>>>> modulo packet loss, you would discover v101 on cache A.  If the
>>>>>>>>>>> forwarder is just doing “best path” and can round-robin between
>>>>>>>>>>>cache
>>>>>>>>>>> A and cache B, then your application could miss v101.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> c,d In general I agree that LPM performance is related to the
>>>>>>>>>>>number
>>>>>>>>>>> of components. In my own thread-safe LMP implementation, I used
>>>>>>>>>>>only
>>>>>>>>>>> one RWMutex for the whole tree. I don't know whether adding 
>>>>>>>>>>>lock
>>>>>>>>>>>for
>>>>>>>>>>> every node will be faster or not because of lock overhead.
>>>>>>>>>>>
>>>>>>>>>>> However, we should compare (exact match + discovery protocol) 
>>>>>>>>>>>vs
>>>>>>>>>>> (ndn
>>>>>>>>>>> lpm). Comparing performance of exact match to lpm is unfair.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, we should compare them.  And we need to publish the ccnx 
>>>>>>>>>>>1.0
>>>>>>>>>>> specs for doing the exact match discovery.  So, as I said, I’m
>>>>>>>>>>>not
>>>>>>>>>>> ready to claim its better yet because we have not done that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Sep 20, 2014 at 2:38 PM,  <Marc.Mosko at parc.com> wrote:
>>>>>>>>>>> I would point out that using LPM on content object to Interest
>>>>>>>>>>> matching to do discovery has its own set of problems.  
>>>>>>>>>>>Discovery
>>>>>>>>>>> involves more than just “latest version” discovery too.
>>>>>>>>>>>
>>>>>>>>>>> This is probably getting off-topic from the original post about
>>>>>>>>>>> naming conventions.
>>>>>>>>>>>
>>>>>>>>>>> a.  If Interests can be forwarded multiple directions and two
>>>>>>>>>>> different caches are responding, the exclusion set you build up
>>>>>>>>>>> talking with cache A will be invalid for cache B.  If you talk
>>>>>>>>>>> sometimes to A and sometimes to B, you very easily could miss
>>>>>>>>>>> content objects you want to discovery unless you avoid all 
>>>>>>>>>>>range
>>>>>>>>>>> exclusions and only exclude explicit versions.  That will lead 
>>>>>>>>>>>to
>>>>>>>>>>> very large interest packets.  In ccnx 1.0, we believe that an
>>>>>>>>>>> explicit discovery protocol that allows conversations about
>>>>>>>>>>> consistent sets is better.
>>>>>>>>>>>
>>>>>>>>>>> b. Yes, if you just want the “latest version” discovery that
>>>>>>>>>>> should be transitive between caches, but imagine this.  You 
>>>>>>>>>>>send
>>>>>>>>>>> Interest #1 to cache A which returns version 100.  You exclude
>>>>>>>>>>> through 100 then issue a new interest.  This goes to cache B 
>>>>>>>>>>>who
>>>>>>>>>>> only has version 99, so the interest times out or is NACK’d.  
>>>>>>>>>>>So
>>>>>>>>>>> you think you have it!  But, cache A already has version 101, 
>>>>>>>>>>>you
>>>>>>>>>>> just don’t know.   If you cannot have a conversation around
>>>>>>>>>>> consistent sets, it seems like even doing latest version
>>>>>>>>>>>discovery
>>>>>>>>>>> is difficult with selector based discovery.  From what I saw in
>>>>>>>>>>> ccnx 0.x, one ended up getting an Interest all the way to the
>>>>>>>>>>> authoritative source because you can never believe an
>>>>>>>>>>>intermediate
>>>>>>>>>>> cache that there’s not something more recent.
>>>>>>>>>>>
>>>>>>>>>>> I’m sure you’ve walked through cases (a) and (b) in ndn, I’d be
>>>>>>>>>>> interest in seeing your analysis.  Case (a) is that a node can
>>>>>>>>>>> correctly discover every version of a name prefix, and (b) is
>>>>>>>>>>>that
>>>>>>>>>>> a node can correctly discover the latest version.  We have not
>>>>>>>>>>> formally compared (or yet published) our discovery protocols 
>>>>>>>>>>>(we
>>>>>>>>>>> have three, 2 for content, 1 for device) compared to selector
>>>>>>>>>>>based
>>>>>>>>>>> discovery, so I cannot yet claim they are better, but they do 
>>>>>>>>>>>not
>>>>>>>>>>> have the non-determinism sketched above.
>>>>>>>>>>>
>>>>>>>>>>> c. Using LPM, there is a non-deterministic number of lookups 
>>>>>>>>>>>you
>>>>>>>>>>> must do in the PIT to match a content object.  If you have a 
>>>>>>>>>>>name
>>>>>>>>>>> tree or a threaded hash table, those don’t all need to be hash
>>>>>>>>>>> lookups, but you need to walk up the name tree for every prefix
>>>>>>>>>>>of
>>>>>>>>>>> the content object name and evaluate the selector predicate.
>>>>>>>>>>> Content Based Networking (CBN) had some some methods to create
>>>>>>>>>>>data
>>>>>>>>>>> structures based on predicates, maybe those would be better.  
>>>>>>>>>>>But
>>>>>>>>>>> in any case, you will potentially need to retrieve many PIT
>>>>>>>>>>>entries
>>>>>>>>>>> if there is Interest traffic for many prefixes of a root.  Even
>>>>>>>>>>>on
>>>>>>>>>>> an Intel system, you’ll likely miss cache lines, so you’ll 
>>>>>>>>>>>have a
>>>>>>>>>>> lot of NUMA access for each one.  In CCNx 1.0, even a naive
>>>>>>>>>>> implementation only requires at most 3 lookups (one by name, 
>>>>>>>>>>>one
>>>>>>>>>>>by
>>>>>>>>>>> name + keyid, one by name + content object hash), and one can 
>>>>>>>>>>>do
>>>>>>>>>>> other things to optimize lookup for an extra write.
>>>>>>>>>>>
>>>>>>>>>>> d. In (c) above, if you have a threaded name tree or are just
>>>>>>>>>>> walking parent pointers, I suspect you’ll need locking of the
>>>>>>>>>>> ancestors in a multi-threaded system (“threaded" here meaning
>>>>>>>>>>>LWP)
>>>>>>>>>>> and that will be expensive.  It would be interesting to see 
>>>>>>>>>>>what
>>>>>>>>>>>a
>>>>>>>>>>> cache consistent multi-threaded name tree looks like.
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 20, 2014, at 8:15 PM, Tai-Lin Chu <tailinchu at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I had thought about these questions, but I want to know your 
>>>>>>>>>>>idea
>>>>>>>>>>> besides typed component:
>>>>>>>>>>> 1. LPM allows "data discovery". How will exact match do similar
>>>>>>>>>>> things?
>>>>>>>>>>> 2. will removing selectors improve performance? How do we use
>>>>>>>>>>> other
>>>>>>>>>>> faster technique to replace selector?
>>>>>>>>>>> 3. fixed byte length and type. I agree more that type can be
>>>>>>>>>>>fixed
>>>>>>>>>>> byte, but 2 bytes for length might not be enough for future.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Sep 20, 2014 at 5:36 AM, Dave Oran (oran)
>>>>>>>>>>> <oran at cisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Sep 18, 2014, at 9:09 PM, Tai-Lin Chu <tailinchu at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I know how to make #2 flexible enough to do what things I can
>>>>>>>>>>> envision we need to do, and with a few simple conventions on
>>>>>>>>>>> how the registry of types is managed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could you share it with us?
>>>>>>>>>>>
>>>>>>>>>>> Sure. Here’s a strawman.
>>>>>>>>>>>
>>>>>>>>>>> The type space is 16 bits, so you have 65,565 types.
>>>>>>>>>>>
>>>>>>>>>>> The type space is currently shared with the types used for the
>>>>>>>>>>> entire protocol, that gives us two options:
>>>>>>>>>>> (1) we reserve a range for name component types. Given the
>>>>>>>>>>> likelihood there will be at least as much and probably more 
>>>>>>>>>>>need
>>>>>>>>>>> to component types than protocol extensions, we could reserve 
>>>>>>>>>>>1/2
>>>>>>>>>>> of the type space, giving us 32K types for name components.
>>>>>>>>>>> (2) since there is no parsing ambiguity between name components
>>>>>>>>>>> and other fields of the protocol (sine they are sub-types of 
>>>>>>>>>>>the
>>>>>>>>>>> name type) we could reuse numbers and thereby have an entire 
>>>>>>>>>>>65K
>>>>>>>>>>> name component types.
>>>>>>>>>>>
>>>>>>>>>>> We divide the type space into regions, and manage it with a
>>>>>>>>>>> registry. If we ever get to the point of creating an IETF
>>>>>>>>>>> standard, IANA has 25 years of experience running registries 
>>>>>>>>>>>and
>>>>>>>>>>> there are well-understood rule sets for different kinds of
>>>>>>>>>>> registries (open, requires a written spec, requires standards
>>>>>>>>>>> approval).
>>>>>>>>>>>
>>>>>>>>>>> - We allocate one “default" name component type for “generic
>>>>>>>>>>> name”, which would be used on name prefixes and other common
>>>>>>>>>>> cases where there are no special semantics on the name 
>>>>>>>>>>>component.
>>>>>>>>>>> - We allocate a range of name component types, say 1024, to
>>>>>>>>>>> globally understood types that are part of the base or 
>>>>>>>>>>>extension
>>>>>>>>>>> NDN specifications (e.g. chunk#, version#, etc.
>>>>>>>>>>> - We reserve some portion of the space for unanticipated uses
>>>>>>>>>>> (say another 1024 types)
>>>>>>>>>>> - We give the rest of the space to application assignment.
>>>>>>>>>>>
>>>>>>>>>>> Make sense?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> While I’m sympathetic to that view, there are three ways in
>>>>>>>>>>> which Moore’s law or hardware tricks will not save us from
>>>>>>>>>>> performance flaws in the design
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> we could design for performance,
>>>>>>>>>>>
>>>>>>>>>>> That’s not what people are advocating. We are advocating that 
>>>>>>>>>>>we
>>>>>>>>>>> *not* design for known bad performance and hope serendipity or
>>>>>>>>>>> Moore’s Law will come to the rescue.
>>>>>>>>>>>
>>>>>>>>>>> but I think there will be a turning
>>>>>>>>>>> point when the slower design starts to become "fast enough”.
>>>>>>>>>>>
>>>>>>>>>>> Perhaps, perhaps not. Relative performance is what matters so
>>>>>>>>>>> things that don’t get faster while others do tend to get 
>>>>>>>>>>>dropped
>>>>>>>>>>> or not used because they impose a performance penalty relative 
>>>>>>>>>>>to
>>>>>>>>>>> the things that go faster. There is also the “low-end” 
>>>>>>>>>>>phenomenon
>>>>>>>>>>> where impovements in technology get applied to lowering cost
>>>>>>>>>>> rather than improving performance. For those environments bad
>>>>>>>>>>> performance just never get better.
>>>>>>>>>>>
>>>>>>>>>>> Do you
>>>>>>>>>>> think there will be some design of ndn that will *never* have
>>>>>>>>>>> performance improvement?
>>>>>>>>>>>
>>>>>>>>>>> I suspect LPM on data will always be slow (relative to the 
>>>>>>>>>>>other
>>>>>>>>>>> functions).
>>>>>>>>>>> i suspect exclusions will always be slow because they will
>>>>>>>>>>> require extra memory references.
>>>>>>>>>>>
>>>>>>>>>>> However I of course don’t claim to clairvoyance so this is just
>>>>>>>>>>> speculation based on 35+ years of seeing performance improve 
>>>>>>>>>>>by 4
>>>>>>>>>>> orders of magnitude and still having to worry about counting
>>>>>>>>>>> cycles and memory references…
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 18, 2014 at 5:20 PM, Dave Oran (oran)
>>>>>>>>>>> <oran at cisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Sep 18, 2014, at 7:41 PM, Tai-Lin Chu
>>>>>>>>>>> <tailinchu at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> We should not look at a certain chip nowadays and want ndn to
>>>>>>>>>>> perform
>>>>>>>>>>> well on it. It should be the other way around: once  ndn app
>>>>>>>>>>> becomes
>>>>>>>>>>> popular, a better chip will be designed for ndn.
>>>>>>>>>>>
>>>>>>>>>>> While I’m sympathetic to that view, there are three ways in
>>>>>>>>>>> which Moore’s law or hardware tricks will not save us from
>>>>>>>>>>> performance flaws in the design:
>>>>>>>>>>> a) clock rates are not getting (much) faster
>>>>>>>>>>> b) memory accesses are getting (relatively) more expensive
>>>>>>>>>>> c) data structures that require locks to manipulate
>>>>>>>>>>> successfully will be relatively more expensive, even with
>>>>>>>>>>> near-zero lock contention.
>>>>>>>>>>>
>>>>>>>>>>> The fact is, IP *did* have some serious performance flaws in
>>>>>>>>>>> its design. We just forgot those because the design elements
>>>>>>>>>>> that depended on those mistakes have fallen into disuse. The
>>>>>>>>>>> poster children for this are:
>>>>>>>>>>> 1. IP options. Nobody can use them because they are too slow
>>>>>>>>>>> on modern forwarding hardware, so they can’t be reliably used
>>>>>>>>>>> anywhere
>>>>>>>>>>> 2. the UDP checksum, which was a bad design when it was
>>>>>>>>>>> specified and is now a giant PITA that still causes major pain
>>>>>>>>>>> in working around.
>>>>>>>>>>>
>>>>>>>>>>> I’m afraid students today are being taught the that designers
>>>>>>>>>>> of IP were flawless, as opposed to very good scientists and
>>>>>>>>>>> engineers that got most of it right.
>>>>>>>>>>>
>>>>>>>>>>> I feel the discussion today and yesterday has been off-topic.
>>>>>>>>>>> Now I
>>>>>>>>>>> see that there are 3 approaches:
>>>>>>>>>>> 1. we should not define a naming convention at all
>>>>>>>>>>> 2. typed component: use tlv type space and add a handful of
>>>>>>>>>>> types
>>>>>>>>>>> 3. marked component: introduce only one more type and add
>>>>>>>>>>> additional
>>>>>>>>>>> marker space
>>>>>>>>>>>
>>>>>>>>>>> I know how to make #2 flexible enough to do what things I can
>>>>>>>>>>> envision we need to do, and with a few simple conventions on
>>>>>>>>>>> how the registry of types is managed.
>>>>>>>>>>>
>>>>>>>>>>> It is just as powerful in practice as either throwing up our
>>>>>>>>>>> hands and letting applications design their own mutually
>>>>>>>>>>> incompatible schemes or trying to make naming conventions with
>>>>>>>>>>> markers in a way that is fast to generate/parse and also
>>>>>>>>>>> resilient against aliasing.
>>>>>>>>>>>
>>>>>>>>>>> Also everybody thinks that the current utf8 marker naming
>>>>>>>>>>> convention
>>>>>>>>>>> needs to be revised.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 18, 2014 at 3:27 PM, Felix Rabe <felix at rabe.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Would that chip be suitable, i.e. can we expect most names
>>>>>>>>>>> to fit in (the
>>>>>>>>>>> magnitude of) 96 bytes? What length are names usually in
>>>>>>>>>>> current NDN
>>>>>>>>>>> experiments?
>>>>>>>>>>>
>>>>>>>>>>> I guess wide deployment could make for even longer names.
>>>>>>>>>>> Related: Many URLs
>>>>>>>>>>> I encounter nowadays easily don't fit within two 80-column
>>>>>>>>>>> text lines, and
>>>>>>>>>>> NDN will have to carry more information than URLs, as far as
>>>>>>>>>>> I see.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 18/Sep/14 23:15, Marc.Mosko at parc.com wrote:
>>>>>>>>>>>
>>>>>>>>>>> In fact, the index in separate TLV will be slower on some
>>>>>>>>>>> architectures,
>>>>>>>>>>> like the ezChip NP4.  The NP4 can hold the fist 96 frame
>>>>>>>>>>> bytes in memory,
>>>>>>>>>>> then any subsequent memory is accessed only as two adjacent
>>>>>>>>>>> 32-byte blocks
>>>>>>>>>>> (there can be at most 5 blocks available at any one time).
>>>>>>>>>>> If you need to
>>>>>>>>>>> switch between arrays, it would be very expensive.  If you
>>>>>>>>>>> have to read past
>>>>>>>>>>> the name to get to the 2nd array, then read it, then backup
>>>>>>>>>>> to get to the
>>>>>>>>>>> name, it will be pretty expensive too.
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>> On Sep 18, 2014, at 2:02 PM, <Ignacio.Solis at parc.com>
>>>>>>>>>>> <Ignacio.Solis at parc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Does this make that much difference?
>>>>>>>>>>>
>>>>>>>>>>> If you want to parse the first 5 components. One way to do
>>>>>>>>>>> it is:
>>>>>>>>>>>
>>>>>>>>>>> Read the index, find entry 5, then read in that many bytes
>>>>>>>>>>> from the start
>>>>>>>>>>> offset of the beginning of the name.
>>>>>>>>>>> OR
>>>>>>>>>>> Start reading name, (find size + move ) 5 times.
>>>>>>>>>>>
>>>>>>>>>>> How much speed are you getting from one to the other?  You
>>>>>>>>>>> seem to imply
>>>>>>>>>>> that the first one is faster.  I don¹t think this is the
>>>>>>>>>>> case.
>>>>>>>>>>>
>>>>>>>>>>> In the first one you¹ll probably have to get the cache line
>>>>>>>>>>> for the index,
>>>>>>>>>>> then all the required cache lines for the first 5
>>>>>>>>>>> components. For the
>>>>>>>>>>> second, you¹ll have to get all the cache lines for the first
>>>>>>>>>>> 5 components.
>>>>>>>>>>> Given an assumption that a cache miss is way more expensive
>>>>>>>>>>> than
>>>>>>>>>>> evaluating a number and computing an addition, you might
>>>>>>>>>>> find that the
>>>>>>>>>>> performance of the index is actually slower than the
>>>>>>>>>>> performance of the
>>>>>>>>>>> direct access.
>>>>>>>>>>>
>>>>>>>>>>> Granted, there is a case where you don¹t access the name at
>>>>>>>>>>> all, for
>>>>>>>>>>> example, if you just get the offsets and then send the
>>>>>>>>>>> offsets as
>>>>>>>>>>> parameters to another processor/GPU/NPU/etc. In this case
>>>>>>>>>>> you may see a
>>>>>>>>>>> gain IF there are more cache line misses in reading the name
>>>>>>>>>>> than in
>>>>>>>>>>> reading the index.   So, if the regular part of the name
>>>>>>>>>>> that you¹re
>>>>>>>>>>> parsing is bigger than the cache line (64 bytes?) and the
>>>>>>>>>>> name is to be
>>>>>>>>>>> processed by a different processor, then your might see some
>>>>>>>>>>> performance
>>>>>>>>>>> gain in using the index, but in all other circumstances I
>>>>>>>>>>> bet this is not
>>>>>>>>>>> the case.   I may be wrong, haven¹t actually tested it.
>>>>>>>>>>>
>>>>>>>>>>> This is all to say, I don¹t think we should be designing the
>>>>>>>>>>> protocol with
>>>>>>>>>>> only one architecture in mind. (The architecture of sending
>>>>>>>>>>> the name to a
>>>>>>>>>>> different processor than the index).
>>>>>>>>>>>
>>>>>>>>>>> If you have numbers that show that the index is faster I
>>>>>>>>>>> would like to see
>>>>>>>>>>> under what conditions and architectural assumptions.
>>>>>>>>>>>
>>>>>>>>>>> Nacho
>>>>>>>>>>>
>>>>>>>>>>> (I may have misinterpreted your description so feel free to
>>>>>>>>>>> correct me if
>>>>>>>>>>> I¹m wrong.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Nacho (Ignacio) Solis
>>>>>>>>>>> Protocol Architect
>>>>>>>>>>> Principal Scientist
>>>>>>>>>>> Palo Alto Research Center (PARC)
>>>>>>>>>>> +1(650)812-4458
>>>>>>>>>>> Ignacio.Solis at parc.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/18/14, 12:54 AM, "Massimo Gallo"
>>>>>>>>>>> <massimo.gallo at alcatel-lucent.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Indeed each components' offset must be encoded using a fixed
>>>>>>>>>>> amount of
>>>>>>>>>>> bytes:
>>>>>>>>>>>
>>>>>>>>>>> i.e.,
>>>>>>>>>>> Type = Offsets
>>>>>>>>>>> Length = 10 Bytes
>>>>>>>>>>> Value = Offset1(1byte), Offset2(1byte), ...
>>>>>>>>>>>
>>>>>>>>>>> You may also imagine to have a "Offset_2byte" type if your
>>>>>>>>>>> name is too
>>>>>>>>>>> long.
>>>>>>>>>>>
>>>>>>>>>>> Max
>>>>>>>>>>>
>>>>>>>>>>> On 18/09/2014 09:27, Tai-Lin Chu wrote:
>>>>>>>>>>>
>>>>>>>>>>> if you do not need the entire hierarchal structure (suppose
>>>>>>>>>>> you only
>>>>>>>>>>> want the first x components) you can directly have it using
>>>>>>>>>>> the
>>>>>>>>>>> offsets. With the Nested TLV structure you have to
>>>>>>>>>>> iteratively parse
>>>>>>>>>>> the first x-1 components. With the offset structure you cane
>>>>>>>>>>> directly
>>>>>>>>>>> access to the firs x components.
>>>>>>>>>>>
>>>>>>>>>>> I don't get it. What you described only works if the
>>>>>>>>>>> "offset" is
>>>>>>>>>>> encoded in fixed bytes. With varNum, you will still need to
>>>>>>>>>>> parse x-1
>>>>>>>>>>> offsets to get to the x offset.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo
>>>>>>>>>>> <massimo.gallo at alcatel-lucent.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 17/09/2014 14:56, Mark Stapp wrote:
>>>>>>>>>>>
>>>>>>>>>>> ah, thanks - that's helpful. I thought you were saying "I
>>>>>>>>>>> like the
>>>>>>>>>>> existing NDN UTF8 'convention'." I'm still not sure I
>>>>>>>>>>> understand what
>>>>>>>>>>> you
>>>>>>>>>>> _do_ prefer, though. it sounds like you're describing an
>>>>>>>>>>> entirely
>>>>>>>>>>> different
>>>>>>>>>>> scheme where the info that describes the name-components is
>>>>>>>>>>> ...
>>>>>>>>>>> someplace
>>>>>>>>>>> other than _in_ the name-components. is that correct? when
>>>>>>>>>>> you say
>>>>>>>>>>> "field
>>>>>>>>>>> separator", what do you mean (since that's not a "TL" from a
>>>>>>>>>>> TLV)?
>>>>>>>>>>>
>>>>>>>>>>> Correct.
>>>>>>>>>>> In particular, with our name encoding, a TLV indicates the
>>>>>>>>>>> name
>>>>>>>>>>> hierarchy
>>>>>>>>>>> with offsets in the name and other TLV(s) indicates the
>>>>>>>>>>> offset to use
>>>>>>>>>>> in
>>>>>>>>>>> order to retrieve special components.
>>>>>>>>>>> As for the field separator, it is something like "/".
>>>>>>>>>>> Aliasing is
>>>>>>>>>>> avoided as
>>>>>>>>>>> you do not rely on field separators to parse the name; you
>>>>>>>>>>> use the
>>>>>>>>>>> "offset
>>>>>>>>>>> TLV " to do that.
>>>>>>>>>>>
>>>>>>>>>>> So now, it may be an aesthetic question but:
>>>>>>>>>>>
>>>>>>>>>>> if you do not need the entire hierarchal structure (suppose
>>>>>>>>>>> you only
>>>>>>>>>>> want
>>>>>>>>>>> the first x components) you can directly have it using the
>>>>>>>>>>> offsets.
>>>>>>>>>>> With the
>>>>>>>>>>> Nested TLV structure you have to iteratively parse the first
>>>>>>>>>>> x-1
>>>>>>>>>>> components.
>>>>>>>>>>> With the offset structure you cane directly access to the
>>>>>>>>>>> firs x
>>>>>>>>>>> components.
>>>>>>>>>>>
>>>>>>>>>>> Max
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- Mark
>>>>>>>>>>>
>>>>>>>>>>> On 9/17/14 6:02 AM, Massimo Gallo wrote:
>>>>>>>>>>>
>>>>>>>>>>> The why is simple:
>>>>>>>>>>>
>>>>>>>>>>> You use a lot of "generic component type" and very few
>>>>>>>>>>> "specific
>>>>>>>>>>> component type". You are imposing types for every component
>>>>>>>>>>> in order
>>>>>>>>>>> to
>>>>>>>>>>> handle few exceptions (segmentation, etc..). You create a
>>>>>>>>>>> rule
>>>>>>>>>>> (specify
>>>>>>>>>>> the component's type ) to handle exceptions!
>>>>>>>>>>>
>>>>>>>>>>> I would prefer not to have typed components. Instead I would
>>>>>>>>>>> prefer
>>>>>>>>>>> to
>>>>>>>>>>> have the name as simple sequence bytes with a field
>>>>>>>>>>> separator. Then,
>>>>>>>>>>> outside the name, if you have some components that could be
>>>>>>>>>>> used at
>>>>>>>>>>> network layer (e.g. a TLV field), you simply need something
>>>>>>>>>>> that
>>>>>>>>>>> indicates which is the offset allowing you to retrieve the
>>>>>>>>>>> version,
>>>>>>>>>>> segment, etc in the name...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Max
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 16/09/2014 20:33, Mark Stapp wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/16/14 10:29 AM, Massimo Gallo wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think we agree on the small number of "component types".
>>>>>>>>>>> However, if you have a small number of types, you will end
>>>>>>>>>>> up with
>>>>>>>>>>> names
>>>>>>>>>>> containing many generic components types and few specific
>>>>>>>>>>> components
>>>>>>>>>>> types. Due to the fact that the component type specification
>>>>>>>>>>> is an
>>>>>>>>>>> exception in the name, I would prefer something that specify
>>>>>>>>>>> component's
>>>>>>>>>>> type only when needed (something like UTF8 conventions but
>>>>>>>>>>> that
>>>>>>>>>>> applications MUST use).
>>>>>>>>>>>
>>>>>>>>>>> so ... I can't quite follow that. the thread has had some
>>>>>>>>>>> explanation
>>>>>>>>>>> about why the UTF8 requirement has problems (with aliasing,
>>>>>>>>>>> e.g.)
>>>>>>>>>>> and
>>>>>>>>>>> there's been email trying to explain that applications don't
>>>>>>>>>>> have to
>>>>>>>>>>> use types if they don't need to. your email sounds like "I
>>>>>>>>>>> prefer
>>>>>>>>>>> the
>>>>>>>>>>> UTF8 convention", but it doesn't say why you have that
>>>>>>>>>>> preference in
>>>>>>>>>>> the face of the points about the problems. can you say why
>>>>>>>>>>> it is
>>>>>>>>>>> that
>>>>>>>>>>> you express a preference for the "convention" with problems ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ndn-interest mailing list
>>>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ndn-interest mailing list
>>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ndn-interest mailing list
>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ndn-interest mailing list
>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Ndn-interest mailing list
>>>>>Ndn-interest at lists.cs.ucla.edu
>>>>>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>
>>>>
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>_______________________________________________
>>>Ndn-interest mailing list
>>>Ndn-interest at lists.cs.ucla.edu
>>>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>