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

[Tai-Lin Chu]

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

1. my proposal is not compatible with current ndn.
2. sorry I did not say precisely. whether mypage is a data or a
metadata (dataset) is decided by producer. It is not "list all
children", so image1 might or might not be in mypage. "For now" (I am
thinking whether it is useful to put data with other prefix into
metadata), every item in metadata must be a suffix.

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

Yes. This is what I mean. FinalBlockId only allows sequential
fetching. My proposal allows you to fetch in any order you like
because you know the complete set.

On Tue, Oct 7, 2014 at 4:27 PM, Adeola Bannis <abannis at ucla.edu> wrote:
>
>
> 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
>
>