Re: [decade] Object naming in -req and -arch

Peng Zhang <pzhang.thu@gmail.com> Tue, 10 July 2012 04:32 UTC

Return-Path: <pzhang.thu@gmail.com>
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCAC11E814C for <decade@ietfa.amsl.com>; Mon, 9 Jul 2012 21:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMjBbEs+u1sL for <decade@ietfa.amsl.com>; Mon, 9 Jul 2012 21:32:40 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4611E813E for <DECADE@ietf.org>; Mon, 9 Jul 2012 21:32:40 -0700 (PDT)
Received: by qaea16 with SMTP id a16so2009050qae.10 for <DECADE@ietf.org>; Mon, 09 Jul 2012 21:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=5PTEE6lLCCdf3f/7/PrKPPLVmzgSS3SCOFXDEz4umsg=; b=GHoedUndn2EVa71dfnFAOxlTDM65NQegOdUwCdOqwkc5ruY45Rm7rDpZ9mpavWbARZ KjfoFyH0ygfmLLaS6C9cR/56RVe9PqBzzbi4YrL/o1QFkpWFjvYOH3MruTuXC+RTKXFa AWRXEfDa65/ZdrHYl0LwGMRBpowxn23g5LSsjNtXuSl62Mw9uBT1MpJwDLbjJa/njEAl 2fh6F729KDGf/Y9Kiwu1kqYmF1MzO9NlqZ5MEtrZWREtmEYT00eDhcXO99dPicdo2Pm1 0FaCNAJ+pPwIC7lHAMefYSqbv01Vgq41jFKj24z0YR+JjsJpI//2UHc6FD3KCv8n8ocz rtzw==
Received: by 10.229.111.74 with SMTP id r10mr16926383qcp.24.1341894786970; Mon, 09 Jul 2012 21:33:06 -0700 (PDT)
Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id et8sm8359394qab.9.2012.07.09.21.33.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 21:33:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AF7FC25E-97D0-471D-B9F6-8CD19FB806D5"
From: Peng Zhang <pzhang.thu@gmail.com>
In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd>
Date: Tue, 10 Jul 2012 00:33:04 -0400
Message-Id: <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com>
References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> <ED41823C-5ACD-4428-866E-3C9B8D5BF16C@gmail.com> <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd>
To: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
X-Mailer: Apple Mail (2.1278)
Cc: "DECADE@ietf.org" <DECADE@ietf.org>
Subject: Re: [decade] Object naming in -req and -arch
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 04:32:41 -0000

Hi Dirk and all,

	I agree that the NI specification meets the basic requirement of DECADE (without optimization on "early name generation"). 

	As for the Merkle Hash Tree, or MTH, it is a integrity-assurance method for a sequence of objects. It is critical to the PPSP protocol. But i wonder wether we should incorporate it in our design:

	First, DECADE is targeted at general content distribution applications, and for applications other than P2P streaming, there is no great value of using Merkle Hash Tree. It may cause high overhead to these applications due "meta data" including signatures and full hashes should be exchanged. 

	Still, we can discuss more on how to better incorporate PPSP based on NI without hurting the general application of DECADE. Thanks.

B,

Peng.


On Jul 9, 2012, at 12:35 PM, Dirk Kutscher wrote:

> Hi Peng and all,
>  
> Thanks for the discussion.
>  
> So, I think it’s good to check the requirements and assess draft-farrell-decade-ni accordingly. I personally that it meets the ones you listed in your earlier message.
>  
> One of the interesting features is that the NI specification defines a common format that enables the integration of hashes (or other cryptographic functions’ output) into names and corresponding validation steps on nodes. The explicit signaling of the function that is actually used allows for application-specific usage (if so needed) and for some agility regarding crypto algorithms. A DECADE protocol specification could specify the usage of the scheme, MANDATORY to implement algorithms etc more specifically.
>  
> One of the, IMO, important things that have not been discussed sufficiently is the question about PPSP compatibility that Richard Yang brought up.
>  
> My view on this is as follows: the PPSP Merkle Hash Tree approach for static and live content has requirements on the *object* and *meta-data* format.  For example, chunks have to carry sibling and uncle hashes. Specifically, for live streaming with dynamic trees, chunks have to provide chunk signatures (block signature, chunk position in the block, and the digests of the sibling to the way to the root).
>  
> For both static object and live streaming with PPSP, I think, a hash-based naming scheme could be employed. Now, it can be worthwhile to employ a naming scheme that signals the existence of the specific object format (to aid receiving nodes). This would all be feasible with the scheme in draft-farrell-decade-ni – but it could be good to extend this discussion to PPSP.
>  
> Best regards,
> Dirk