Re: [Icnrg-harmonization] NDN use of nameless Data

Alex Afanasyev <aa@cs.ucla.edu> Tue, 06 September 2016 04:21 UTC

Return-Path: <cawka1@gmail.com>
X-Original-To: icnrg-harmonization@ietfa.amsl.com
Delivered-To: icnrg-harmonization@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15DE12B10D for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 21:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 cIzcSY62-QSk for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 21:21:41 -0700 (PDT)
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DFE12B04C for <icnrg-harmonization@irtf.org>; Mon, 5 Sep 2016 21:21:40 -0700 (PDT)
Received: by mail-pf0-f173.google.com with SMTP id w87so11996014pfk.2 for <icnrg-harmonization@irtf.org>; Mon, 05 Sep 2016 21:21:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Qhxzh0aZb6E8ZcHEajln50MNo6thx9j6zE0OfDhpUn4=; b=eo8GKlEC+K5jQ1IM2fAhywPjbkTbTAg0vgMbxHbRYrZ20YYk5kBbSvu3IH8u1kZ76t VG5H8p9iKozP8BPrZZEDZcqZnYn3dlPo3bW2ZEFU+UdRu8AKOA6L4wduYKxt0u8WOf+f WKeJ3/7Mj1u/Ywj7I87Ct3Gf362GsXjDwp8FlLOlCBbRneVydGBNWTkAIHcJ3ISfOVeF Uk5YAYoQYnn5zJyiJDTRFhEjs1af/bKiD/oadjfVvTp7LRxn/xQ4nVSpay03ct888Mei UOAQNdKptwaSzLeo23Cr8egNDffCYG+rNXgvxVdBtyRHj3MBxNugMR46kcg2KzePYsYc gYSQ==
X-Gm-Message-State: AE9vXwPv1K8KqXJKDXdUmibxYIzh/2vOzyAOAGLamRYD8LJzw8GGJILmeCpUqeJ/Me3log==
X-Received: by 10.98.134.135 with SMTP id x129mr12412076pfd.21.1473135700458; Mon, 05 Sep 2016 21:21:40 -0700 (PDT)
Received: from ?IPv6:2605:e000:1521:18b:197f:ce20:955:9b74? ([2605:e000:1521:18b:197f:ce20:955:9b74]) by smtp.gmail.com with ESMTPSA id g90sm19295618pfe.96.2016.09.05.21.21.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Sep 2016 21:21:39 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E1007503-2183-4586-9F4C-0533843D33A1"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail
From: Alex Afanasyev <aa@cs.ucla.edu>
In-Reply-To: <87A7A215-9145-4B1B-B240-213F0B1916B7@parc.com>
Date: Mon, 5 Sep 2016 21:21:38 -0700
Message-Id: <731A5A92-439C-40A3-A0A4-B0E1856BFCC5@cs.ucla.edu>
References: <92ABC834-3C47-4B3C-9D85-83493B8B9414@parc.com> <D96E28F4A22C864DBC6C871B5B1C4CC320CC5020@SJCEML701-CHM.china.huawei.com> <87A7A215-9145-4B1B-B240-213F0B1916B7@parc.com>
To: Marc.Mosko@parc.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/WHc5gSDASxGXfyImlEYJGxnGDPA>
Cc: ravi.ravindran@huawei.com, icnrg-harmonization@irtf.org
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
X-BeenThere: icnrg-harmonization@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: ICN Harmonization Discussion <icnrg-harmonization.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg-harmonization>, <mailto:icnrg-harmonization-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg-harmonization/>
List-Post: <mailto:icnrg-harmonization@irtf.org>
List-Help: <mailto:icnrg-harmonization-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg-harmonization>, <mailto:icnrg-harmonization-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 04:21:43 -0000

> There has been a bit of talk about CCNx making explicit the use of nameless objects, but Iā€™d like to point out that one can do essentially the same thing in NDN using the Interest Link.  If CCNx were to adopt the Link approach to routing indirection, it could be done this way too (though using the ContentObjectHashRestriction field, not the implicit digest).
> 
> This is based on the 0.2-alpha-3 NDN packet format specification and the SNAMP-NDN-Scalability.pdf paper.  If I have misread something, please let me know.
> 
> The NDN spec says a Name is zero or more NameComponent.  Therefore, I can create a Data object with an empty name.  In an Interest, I can put one NameComponent of type ImplicitSha256DigestComponent and set Min/Max SuffixComponents to 0 and then include one or more Link objects in the Interest for routing.

The fact that generic definition of the name allows zero component is not related to the fact that ALL data packets have name.  Name is the identifier of the data.  (What Lixia is arguing is that Interest packet must not have an empty name, as Interest should ask for something.  This part is an oversight in the current spec.)

In my opinion, there is no "nameless" Data in NDN.  I would like to say it even more generally, that in ICN there could not be "nameless" data, as name is data's identifier.  I understand that in CCNx 1.x spec you redefined the concept of the name, which creates a lot of confusion.

I would like also to reiterate my opinion that not properly naming each individual data packet is a serious limitation.  Yes, manifest and etc. can provide contexts to verify data, but it is really limitings.  Data packet by itself is worthless, as there is neither application context to which this packet belong nor security context to verify it.

And additional point.  I would like to bring back the conversation we had last week, where we pointed out that there are many cases where consumer inherently cannot know neither the full nor exact name.  Therefore, I'm not quite sure where are we going with this conversation.  In general, each Data packet should have a unique name.  And in many cases, such as real-time data retrieval, the name should use predictable naming conventions, at the very least to allow pipelining of interests.

---
Alex

> My understanding of NDN is that because the ImplicitSha256DigestComponent is not in the FIB, a forwarder will forward via the Link.  The nameless Data Object ā€“ having 0 name components ā€“ will have a FullName of only its ImplicitSha256DigestComponent and that will match the name in the Interest.
> 
> I believe this use of NDN also maintains the property we were going after in CCNx nameless objects in that one cannot poison the cache by feting a Data object by hash that could then later be confused with a Data object being fetched by prefix or name (unless one put a 0 component name in the Interest with MaxSuffixComponents of at least 1 and used Link routing).
> 
> Marc