[icnrg] Review comments on draft-mendes-icnrg-dabber-04

["David R. Oran" <[e-mail]>]

Before getting to my review, one comment with **<Chair hat>**.

This seems novel and interesting ICN research deserving of more 
visibility, review, and hopefully publication through the IRTF. However, 
it’s gotten very little visibility and even less review in ICNRG, so 
as chair I need to ask - does this have enough interest to warrant 
adoption as an ICNRG draft, or should we encourage the authors to pursue 
other publication options (perhaps as an individual contribution). 
Unless we get more reviews and input encouraging adoption, it’s hard 
to ask the authors to continue to revise the work leaving it in limbo. 
PLEASE review this and send comments and indications of whether you 
support adopting this as ICNRG work.

**</Chair hat>**

The remainder of this review message is with **<Chair Hat Off>**

##General Comments##

- There are a lot of typos and English language usage problems, so the 
draft needs some editorial work. I’ve attached a marked up version 
with my suggested corrections, but I doubt I caught everything, and in 
particular was less rigorous about marking corrections later in the 
draft, since many of the usage problems are of the same general nature 
throughout.

- There needs to be a terminology section, and more care taken to define 
terms and acronyms either before or at their first usage. Some examples 
include:
	- data consumer ID (DID?)
	- custodian ID
	- neighbor (see detailed comment below)
	- NFD (also mis-spelled as NDF) on page 16
	- ICDTN on page 19

- This may be obvious, but you really do need to have Figure 1, not a 
TBD.

- I am not enough of an expert of the dynamics and optimization 
properties of DTNs to have a confident review of the material on 
node/social contact optimization (section 5.1-5.3). I therefore don’t 
have much to say on this material - it could of course be perfect.

##Detailed Technical Comments##

- Some of the assumptions in section 1.2 are not actually assumptions, 
as they are testable. For example, the statement “Selecting the best 
set of neighbors to replicate packets to, may not be efficient if based 
only on connectivity based information”. I also had a hard time 
figuring out why some things were considered assumptions and others 
requirements. It might be better to eliminate this distinction and 
instead articulate these as “design considerations”.

- Along the same line, why is it a requirement that “Routing 
information must be exchanged based on Interest / Data  messages”. 
That seems a design choice. It seems a good one, as it means you don’t 
have to resort to non NDN/CCNx machinery to create your routing 
protocol, but that doesn’t make it a requirement. A requirement would 
be something more like the statement further down that you can’t rely 
on the inverse path the Interest took to reach a producer/custodian to 
return data, as that path may no longer exist when you want to send the 
data back.

- The role of data consumer IDs and custodian IDs is not well explained 
at all in the introductory material. At least a forward reference to 
section 2.3 would help. I also had a hard time thinking clearly about 
their security properties, how easy they are to spoof (especially if 
interest messages are not signed), what the consequence of unintended 
value collisions were, etc. This whole part of the design needs to be 
explained in more detail, and early in the exposition. Where the terms 
are introduced (e.g. in section 1.2) a forward reference to the part of 
the spec that explains them would be particularly helpful.

- The nonce based scheme you explicitly rely on  (page 8) for loop 
detection has been definitively demonstrated to not work, and to fail 
spectacularly if you allow any in-network retransmissions (which I 
assume for a DTN-like architecture you’d want to have). CCNx has 
eliminated nonce-based loop detection entirely in version 1.0, and NDN 
has added hop counts as a mandatory backup for the cases where nonces 
fail to detect a loop. I suggest finding a better loop detection scheme 
- if hop counts don’t cut it perhaps something based on Brent’s 
algorithm (e.g. https://arxiv.org/abs/1612.04430) might be worth 
considering? Also, I don’t see how disabling a face producing loops 
helps unless you are getting zero forwarding utility through that face. 
The topology is likely to be sparse and you want to use any working face 
if possible.

- in section 2.2, you talk about DABBER querying about “neighbor” 
nodes. In the world of DTN with nebulous and changing topology, what 
exactly is your definition of a neighbor? Any node the current node has 
ever talked to directly (i.e. over one radio hop), any node on a L2 mesh 
that hides the internal topology from L3? Something else?

- (p.9) How does “application category” relate to the metrics that 
DABBER would actually use? Is this some name mapping function where by 
application category you actually mean “part of the global 
namespace”?

- how do you compute node degree in a fluid topology? Is it the number 
of nodes contacted in some time window? Usually node degree measures the 
number of neighbor nodes that can be **simultaneously** reached, not the 
number reachable over time. This may or may not not affect your 
computation of centrality, The other parameters used to compute 
centrality seem intuitively the right ones though.

- The term “node similarity” doesn’t seem to capture the actual 
metrics mentioned in this category; perhaps a better term would be 
“node connectivity quality”?

- page 11 top - you are a bit sloppy in talking about an OPPface being 
“connected” - since in NDN and CCNx there is no real notion of a 
face being connected, only a neighbor being available over a face. It 
isn’t clear to me why you need a special face at all, since a regular 
face queue could get blocked for a long time due to link errors or 
long-baseline link scheduling like you’d see with LoRa or other 
low-bandwidth systems. There are other interactions I’m pretty unclear 
on as well, such was whether interactions with Interest Lifetime get 
modified for OPPfaces or not. It also seems a bit weird to have a single 
face that has two different MTU values - that seems implied by the 
discussion, however I think you mean that these two transmission modes 
(TCP or Mac-layer WiFi direct) would actually be different OPPface 
instances. The latter seems cleaner, no?

- top of page 12 - I don’t see how the selection heuristic minimizes 
the number of WiFi Direct groups in a certain area. I’m obviously 
missing something about the way WiFi direct works, since I thought the 
number of groups was essentially undefined since there’s no protocol 
to compute transitive closure of the nodes, hence you don’t know how 
many “groups” there are, or even if the notion of a WiFi direct 
“group” is even meaningful in the context of DABBER.

- at the end of section 2.4.1,  you say “DABBER would need to encode 
in the Interest packet information about the ID of the neighbors that 
should process the overheard Interest packet.” Why is this any 
different from normal multi-path forwarding in NDN/CCNx? Do you want to 
suppress duplicate upstream forwarding of Interests by somehow telling 
which neighbor is intended to be the forwarder? If so, this is normally 
done by L2/L3 demultiplexing and not something ”extra” in an L3 
packet.

- question: you seem to say DTNFaces only handle Data packets, not 
Interest packets? Seems right, but more explanation would be helpful. In 
particular you don’t explicitly say whether OPPfaces never handle data 
packets, only Interest packets; is this the case?

- section 2.4.3: you need to say a few words about CMFace rather than 
TBD. Using a special face type (actually any face at all) for 
communicating with the Context manager is actually an internal 
implementation design decision, right? One could have just as easily 
made the Context manger an application and used the NDN/CCNx APIs for it 
to talk to the forwarder, right? If not, and a face is needed 
semantically, this would be the place to explain the design, how the FIB 
directs things here and how the state passes as Interest/Data exchanges 
over this face.

- in the first paragraph of section 3, you claim that by using “data 
reachability cost” as the metric rather than than path cost, you 
magically reduce the impact of topological changes on routing stability. 
Well, that’s true only if the “data reachability cost” doesn’t 
change when the topology changes, right? And if it doesn’t change 
based on that, exactly what does it change based on? This doesn’t seem 
to map obviously to the availability, centrality, and similarity metrics 
mentioned earlier. You need to connect the concepts better. It would 
also help to better explain why having the data reachability cost avoids 
local flooding. Do you only forward to the next hop with the cheapest 
data reachability metric? Why would that be different from filtering on 
any other metric?

- It isn’t completely clear whether you are using the older Chronosync 
or just the newer PSync, since you reference both. It doesn’t seem you 
need the full overhead of chronosync, as is seems PSync (or something 
with even weaker semantics) would not suffice. In any event, it would be 
useful to cite some newer work, for example 
https://named-data.net/wp-content/uploads/2019/01/li2018sync-intro.pdf.

- Are LSA Interests sent on OPPfaces or regular faces? Are the Data 
replies sent back using DTNfaces? Seems like this would not be good, as 
they are one-hop protocols. The other problem could be a lot of 
duplicate interests since the OPPface queueing might have many redundant 
requests queued since nowhere does the face queue know about or try to 
suppress duplicate packets.

- At the top of page 18, you say “The higher the values of C, A and S, 
the most preferential a neighbor is.” But this isn’t well defined as 
you don’t specify a partial or total order among the metrics. Is this 
some sort of linear regression equation (ala what EIGRP does with 
multiple metrics?) Something else?

- What is the consequence of different Dabber nodes using different NFD 
RIB update policies (as described on p.19)? It seems that if all nodes 
don’t choose the same policy, even a local loop suppression policy 
like Downward Path won’t suppress loops if some other node selects 
Increased Diversity.

- I may have missed this, but another fairly deep fundamental property 
of NDN/CCNx forwarding is that Data packets which arrive without 
matching an existing PIT entry should be preferentially discarded, and 
certainly not opportunistically forwarded further. The DTN scheme you 
use for DABBER seems to quite dramatically violate this principle. The 
NDN/CCNx treatment of arriving data packets clearly has to be relaxed to 
accommodate DTNs. Part of my confusion is the statement “making usage 
of information stored in the PIT” since if you don’t use paths to 
nodes without an active PIT entry, you can in fact only use symmetric 
routes. There’s a lot of detail on page 23, which deals with the 
forwarding precedence, but not the (harder?) problem of how to manage 
the CS of one of these nodes opportunistically keeping Data packets for 
which there is no corresponding PIT entry.

- Section 8, beginning, you blithely state “ensuring the needed levels 
of confidentiality”. What in fact are the needed levels of 
confidentiality? I also suspect that a blanket statement like 
“Moreover, DABBER ensures the right level of privacy of the involved 
entities, who provide local information to support routing decisions.” 
might raise hackles. Local information distribution almost inevitably 
leaks, and you don’t really address the level of transitive trust that 
you are assuming for these local environments. Some of this is covered 
in section 8.1, so perhaps fewer words in the introduction, or explicit 
forward reference would keep the reader calm about the assertions.

- There seems to be a bit of circular logic in section 8.1 around the 
fetching of keys. You need a certain amount of routing information to 
support the fetching of keys from more than one hop away, yet the 
authenticity of the routing information in turn depends on your 
believing the keys. I suspect there is some invariant that ensures the 
scope of key storage is deterministically more localized than the 
routing information it secures, but it isn’t entirely clear that the 
key hierarchy by itself guarantees this.





##Nits##

- Need a reference for “Epidemic Routing” on p5
- in the first paragraph of section 2, I think OPPFace and DTNFace are 
face *types*, not faces. Also, forward reference to where these are 
actually defined and used would help.
- On page 9, in the paragraph on contextual awareness, you talk about a 
user’s “interests”, which is normally a fine term to use, but in 
this context, it has the obvious potential to be confusing. I suggest 
changing the sentence to “…the user configures any desired types of 
information or other types of personal preferences.”
- top of page 9, you say you only need one OPPface per device - but I 
don’t think this is true for a device with multiple radios, right? 
It’s one OPPface per radio operating in broadcast mode, plus one for 
each radio (or wired connection) operating in point-to-point mode. Yes?
- You don’t seem to specify the size/range of the LSA version. Is it 
modular or monotonic? Maximum value?
- I thought Chronosync and Psync use Bloom filters to find the diffs. 
The description on pp 14/15 seems to imply otherwise.
- Validity seems to be done via a separate Validity timer rather than 
relying on Data Expiry of the Itnerest/Data exchange. Is this because 
the individual LSAs are packaged together with multiple name prefixes to 
each prefix might be different expiry? In any event, the expire ought to 
be the MIN(LSA Data message expiry, Prefix expiry).
- You say “The routing table is then ordered by name prefix in 
decreased order of validity.” Why? This only matters when computing 
the FIB or deciding which LSAs (if any) to filter). Seems unnecessary 
overhead to keep the RIB sorted.
- In your example on page 20, you don’t say if the validity is in fact 
the Data Expiry value of the Data object in the Content store. I would 
hope it is, since if you make a separate validity value you can either 
continue to announce data that has expired, or black hole data that is 
still useful from the data producer’s standpoint. If the LSA covers a 
prefix with data objects of wildly different expirations, then I suspect 
the application needs to be rethought, or at least the structure of its 
namespace rethought.
- On page 21, you say “Independently of the used forwarding strategy, 
it has to respect the ranking of faces done by DABBER on the RIB.” 
This seems to imply that forwarding has to look at the RIB, which I 
don’t think is what you mean. I assume what you mean is that the FIB 
has to correctly reflect the ordering of the RIB with appropriate 
filters and face eligibility/precedence. In any event this doesn’t 
seem to be the right place in the exposition to be saying this.
- in section 7.1, you say “However, when DABBER is executing the LSA 
dissemination procedure over a Wi-Fi face, towards an edge router it 
will ignore all notifications that Chronosync will send related to 
Adjacency LSAs. Why? A few more words here would be helpful.


[End of Comments]


DaveO