Re: [icnrg] icnrg Digest, Vol 97, Issue 1

Ken Calvert <calvert@netlab.uky.edu> Tue, 07 April 2020 20:49 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 8E0CE3A1231 for <icnrg@ietfa.amsl.com>; Tue, 7 Apr 2020 13:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HcuBwHzknuB1 for <icnrg@ietfa.amsl.com>; Tue, 7 Apr 2020 13:49:11 -0700 (PDT)
Received: from mail3.netlab.uky.edu (wonder.netlab.uky.edu [128.163.140.37]) by ietfa.amsl.com (Postfix) with ESMTP id 655963A1229 for <icnrg@irtf.org>; Tue, 7 Apr 2020 13:49:11 -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 A21EC1FF51 for <icnrg@irtf.org>; Tue, 7 Apr 2020 16:49:09 -0400 (EDT)
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9C7C17DA-782E-4FF8-9A9F-0F9EB0F1A512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Date: Tue, 07 Apr 2020 16:49:06 -0400
References: <mailman.100.1585854050.15246.icnrg@irtf.org>
To: icnrg@irtf.org
In-Reply-To: <mailman.100.1585854050.15246.icnrg@irtf.org>
Message-Id: <DB76BDBB-0BC6-4FF7-8496-882E07974DC1@netlab.uky.edu>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/zl6axlANaHx-ZPrhlMfO87XUeas>
Subject: Re: [icnrg] icnrg Digest, Vol 97, Issue 1
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: Tue, 07 Apr 2020 20:49:14 -0000

Dave and Dirk (and all) -

Thanks for writing up the reflexive forwarding scheme!  The draft describes it clearly.  (I have some minor presentation/typo comments that I'll send separately.)
I like the approach of having a separate FIB for this purpose!
> Since this is a fairly major change/enhancement to the CCNx forwarding model, it really needs a close review to help us figure out:
> 
> Are we crazy?
No more so than the rest of us, I think. :-)
> Is the complexity/functionality tradeoff appropriate?
I think that is the big question, and I'm still mulling it.  See below for some general comments.
> Did we miss anything, particularly any corner cases we should have considered
One thing I found myself wondering about is the definition of "next/previous hop".  All the diagrams and explanations seem to implicitly assume it's a single node.  What happens if a forwarder broadcasts a regular interest and it is received (and forwarded on) by multiple next hops? Is it worth mentioning that possibility so you can say explicitly that it's fine (or not)?

Along those lines, if a "next hop" is not identified with a specific machine, it seems like anyone that can get a packet to the upstream (toward the server) interface can blow away the reflexive FIB entry by sending a bogus Data packet that matches the interest.  But that is also true for PIT entries, so maybe this problem has a known solution (apologies for not knowing it).

My other comment is that the PIT entry lifetime-lengthening algorithm seems pretty complicated.  Why wouldn't it be sufficient to just put it on the consumer to set the lifetime of the original interest to be longer, and have forwarders admit a somewhat higher max lifetime for interests that carry a reflexive name prefix?  The application has to know whether the server might request information from it, so that seems cleaner, but I may be missing something.  I get nervous about per-packet state that can be renewed (see https://dl.acm.org/doi/10.1145/964725.633051 <https://dl.acm.org/doi/10.1145/964725.633051>).
> Which of the alternative approaches to backward/forward compatibility we describe seems the right one?
It seems to me there are two aspects to consider and they are mostly orthogonal:

(i) Enable neighboring forwarders to know each others' capabilities so they can construct and use routes that fully support reflexive forwarding (if they exist).  You posit two solutions to this, version numbers and a (new, to be designed) capabiliites-exchange protocol.

(ii) What should happen when an interest encounters a "gap" in support for reflexive forwarding? This can still happen, even with a solution to (i), and it can happen in the middle of the network. ISTM a solution to (i) would just (at best) shift who gets the "no route" error. In that case the consumer can get it when an interest containing a reflexive name reaches a forwarder that supports it, but which doesn't know a compliant route to the producer.  In every other case the producer can still get "no route to destination".   Apologies if I am missing something.
> Are there more use cases that we ought to document? We were hoping to have one or two to include for state synchronization, but have deferred that for now in the interest of getting the spec out for review.
> We’d like to talk about this at the ICNRG Interim meeting on April 20, so p[lease sets aside some time to read/eview/think about between now and then
> 
> 

I look forward to the discussion!

Ken