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

Picconi Fabio <Fabio.Picconi@technicolor.com> Mon, 14 May 2012 15:55 UTC

Return-Path: <Fabio.Picconi@technicolor.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 AF69C21F8805 for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 08:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.741
X-Spam-Level: *
X-Spam-Status: No, score=1.741 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 yrKJ5ca1r5cS for <ppsp@ietfa.amsl.com>; Mon, 14 May 2012 08:55:41 -0700 (PDT)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id D335B21F87F8 for <ppsp@ietf.org>; Mon, 14 May 2012 08:55:31 -0700 (PDT)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT7Eq8xk5GlkMM1eusoaMHmQdWMkKmz/k@postini.com; Mon, 14 May 2012 08:55:40 PDT
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 17:52:22 +0200
Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 14 May 2012 17:52:28 +0200
From: Picconi Fabio <Fabio.Picconi@technicolor.com>
To: "arno@cs.vu.nl" <arno@cs.vu.nl>
Date: Mon, 14 May 2012 17:52:27 +0200
Thread-Topic: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
Thread-Index: Ac0xzTrPI9O802dFRs+P8R1FUTHbygABm3Uw
Message-ID: <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com>
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> <4FB0FAEA.8010504@cs.vu.nl>
In-Reply-To: <4FB0FAEA.8010504@cs.vu.nl>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: ppsp <ppsp@ietf.org>
Subject: Re: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
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: Mon, 14 May 2012 15:55:41 -0000

Here's a brief comparison:

[0-P]
Bins: 1 integer if power of 2, multiple integers otherwise
Range list: always 2 integers

[P+1,P+W] worst case
Bins: W/2 integers
Range list: W/2 ranges, i.e., W integers

[P+1,P+W] average case
Bins: ?
Range list: ?

[P+W+1,N] empty range
Bins: no integers
Range list: no integers

Taking W=30 seconds and 3 chunks per second, 4 bytes per integer, and 1 buffer map per second to 10 neighbors, range list requires ~ 30 kbps in the worst case vs. ~ 15 kbps for bins. For a 1 Mbps stream, that's a 3% overhead instead of 1.5%, which I don't think is that big a deal.

Now, two things: 1) an optimized implementation of range lists would encode single-element ranges with a single integer, so the overhead would be identical to that of bins (i.e., 1.5%); 2) we're talking about the worst case which is extremely unlikely to happen... it would be interesting to do the average case analysis for the [P+1,P+W] interval.

Fabio


> -----Original Message-----
> From: Arno Bakker [mailto:arno@cs.vu.nl]
> Sent: lundi 14 mai 2012 14:31
> To: Picconi Fabio
> Cc: zhangyunfei; ppsp
> Subject: Re: [ppsp] 回复: Re:回复: Re: Proposal to resolve Issue 10 + 13
> 
> On 14/05/2012 13:17, Picconi Fabio wrote:
> > 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.
> >
> 
> Hi Fabio and all
> 
> can you clarify how you would express the above example in your
> proposed numbering scheme, which is [start byte range,end byte range],
> right?
> 
> In bin notation, there would be 1 or more bins to express [0-P] (more
> than 1 is needed if P is not a power of 2). For [P+1,P+W] there would
> be, at worst case (=0101010101...) 1 bin per 2 chunks, so W/2 bins. The
> empty range would require no bins. As each bin requires 1 int, the on-
> the-wire costs of transmitting this chunk availability map are ~ W/2
> integers.
> 
> To summerized my position: bins are more efficient in common
> situations, and lead to a clean protocol design when Merkle Hash trees
> are used for content integrity protection, at the cost of a small
> increase in complexity.
> 
> Regards,
>     Arno