[icnrg] Some comments on the CCNx Selectors draft (https://datatracker.ietf.org/doc/draft-mosko-icnrg-selectors/)

["David R. Oran" <[e-mail]>]

All comments with <chair hat off>

Content discovery is important, so I’d like to see something adopted 
by the RG for formal progression to experimental.

I’d like to step back a bit though and ask if evolving the approach in 
CCNx 0.x and NDN is appropriate knowing what we’ve learned in the last 
few years. The current selectors draft 
(https://datatracker.ietf.org/doc/draft-mosko-icnrg-selectors/) 
basically fixes the original design mistake of forcing all forwarders to 
do discovery through prefix match on CS data. It does this by leveraging 
typed name components and using an encapsulation technique so that 
whatever object that matches the selectors can be returned as 
“native” - with its original name and signature.

On the other hand, it still has the following properties:

- returns only one object when multiple might match

- does not have a completely deterministic answer in the presence of 
cache/repo/producer instance desynchronization (not clear this is 
avoidable since we have a distributed system with at best eventual 
consistency semantics)

- requires exclusions, which can make for big interests that in turn 
causes fragmentation to be needed and complicates congestion control as 
a consequence.

- seems to still permit cache exploration (since the selector interests 
are not authenticated), which might be viewed as a privacy problem.

I don’t have a concrete proposal to make though. Here are a few 
thoughts about a possible alternative approach:

- Since we depend a lot more on Manifests now that the original NDN & 
CCNx 0.x designs, why not have the discovery return a Manifest instead 
of a single encapsulated object?

- Since we have fast exact match and nameless objects along with now 
permitting objects to have multiple names and hence multiple ways 
objects can be discovered, perhaps we can exploit that to allow 
different discovery patterns rather than smooshing everything into a 
static/brittle set of selectors

- Some of the properties were driven by trying to make discovery cheap 
and ubiquitous and hence forced into casting discovery as a direct 
single Interest/Data exchange. Since we now know that pawing through a 
large CS or Repo can be computational expensive (and even require a fair 
amount of I/O), maybe this tradeoff isn’t attractive. We now have 
experience with distributed method invocation (e.g. NFN and RICE) so 
maybe we do discovery as an explicit remote method. This may solve a few 
problems:

	- We can do authentication and key exchange, so discovery operations 
and results can be more private and cache exploration is no longer a 
hazard

	- It might make it easier to build extensibility into the supported 
discovery patterns as all of them might not need to be supported by all 
discovery services. (Aside - it seems that a similar direction is being 
taken in the fast-repo work for NDN, where a given application can 
design patterns for the Repo to fetch the right stuff for storage of 
that application’s data).

	- We can more easily manage the resources for expensive discovery 
operations, and following the idea of using Manifests, make those the 
result of the discovery computation.
	- By essentially “binding” to one of the discovery 
services/servers, it may be possible to get a more internally-consistent 
set of results.

Yes, this might make discovery a lot more “expensive” in terms of 
RTTs but in the end it might also make applications easier to write with 
patterns that look more like what the application considers “native” 
and the results as a Manifest easier to paw through and possibly iterate 
on.

Thoughts?

DaveO