[icnrg] draft-oran-icnrg-reflexive-forwarding-02

Dirk Kutscher <ietf@dkutscher.net> Wed, 16 February 2022 15:07 UTC

Return-Path: <ietf@dkutscher.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 DFA3B3A1364 for <icnrg@ietfa.amsl.com>; Wed, 16 Feb 2022 07:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 xPSIZZ-tJvCv for <icnrg@ietfa.amsl.com>; Wed, 16 Feb 2022 07:07:35 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (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 C11073A0C33 for <icnrg@irtf.org>; Wed, 16 Feb 2022 07:07:34 -0800 (PST)
Received: from [192.168.1.50] ([95.89.114.110]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MryKp-1o5X4j0E69-00ny5t for <icnrg@irtf.org>; Wed, 16 Feb 2022 16:07:32 +0100
From: Dirk Kutscher <ietf@dkutscher.net>
To: ICNRG <icnrg@irtf.org>
Date: Wed, 16 Feb 2022 16:07:31 +0100
X-Mailer: MailMate (1.14r5852)
Message-ID: <35388029-C3DB-42D8-9D08-2FB42A390381@dkutscher.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_1D37B468-F993-4001-B25C-A10981779E1F_="; micalg=sha-256; protocol="application/pkcs7-signature"
X-Provags-ID: V03:K1:4CFxLGJIJVQUOJwZxEUtKSoYsktkBWaGqwuNHSgT3EmG7fQzx+b vVs535YNIc3OoS6d2FWh5/e1DI2G9aci2wn7kL2nIU+fWQdj46gP/U1Y6xYcfbyPEOP0Cme x3RPrwhQgLNLNni0AsRuh4vWbHC7ws/VQlvYPIFk0YasQ4gG7NMO3tW4r+6kXy0/2qOs6dq fdQg2jAxGW/X03cXUATIw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:IiHzMkQTP6E=:GjCqbxyfYS5gaSqROxWUj9 IK0jp24zUENZJbKDHPbSgQYxrG2m/Lud7c4pq4a+7IuGvC0KctPtgPZxOS97DtdZw45c6jLzI 9tltDGVntAFqxg9bT4CcUgfqGVyaye6+JfYAcGci8H+LAtlV9OzmaTaTA1744rNyELQjAeDC/ pT5kl4by1SN1HQxC/9iS/vxyl1vIKoJuz9TWE82osKlUWVoyyBgCbS2g5SQMIphMFu5nY52e8 ZdAJqkaaam1j6F+JmXciY/WeVJD1rw7hj71Y7EOVH91/NbBjIXdMSlbvtz499hx69kEneZrBk pCzvkg/15vrTKoFRHGYIci3YoOZaRht1XCiKf8QANS5F/VCTXZULrEa+upUInv7fXKu5pDp4e X32oEk2vZaBFY8PJGSgATY6P+qZFQSKETBNXmA/A9Cs264co+rxA3nT6+m/D0G9HnTxKoaXWh o7MYxdBckuJ0GP8Sl+iRr4IIdrIwW+Iy2CFLg5kaIIXdikZU1xHSEuem3EYfQ4LItjwTVoMIS aUd4sIgZNl5nvhQMXXbVESZg3kU5xi1nu1A9yCM0aKYmzUSgaZnwh66XWGeETB609GFLg9iC6 79PefBVf+odmvMKfe+0E4vyUJ59XJqjfzlqA2anhcxm+vIKHVr7IfClcKuaOZxuBP+0sjPa4L YtG9gmcW4r9C0qo9iRWUzvyjCvo3ACpoChoVjfTUpEPCs7kYVVIZSk/Vubqd6TLQlZBE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/lTtihmeNqOoL9yC78QNBZpqBQ3Q>
Subject: [icnrg] draft-oran-icnrg-reflexive-forwarding-02
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: Wed, 16 Feb 2022 15:07:40 -0000

Hi ICNRG,

Dave and I had been working on an update the Reflexive Forwarding specification, and we just submitted a new revision. As a heads-up: we are planning to present and discuss this with the community at our upcoming meeting at IETF-113.

https://datatracker.ietf.org/doc/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.

**Key Changes**

The previous version was based on handling dynamic FIB entries. We have changed that know towards a token-based approach, inspired by the PIT token in the ndn-dpdk high-speed forwarder design [1] [2]. This design is allowing for less invasive and more efficient forwarder implementations, without being less robust/secure. It's also orthogonal to other potential enhancements such as path steering.

**Request for Feedback**

We are interested in feedback, especially from people who are working on forwarder implementations or on applications that require some kind of client-server-style communication, transferring consumer data to a producer etc.

Best regards,
Dave and Dirk



* [1] Junxiao Shi, Davide Pesavento, and Lotfi Benmohamed. 2020. NDN-DPDK: NDN Forwarding at 100 Gbps on Commodity Hardware. In <i>Proceedings of the 7th ACM Conference on Information-Centric Networking</i> (ICN '20). Association for Computing Machinery, New York, NY, USA, 30–40. DOI:https://doi.org/10.1145/3405656.3418715
* [2] https://github.com/usnistgov/ndn-dpdk