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

Ken Calvert <calvert@netlab.uky.edu> Thu, 02 June 2022 22:06 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 E221BC157B33 for <icnrg@ietfa.amsl.com>; Thu, 2 Jun 2022 15:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBCKD40RgQFk for <icnrg@ietfa.amsl.com>; Thu, 2 Jun 2022 15:05:59 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF60BC157B32 for <icnrg@irtf.org>; Thu, 2 Jun 2022 15:05:59 -0700 (PDT)
Received: from smtpclient.apple (69-174-167-135.lxtnkyaa.metronetinc.net [69.174.167.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id CACFB1813D for <icnrg@irtf.org>; Thu, 2 Jun 2022 18:05:56 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1654207557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=CPyQL3YpNK6DqDXNDhI6JgKDVrJ0903aO4zUueXORuI=; b=bWURSMN3WblmHlShjmDMA2OKde/0qjYk2/TI/A9JCtCIxTJJfziLeR1R7brKkN1SFBh8AO LAT/FiuqRdzFvUA0kxbG8j+paKMxf8HGLdE23lYP3D2+WRkahR2OjZ8+xKD6R0ev784pPf 9KnZRisiuB5DrIQ2i46sj7nkXs/xjX5dZEn6mLTMg6fdEQLNyr0F8KdJVwoR7NqNTJhnwX gVhRwcB1etbDKBgeFZmChBq6yDV50aGxpfpZFq6N85lQSjYtSf5FfQ1NfW0iWEvG5Ee95O xSAOjF2BpV8yVtVsiCEhu4J1wcyTZhdFzm8QxXMYFqsBPzmImAtmG09BI9aQsw==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Message-Id: <A575B682-D9B5-43E2-B6CA-0394D022D895@netlab.uky.edu>
Date: Thu, 02 Jun 2022 18:05:56 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1654207557; a=rsa-sha256; cv=none; b=ZLKx7jygR8rwonzPEODe43Z5I9LLaYQq3BKJ4kvxVp+ScHtiQOaVdMB3juPbmtUb93q/WE kMZhaMFfKn3v0hGZ1tfGV1nH3UxwIcQmIs2RYd3VzhpDKUWqro/dtxyV7TcxBlPXPVoe2I Fo6ih8SG4YQM+A8jD/Hwr0BuHVkQT2egvBtdbhDG7aW2Ux2mh6zqVjE2rZls7svLQtPMww 9RBnBZGN3REFyv39xj4jG1rp6duXyiXXjsNesehYe9tO5kwf8hWPgFyQT4Mf7adIwOpg7Q tig5tT0RAVs4me+J7ufUDYGGO77MeiU8jKFy2XqAr5J+BsDxXBJdvRhPjy0eQg==
ARC-Authentication-Results: i=1; mail.netlab.uky.edu; auth=pass smtp.auth=calvert@netlab.uky.edu smtp.mailfrom=calvert@netlab.uky.edu
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1654207557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=CPyQL3YpNK6DqDXNDhI6JgKDVrJ0903aO4zUueXORuI=; b=B3IL5p/kPwo1AbPDIh+gZq1MV+abf5QUA9wBDZDNTVJqz/K19Xy7yQUlcpBZ5tSxJY0655 u7IbQqDljllZms1Qoa+gPLzCqND/QAtCZ8EqhNFSFYVIAZMON8Q5pQuD9US2uNhiycNng4 a6htDEuLuEEVXwXOIGeVmmucdUx1eEOswDI+g2qHEFD8eSuoanCNDk7bd+UQHXRfKq5272 xAdZwjFTBpQqoglJTgPu2GRz+/veMcFzSyGDsvfOYncmnAEChb4gbcI7LpydEQdejxsZRc Ibsb7PDH7j0ZL//LtRkHhAz9ZCAIrsvHfAQwOEZbYZD7QMpUqNzQqjm52HiydA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/SHb5awW3JCcblzBSFbd_dUKPP-Y>
Subject: [icnrg] Comments on draft-oran-icnrg-reflexive-forwarding-02
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
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 Jun 2022 22:06:04 -0000

I finally got around to a careful read of "Reflexive Forwarding for CCNx and NDN Protocols".  I really like this work.  The draft is well-written, and does a great job motivating the approach. My comments are mostly nits, typos, and suggested clarifications.

Section 3:
Figure 2 - I know it is challenging to fit everything in the ASCII art, but the notation is a little inconsistent and therefore (to me) confusing.  For example, what is the difference between "FPT(I2)" and "FPT of I2"?  And is it the intent that the forward PIT token sent upstream over a link will ALWAYS be used as the RPT for reflexive Interests sent downstream over the same hop?  And mutatis mutandis (up<->down, forward<->reverse) for the corresponding Data objects?  Or is this an implementation choice?

Suggestion: give specific placeholder values for the various FPTs/RPTs in the example, e.g., "FPT=X", "RPT=Y", and show them in the message labels.

Section 5 - Constructing names for reflexive Interests:  Isn't case #3 subsumed by case #1?  Also, could not a manifest specify other methods of constructing names for the producer to retrieve, e.g., routable ones (as opposed to just "suffixes that may be used" with the RNP)?  IOW: the RNP/manifest pattern offers a clean way to switch to routed prefixes, which seems like it might be useful in some (e.g., mobile) use cases.  Maybe worth calling that out, though I still think it should be part of case #1.

Section 7 - Forwarder steps:   Step 2 - "and Interest" -> an Interest
Step 3 - seems like this logically precedes step 2.
Step 4 - suggest changing the third sentence to "else continue".
Step 6 - suggest "in this PIT entry" -> "in the PIT entry created in the previous step"
Also, "FTP TLV" -> "FPT TLV"

Also - "Append a FPT TLV to the Interest if the forwarder requires the downstream forwarder to supply an RPT..."  - I'm a bit confused about this.  My (possibly incorrect) understanding was that PIT tokens are an optional optimization.  Though they need to be supported for the whole reflexive forwarding scheme to work, I don't see how one forwarder can "require" another to use them.  In fact, it seems like things will still work - in this specific part of the protocol - if the downstream forwarder ignores the FPT here.  If I'm wrong, maybe it would be good to clarify where PIT tokens MUST be used. Otherwise I was going to suggest "Optionally add a FPT TLV to the Interest for the downstream forwarder to use as RPT in any returned Data for this Interest" ? (I told you these were nits!)

Section 7.1.2 -
IF Interest contains an RPT
   use RPT to lookup [-> look] up PIT entry...
ELSE ...
What happens if either lookup fails?

Section 10.2.1 - "It is therefore worth noting that the object is bound to the reflexive Interest full name via the hash..." - what hash?  The hash that is part of the Data object signature?

Section 10.2.2 - T_RETURN_PROHIBITED - cite CCNx RFCs?

Section 12.1, Table 2, entry for T_RPT - I believe "upstream" in the description should be "downstream".  (The rule I inferred is that Data and reflexive interests flow "downstream" and Interests and Data responding to reflexive interests flow "upstream".)

Section 13.1 - "with Length 9 bytes" -> "with Length 16 bytes".

Finally, about backward compatibility and partial deployment (Section 11): if the third alternative (neighbor capability negotiation protocol) is taken, maybe path switching could be used to tunnel through non-supporting routers?  But that is kind of begging the question...

Cheers,
Ken