[icnrg] Revision of draft-irtf-icnrg-ccninfo-04

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

Dear All,

In this email I provide my revision of the draft  "CCNinfo: Discovering
Content and Network Information in Content-Centric Networks
" - draft-irtf-icnrg-ccninfo-04 (
https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04).

A) Overall comments

This draft provides a description of important tools to manage an ICN
network, to the same extent that traceroute is important for IP networks.

It is important to understand what is the different between the proposal
sent to ICNRG as "experimental" - CCNinfo - and the previous proposal,
called "Contrace".

CCNinfo is supposed to facilitate the tracing of a routing path and
provides the RTT between the content forwarder and consumer. Can´t this
information (RTT) be computed based on the lapsing time between sending an
Interest packet and receiving the corresponding Data packet?

It is said that CCNinfo identifies the states of the cache. But the draft
should be more specific, since it seems that CCNinfo can only provide info
about in-line caches.

The draft lacks an explanation about the security mechanism, since CCNinfo
a protocol to retrieve information from CCN routers.

B) Specific comments

- Section 1:

Authors should clarify the difference between CCNinfo and ccninfo, when
they say "
Some parts of the draft are difficult to understand. For instance when
authors say "CCNinfo can be implemented with the user commands (such as
ccninfo described in Appendix A)"

From what the authors say "When an appropriate adjacent neighbor router
receives the Request message, it retrieves the cache information" it seems
that CCNinfo only works with inline caches. How could CCNinfo collect
information from off-the-path caches?

It seems that the proposed system is only able to gather information about
one cache - the first one that stores the data related to the name
transported in the Request message. This means that by using CCNinfo a
network operator will not be able to have a full image of its network,
since that data may be replicated in other caches that are not reached.
Even if the CCN router makes use of a broadcast/multicast forwarding
strategy, the different copies of the Request message will stop at the
first cache with a matching entrance.

Authors mention that the proposed request-reply message flow is similar to
the behavior of the IP multicast traceroute facility. This requires Request
messages to be forwarded based on a multicast/broadcast strategy. Later on
in the draft it is said that "CCNinfo supports multipath forwarding". Does
this mean that CCNinfo comes with its own multicast forwarding scheme? If
so, why does CCNinfo use a default CCN broadcast strategy? If it is really
multicast, how are neighbor nodes (multicast tree branches) identified?

Based on fig 1, it seems that CCNinfo requires caches to announce name
prefixes and not only producers. This needs to be clarified.

Based on fig 2, it seems that reply messages are not aggregated in merging
points.

When describing figure 3, it is said that "Two different Replies are later
received on Router D and each Reply is appropriately forwarded to Router B
and Router C, respectively." This should not happen since the path from
router D to the publisher is the same. So only one pair request-reply
should be needed to collect information about the segment router D -
Publisher. It seems that CCNinfo is not able to avoid such duplication
since the information about the path and caches is collected by the Request
messages. The mentioned duplication of messages may be avoided if the
information is collected by the Reply messages.

Section 2.1

The sentence "CCNinfo requests flow in the opposite direction to the data
flow, we refer to "upstream" and "downstream" with respect to data, unless
explicitly specified" needs further explanation. You mean that CCNinfo
requests flow in the direction of Interest packets and CCNinfo replies in
the direction of Data packets, right? The notion of upstream and downstream
is confusing in this context.

The definition of "Outgoing face" gets confusing due to the presence of the
terms "transmit" and "publisher" when referring to data (CCNinfo replies?),
since CCNinfo transmitted by publishers are received on the income
interface, and the outgoing interface is used to send CCNinfo replies to
consumers.

This section needs to define "CCNinfo Request" packets and "CCNinfo Reply"
packets in relation to Interest and Data packets. This should be an
introduction to section 3 and should answer to the following question: Why
can´t CCNinfo Request be implemented based in Interest packets and CCNinfo
Replies based on Data packets?

This section needs to define CCNinfo Request messages and CCNinfo Reply
messages. Are those the same as packets or are related to a set of packets?
In the latter case how is a set of packets defined?

In the definition of FHR it is not clear how a router knows that beyond a
certain outgoing interface there is a published for a certain name prefix.
The only way for this to happen is based on a name-based routing protocol
(e.g. NLSR or DABBER), but this is not mentioned. This issue needs to be
clarified.

Section 3

Again, the question mentioned in the previous comment should be answered,
since if Requests and Replies are implemented as Interests and Data packets
with special payload that would simplify the operation of routers.

A further analysis of section 3 is dependent from the above mentioned
explanation.

Section 4.1

Not clear what does it mean that "The user later obtains both the routing
path information and in-network cache information simultaneously".
Simultaneously?

In what situations will the CCNinfo user’s program require appending the
user’s signature into the CCNx ValidationPayload TLV?

Two comments to the sentence "The router then forwards the Request message
or sends the Reply message whenever it approves the Request; otherwise, it
rejects the Request message as described in Section 6.11."
1 - A router only sends a reply when it has the content referred in the
name carried in the Request. This reasoning is not sustained in this
sentence
2 - It is not clear in which situations the request message is rejected.

Section 4.2.

Instead of reading "A CCNinfo user’s program will receive one or multiple
CCNinfo Reply
messages from the adjacent neighbor router.", we should read "A CCNinfo
user’s program will receive one or multiple CCNinfo Reply messages from the
adjacent neighbor routers", right? (CCNinfo is supposed to use a multicast
forwarding strategy).

The sentence "If the number of Report blocks in the received Reply is more
than the
initial HopLimit value (which was inserted in the original Request), the
Reply MUST be silently ignored." is not clear. The HopLimit aims to limit
the scanning range of an CCNRequest, right? If a Reply carries reports from
routers that are beyond that limit, why is the full Reply message ignored?
Should the user just ignore the reports sent by routers that are beyond the
HopLimit?

Section 5.3.1

It is said that the router specifies the Request Arrival Time in the Report
block. Does this mean that all CCN routers need to have synchronized clocks?

It is said that CCNinfo supports multipath forwarding, but the draft does
not explain how to select the set of neighbours that will receive the
Request message. Without this explanation it seems that a broadcast
strategy is used.

Section 5.3.2

It is said that the upstream routers forward the Requests to all multiple
upstream routers based on the FIBs simultaneously. This is not the same as
saying that with an F flag a router will use a broadcast forwarding
strategy instead of a multicast one?

It is said "… routers SHOULD NOT remove the PIT entry created by the full
discovery request until the CCNinfo Reply Timeout value expires." How is
this Timeout value defined by the administrators/operators? The value of
this variable has a significant impact in the efficiency of CCNinfo, since
the used time value may not be enough to collect all the data from all
multicast branches, and since we do not know how deep these branches are,
it may be difficult to find a proper value for the timeout.

Section 5.5.

How do you determine that a neighbor is valid?


Section 6

It is mentioned "performing an expanding hop-by-hop trace". However it is
not clear what does it mean an "expanding hop-by-hop trace". Expanding
traces need to be defined.

In which cases  can an intermediate router return a Reply before a Request
reaches the
caching router?

Section 7.1

Again about the Timeout value: why shouldn´t the value be larger than 4
seconds and lower than 2 seconds. What evidence is there?

Section 8.4

It is said that if the routers have synchronized clocks, it is possible to
estimate the propagation and queuing delays from the differences between
the timestamps at the successive hops. What happens if the routers do not
have synchronized clocks? How can we ensure that the clocks are in sync?

Section 10.5

Further explanation is needed of the statement "CCNinfo may impose heavy
tasks at content forwarders."

Regards

*Paulo Mendes, Ph.D*

Senior Scientist

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.