Re: [icnrg] icnrg Digest, Vol 101, Issue 10

Ken Calvert <calvert@netlab.uky.edu> Sat, 08 August 2020 20:07 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 C4EF53A0D01 for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 13:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVyGFC8pdcqq for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 13:07:13 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00433A0D07 for <icnrg@irtf.org>; Sat, 8 Aug 2020 13:07:13 -0700 (PDT)
Received: from hardy.local (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 mail.netlab.uky.edu (Postfix) with ESMTPSA id 40EB418106 for <icnrg@irtf.org>; Sat, 8 Aug 2020 16:07:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1596917230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=clJMHw0vjvKx+dkmECow8tYA37gDW7emoc6pLITK7Jg=; b=qai5+wR5PAUxVkeYvbqEjOFF7TgB5Emrn/0R6NAW1fiPrLD53SLQ+L8A+6TAfcFCZWuPGt urXk0DKMw1o+50rD8wF1NFUPRKzLnbzZ4Ury2fL/fNqk61i6G13/NiCo2xnxnIdmBY4/be BtIpi0ZZyonVMdH3bR/KbClB3Ucc/D4o87H/vMB/M/H5RQVr1YGpCmzKuxS2CqZBMUOimg Gsm0suR6n3AhHuVdKC/JjRXTEHnLEu982Cb8tBD1Z5tPuiVTyfWJ9MoDG8Eke1eGlVeNLJ GgcEK7eO7XeQomvxcR0yCvd047ImANRuS6FIhQMx6Lhw2YZ9R4c4Ggr4QX5f6A==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_217B21C7-F6B9-4A3D-9440-606415DC091E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 8 Aug 2020 16:07:06 -0400
References: <mailman.96.1596826813.2510.icnrg@irtf.org>
To: icnrg@irtf.org
In-Reply-To: <mailman.96.1596826813.2510.icnrg@irtf.org>
Message-Id: <5BB844BD-CFD9-49D0-9948-A2B2782C4F43@netlab.uky.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1596917230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=clJMHw0vjvKx+dkmECow8tYA37gDW7emoc6pLITK7Jg=; b=dfobngi+tJ/qS/rEXV/orqUWZrFhF9LeiE1AMtDKDE7RLn+QBrMeeLamj52EatpM8FiQW3 c3N5ffYlH9xdZ+nPUD7OmsoXwxzXJtkLF/11JLXTXwjX/VbHbz1tdqMo+ZDseS2O/NyNrx rYzDbQ9af7YsPiY2jSuf76jwv+iOOri0HDYeaOFyJOj61ruHeDh+srDe/+I1emS7LXNiq+ ORWsNRDFs0I51Ivs3ivinthawLZuX7/zhFcgfQgVmfwatM/cJKylY0iXCDUkm8G51DeoKy rOeYnAGRSI2h2BuEh0hBxnQGMHd0iVCxjbwXvTRhiS2iLLqg7wXacqcb2cK+TQ==
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1596917230; a=rsa-sha256; cv=none; b=A8+Jy6QSwCpAjoHrzod0D6vbUIwXQo0dBOSWTXhQ39RzGdph/51QammdXCipdxDi6+OvER YGjq80GozuRHxrWzyLtLowHRwxq/BjidsTVD53gnNFoHToDTOqaK8ijcin0392EOA4enCR +Hlvl0KbUk+H8A4l/n0ZeWkr5blgROH5RC0nK/hMRC5lbvgwrd6tugsqQejulhTlgU7XGw Lj651vFQDcQO1jsOCVXe1ETfzTg3CDjxljK7CQEG3h2dJJH/mPMJIJzxVIbbbffvTf5+i4 P66p4o/xsntZYjCBFBLJoPYxdmOjOxrW4P+cr2BOXvvqixhri5tte2U1QD+dmA==
ARC-Authentication-Results: i=1; mail.netlab.uky.edu; auth=pass smtp.auth=calvert@netlab.uky.edu smtp.mailfrom=calvert@netlab.uky.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/oG7j9drBxb4CE5s5fyqeAnq8940>
Subject: Re: [icnrg] icnrg Digest, Vol 101, Issue 10
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: Sat, 08 Aug 2020 20:07:16 -0000

Dave said:
> I’m starting a new thread on this, since it’s coming at some of the architectural choices from a broader point of view than what the producers/consumers of application data may need in a Manifest. The implications, if you buy into my general proposition, touch on a number of aspects of Manifest design, including extensibility tradeoffs, what goes into the base required functionality, and how we view both security and privacy issues.
> 
> Here’s the basic premise. I believe we want Manifests to be useful to any element that stores, fetches, or caches the content described by a manifest. This includes both:
> 
> Repositories (in NDN terms “Repos”) that provide non-volatile storage of content produced elsewhere and act both as:
> 
> archival storage that can survive the temporary or possibly permanent unavailability of the original producer of data
> A form of distributed cache in which content can be replicated and advertised into routing the same way the origin producer would.
> Forwarder Caches (Content Stores) that can provide various optimizations beyond simple on-demand opportunistic caching to improve latency and/or robustness to downstream consumers. This would include watching for requested Manifests and in addition to caching them, using information in the Manifest to pre-fetch content likely to be requested by one or more downstream consumers.
> 
It seems to me that there is an important difference between these two kinds of things.  I regard the first thing as being outside the fundamental infrastructure of the network, and on the same footing as any other user with respect to network service providers (NSP) - somewhat analogous to DNS servers.  The second is part of the network infrastructure, and is controlled by the NSP.

The point is that it's a lot harder to change specs that are relied on by NSPs.  We are a long, long way from this being a serious problem today, but perhaps it's worth keeping IETF history in mind.  To that end, having a NO-COST option for the application to hide the manifest structure from NSP forwarders, right from the beginning (as I think is proposed under #3 below) is very important.
> Both of these require that Manifests have, I believe at a minimum, the following characteristics:
> 
> Manifests have Name Constructors so that these non-application elements are able to form Interests to fetch the content described in the Manifest without knowing application-specific namespace conventions.
> 
> We have some generally understood annotations (or whatever we decide to call this restricted form of metadata) to give hints about:
> 
> optimal/desirable fetch order
> relative importance for availability when producer is either not reachable or down
> interdependence of pieces if partial and not total to help drive cache replacement policies
> Clear and simple binding to the “right” security context so that there is not a complex explosion of signing and encryption keys. My recommendation would to allow only two security contexts for Manifests
> 
> signed/encrypted by keys used for application data. Such data would not be available to the intermediaries descried above.
> signed/encrypted under by the keys used for the Manifest itself. Such data would be available to any/all elements that are given the keys associated with the names in the Manifest’s namespace.
> any other goop in a Manifest (e.g. general application metadata) is treated as if were any other transparently cached application data, although I argue elsewhere against trying to support general application metadata in Manifests.
> 
> So, as a top level question, do people think these are important and/or reasonable requirements to accommodate in our Manifest architecture?
> 
FWIW, I think these are reasonable.  I agree with the general position that a base manifest structure should be defined in such a way that it can be implemented in a common library, and used by many(?) applications that don't need anything more than a way to abstract from (and amortize the cost of) chunking, signing, and possibly encrypting large blobs of bits.  I think it is not useful to define a highly abstract structure that needs to be re-implemented (or "profiled") for every application - especially at this early stage of the game.

Another top-level question for me is whether there is consensus that prefetching (by network elements) is something that a base manifest spec should be designed to support?  It seems to me to be very difficult to calculate the tradeoff of benefit with the cost to applications that don't need/want it.  If it is supported, an application hint "don't prefetch" would seem to be required (without requiring the manifest itself to be encrypted end-to-end).
> I’ll note that it is of course possible to design a completely separate data structure and named elements for use by Repositories and forwarders, but that seems to me to be way more complex than just viewing manifests in this broader context.
> 

Agree with this, but IMHO it makes the "signed/encrypted by keys used for application data" option very important.

Ken