Re: [icnrg] comments on Reflexive Forwarding draft

[Ken Calvert <[e-mail]>]

Let me say that I believe the benefits of this reflexive forwarding scheme, in terms of keeping interests small and free of client-identifying information, are worth the added complexity - which is maybe not as significant as I first thought.
> You may very well be right that we picked the wrong tradeoff and the complexity and the additional hazard that has to be dealt with by consumers is not justified when the consumer can just inflate the original interest lifetime. Our concern was that consumers will have no motivation to even try to guess a good interest lifetime since they don’t know how many additional RTTs may be involved, and pick very large values, causing long recovery times on Interest loss. There’s a whole line of reasoning about these tradeoffs in the work my group did on timers for ICN back a few years ago. If the probability of undetected Interest loss is vanishing small (which it can be if you have robust hop-by-hop reliability mechanisms) then inflated interest lifetimes are not a big concern. However, we don’t have these mechanisms now for all link types, and for IP tunnels the loss probability can be pretty high. I’ve attached a copy of the presentation for refresh peoples’ memories.
> 
I was originally thinking that routers would (for engineering reasons) clamp interest lifetimes in their PITs in any case, and that the application would have a good idea of the number of additional round-trips.  Would it be reasonable to specify a design limit for this mechanism?  Say, enough for two round trips plus some transmit time - enough to get a manifest plus a limited amount of content. Seems like there are reasonable alternatives that applications needing a lot of info from the consumer could make use of, if Interest lifetimes are known to be absolutely bounded.

The other place where I had a (second order) comment is Section 4 - specifically, the enumeration of cases for contents of the Reflexive Name Prefix TLV.  First, allowing an option and then recommending against it (#4, multiple Reflexive Name TLVs) seems like not a good idea, especially for a mechanism that needs to be supported along the entire path.  If there's a compelling use case that requires this, it would be good to describe it explicitly.  Otherwise, it seems like a single TLV containing a reflexive prefix + optional consumer-defined suffix should suffice.

Cheers,
Ken