Re: [icnrg] comments on Reflexive Forwarding draft

"David R. Oran" <> Thu, 09 April 2020 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36FCE3A0CF3 for <>; Thu, 9 Apr 2020 10:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AS7YhotLOLJY for <>; Thu, 9 Apr 2020 10:16:05 -0700 (PDT)
Received: from ( [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 054E43A0CE9 for <>; Thu, 9 Apr 2020 10:16:04 -0700 (PDT)
Received: from [] ([IPv6:2601:184:407f:80ce:adc1:3d0:f316:2de6]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 039HG0jZ028406 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Apr 2020 10:16:02 -0700
From: "David R. Oran" <>
To: Ken Calvert <>
Date: Thu, 09 Apr 2020 13:15:55 -0400
X-Mailer: MailMate (1.13.1r5681)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [icnrg] comments on Reflexive Forwarding draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Apr 2020 17:16:07 -0000

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