Re: [icnrg] comments on Reflexive Forwarding draft

On 9 Apr 2020, at 12:04, Ken Calvert wrote:

> 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.
>
That may be, in which case the added complexity is not warranted. I’m 
interested on what others (particularly people who have implemented 
high-speed forwarders) have to say about this tradeoff. My personal view 
on this tradeoff is highly dependent on how frequent undetected interest 
loss is, since that makes the recovery penalty from over-estimating 
interest lifetime potentially very severe.

> 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.
>
We left the option there so that we haven’t boxed ourselves in if a 
use case appears. If we decide to explicitly disallow more than one 
reflexive interest TLV, there’s a convenient T_MALFORMED_INTEREST 
error that can be returned. Would obviously like more input on this 
issue as well.

> Cheers,
> Ken


> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO