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

["Milheiro Mendes, Paulo Jorge" <[e-mail]>]

Hi David,

First of all, thank you for the extended review and valuable feedback. We
will take all your comments into consideration aiming to improve the draft.
We will also consider any other comments coming, in the meantime, from the
ICNRG community.

@ICNRG community: I would like to ask the ICNRG community to send comments
and indications about their support to adopt DABBER as an ICNRG work item.
Such comments will allow us to improve the protocol spec while preparing
its implementation. It is our opinion that the ICNRG would benefit by
having a working item that aims to support the development of ICN-based
wireless adhoc networks: this is the intention of DABBER.

Regards
Paulo


On Mon, Apr 13, 2020 at 5:05 PM David R. Oran <[e-mail]> wrote:

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


-- 

*Paulo Mendes, Ph.D*

Senior Scientistic

Central Research and Technology, XRC

*Airbus*
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.