Subject: [icnrg] Draft Minutes from Sunday ICNRG Interim Meeting at UCL in advance of IETF 101 London

From: "David R. Oran" <[email-masked]>
Date: Tue, 20 Mar 2018 17:41:25 +0000

Comments & corrections to [email-masked]

Thanks,
DaveO.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 21 Mar 2018 10:12:36 +0900

Hi folks,

I give some comments for the questions about CCNinfo presented in the interim meeting.

=== copy from minutes ===
•	New draft: (based on Contrace): "CCNinfo: Discovering Content and Network Information in Content-Centric" : https://datatracker.ietf.org/doc/draft-asaeda-icnrg-ccninfo/ - Xun Shao (15 min)

Dave: the reason you depend on the timeout rather than the response, is that a single request can have multiple responses right? Have you thought about how to allocate the link resources for these things?
Dirk: you are ignoring flow balance here right?
Xun: There is no flow balance.
Dave: (chairhat off) indeed merging with traceroute won't work because they are quite different. Technical comment, since your planning on returning lot of information, channel allocation is made really difficult.
Borje: How far are you planning to distribute these Interest messages?
Xun: There are hop limit and timeout options
Dave: I think we need a way to trade off the resource expanses on the exploding amount of data that might be returned.
===

Section 5.2 says;
  "CCNinfo supports multipath forwarding.  The Request messages can be
   forwarded to multiple neighbor routers.  Some router may have
   strategy for multipath forwarding; when it 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 strategy; a CCNinfo user could trace the
   actual forwarding path based on the strategy.  On the other hand,
   there may be the case that a CCNinfo user wants to discover all
   potential forwarding paths based on routers' FIBs.  If a CCNinfo user
   invokes a CCNinfo Request with the parallel request flag (i.e.,
   "%x08" bit as seen in Figure 10), the forwarding strategy will be
   ignored and the router sends Requests to multiple upstream routers
   simultaneously, and the CCNinfo user could trace the all potential
   forwarding paths.  Note that this flag may be ignored according to
   the router's policy."

As you see, the CCNinfo's default behavior is that the request message is forwarded according to the routers' strategy; the request message is forwarded just like an ordinary interest. I don't think some extra flow control must be defined here.

On the other hand, from discovery perspective, in some situation we may want to discover all potential paths including all multipath configurations. In this case, a request message is forwarded through all potential upstreams. Regarding this behavior, some rate limit approaches should be considered, while we have not described them in detail. They will be precisely defined when it becomes an RG draft. :)
BTW, if there is a consensus that we should not adopt this fully-discovering request, we also have a choice to eliminate this option from the specification.

Regards,

Hitoshi