[Ndn-interest] spec 0.3

Junxiao Shi shijunxiao at email.arizona.edu
Fri Mar 2 04:49:35 PST 2018


Hi Christian

The new spec is indeed interesting, one already feels that this will
> lead to leaner code!

It’s leaner *forwarder* code. The case could be different in *application*
 side.
For example: https://redmine.named-data.net/issues/4396

I wonder about the terminology of "prefix name, exact name and full
> name", whether a semantic denotation instead one based on the match
> mechanics would have been easier to understand, and simpler.
>
> One could have used:
> - name :== forwarding hint with an optional digest
> - forwarding hint :== one or more name component
> - digest :== sha256 value


The current goal is to clearly explain the semantics, not to use the most
concise EBNF. It would be confusing if Name is built upon forwarding hint.
At EBNF level, this definition is wrong. First,
ImplicitSha256DigestComponent *is-a* NameComponent, so your “forwarding
hint” can still contain a digest. Second, the actual ForwardingHint is a
sequence of Delegations.

because prefix name and exact name are the same, and nothing more than
> this: a forwarding hint where one OR MORE data object may satisfy such
> an name.

A name is not a forwarding hint. The “forwarding hint” directs Interest to
a certain network region. Its delegation is not a prefix of Data name.
Please read “Link object” section and Alex’s dissertation
https://irl.cs.ucla.edu/data/files/theses/afanasyev-thesis.pdf for more
information.

Of course there is the additional requirement that the name
> components must match (prefixly or exactly) those in the data object.
> But this is now captured in the "canBePrefix" element, right?
>
> The definition above, with only one sort of names instead of three,
> would be usable for "nameless objects" (which are not captured in spec
> 0.3) where there are no name components to match, only the digest. I
> understand that this would also imply a change in the matching logic,
> for example a rule saying that the digest always trumps.

Nameless objects are always possible. Interest name must have at least one
component, which could be an ImplicitSha256DigestComponent. Data name has
zero component, and the forwarder could use this Data to satisfy an
Interest with the Data’s digest.
However, due to lack of hierarchical components in the Interest name,
Interest forwarding has to rely on flooding or a hierarchical name in
forwarding hint. It is also prohibitively expensive for every forwarder to
compute Data digest to find which Interest it could match.

PS: Perhaps an overlooked reference to selectors, to be cleaned up? In the
> Name section:
>    ", either as the last component of Interest Name to request
>     a specific Data packet, or in the Exclude selector to exclude
>     specific Data packet(s)"

Recorded as https://redmine.named-data.net/issues/4444#note-3

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20180302/16a5c0f5/attachment-0001.html>


More information about the Ndn-interest mailing list