Re: [icnrg] Comments on FLIC

Dirk Kutscher <> Mon, 04 May 2020 10:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99D1B3A077C for <>; Mon, 4 May 2020 03:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8zsALT0pR606 for <>; Mon, 4 May 2020 03:09:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05B533A0778 for <>; Mon, 4 May 2020 03:09:29 -0700 (PDT)
Received: from [] ([]) by (mreue011 []) with ESMTPSA (Nemesis) id 1MDygG-1jLcQA1Vi8-009x95; Mon, 04 May 2020 12:09:22 +0200
From: "Dirk Kutscher" <>
To: "Ken Calvert" <>
Date: Mon, 04 May 2020 12:09:20 +0200
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Provags-ID: V03:K1:ax+Q+ZYoJuMDDKoS+I6u5TNkb+p5v7CBKm8z2I0+xQgrk7Pxxc7 GB0SmoznOY0oWKxE/Wwz9FulAh3fpPOyEkClCYGvp16+7ieRwJWojGCXcY9zBDMcpS77/tW jNbJhDIT9Bh6wSkp8XWUpaNCliD4D7Hef5OnH4mbO0+K86lYQmK8YhrVfaDY5hRzV1KMgmT jW4gNQHMIgRL6y1qiov+g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:OG3yZ+PMKZc=:bP7JwicgVB1sl4CtZpnOBI JUwfBAmVjS2oNYNGNTxWi66Mzn+7NAma0ab1AJJTS4bGLpTZ8dLUjHgRnGrVWcmDAdYkp07At rB860rPLiDVOvjn43Lax1my2ZkPU5JfczDtF/ji7ktyGh+XEBOtfoAU88UEHxYBldQULNWLov LWRDVKTSq9NzlBKx5iOEX10gKgo5p0G+jXXqwH01SIOBFkhhfA/Evk1WRC7GkGMSis0RBkaGc wuzhOFkp/xLYBwvcY7ownObVJ2reQEeBL3jvQ2+dDSTpmhY/+jbj+E9p0LGTqE9vHrNJGyQSy 6J/PJeLlR2t5ib+pG9jaYfSPzx/SYmqW899TcaQ3ZN/JPfNUUGBtQMKVZ4JR1BARuj6PVJWVu iiop8Pcl8lpeeUenudybj11cEdBqsNRFl17gqoY7WKXoiaR55tZq5qRZJByItbbpQujb5VvrQ WtFT73TLccebyuE57u9kZDYn5G+T7lGDA5AYiql+g/kvmPuS4ZMNIhlvLavxqq//ZRnJX8dgN /J7smEObHahvemC3oJagrMLhXfJ70KMu+LhiuY6PXbHTwTHnvyaPYUeh/ETHbVT8X5ePIZDsN 6pwf1oBSj7xARYA6lQkNCO1ugZ7AanhDd8FB90pex0bWZbBOltoBeezQQsxveiSl8lkPLIyg+ A5vrazYelDnmOrfbVpFYI2Mmx4ZxjFwrRrCm42EC1IdWYn/q9f2BkdE0K5hXWKQ4myiyeNvXh EnozRCUpXzRQf8JNgVpWznOPOhI13Td8s6syo9qzhEI8r7SPVB7MWqN03RrVpPQyEYjOxqpoi Pe9mc+gP1NF/Y2gm5tcbKbg8ElrUaLSVkfjyBOVK/myYht9RiV39t8S6SrRhPQob4tQD2Zj
Archived-At: <>
Subject: Re: [icnrg] Comments on FLIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 May 2020 10:09:33 -0000

Hi Ken,

thanks a lot -- this is really helpful. Would be great if we could 
consider these comments for a FLIC update.

> Context: I came to the document with general knowledge of CCN/NDN and 
> understanding of the manifest concept, but without knowledge of the 
> details of any proposed implementation.  I approached it as if I were 
> going to implement or use the protocol from scratch.  There may be 
> relevant drafts I haven't read, which would affect my understanding.

No, I don't think there are other relevant drafts that should have been 
read before other than the CCNx specs.


> Two parts to this: (I) high-level suggestions on presentation, and 
> (II) corrections and nits.
> I. High-level/global suggestions
> -----------------------------------------
> 0. Define a consistent terminology early, giving the meanings in terms 
> of BOTH CCNx and NDN standard terminology, and then use that 
> throughout. Currently some terms are defined only in CCNx terms, while 
> others need to be more precisely defined in standard terms.  I guess 
> what I'm saying is the "Terminology" section 3.1 did not help me much. 
>  Example: the relationship among Links, Locators, Namespaces, Names, 
> and Prefixes all need to be made clear.  Some of this may be due to 
> this draft not yet reflecting the RFC terminology.  (I'd volunteer to 
> help with that, as it would help me understand the latter better.)
> 1. The inode analogy is useful in the document's abstract and 
> introduction for giving some intuition, but it may not be helpful 
> beyond that.  The term "pointer", for example, is a basic computer 
> science concept, and could be defined without citing inodes.  In some 
> places (Section 4 and Appendix A) the inode model does seem most 
> appropriate, while in others (Section 3), trees seem like the more 
> useful paradigm, but because I was expecting inode-like structure, it 
> was confusing.
> 2. Section 2 is more like a list of features than a set of "Design 
> Goals". Stating design goals is fine, but they should be formulated as 
> such, rather than as selling points of the protocol.  (This would also 
> help reviewers of the specification.)
> 3. Move the use cases (Sections 4.1, 4.3-4.5) earlier in the document. 
>  The notation used is self-explanatory, and IMO illustrates the 
> utility and flexibility of the design better than what comes before.  
> For example, the earlier sections give the impression that it is 
> necessary (or at least usual) to have BOTH Root and Top manifests 
> (i.e., two levels of indirection); the use cases show that this isn't 
> required, but also how it can be useful.
> 4. Putting the section containing the grammar earlier in Section 3 
> might make the rest of that section easier to understand.  But I'm not 
> sure - see also #0 above.
> 5. I think "preferred" should be avoided in a specification.  Better 
> to state what an approach or technique is good for (and why!), and let 
> the reader decide whether it applies to any particular case (see also 
> #3 above). I also suggest avoiding "typical" unless the scope is 
> clear.
> II. Corrections/nits
> --------------------
> 1. Introduction
>   7th paragraph - the sentence "A FLIC manifest encodes locators the 
> same for both ICN protocols, though they are encoded differently in 
> the underlying protocol." is self-contradictory.  Suspect the first 
> "encodes" should be something else. Is this sentence necessary?
> 3.1 Terminology
>   Internal Manifest - last sentence, s/direct manifests/direct 
> pointers/ .
> 3.3 Namespaces
>   "If using namespaces, typically there are two defined: one for the 
> manifest namespace and one for the application data namespace. If the 
> two are the same, they can share a namespace."  This seems to be a 
> tautology, although perhaps it's just semantic ambiguity about what 
> "the two" refers to.
> 3.4 Manifest Metadata
> 2nd paragraph seems out of place - it's completely unclear what it has 
> to do with the first paragraph, or with the section header.
> 3.7.1 Traversal
>   "The algorithms in Figure 2 show the in-order forward traversal code 
> ..." Actually the code shows preorder [sic] traversal; "in-order" is a 
> different thing.
>   Next-to-last line of reverse_preorder should be indented; the last 
> line should not be indented.
> 3.8 - I did not go over this carefully.
> 3.9.1 and 3.9.2 - both contain, in places, sentences like: "The Root 
> Manifest content object has a name used to fetch the manifest....It 
> has a set of Locators used to fetch the remainder of the manifest."  
> This makes it seem like double-indirection is required. Should there 
> be an "if any" or similar in there somewhere?
> 3.10 Figure 9 - Including this figure at this point is not very useful 
> - the reader understands indirection by this point, and it just raises 
> the question why you would want to require three-deep manifest 
> retrievals and 55% overhead to get to the actual data.
> 4.2 Seeking
>   " to compute the byte offset of the data pointed at by pointer 
> P_i, offset_i.  In this formula, let P_i represent the Size value of 
> the i-th pointer."
> I think you mean to say " pointer P_i, *call it* offset_i" in the 
> first sentence, then "let P_i.size represent..." in the second 
> sentence.
> In the formula "offset_i = \sum_{i=1}^{i-1} P_i.size",  RHS should be 
> \sum_{k=1}^{i-1} P_k.size.
> The code after the second paragraph is also wrong, the condition 
> should be
>    if (P < offset + P_i.size) ...
> Also the code indentation is a little off.
> Paragraph below Figure 13 is garbled, the P_i in the last sentence 
> should be P_N, and the formula should be:
> D - ((N-1) * L)
> Then the sentence after that basically says the same thing again.  The 
> algorithm seems right though.
> 4.5 Re-publishing a FLIC under a new name.
> Second bullet - "would like a local result to appear."  - not clear 
> what this means. Apparently here prefixes (/beta, /gamma) are being 
> used as names of "sites". One gets the idea that there is some common 
> understanding that some parts of the namespace are tied to topology.  
> If that's the case, can some documentation be cited?
> Same paragraph, "maniest" -> manifest.
> Appendix A - code for building trees - I think interior_direct() is 
> not indented properly, should be at the same level as 
> interior_indirect().
> Also, the statement in interior_indirect():  "reserve_count = min(m, 
> segment.tail - segment.head)" - I suspect that should be
> reserve_count = min(k, segment.tail - segment.head)
> When I worked an example with 100 data blocks, k=20 and m = 5, I got a 
> top manifest with 5 direct pointers and 4 indirect pointers, the 
> latter pointing to 2nd-level manifests with 20, 25, 25, and 25 direct 
> pointers, respectively. The 5 direct pointers (when there is room for 
> 20) seems to contradict the comment that "we want the top of the tree 
> packed".  With the suggested change, I end up with 20 direct pointers 
> and 4 indirect in the top manifest, with the 2nd-level manifests 
> containing 5, 25, 25 and 25 direct pointers.
> Ken
> _______________________________________________
> icnrg mailing list