[icnrg] Fwd: New Version Notification for draft-oran-icnrg-reflexive-forwarding-00.txt

"David R. Oran" <daveoran@orandom.net> Thu, 02 April 2020 15:50 UTC

Return-Path: <daveoran@orandom.net>
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 942603A15C0 for <icnrg@ietfa.amsl.com>; Thu, 2 Apr 2020 08:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 hk8AzaGltM-8 for <icnrg@ietfa.amsl.com>; Thu, 2 Apr 2020 08:50:22 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DA63A15AD for <icnrg@irtf.org>; Thu, 2 Apr 2020 08:50:22 -0700 (PDT)
Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 032FoIBu011170 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Thu, 2 Apr 2020 08:50:20 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Thu, 02 Apr 2020 11:50:13 -0400
X-Mailer: MailMate (1.13.1r5680)
Message-ID: <6EBB0F3C-284B-4DF5-A5F0-96D9AEC83F15@orandom.net>
References: <158583825227.26288.2391283622080702417@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_3BE0A321-A1BD-44C4-85F5-2ACA07D11DEA_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/Ml-vVHOo-S7SKJWyVJ75L2Bu8FQ>
Subject: [icnrg] Fwd: New Version Notification for draft-oran-icnrg-reflexive-forwarding-00.txt
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, 02 Apr 2020 15:50:25 -0000

ICNRGers,

Dirk Kutscher and I have formalized the reflexive forwarding scheme we 
developed for RICE 
(https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final9.pdf), 
expanded it to cover more use cases (e.g. IoT sensors) and spelled out 
the whole scheme in detail including algorithms and encoding in the 
Internet Draft we just submitted.

It should work equally well for both CCNx and NDN and has concrete 
encoding for CCNx, although we need some help from the NDN team on what 
the best packet encoding ought to be in NDN for the new TLV we define.

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?
- Is the complexity/functionality tradeoff appropriate?
- Did we miss anything, particularly any corner cases we should have 
considered
- Which of the alternative approaches to backward/forward compatibility 
we describe seems the right one?
- 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.

Many thanks!

Dirk & DaveO.


Forwarded message:

> From: internet-drafts@ietf.org
> To: Dave Oran <daveoran@orandom.net>, David Oran 
> <daveoran@orandom.net>, Dirk Kutscher <ietf@dkutscher.net>
> Subject: New Version Notification for 
> draft-oran-icnrg-reflexive-forwarding-00.txt
> Date: Thu, 02 Apr 2020 07:37:32 -0700
>
> A new version of I-D, draft-oran-icnrg-reflexive-forwarding-00.txt
> has been successfully submitted by Dave Oran and posted to the
> IETF repository.
>
> Name:		draft-oran-icnrg-reflexive-forwarding
> Revision:	00
> Title:		Reflexive Forwarding for CCNx and NDN Protocols
> Document date:	2020-04-02
> Group:		Individual Submission
> Pages:		30
> URL:            
> https://www.ietf.org/internet-drafts/draft-oran-icnrg-reflexive-forwarding-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-oran-icnrg-reflexive-forwarding/
> Htmlized:       
> https://tools.ietf.org/html/draft-oran-icnrg-reflexive-forwarding-00
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-oran-icnrg-reflexive-forwarding
>
>
> Abstract:
>    Current Information-Centric Networking protocols such as CCNx and 
> NDN
>    have a wide range of useful applications in content retrieval and
>    other scenarios that depend only on a robust two-way exchange in 
> the
>    form of a request and response (represented by an _Interest-Data
>    exchange_ in the case of the two protocols noted above).  A number 
> of
>    important applications however, require placing large amounts of 
> data
>    in the Interest message, and/or more than one two-way handshake.
>    While these can be accomplished using independent Interest-Data
>    exchanges by reversing the roles of consumer and producer, such
>    approaches can be both clumsy for applications and problematic from 
> a
>    state management, congestion control, or security standpoint.  This
>    specification proposes a _Reflexive Forwarding_ extension to the 
> CCNx
>    and NDN protocol architectures that eliminates the problems 
> inherent
>    in using independent Interest-Data exchanges for such applications.
>    It updates RFC8569 and RFC8609.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat