[ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13

zhangyunfei <zhangyunfei@chinamobile.com> Wed, 18 April 2012 10:34 UTC

Return-Path: <zhangyunfei@chinamobile.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 11D1921F8592 for <ppsp@ietfa.amsl.com>; Wed, 18 Apr 2012 03:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.885
X-Spam-Level:
X-Spam-Status: No, score=-90.885 tagged_above=-999 required=5 tests=[AWL=-2.157, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, 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 dy5dqr8Pbibt for <ppsp@ietfa.amsl.com>; Wed, 18 Apr 2012 03:34:53 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EC78A21F858E for <ppsp@ietf.org>; Wed, 18 Apr 2012 03:34:52 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id C2A26EDD0; Wed, 18 Apr 2012 18:34:51 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 974AAEE56; Wed, 18 Apr 2012 18:34:51 +0800 (CST)
Received: from zyf-PC ([10.2.52.214]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012041818345009-29137 ; Wed, 18 Apr 2012 18:34:50 +0800
Date: Wed, 18 Apr 2012 18:34:45 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: "arno@cs.vu.nl" <arno@cs.vu.nl>
References: <OF97B14220.883D5968-ON482579DB.003454AD-482579DB.0035B23D@zte.com.cn> <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <20120418183444961415101@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-04-18 18:34:50, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-04-18 18:34:51, Serialize complete at 2012-04-18 18:34:51
Content-Type: multipart/alternative; boundary="----=_001_NextPart734332068654_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18846.006
X-TM-AS-Result: No--37.693-7.0-31-10
X-imss-scan-details: No--37.693-7.0-31-10;No--37.693-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: ppsp <ppsp@ietf.org>
Subject: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
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: Wed, 18 Apr 2012 10:34:54 -0000

Hi Arno,
    Pls see inline.Thanks.

Yunfei




zhangyunfei

发件人: Arno Bakker
发送时间: 2012-04-18 15:31
收件人: zhangyunfei
抄送: ppsp
主题: Re:[ppsp]回复: Re: Proposal to resolve Issue 10 + 13
On 18/04/2012 09:00, zhangyunfei wrote:
> Hi Arno,
> I think I understand your example. So is there some figures to show that 
> the case I raised is a small-probability case? That would be convincing 
> to show the efficiency of MHT method.

Hi Yunfei and all

bin numbers can be more bandwidth efficient and lead to a more elegant
design when used in combination with content integrity protection using
Merkle hash trees, as there is one unit in the system then. The
efficiency gains depend on usage. If you request chunks in groups of
powers of 2 (e.g. 128 KiB, 256 KiB) as is common in computer networks,
you only need single bin numbers. On the other hand, if you want to
express a sliding window over the chunk space, especially when that is
not a power of 2 wide, you need more than 1 bin number.

[Yunfei] This is what I worry about. We cannot assure that each time we can request 
chunks in groups of powers of 2, as it's dependent on what the serving peers have, which 
is hard to ensure that the number of available chunks being powers of 2. In such cases, requsting 
a range of chunks needs no more bits than bin number. What's worse, if the chunks peer A has is 
sparsely distributed, i.e., the chunkmap is likely to be 10001011110, bin numbering needs more bits.

> BTW, I remember that in last interim meeting, you replied that the 
> mapping between binmap and range expression is quite easy. Could you 
> elaborate this mapping? Thanks.

Assuming ranges are intervals of a list of chunks numbered 0...N: for a
given bin number "bin":

startrange = (bin & (bin + 1))/2
endrange = ((bin | (bin + 1)) - 1)/2
[Yunfei] I need more time to reply on this:)
Note that a binmap is a novel data structure to efficiently store a
bitmap, which is not directly related to bin numbers.

Regards,
    Arno