Return-Path: 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 ; 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 ; 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 ; 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 Message-Id: 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" References: <11DAE974-C4B9-4733-A650-26C73BBBBA29@orandom.net> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 16:05:06 -0000 --Apple-Mail=_D4DA6EFB-4E5C-4610-9D9B-0797148BC0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t know how many additional RTTs may be involved, and pick = very large values, causing long recovery times on Interest loss. = There=E2=80=99s 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=E2=80=99t have = these mechanisms now for all link types, and for IP tunnels the loss = probability can be pretty high. I=E2=80=99ve attached a copy of the = presentation for refresh peoples=E2=80=99 memories. >=20 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 --Apple-Mail=_D4DA6EFB-4E5C-4610-9D9B-0797148BC0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=99t know how many additional RTTs may be involved, and pick = very large values, causing long recovery times on Interest loss. = There=E2=80=99s 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=E2=80=99t have these mechanisms now for all = link types, and for IP tunnels the loss probability can be pretty high. = I=E2=80=99ve attached a copy of the presentation for refresh peoples=E2=80= =99 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

= --Apple-Mail=_D4DA6EFB-4E5C-4610-9D9B-0797148BC0F4--