[icnrg] Comments on draft-irtf-icnrg-ccninfo-02

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

I did a full re-read of the latest CCNInfo draft. These comments are 
with <Chair Hat off>. I’ll be sending a separate message with my 
<chair hat on> comments shortly.

General comments:

- The specification is a lot more complete and easy to understand. 
It’s already implemented (by the authors), and I suspect another 
implementer could get pretty close to an interoperable implementation 
from the material in the current version.

- The design seems fundamentally solid. It’s not the design I would 
have chosen, but given this is for research purposes and heading toward 
experimental status rather than a standard, I think progressing this 
approach is fine. We can experiment with it (and other approaches) to 
learn more about how to instrument and manage networks based on CCNx. 
There is of course other complementary work in ICNRG (e.g. ping and 
traceroute) so researchers would be encouraged to do both qualitative 
and quantitative evaluation of the tradeoffs in the various approaches. 
There is also work under submission to the ICN’19 conference that 
takes yet another approach so soon we may have a rich set of things to 
compare and contrast.

- The forwarding model is pretty much separate from the Interest/Data 
forwarding procedures. I understand the authors’ motivation for this, 
but it does mean a lot of extra code in all the forwarders in order to 
have appropriate coverage. It also raises a number of possibly tricky 
resource allocation issues, since CCNInfo will be competing for both 
memory (i.e. PIT) and link bandwidth with Interest/Data while having 
somewhat different dynamic characteristics. For example, the Request 
messages will be large compared to regular Interests (especially so if 
they are signed), and the set of state stored in the PIT somewhat 
different, meaning you either have a separate data structure or a more 
complex joint PIT data structure.

- It was somewhat difficult for me to get a holistic grasp of the 
security properties of the CCNInfo Request/Reply protocol. For example:
	- Requests can be signed by the initiator, but the request blocks are 
not individually signed. This seems to result in a fully transitive 
trust model upstream toward the FHR (CCNInfo terminology identifying the 
forwarder directly attached to a producer). Is this a problem? I’m not 
sure.
	- Conversely, recording the identity of every upstream forwarder may 
represent a privacy problem. Again, the tradeoffs are difficult to 
assess, since there is the ability in the protocol for information 
hiding, and administrative controls at domain boundaries. However, the 
anonymity characteristics of Interest handling (the further you are away 
from the consumer, the harder it is to localize the consumer in the 
topology, discover the identity, or establish linkability) are 
compromised. Does this matter? I’m not sure.
	- On a similar note, it appears the individual reply blocks in Reply 
messages are not signed so again CCNInfo appears to rely on transitive 
trust to protect the returned information. Even if they were to be 
signed, deciding whether the right key was used is not at all clear 
(this is related to another comment later on the question of how 
forwarders are named/identified).

- Some of the statistics reported in CCNInfo are likely to be expensive 
to compute, and possibly quite algorithmically difficult to implement 
efficiently in high-performance implementations that shard the PIT & CS. 
It isn’t clear whether these ought to be done by CCNInfo or obtained 
instead by a direct application-layer management protocol talking to the 
management application in a forwarder node. It may be worth scrubbing 
these to only return basic information about an individual Data Object 
in a cache, repo or producer, and only return a return handle to use 
(via a separate protocol) to obtain the details for groupings like 
prefixes.

- CCNInfo creates a non-CCNx namespace for naming/identifying 
forwarders. Why? This seems to me both fraught with management 
complexity (allocation, duplication, security, etc.), at odds with the 
naming architecture of CCNx (or NDN) and frankly unnecessary. If instead 
CCNinfo used the existing namespace structure to name forwarders, things 
would (at least in my opinion) be much better:
	- name allocation for forwarders is no different from that for any 
other data producer
	- by providing these names in CCNInfo Replies to the initiator, you now 
have a direct and easy coupling to a more comprehensive management 
protocol driven by regular interest/data exchanges (or for more 
sophisticated uses, by RICE).
	- security becomes a lot better integrated, as you can use all the 
existing trust schema work to decide what to sign, what to encrypt, and 
using what keys.

- It appears flow balance is seriously violated by the discovery form of 
CCNInfo request/reply exchanges, as a single request can generate 
multiple replies (in pathological cases, an exponential number of 
replies since Request aggregation is turned off explicitly). We really 
need to deal with this. Some possible alternatives:
	- quarantine relies at intermediate forwarders and combine them; 
returning only one “aggregate” reply on each downstream link.
	- Explicitly bound the number of replies as well as their size and 
communicate this in the protocol so the resource allocators can account 
for this in congestion management.

Here are some more detailed comments on things that I found in reading 
the specification:

- Report blocks can get pretty big. The recommendation is to just give 
up and not report anything more if your reply would exceed an IPv6 MTU. 
Why? CCNx supports Data objects as large  as 64K and current NDN 
restricts to 4K. Admittedly this has all sort of “interesting” 
fragmentation and congestion control implications (which are the subject 
of a new I.D. I plan to submit soon…but  I digress). Given that there 
is no exclusion capability, nor steering capability it’s not possible 
to get beyond the “horizon” created by this limitation. I’m not 
advocating necessarily adding either of these, however the small MTU for 
replies does seem to be problematic for a network management tool.

- In describing the information returned from caches, it wasn’t 
entirely clear if the these sum all the things in the cache matching a 
given prefix or something else. If they are in fact prefix-matched, this 
really needs to be done in the background and not in the forwarding path 
given the expense of traversing the cache data structures. (Folks will 
recall we got rid of prefix-match on data in CCNx for exactly this 
reason, and NDN recently changed to prefer exact match as well). Once 
you do this it may be appropriate to ask why not just layer these 
capabilities of CCNInfo as an application (as does the NIST work for 
NDN) rather than bake it into the basic network layer packet forwarding. 
I don’t necessarily advocate this; in fact I would prefer to simplify 
CCNInfo to make it feasible to implement at high performance (see my 
general comment earlier about only returning simple stuff in CCNInfo and 
doing the complex stuff on top).

- I didn’t see use of the existing T_MTU_TOO_LARGE error when you run 
out of space (page 11). Did I miss it?

- Is 16 bits enough entropy for RequestID (page 12)? it may be ok if you 
don’t do any aggregation across consumers (which you currently 
don’t) and lifetimes are bounded very small as you currently do (4 
seconds). It still makes me nervous though.

- On page 14 you RECOMMEND routers have synchronized clocks. This too 
strong in my opinion, for three reasons:
	- you are throwing away the low order 16 bits of the NTP timestamp 
anyway
	- loose synchronization is sufficient for the kinds of uses I think you 
want from CCNInfo.
	- If you expect CCNInfo to give you accurate per-hop and total RTT 
estimation using these clocks this isn’t terribly helpful given that 
the whole protocol runs on a different forwarding model, so you can’t 
use the CCNInfo RTT measurements to say much of anything about what real 
Interest/Data exchanges will experience. The alternative Ping and 
Traceroute proposals should do a much better job of this.

- Is the count of “received interests” (page 18) all those received 
or only those satisfied?

- I didn’t see much value in the Reply block information on First/Last 
Segnum or Elapsed Cache time.  For these and some others it might help 
to given some examples of how one might use this.

- in Section 4.2 you say you have to compare the number of report blocks 
with the hop limit. I think this means you have to remember the received 
hop limit in the PIT entry for the request, but I didn’t see that in 
the list of state you have to keep.


Minor stuff:

- move the actual packet type and TLV allocations to the IANA 
considerations section, and mark the values as “TBS” rather than 
picking them (yes…this might force you to change the implementation, 
but them’s the rules for RFCs…).

- page 23 s/the fill discovery request/the full discovery request/

[End of comments]

DaveO