Re: [ppsp] [Spam] 回复: 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 250B021F8539 for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 19:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.614
X-Spam-Level:
X-Spam-Status: No, score=-91.614 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_05=-1.11, 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 OXbF7zBaM1Rj for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 19:55:07 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 392EA21F851B for <ppsp@ietf.org>; Mon, 14 May 2012 19:55:07 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 893A0E57D; Tue, 15 May 2012 10:55:04 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 8000BE571; Tue, 15 May 2012 10:55:04 +0800 (CST)
Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051510550222-7031 ; Tue, 15 May 2012 10:55:02 +0800
Date: Tue, 15 May 2012 10:54:59 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: "arno@cs.vu.nl" <arno@cs.vu.nl>, ppsp <ppsp@ietf.org>
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> <4FAA0C76.9010306@cs.vu.nl>, <4FAA1680.9080000@cs.vu.nl>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012051510545944553531@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:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:04, Serialize complete at 2012-05-15 10:55:04
Content-Type: multipart/alternative; boundary="----=_001_NextPart477186012210_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003
X-TM-AS-Result: No--24.387-7.0-31-10
X-imss-scan-details: No--24.387-7.0-31-10;No--24.387-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Subject: Re: [ppsp] [Spam] 回复: 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:08 -0000

Hi Arno,
    Please see inline.




zhangyunfei

From: Arno Bakker
Date: 2012-05-09 15:02
To: ppsp@ietf.org
Subject: Re: [ppsp][Spam] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
On 09/05/2012 08:19, Arno Bakker wrote:
> 
>> 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.
> 
> Bins are actually more efficient than (start,end) in this example. With
> bin numbers, you'll in the worst case need an integer for every 1 in the
> bitmap, so 6 in this case. In a better case we might be able to address
> the 4 ones at the end as a single bin. However, if you use (start,end)
> addressing, you'll actually need 2 integers per 1 bit, or 12 integers.
> 

Correction: bins are equally or more efficient. It will take 3
(start,end) byte range pairs to represent 10001011110, so 6 ints. It
will take 3 to 6 bins to represent that, so 3-6 ints.

Yunfei: For representating a single 1 followed by 0, the range pair can be shortened 
from (start,end) to just (start). So 3 ints are eliminated in this case.
So my point is that:
1) in a worst case for bin, 101010..., the scheme of bin and range are equal considering in such case range scheme . only 1 ints is needed for a single 1;
2) in a common case where there are the consecutive 1 with the amount not the order of power of 2,
the scheme of bin is not more efficicent than range.
3) Only in the case where the consecutive 1 are of the amount the order of power of 2, one int is saved in bin scheme.
However the complexity is also increased in all 3 cases. So range scheme is a simple way to address this. 

CU,
     Arno

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp