[Ndn-interest] use cases of manifest objects in NDN

[Tai-Lin Chu]

sorry for the confusion. metadata can also be used to discover name.
Imagine metadata as a pointer to a list of data.

>Why do you need this orthogonality ?

Orthogonality is always nice to have, and it also makes name matches
what it actually is.

My proposal is based on exact matching but converting to lpm is just
relaxing the constraints. To me, if we add metadata, we don't need
lpm(also selectors because it is highly coupled with lpm) and
FinalBlockId. (exact matching + metadata) not only improves
performance of verification, but also allows us to remove many things.

1. every interest will return one of 3 types of packets: data,
metadata and nack. (still 1-1 relation)
data is used if there is only 1 data packet that matches. metadata is
used when there are more than 1: for either segmentation or children.
nack is for data not found.

2. the metadata contains a list of pair(suffix, digest) for quicker
verification. Note it is just suffix not the full name. Because we
also enforce 1-1 relation and we might have too many suffixes to
segment, this suggests that "metadata about metadata" should be
considered valid. I do not see this in the tr.

3. so what do I envision here? metadata tells consumer a data-fetching
tree, which has internal node as meta data and leaves as data. In most
cases this tree is very shallow but wide. We only need to verify
pubkey once at the root. Because we will know all names in metadata,
this allows parallel fetching. Therefore, finalblockId is then
obsolete.








On Tue, Oct 7, 2014 at 9:55 AM, Ilya Moiseenko <iliamo at ucla.edu> wrote:
>
>> 1. This reminds me of the discovery protocol that parc talks about.
>> metadata for data discovery, maybe?
>
> There is no discovery phase. Name is known a priori, only segment number component is computed dynamically.
>
>> 2. how do you differentiate metadata from data? contentType?
>
> Yes, I defined a new contentType.
>
>> 3. can we leave /a/b/<id> just for data segments for orthogonality?
>
> Why do you need this orthogonality ?
>
> Ilya
>
>>
>> On Mon, Oct 6, 2014 at 1:21 PM, Ilya Moiseenko <iliamo at ucla.edu> wrote:
>>> Hi all,
>>> while working on some of the research projects / demos / apps, many people noticed that there is a potential or real benefit of using information objects that do not carry any content, but instead carry useful meta-information about some other Data packets. Right now, these “supportive” objects are usually called Manifests.
>>>
>>> One particular use case of manifests is speeding up signing and verification of multiple Data packets. The speed-up comes from the fact that instead of signing each Data packet using public key crypto methods, the Data packets can be secured by much faster hash computation. The name of each Data packet along with a corresponding hash is placed in the Manifest packet, which is signed with public key crypto.
>>>
>>> This scheme makes packet verification faster, because only a manifest packet must be verified using public key crypto methods, and all other data packets listed in the manifest can be verified by recomputing the digest and comparing to the digest specified in the manifest.
>>>
>>> One disadvantage of this scheme, is that in general case there is an additional round-trip delay, because manifest needs to be fetched first. (More info in the paper “Self verifying names for read-only named data“)
>>>
>>> I’ve put online a technical report that describes a protocol eliminating round-trip delay for fetching multi-segment content with embedded manifests: http://named-data.net/publications/techreports/ndn-tr-25-manifest-embedding/
>>>
>>> I expect that this approach can be useful for passing around multi-segment content (made dynamically) with roughly 5-10 times faster signing and verification execution over the traditional approach.
>>>
>>> If you have comments or counterarguments, let’s have a discussion in this thread.
>>>
>>> Thanks
>>> Ilya
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>