[Ndn-interest] any comments on naming convention?

Burke, Jeff jburke at remap.ucla.edu
Mon Sep 22 15:11:58 PDT 2014


Hi Nacho,

>
>Discovery is needed, but what we need is not ³forwarder-level² discovery.

Can you share with the list some use cases that can be employed to
evaluate this statement? i.e., In what you have looked at, are there *no*
applications that can benefit, or only some without sufficient impact?

>Finally, it¹s unlikely that medium and big routers will implement LPM and
>selector matching.  Cisco doesn¹t think they work, Alcatel-Lucent doesn¹t
>think they work, PARC doesn't think they work;  Huawei, what do you think?
> Ericsson? Juniper?  Anybody?
> 

There seem to be at least three threads of equally valid work here: 1)
what can applications benefit from; 2) how effective are the proposed
architectural abstractions in providing those benefits; 3) how efficiently
(and where in the architecture) can one implement what works well for a
broad range of applications?  This thread seems to be barreling around the
third question without (at least from what I can tell) a lot about the
first two.  

Marc mentioned that it's not possible for PARC to share the discovery
alternative that you are thinking of, so I'm not sure how to compare
solutions. But perhaps we can look at use cases.

The types of applications that we have been considering most recently were
outlined at NDNComm. In the long run, we plan to evaluate those use cases
from the application development perspective by adapting usability
frameworks like Green & Petre's cognitive dimensions framework.  [1]
Certainly performance--whether measured by round trips, application CPU
cycles, router requirements, etc.  is also important and will be
evaluated, but other aspects of application development play a significant
role here. In addition to the use cases, are you able to talk about how
you are comparing the impact on application design and deployment?

>IF your argument is that selectors are useful because they are used for
>discovery, then why not use real selectors that implement full regular
>expressions?  Why not a full query language?
>
>In terms of performance, what is the current limit on selectors?  How many
>excludes can I have? (And what effect does that have on router
>performance?) Are these enough? How many roundtrips do I need to take to
>discover the data that I want?    I¹ve always found this a funny argument
>because you¹re basically saying: I¹m not sure what I want (hence the
>discovery protocol), but I¹ll know what I want when I see it.

To me, part of the innovation of ICN architectures like NDN and CCN is
that they are data dissemination focused and as a result different
consumption patterns can be applied to the same data.  e.g., One
application's real-time video stream is another's archival playout is
another's multi-segment file to transfer.

 So if a small number of Interest selectors allow a simplification of
interoperability between applications by enabling them to use the same
patterns with a wide variety of data from both live and historical
producers, this is a really significant benefit... especially in a
research context that (for us) is encouraged by NSF to be application
driven.  One can always create a discovery protocol that directly talks to
end nodes in NDN, but this doesn't necessarily negate the usefulness of
selectors. If they end up broadly useful, perhaps we need to push on where
and how they can be implemented a little more.

Also, I wonder if the dichotomy between "exact match" and "wander the
namespace" could be misleading. What about other application-level
primitives like "best effort for fresh content", which seems natural for
some web browsing, or search applications that use sortable feature
vectors as names and LPM+selectors to implement nearest neighbor matches.
These are some nice possibilities for NDN. Sure, they can all be done with
explicit protocols, but perhaps there more tradeoffs such as publisher
load or more roundtrips in those cases.  Seems like there is still room
for comparison and discussion by looking at where selectors work well in
addition to where they appear to have problems.


>
>Well, maybe if you had a real protocol that could specify what you wanted
>you would have gotten it in one round trip. So this is general protocol
>performance.

Not knowing exactly what you mean by a "real protocol" it seems to involve
either some reliance on direct interaction with the producer or with
caches that are deemed authoritative (which in turn brings up the
latest-matching problem in and of itself). Could you clarify what you mean
by "real" and whether it involves either of these?  If the former, you're
trading publisher load for round trips, which can again can be done in NDN
anyway (e.g., protocols that pose discovery questions to end nodes).

But I am a little confused about the emphasis on round-trips with no
context here.  If NDN is proposed to replace Layer 2, is the optimization
of a single packet round-trip for an as-yet-undefined use case the gold
standard?  Can we identify the number of IP round trips in a specific
application or two as a point of comparison?

Thanks,
Jeff

[1] Green, Thomas R. G., and Marian Petre. "Usability analysis of visual
programming environments: a
Œcognitive dimensions¹ framework." Journal of Visual Languages & Computing
7.2 (1996): 131-174.






More information about the Ndn-interest mailing list