Re: [icnrg] comments on Reflexive Forwarding draft

Ken Calvert <calvert@netlab.uky.edu> Thu, 09 April 2020 16:05 UTC

Return-Path: <calvert@netlab.uky.edu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8A3A0B4E for <icnrg@ietfa.amsl.com>; Thu, 9 Apr 2020 09:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DuAaW9JNSdj for <icnrg@ietfa.amsl.com>; Thu, 9 Apr 2020 09:04:59 -0700 (PDT)
Received: from mail3.netlab.uky.edu (wonder.netlab.uky.edu [128.163.140.37]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE43A0B59 for <icnrg@irtf.org>; Thu, 9 Apr 2020 09:04:38 -0700 (PDT)
Received: from [192.168.73.191] (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.netlab.uky.edu (Postfix) with ESMTPSA id EB9FF1FF51; Thu, 9 Apr 2020 12:04:36 -0400 (EDT)
From: Ken Calvert <calvert@netlab.uky.edu>
Message-Id: <DA4AE662-B81D-4908-BB36-9ACEAD24FECF@netlab.uky.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D4DA6EFB-4E5C-4610-9D9B-0797148BC0F4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Date: Thu, 9 Apr 2020 12:04:34 -0400
In-Reply-To: <11DAE974-C4B9-4733-A650-26C73BBBBA29@orandom.net>
Cc: icnrg@irtf.org
To: "David R. Oran" <daveoran@orandom.net>
References: <mailman.100.1585854050.15246.icnrg@irtf.org> <DB76BDBB-0BC6-4FF7-8496-882E07974DC1@netlab.uky.edu> <11DAE974-C4B9-4733-A650-26C73BBBBA29@orandom.net>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/FMPaSZFVlQmAffRHEvQNjN2Hf24>
Subject: Re: [icnrg] comments on Reflexive Forwarding draft
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 16:05:06 -0000

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