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

zhangyunfei <zhangyunfei@chinamobile.com> Tue, 15 May 2012 02:55 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 267B121F85D8 for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 19:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.911
X-Spam-Level:
X-Spam-Status: No, score=-90.911 tagged_above=-999 required=5 tests=[AWL=-2.183, 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 jHowoPxBZfux for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 19:55:24 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1C721F851B for <ppsp@ietf.org>; Mon, 14 May 2012 19:55:23 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3DCFDE580; Tue, 15 May 2012 10:55:21 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 1ADABE57D; Tue, 15 May 2012 10:55:21 +0800 (CST)
Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051510551972-7040 ; Tue, 15 May 2012 10:55:19 +0800
Date: Tue, 15 May 2012 10:55:16 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: Picconi Fabio <Fabio.Picconi@technicolor.com>, "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> <20120418183444961415101@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012051510551681806632@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:20
Content-Type: multipart/alternative; boundary="----=_001_NextPart165312141558_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003
X-TM-AS-Result: No--41.393-7.0-31-10
X-imss-scan-details: No--41.393-7.0-31-10;No--41.393-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:回复: 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: Tue, 15 May 2012 02:55:25 -0000

+1.




zhangyunfei

发件人: Picconi Fabio
发送时间: 2012-05-14 19:17
收件人: zhangyunfei; arno@cs.vu.nl
抄送: ppsp
主题: RE: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
Sorry about the late reply. I agree with Yunfei. As I mentioned during the Paris meeting, I think that most exchanged buffer map are likely to look like this: 1) a contiguous range [0-P] (the peer has all chunks from 0 to P, where P is the playback position), a sparsely populated range [P+1,P+W] which corresponds to the download window, and an empty range [P+W+1,N]. So I’m not sure that bin numbers would constitute a big improvement over using a list of ranges.
Fabio
 
From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: mercredi 18 avril 2012 12:35
To: arno@cs.vu.nl
Cc: ppsp
Subject: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
 
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