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

Ken Calvert <calvert@netlab.uky.edu> Sat, 08 August 2020 19:18 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 4CC983A0CA7 for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 12:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 yPs9IMaDqpQt for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 12:18:22 -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 D9FAA3A0CA5 for <icnrg@irtf.org>; Sat, 8 Aug 2020 12:18:21 -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 0AAD1180A8 for <icnrg@irtf.org>; Sat, 8 Aug 2020 15:18:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1596914299; 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: in-reply-to:in-reply-to:references:references; bh=tUB3KoFGL3Dtr5dXdbLdliRyg7sGzVr9ZKjnGS8D2M8=; b=zXhrHQnKbRwHB5JfRJHlEFt7y2RG+dvyHf5+VAf16vzsRbL3Ab+H1qL2567mB6BH2g7jlv zFad+5diy8IX9Ps9TSp6XMJcL0S772BLWIYyu+uhgEr5zf1FO2oOGqGUY5FcW7H7i0/w+j hE7A8pJbBf2dc9ISZN1Ls91TNono4BQSL1CRR97/mXfpzFAM/f+yZjz3HlNRh3UgsdRdm6 FF11yW6qdzDsL7RwixczO+uwhr0hZRd6PZ7MSETz5qmS3LGBEjk4JrNNb5b+OBV2XQX+Q5 ZWwKu6IysBl67grbFwxj85KDz/EX4yYSpPxXlHotWyVCEGfJLNypX0u24ds2Pw==
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 13.4 \(3608.80.23.2.2\))
Date: Sat, 8 Aug 2020 15:18:16 -0400
References: <mailman.707.1596693979.7280.icnrg@irtf.org>
To: icnrg@irtf.org
In-Reply-To: <mailman.707.1596693979.7280.icnrg@irtf.org>
Message-Id: <B8726370-8DEC-4F8C-BB1B-9627A4B15AD1@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=1596914299; 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: in-reply-to:in-reply-to:references:references; bh=tUB3KoFGL3Dtr5dXdbLdliRyg7sGzVr9ZKjnGS8D2M8=; b=jPOqZzZAdcwvpABOUk65Ftx2NdDYWJzy0wx6udZSO3KTvvtobHh6+8AQW5XiSt4AX2cHwE Cwwxlh05uhrHd5s6fknbY++dBkTQ+YolzLoo0A6jrFzWNJnF6Sy8Jx6i/Mw0bQqRd5H4mK 18OmxYQlkU4wWaMoJS1gW8t24iyyvpXPtG8wTvkD2vjvyri2I2IfcKlA0bFh3Vl70hkR0p KTn7mRHztfkgyInyssoRH5VzmkPNAlSp3NELD2KbWU7/v4qHENMHL5uTrc7n03bcP+MHms Z57JBO2h/tzFqkcpcnjj5C9jsZ7zga0s1Wq2L0kE1AP93u5s+7LrOTaPSGYQcw==
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1596914299; a=rsa-sha256; cv=none; b=W9dOHP4tIEkGJ45I0fr/a8LU7w0PumXdhJ1x77hIDWSkWY9TxoCROFOCM7EywfBdm8mlkM dRhjO3YY3SSXB9kbXRSNVO3Gy2iM4cxLJaCzlk5uFlZ3jB1LGmIFgpjOkSgaj++/hU4vVk cZnN4llOcxbcwBUJaveZLRLvn3rIUSW5OfjGwOhDctQ5vnjmEflVkjkk04XNJXNhJr85J/ T8Vlv34Os9N7ndrxcFPMnYEFw98mQjNEQ08PrwmYOQ4x/HUijtAFlrk7TxDZ1T669DKJ2z mJzMRtV44wPOrIVrpv6LOXSSQJW6SuUjnuDixdNRHCzuC1vFfQKwHgJBiWqRiQ==
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/1KsFr447qWsl7YlfzbmzARh0dPI>
Subject: Re: [icnrg] icnrg Digest, Vol 101, Issue 6
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 19:18:23 -0000

OK, I've read through all the inputs except DaveO's latest "new thread" message.  This is the first of a couple of messages responding to particular things.

A comment on one of Christian's points (and a related point by others) on inlining:

> packet := length-limited data object (NDN, CCN)
> 
>         I assume that a data object has type information such that
>         "real blob" can be distinguished from "manifest packet". Having
>         a hash name and retrieving the data object will tell us what
>         kind of packet it is. Anything else (e.g., tagging hash
>         pointers whether they are pointing to real blobs or a manifest
>         pkt is a claim and thus unreliable. It's fine to keep such
>         tags as a decoration but these are not needed to implement
>         the virtual blob abstraction.
> 
> r_pkt := packet with TLV for "real blob"
> m_pkt := packet with TLV for "manifest"
> 
> r_pkt.payload = any                              # the "real blob"
> m_pkt.payload = manifest_spec
> 
> manifest_spec := deco + cont_seq                 # two fields, must fit in one packet
> deco          := None | hashval | inlined
> cont_seq      := sequence of (hashval | inlined)

Yikes - you lost me here.  I am interpreting "inlined" to mean "application data contained directly *in* the manifest structure" (analogous to inode inlining). So here you mean the sequence is heterogeneous, and I have to figure out if each element in the cont_seq is a 32/64-byte hash or some amount of real data?  I don't like this.  I have the same reaction to inlining "r_blob" data in a manifest (with no pointers).  Again, I apologize if I've misunderstood.  (I think Marc made the same point in a later message.)

My personal view is that, unlike iNodes, which you MUST go through to get access to the r_blob of a file (and therefore inlining is a reasonable shortcut), manifests are an OPTIONAL overhead amortization mechanism.  If you don't need to break an object into chunks, you can retrieve it directly.  If editing or whatever results in less a chunk size smaller than a hash pointer, well, the additional overhead of retrieving that small chunk is just overhead.  And it is traded off against the cost of determining, for EVERY element of EVERY cont_seq, whether it is a hash or inlined data.

(Note: As Dave mentions in a later note, we would need a way to represent "holes" in a virtual blob, if pointers are un-annotated and homogeneous - something like an all-zero pointer value could work for that. If each pointer has its own TLV [oog], you could have a "hole type", I guess.) 

Ken