[Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy?

Dave Oran (oran) oran at cisco.com
Tue Mar 15 12:11:58 PDT 2016


> On Mar 15, 2016, at 10:58 AM, Alex Afanasyev <aa at CS.UCLA.EDU> wrote:
> 
>> 
>> On Mar 15, 2016, at 10:43 AM, <Ignacio.Solis at parc.com> <Ignacio.Solis at parc.com> wrote:
>> 
>> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" <ndn-interest-bounces at lists.cs.ucla.edu on behalf of jburke at remap.UCLA.edu> wrote:
>> 
[SNIP]

>> Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit?
> 
> In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery.  There is simply no way it is possible to have an "oracle" that can tell you what is there.
> 
I disagree.
The requirement is that within any partition of the network that needs to operate autonomously, there has to be a service instance that can answer bootstrapping/discovery queries. The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) then in-network discover mechanisms will fail. Further, if in order to obtain an useful bootstrapping data you have to flood rather than route to a discovery service, there are some obvious scalability and DDoS concerns.

> I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery.
We need a crisp definition  of an “immutable data packet” to continue this discussion productively. If the only immutable property is on hash-based names and you ONLY can request data by hash-name, then you have only immutable packets. On the other hand, if you can have different packets, with different hashes, that bind the same name (minus the hash) to different data, the useful application-meaningful data is not immutable. It’s also important to add time to the semantics here, such that applications may operatie correctly if and only if there is only one *unexpired* packet with a given name emitted by a publisher in a given expiration period.

>  The communication will not work otherwise without having an out-of-band channel to tell you what to fetch.  What is the best way to achieve this is a completely different question.
> 
> And a note note.  It is not LPM!  It is fetching data with interests that don't have a full name (if needed with hash digest.
Actually, this is an interesting point. Are you saying you can return *ANY* prefix match? If so, I don’t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets (which might be needed in practice even *with* LPM).


> 
> ---
> Alex
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160315/8bd81f9e/attachment.bin>


More information about the Ndn-interest mailing list