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

Dear Paulo Mendes,

Thank you for your review and comments.
And sorry for my late response.

Replied inline.

> On May 13, 2020, at 17:41, Milheiro Mendes, Paulo Jorge <paulo.mendes@airbus.com> wrote:
> 
> 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".

"Contrace" published in IEEE ComMag 2015 is our previous work. It enables end users (i.e., consumers) to investigate path and in-network cache conditions in CCN. Contrace is implemented as an external daemon process running over TCP/IP that can interact with an obsolete CCNx forwarding daemon (CCNx-0.8.2) to retrieve the forwarding daemon's condition. This solution is flexible but heavily depends on the implementations and hence is difficult to advocate its global/common deployment without defining the common APIs. On the other hand, CCNinfo defines the protocol messages to investigate path and in-network cache conditions in CCN. It is embedded in the CCNx forwarding process and facilitates with non-IP networks as with the basic CCN concept. ICNRG agreed on this work.
We will briefly describe this background in the revision. Thanks.

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

Yes, it can. But CCNinfo does not require the actual data retrieval. It is an active networking tool. By CCNinfo, you can obtain the path and in-network cache information without retrieving the actual data. In addition, CCNinfo enables to investigate path and in-network cache conditions from/on different content forwarders by skipping the closest (or several) content forwarder(s) using Skip Hop Count (explained later). In the actual interest-data communications, you cannot bypass the closest forwarder, so that you cannot know the path/in-network conditions from/on other forwarders, while CCNinfo contributes to such analysis.

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

CCNinfo request/response messages are traversed along FIB entries. This document mentions that CCNinfo paths are decided "based on the FIB entry”, which means CCNinfo retrieves the on-path cache information.
Ok, we’ll add the “on-path” word in the revision. Thanks.

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

Currently, we provided Section 10 for security consideration (with 3 pages). An access control mechanism, which is a lightweight manner, is also described. As an external mechanism, HopAuth is introduced to protect the path information.
In addition, we will add a requester (consumer) and replier (forwarder) verification mechanism in the revision.

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

CCNinfo is the protocol name, while ccninfo is the name of the user program. ccninfo program/command invoked by a end-user sends CCNinfo requests and receives CCNinfo reply messages.
To clarify this, we will say, "Usually, the CCNinfo user (e.g., consumer) invokes the CCNinfo user program (such as "ccninfo" command described in Appendix A) with the name prefix of the content. The user program initiates the "Request" message (described in Section 3.1) to obtain routing path and cache information." in the revision.

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

As mentioned above, it only discovers the on-path in-network cache based on the FIB entries. CCNinfo does not intend to broadcast the messages to discover potential forwarders in the whole network. CCNinfo Request messages are forwarded only to the neighbor routers listed in the FIB.

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

CCNinfo can skip some specific cache forwarder(s) by specifying Skip Hop Count.
Routers corresponding to the value specified in the SkipHop field in the Request block are skipped and the CCNinfo Request messages are forwarded to the next router without the addition of Report blocks; the next upstream router then starts the trace. So, if you want to bypass some node(s), you can specify the bigger value than the hop count(s) of the node(s) and obtain other in-network cache from the far routers.

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

It seems you are misunderstanding.
This document says, "This request-reply message flow, walking up the tree from a consumer toward a publisher, is similar to the behavior of the IP multicast traceroute facility." It means that, like multicast traceroute (RFC8487), CCNinfo Request messages are traversed toward a publisher (based on the FIB). Not toward a consumer as unicast traceroute does.
It is not related to any strategy.

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

I cannot understand this comment. CCNinfo does not interact with any routing protocol or caching algorithm.

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

Reply messages are not aggregated anywhere.
The default behavior for the Reply messages shown in Fig.2 is that one Reply message is first forwarded by a content forwarder (Router C) and the other Reply later given by another content forwarder (Caching router) is discarded as the corresponding Reply was already forwarded. It is like an ordinary interest-data communication.
BTW, we will revise the caption to, "Another Reply message from the Caching router (i.e., Reply(C)) is discarded at Router B when the other Reply message (i.e., Reply(P)) was already forwarded by Router B.", which might be better.

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

The condition explained with Figure 3 is a bit complex.
For the regular interest-data communication, two interests arrive at Router D but only one interest is forwarded toward publisher. After one data packet is arrived at Router D, Router D forwards the data packet to “both” Router B and C as Router D has the corresponding two PIT entries. Router A hence receives "two" data packets but only "one" of these data packets is forwarded to the consumer. The point is that the path used for returning the data may be different from the path used for sending interest, while it is not a problem for the ordinary interest-data communication.
Compared with the above interest-data communication, CCNinfo reply packets must be distinguished the paths -- whether the reply comes from either Router B or C -- because the reply message coming back through the inbound path must use the outbound path with the opposite direction. To do this, CCNinfo differentiates the PIT entries and successfully transmits request and reply messages via the same roundtrip path.

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

As the sentence says, CCNinfo requests flow in the opposite direction to the data flow.
In Terminology section, we already say an incoming face, an outgoing face, and an upstream router. We’ll also add a downstream router.

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

CCNinfo messages are differently handled from the regular interest-data messages. For example, CCNinfo supports the full-discovery request in which the PIT operation on a router is different. The CCNinfo Request message uses the hop-by-hop header to indicate intermediate routers. CCNinfo Replies MUST NOT be cached in routers upon the transmission of Reply messages.

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

All CCNinfo messages are defined in section 3.

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

In Cefore (https://cefore.net), there is an API by which a publisher informs the application prefix to the FHR and the FHR registers it into the FIB. The prefix entry then can be statically configured on other routers or announced by a routing protocol.
It depends on the implementation, but we will briefly describe this. Thanks.

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

Answered above.
Also, we can measure the path and cache condition not on/from the closest content forwarder when we use SkipHopCount.

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

Both the routing path information and in-network cache information are reported in the single Reply. Change it to "in the single Reply" is reasonable?

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

Section 4.1 says;
   Owing to some policies, a router may want to validate the CCNinfo
   Requests using the CCNx ValidationPayload TLV (whether it accepts the
   Request or not) especially when the router receives the "full
   discovery request" (see Section 5.3.2).

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

I cannot understand your comments.
This paragraph explains CCNinfo request will be rejected if the validation fails.

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

Yes, potentially there are multiple adjacent neighbor routers. We'll say "adjacent neighbor router(s)".

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

Routers along the path insert their report blocks in the hop-by-hop header in the request message whenever they forward the message. The user who sent the request can recognize the number of the router reports in the message but cannot recognize who inserted the wrong report(s) beyond the hop limit value when s/he receives the reply message. So if the user recognizes the wrong reply, s/he just ignores the whole reply message.

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

No, it is not obliged that all routers have synchronized clocks. Please see my answer for the following question about 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.

The regular Request messages are forwarded based on the FIBs with the forwarders' regular strategies. As section 5.3.1 says;
"CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. Some routers may have a strategy for multipath forwarding; when a router sends Interest messages to multiple neighbor routers, it may delay or prioritize to send the message to the upstream routers. The CCNinfo Request, as the default, complies with such strategies; a CCNinfo user could trace the actual forwarding path based on the forwarding strategy and will receive a single Reply message such as a content object."
However, as you see in Section 5.3.2, "There may be a case wherein a CCNinfo user wants to discover all possible forwarding paths based on the routers' FIBs." In this case, users can choose the "full discovery Request"; yet it does not imply broadcasting the message. It does not try to discover all the potential paths. CCNinfo request is always forwarded based on the FIB.
There is no discussion/definition about broadcast/multicast strategies in this document.

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

We do not say anything about broadcast/multicast strategy. CCNinfo Request-Reply messages are always follow routers’ FIB entries. I cannot find any contradiction here.

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

It is impossible to define the perfect timeout value that can be applied for any situation. This document does not propose the perfect timeout value that can be used in any situation/condition, but gives the guideline of the highest/lowest time out values with RFC2119 terminologies.
Note that in section 10.6 we mention the difficulties for defining the timeout value from the security perspectives as well.

> Section 5.5.
> 
> How do you determine that a neighbor is valid?

Defining the method for the neighbor validity is out of focus of this document, but we describe the adjacency verification in section 10.9 and refer to HopAuth as one of the potential mechanisms.

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

The word of "expanding" comes from expanding ring search. If the statement is readable without "expanding", I remove it in the revision.

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

All the possible scenarios are mentioned in section 6.

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

The evidence comes from RFC8569. It defines the default value (2 seconds) for InterestLifetime. This draft proposes the timeout value SHOULD NOT be lower than 2 seconds and SHOULD NOT be higher than the twice, and the default is in between.

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

We will say in the revision;
  "Note that it is RECOMMENDED for all the routers on the path to have synchronized clocks to measure one-way latency per hop; however, even if they do not have synchronized clocks, CCNinfo measures the RTT between the content forwarder and consumer."
We do not ensure or require the clocks are in sync, although we say "RECOMMENDED".

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

We will add a few more words for this sentence such as;
"CCNinfo may impose heavy tasks at content forwarders because it makes content forwarders seek their internal cache states reported in the Reply messages whenever they form the Reply messages."
Does this make sense?

Thanks.

Regards,

Hitoshi

> 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._______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg