[decade] Fw: Re: [ppsp] Object naming in -req and -arch
zhangyunfei <zhangyunfei@chinamobile.com> Tue, 10 July 2012 08:25 UTC
Return-Path: <zhangyunfei@chinamobile.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 5C0D921F86CB for <decade@ietfa.amsl.com>; Tue, 10 Jul 2012 01:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.736
X-Spam-Level:
X-Spam-Status: No, score=-97.736 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
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 cnpI12VTfUgC for <decade@ietfa.amsl.com>; Tue, 10 Jul 2012 01:25:45 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E224F21F86C9 for <decade@ietf.org>; Tue, 10 Jul 2012 01:25:44 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 77B59E902; Tue, 10 Jul 2012 16:26:12 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 688CAE8F3; Tue, 10 Jul 2012 16:26:12 +0800 (CST)
Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071016260877-40726 ; Tue, 10 Jul 2012 16:26:08 +0800
Date: Tue, 10 Jul 2012 16:26:06 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: decade <decade@ietf.org>, "arno@cs.vu.nl" <arno@cs.vu.nl>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <20120710162606039401143@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 16:26:08, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 16:26:11, Serialize complete at 2012-07-10 16:26:11
Content-Type: multipart/alternative; boundary="----=_001_NextPart002337256328_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19030.004
X-TM-AS-Result: No--17.592-7.0-31-10
X-imss-scan-details: No--17.592-7.0-31-10;No--17.592-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Subject: [decade] Fw: Re: [ppsp] Object naming in -req and -arch
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
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 08:25:46 -0000
Arno's reply on MHT. BR Yunfei zhangyunfei From: Arno Bakker Date: 2012-07-10 15:49 To: ppsp@ietf.org Subject: Re: [ppsp] [decade] Object naming in -req and -arch Hi all I'll try to clarify the rationale and practical overhead of the Merkle Hash Trees in PPSP. For static content, MHTs enable content integrity protection using self-certified naming. Using a hash tree instead of a single hash is useful in all situations where the content is distributed in parts (=a sequence of objects as you mention it) that are immediately used. In particular, when the parts are delivered to a higher level app upon receipt they must be integrity checked beforehand. This applies to streaming, but perhaps also to other P2P apps using DECADE. Even if parts are not immediately used, an integrity check on parts can help to improve efficiency in a P2P context. An end-to-end integrity check when the content is completely downloaded is sufficient, but for efficiency it would be nice to know if the individual parts are correct instead of finding out at the end, especially for large content. Note that Merkle Hash Trees support both partial and end-to-end integrity checks. When a peer has a copy of the content and the name of the object (=its root hash in the MHT) he can calculate the MHT from the content and compare the calculated root hash to the name. He does not need to receive any of the intermediary hashes from others, if that is not required. Which brings us to the topic of overhead. As discussed in Sec. 5.5 of http://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt the size of the MHT depends on the number of chunks (objects) at the base of the tree. That number depends on the size of the chunks that are processed immediately in the P2P application. For PPSP over UDP over Ethernet these chunks are small. For other P2P apps the chunks may be bigger. How much of the MHT tree actually needs to be sent over the wire to a receiving peer depends on the download policy used. For a linear download only part of the tree needs to be transmitted, as the other part of the tree is calculated by the receiving peer while downloading. In the example in Sec. 5.5, only 7 of the 16 hashes in the tree are actually transmitted. Note that swift, the protocol on which the PPSP peer protocol is based was actually designed as a generic transport protocol, unifying regular downloads, VOD and live streaming. So it still supports efficient non-streaming download policies like BitTorrent's rarest first. In other words, its origins fits the general distribution nature of DECADE. Regards, Arno On 10/07/2012 07:23, Y. Richard Yang wrote: > 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. > _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp
- [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Stephen Farrell
- [decade] 答复: Object naming in -req and -arch Wangdanhua
- [decade] 回复: 答复: Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Stephen Farrell
- Re: [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Stephen Farrell
- Re: [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Stephen Farrell
- Re: [decade] Object naming in -req and -arch Y. Richard Yang
- [decade] 答复: 答复: Object naming in -req and -arch Wangdanhua
- Re: [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Stephen Farrell
- Re: [decade] Object naming in -req and -arch Zhang Peng
- Re: [decade] Object naming in -req and -arch Dirk Kutscher
- Re: [decade] Object naming in -req and -arch Peng Zhang
- Re: [decade] Object naming in -req and -arch Y. Richard Yang
- [decade] Fw: Re: [ppsp] Object naming in -req and… zhangyunfei
- Re: [decade] [ppsp] Object naming in -req and -ar… Peng Zhang
- Re: [decade] [ppsp] Object naming in -req and -ar… Arno Bakker
- Re: [decade] [ppsp] Object naming in -req and -ar… Peng Zhang
- Re: [decade] [ppsp] Object naming in -req and -ar… Arno Bakker
- Re: [decade] [ppsp] Object naming in -req and -ar… Songhaibin