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

Tai-Lin Chu tailinchu at gmail.com
Wed Oct 8 14:07:07 PDT 2014


> In my opinion, it makes packet reassembly much more difficult.

I think it is very simple to implement in recursion: for every node,
fetch all children in parallel, and then check digest if data returns.


>When I perform segmentation, it’s often not possible to know what the last sequence number is going to be until near the end of segmentation.
yes, but my version of metadata does not prevent you from doing
"deferred" final block.
Lets see an example.

metadata
/id/1 (data)
/id/2 (data)
...
/<uuid> (deferred metadata, which is also similar to this one; verify
rsa if you don't provide digest)


> suffix manipulation
could you explain more?

On Wed, Oct 8, 2014 at 10:45 AM, Ilya Moiseenko <iliamo at ucla.edu> wrote:
>
> On 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,
> Why is it nice to have?
>
>> and it also makes name matches
>> what it actually is.
>
> In my opinion, it makes packet reassembly much more difficult.
> When manifests are embedded in the sequence, and a normal Data packet is received, reassembly knows where to look for the corresponding manifest (just look for the first preceding manifest).
>
> And when you have a separate enumeration for Data packets and manifests, it’s impossible to know which manifest corresponds to a particular Data packet. (I’m not going to check every manifest, of course). Or you need some backlink from the Data packet towards the corresponding manifest. I don’t think that it is a good design.
>
>>
>> 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.
>
> FinalBlockId is a great thing, don’t remove it :) When I perform segmentation, it’s often not possible to know what the last sequence number is going to be until near the end of segmentation. So when I finally know this number, I put it in the FinalBlockID. Consumer will stop fetching when this number is read from any Data packet.
>
> And I use implicit digest selector for interest retransmission when received Data packet fails verification (with manifest).
>
>>
>> 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.
>
> In general, I think there should be only full names in the manifest.
> Because if we use suffixes, there could be some nasty security attacks via suffix manipulation.
> Especially when we have longest prefix match.
>
>>
>> 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
>>>
>




More information about the Ndn-interest mailing list