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 8E0CE3A1231 for ; 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 ; 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 ; 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 ; Tue, 7 Apr 2020 16:49:09 -0400 (EDT) From: Ken Calvert 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, 7 Apr 2020 16:49:06 -0400 References: To: icnrg@irtf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 20:49:14 -0000 --Apple-Mail=_9C7C17DA-782E-4FF8-9A9F-0F9EB0F1A512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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: >=20 > 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 = ). > 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=E2=80=99d 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 >=20 >=20 I look forward to the discussion! Ken --Apple-Mail=_9C7C17DA-782E-4FF8-9A9F-0F9EB0F1A512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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).
  • 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=E2=80=99d 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

= --Apple-Mail=_9C7C17DA-782E-4FF8-9A9F-0F9EB0F1A512--