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

[Adeola Bannis]

On Tue, Oct 7, 2014 at 3:40 PM, Tai-Lin Chu <tailinchu at gmail.com> wrote:

> 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.
>

I think manifests are great for segmentation. However, I'm not sure it's
appropriate to use them to list child suffixes.

What if /..../mypage is the name of some data, and /.../mypage/image1 is
also valid data? Does this mean that publishers using metadata can never
have data with names that are prefixes of other data names?


>
> 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.
>
>
If the manifest includes all the segments, then we can get rid of
finalBlockId. However, as I understand Ilya's suggestion for embedded
manifests, a sequence of interests will receive some segments and some
manifests for upcoming segments. Without finalBlockId, a consumer will not
be able to tell a network failure just before the next manifest from the
end of the data.


>
>
>
>
>
>
>
> 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
> >
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20141007/fe7c9970/attachment.html>