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

"Y. Richard Yang" <yry@cs.yale.edu> Tue, 10 July 2012 05:22 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD411E8117; Mon, 9 Jul 2012 22:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level:
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 9D43dnHE1Env; Mon, 9 Jul 2012 22:22:39 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C43C011E80F6; Mon, 9 Jul 2012 22:22:38 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so1707301obb.31 for <multiple recipients>; Mon, 09 Jul 2012 22:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D87iwea/XVb4pasH2W9pia4sx0awppRYHWa2iwgYUgc=; b=Fno9HxOlEdPXANB3HYEe5K6q1o+sEypIjB5WpjDy+cGiEbdQsDPkZVnU/xnxPjlY0e TVz6+SesQ5ABaJZEAb8mC3Ud9NlxProSZ9KlUVnymU10u5/DFupOYKC3e/9s5+hJTsMT UDDTsRPyyITTy0kzpHzloJkDPhc4B6J6e3ASVHwPSgOgeQ6GgTAjrTnnH9Beh7qpXscc im5pRvcMyMwjUDupn2lUjzDoPgIsUL/EvD0Ud4A6Sc3NGM/ChsqeXK+ysJT62dBZLdaI h2WNZZXLvdXZaSq5jukVUjT3JOOEd+7WU8Isz/s6V4PfkslWbwN0XQxT5ecQpTYTWAiV HQEQ==
MIME-Version: 1.0
Received: by 10.182.85.8 with SMTP id d8mr12228009obz.70.1341897785291; Mon, 09 Jul 2012 22:23:05 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.76.86.136 with HTTP; Mon, 9 Jul 2012 22:23:05 -0700 (PDT)
In-Reply-To: <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> <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com>
Date: Tue, 10 Jul 2012 13:23:05 +0800
X-Google-Sender-Auth: XHtBnwLIxGBVn17PzxTx3VEvnZs
Message-ID: <CANUuoLq1s+XyfnTNyU5juqbQBorirG+S4Tj-++82Noi0a6DVsw@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
To: Peng Zhang <pzhang.thu@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04479559d1356104c472ec52
Cc: "ppsp@ietf.org" <ppsp@ietf.org>, "DECADE@ietf.org" <DECADE@ietf.org>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>
Subject: Re: [ppsp] [decade] Object naming in -req and -arch
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 05:22:39 -0000

Hi Peng, Dirk,

I am cc'ing the ppsp list as well. You raised a good point on the
distinction between one object and a sequence of objects. To generalize, we
can discuss even a set of objects (no ordering), and a set of equivalence
objects (dynamic streaming that interleaves different resolutions). Your
arguement against MTH is higher overhead in the general case (end to end
arguements). How much exactly is the overhead? Decade may benefit from the
analysis from ppsp. Since streaming is considered as the main app, how much
overhead if decade has to build on top?

Thanks!

Richard

On Tuesday, July 10, 2012, Peng Zhang wrote:

> 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
>
>