
From hishigh@gmail.com  Sun Nov  3 16:14:02 2013
Return-Path: <hishigh@gmail.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 54B2F11E825C for <ppsp@ietfa.amsl.com>; Sun,  3 Nov 2013 16:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001]
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 o80kAFEc7p3d for <ppsp@ietfa.amsl.com>; Sun,  3 Nov 2013 16:14:01 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A511E825D for <ppsp@ietf.org>; Sun,  3 Nov 2013 16:13:59 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id uz6so6595711obc.0 for <ppsp@ietf.org>; Sun, 03 Nov 2013 16:13:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oq5KWPh4TSXJfHWV3uFIZzZHknG7eiHy8dWGKLtmJUw=; b=DMaydbT7e+1xG7UxdvUfZ8KUZUeNoW/xkKOUY8F5fjBgwTlSmKNnGTL0XxZciJL+lP r71oE1MHY6z4f9AenwTzZZx+UhVq2Xdrk3qbC6b49qsodohv1X4Q27PjXlXBjc3VAOPA 7dhQ98GtCHp0DTnQFxcC29nHYPXS3lTk2a0H7t+vPL/G8VIrSXHQI1ONp5OFtLgcs0uI CUIsPPmm11NoQY49eBVncPykZB+CJNMwF+VXvi2gsKNOrJYvBmUCq8eZfD0pYJGPyM8t ZiV3CCoO4jBtkh7njsopW/IQM/l2PEHPkCgron9Uzld3J+DoO2mFd3r9qrOILSRsc9HP cRuQ==
MIME-Version: 1.0
X-Received: by 10.60.98.69 with SMTP id eg5mr1897886oeb.42.1383524039531; Sun, 03 Nov 2013 16:13:59 -0800 (PST)
Received: by 10.76.98.43 with HTTP; Sun, 3 Nov 2013 16:13:59 -0800 (PST)
Date: Mon, 4 Nov 2013 08:13:59 +0800
Message-ID: <CAHJOc1DqPmQNN_qKZmzn1m0t1LUzTVYAMOtK+baqr6d7dA1Wiw@mail.gmail.com>
From: yunfei zhang <hishigh@gmail.com>
To: "ppsp@ietf.org" <ppsp@ietf.org>
Content-Type: multipart/alternative; boundary=089e013a14c4ea231704ea4ecae1
Subject: [ppsp] Please send the slides for this IETF
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, 04 Nov 2013 00:14:02 -0000

--089e013a14c4ea231704ea4ecae1
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
   For those who'll present on this IETF, please send your slides to Ning
and me befor this night. Also for Arno and Rui, please be reminded to test
the remote effect on Tuesday noon. It's kindly suggested to connect with
the backup people on site to avoid the possible wire problems. See you all
in Vancouver.

BR
Yunfei&Ning

--089e013a14c4ea231704ea4ecae1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>=A0 =A0For those who&#39;ll present on this IETF, please send y=
our slides to Ning and me befor this night. Also for Arno and Rui, please b=
e reminded to test the remote effect on Tuesday noon. It&#39;s kindly sugge=
sted to connect with the backup people on site to avoid the possible wire p=
roblems. See you all in Vancouver.</div>
<div><br></div><div>BR</div><div>Yunfei&amp;Ning</div><div><br><br></div>

--089e013a14c4ea231704ea4ecae1--

From denglingli@chinamobile.com  Mon Nov  4 16:35:03 2013
Return-Path: <denglingli@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 1FD5A21E834F for <ppsp@ietfa.amsl.com>; Mon,  4 Nov 2013 16:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.075
X-Spam-Level: 
X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152]
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 vaSbmTPgTa+u for <ppsp@ietfa.amsl.com>; Mon,  4 Nov 2013 16:34:58 -0800 (PST)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id B070021E838E for <ppsp@ietf.org>; Mon,  4 Nov 2013 16:34:57 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252783ccc7b0-0a7b0; Tue, 05 Nov 2013 08:33:17 +0800 (CST)
X-RM-TRANSID: 2ee252783ccc7b0-0a7b0
Received: from cmccPC (unknown[31.133.162.48]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee252783ccace4-37d47; Tue, 05 Nov 2013 08:33:17 +0800 (CST)
X-RM-TRANSID: 2ee252783ccace4-37d47
From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= <denglingli@chinamobile.com>
To: "'ppsp'" <ppsp@ietf.org>
Date: Tue, 5 Nov 2013 08:34:47 +0800
Message-ID: <046501ced9be$d5fb1a60$81f14f20$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Zvd4vKC0YBL0rTECah8T9+JzF9wAAElBQ
Content-Language: zh-cn
Subject: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-04=2Etxt?=
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: Tue, 05 Nov 2013 00:35:03 -0000

Hi forks,

We are happy to announce the latest version of BFbitmap draft.
In this version, we discussed open issues for accommodating several =
chunk addressing schemes in general as well as how to integrate the BF =
scheme with PPSP protocols.
Your comments and suggestions would be highly appreciated.

BR
Lingli

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org =
[mailto:internet-drafts@ietf.org]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B411=E6=9C=885=E6=97=A5 =
8:29
=E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Yunfei Zhang; Yihong Huang; =
Jin Peng; Lingli Deng; Rachel Huang
=E4=B8=BB=E9=A2=98: New Version Notification for =
draft-deng-ppsp-bfbitmap-04.txt


A new version of I-D, draft-deng-ppsp-bfbitmap-04.txt
has been successfully submitted by Lingli Deng and posted to the
IETF repository.

Filename:	 draft-deng-ppsp-bfbitmap
Revision:	 04
Title:		 Efficient Chunk Availability Compression for PPSP
Creation date:	 2013-11-05
Group:		 Individual Submission
Number of pages: 13
URL:             =
http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-04.txt
Status:          =
http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap
Htmlized:        http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-04
Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfbitmap-04

Abstract:
   Bloom filters are proposed to be used in compressing chunk
   availability information, periodically exchanged between peers and
   the tracker through PPSP-TP and PPSPP protocols, to reduce relevant
   cost and enhance scalability.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of =
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





From a.bakker@vu.nl  Wed Nov 20 04:28:26 2013
Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1CB1ADEAE for <ppsp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level: 
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnRBuKi9ULTe for <ppsp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:28:23 -0800 (PST)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id DE4111ADE86 for <ppsp@ietf.org>; Wed, 20 Nov 2013 04:28:22 -0800 (PST)
Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 13:28:13 +0100
Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 13:28:14 +0100
Message-ID: <528CAAE7.9030907@cs.vu.nl>
Date: Wed, 20 Nov 2013 13:28:23 +0100
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: <ron.even.tlv@gmail.com>, ppsp <ppsp@ietf.org>, riccardo <r.petrocco@gmail.com>
References: <051501ceccad$b4247620$1c6d6260$@gmail.com> <5271244D.1040606@cs.vu.nl>
In-Reply-To: <5271244D.1040606@cs.vu.nl>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.37.253.20]
Subject: Re: [ppsp] Quaetions on tracker and peer protocols
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: arno@cs.vu.nl
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, 20 Nov 2013 12:28:26 -0000

Hi Roni

Did you get my first reply? I just noticed I replied just to the mailing
list, not to you directly, sorry. I've been reading up on ICE and here
is my take on the matter.

To use ICE, a communication channel running a signalling protocol such
as SIP or P2PSIP is needed to transmit the offers and answers. For the
peer protocol, I assume this signalling protocol is a separate protocol,
so no signalling functionality is needed in the peer protocol (as it
isn't in RTP). How the combination of the peer protocol and that
signalling protocol work together can be described in the planned usage
guide draft.

Theoretically, such signalling functionality could be added to the
tracker protocol, but I leave that up to the tracker protocol designers.

In conclusion, for the peer protocol to work with ICE it seems to me
that it is sufficient if we allow STUN and TURN traffic on the same UDP
port as used by the peer protocol. STURN/TURN messages all start with
32-bits containing message type and length, followed by a 32-bit magic
cookie 0x2112A442 [RFC5389,p. 11]. A peer protocol UDP datagram starts
with a 32-bit connection ID, followed by 0 or more PPSPP messages. Each
message consists with a 1 byte message type. Hence, if we reserve
message type 0x21, a UDP datagram can be easily recognized as either
PPSPP or STUN/TURN by checking the length and the 5th byte.

Regarding your item 6 about PEX_RES and same addresses. I misunderstood
your question. The answer should be (quoting from the peer protocol
draft): "If a PEX_REQ message does not originate from a private or
link-local address [RFC1918][RFC4291], then the PEX_RES* messages sent
in reply MUST NOT contain such addresses."

Regards,
    Arno


On 30/10/2013 16:22, Arno Bakker wrote:
> Hi Roni and all
> 
> thanks for your interesting questions, and sorry for my slow reply.
> Please see inline for the peer protocol related parts.
> 
> On 19/10/2013 11:29, Roni Even wrote:
>>
>> 3.       It is also not clear what types of transport are allowed and
>> supported, the only one mentioned is UDP with LEDBAT for congestion control.
>> There is some mention of DTLS in the security section but I think that
>> currently the IESG will require some mandatory secure transport or an
>> explanation why one is not specified.  Maybe propose DTLS over UDP/ICE for
>> transport. 
>>
> 
> At present only UDP with LEDBAT congestion control is allowed. Future
> extensions may define the peer protocol over other transports. The peer
> protocol itself is secure in the sense that integrity of the chunks
> cannot be interfered with, it cannot be used for amplifications attacks
> and malicious peers cannot completely halt its operation, as described
> in the Security Considerations. Did you find holes in these protection
> mechanisms that require DTLS by default in addition? We only have DTLS
> or IPsec when a deployer wants point-to-point confidentiality.
> 
> 
>> 5.       In the peer protocol the HANDSHAKE message does not discuss NAT
>> traversal using ICE to supply more candidates. Is the PEX_REQ and PEX_RES
>> messages duplicating ICE?
>>
> 
> Question is whether the candidate signaling of ICE is done purely via
> the tracker protocol, or also via the peer protocol? I did notice that
> we should add a paragraph to the peer protocol to ensure STUN packets
> are not mistaken for PPSPP datagrams. Reserving message type 0x21 such
> that the magic cookie can be recognized should be enough (see [RFC5389,
> p. 11].
> 
> 
>> 6.       About using PEX_RES message for introducing peers; if peer B and C
>> are in one address domain and A and D are in other than it may happen that
>> peer C and D will have the same IP address, so when B sends to A in the
>> PEX_RES the address of C then A may send PEX_RES to D?
>>
> 
> PEX_REQ and PEX_RES are now (draft-08) used solely for address
> gossiping, and not for NAT hole punching anymore.
> 
> 
>> 7.       In the peer protocol what is the data format the example in section
>> 8.6 have the DATA as ASCII encoded. 
> 
> We have replaced this formalism with the normal IETF bits-on-the-wire
> specification that is hopefully less ambiguous.
> 
> Regards,
>      Arno
> 


From a.bakker@vu.nl  Wed Nov 20 04:39:35 2013
Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531EC1ADF55 for <ppsp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level: 
X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jy4VMll_PEB for <ppsp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:39:34 -0800 (PST)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3E1ADF56 for <ppsp@ietf.org>; Wed, 20 Nov 2013 04:39:34 -0800 (PST)
Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 13:39:26 +0100
Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 13:39:26 +0100
Message-ID: <528CAD87.6020004@cs.vu.nl>
Date: Wed, 20 Nov 2013 13:39:35 +0100
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: <ppsp@ietf.org>
References: <01ab01cece07$7f966a20$7ec33e60$@com>
In-Reply-To: <01ab01cece07$7f966a20$7ec33e60$@com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [130.37.253.20]
Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-03=2Etxt?=
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: arno@cs.vu.nl
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, 20 Nov 2013 12:39:35 -0000

On 21/10/2013 04:44, 邓灵莉/Lingli Deng wrote:
> Hi all,
> 
> With Rachel's help and input, we have updated the BF draft, with more
> specific description about PPSP protocol integration added. After a
> preliminary analysis, it seems that both the current extended tracker
> protocol and peer protocol can incorporate this new algorithm pretty
> easily.
> 
> Your comments are more than welcome.
> 

Hi all

after the meeting I kept on thinking about the use of bloom filters to
convey chunk availability. One additional problem with their use is that
the peer protocol does not tolerate structural omissions ("miss-hits")
in the chunk availability.

Take the example of a single peer with no content (leecher) talking to a
peer with the complete content (seeder). If the bloomfilter that is sent
by seeder is lossy, and does not convey that the seeder has all,
the leecher will be stuck forever waiting to download the unreported
chunks.

More general, in scenarios with multiple peers the bloomfilter creation
algorithm will have to ensure that for each chunk there is least one
peer that reports it as available for download.

Regards,
    Arno

From zongning@huawei.com  Sun Nov 24 17:37:45 2013
Return-Path: <zongning@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3F1AE387 for <ppsp@ietfa.amsl.com>; Sun, 24 Nov 2013 17:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.125
X-Spam-Level: 
X-Spam-Status: No, score=-104.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScjgeUEFJ8mt for <ppsp@ietfa.amsl.com>; Sun, 24 Nov 2013 17:37:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C4D291AE09F for <ppsp@ietf.org>; Sun, 24 Nov 2013 17:37:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAQ83699; Mon, 25 Nov 2013 01:37:33 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 01:37:09 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 01:37:31 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 09:37:28 +0800
From: Zongning <zongning@huawei.com>
To: "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: Meeting minutes
Thread-Index: Ac7pfuZamObxbFoDRMaQ/HEAHhRYyg==
Date: Mon, 25 Nov 2013 01:37:28 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC6667792585356B@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.28]
Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792585356Bnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [ppsp] Meeting minutes
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Nov 2013 01:37:45 -0000

--_000_B0D29E0424F2DE47A0B36779EC6667792585356Bnkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksIEZvbGtzLA0KDQpTb3JyeSBmb3IgdGhlIGJlbGF0ZWQgbWludXRlcyBhbmQgdGhhbmtzIFJv
bmkgZm9yIHRha2luZyB0aGUgbm90ZXMuIFBsZWFzZSBzZWUgYmVsb3cgYW5kIGxldCB1cyBrbm93
IGFueSBjb3JyZWN0cyBuZWVkZWQuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpQUFNQIFNlc3Npb25ASUVURiA4OA0KDQpQbGF6
YSBDLFR1ZXNkYXkgQWZ0ZXJub29uIFNlc3Npb24gSUlJLCBOb3YgNSwgMjAxMw0KDQoNCg0KMTY6
MTAgQWdlbmRhIGJhc2hpbmcgKENoYWlycywgNSBtaW51dGVzKQ0KDQpObyBjb21tZW50cw0KDQoN
Cg0KMTY6MTUgU3RhdHVzIG9mIHRoZSBXRyAoQ2hhaXJzLCAxMCBtaW51dGVzKQ0KDQoxKSAgUGVl
ciBkcmFmdCCoQyBtb3JlIHJldmlldyBuZWVkZWQsIGVzcGVjaWFsbHkgb24gc2VjdXJpdHkgYW5k
IGVuY29kaW5nIHBlcnNwZWN0aXZlcy4NCg0KMikgIFRyYWNrZXIgYmFzZSBkcmFmdCCoQyBuZWVk
IGF1dGhvciB0ZWFtIHRvIHByb2dyZXNzIHRoZSBkcmFmdCBmYXN0ZXIsIG1vcmUgY2FsbHMgYXJl
IG5lZWRlZC4NCg0KM6OpU3VydmV5IGRyYWZ0IKhDIG5lZWQgMm5kIFdHTEMgYmVmb3JlIHN1Ym1p
dHRpbmcgdG8gSUVTRy4NCg0KDQoNCjE2OjI1IFBlZXIgUHJvdG9jb2wgKEFybm8gcmVtb3RlbHks
NTAgbWludXRlcyksIGRyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTA4DQoNCjEpICBOZXcg
cmV2aXNpb24gaGFzIGFkZHJlc3NlZCBhbGwgY29tbWVudHMgZnJvbSBBRCByZXZpZXcuDQoNCjIp
ICBTb21lIGNvbW1lbnRzIGZyb20gUm9uaSBuZWVkIHRvIGJlIGFkZHJlc3NlZCwgZS5nLiBpZiBw
ZWVyIHByb3RvY29sIG5lZWQgdG8gZGVmaW5lIGhvdyB0byBkbyBOQVQgdHJhdmVyc2FsLiBUbyBi
ZSBkaXNjdXNzZWQgb24gdGhlIGxpc3QuDQoNCjMpICBDaHVuayBzaXplIGlzc3VlIGZyb20gWXVu
ZmVpPw0KNCkgIENodW5rIGFkZHJlc3NpbmcgaXNzdWUgqEMgbmVnb3RpYXRpb24gaXMgYmV0dGVy
Lg0KTGluZ2xpOiBpbiB0aGUgbGF0ZXN0IHZlcnNpb24sIHRoZSBwYXJ0IGZvciBvbmxpbmUgdHJh
bnNsYXRpb24gYmV0d2VlbiBjb21tdW5pY2F0aW5nIHBlZXJzIHVzaW5nIGRpZmZlcmVudCBjaHVu
ayBhZGRyZXNzaW5nIHNjaGVtZXMgYXJlIHJlbW92ZWQuIFdoeT8NCkE6IEl0IGlzIHRvbyBjb21w
bGljYXRlZCBhbmQgbm90IG5lY2Vzc2FyeS4NCg0KDQoxNzoxNSBUcmFja2VyIFByb3RvY29sIChS
dWkgcmVtb3RlbHksIDUwIG1pbnV0ZXMpLCBkcmFmdC1pZXRmLXBwc3AtYmFzZS10cmFja2VyLXBy
b3RvY29sLTAyDQoNCjEpICBJbiB0aGUgZHJhZnQsIHN0aWxsIFhNTCBmb3JtYXQgaW4gbWFpbiBi
b2R5LiBOZWVkIHRvIG1vdmUgWE1MIGV4YW1wbGUgdG8gYXBwZW5kaXggd2l0aCBtb3JlIHJlZmVy
ZW5jZXMuDQpZdW5mZWk6IFRoZSBuZXcgdmVyc2lvbiBkb2VzbqGvdCByZWZsZWN0IHRoZSBjb25z
ZW5zdXMgbWFkZSBpbiB0aGUgbGFzdCBtZWV0aW5nLCB3aGljaCBpcyB0byBtb3ZlIHRoZSBlbmNv
ZGluZyBpc3N1ZXMgdG8gdGhlIGFwcGVuZGl4IHdoaWxlIGtlZXAgdGhlIG1haW4gYm9keSB0byBq
dXN0IGRlZmluZSBtZXNzYWdlcy4gQ3VycmVudGx5IHRoZSBtZXNzYWdlcyBhcmUgc3RpbGwgdGV4
dCBiYXNlZC4gSXMgdGhlcmUgYW55IGNvbnNpZGVyYXRpb24gb24gdGhlIHNpdHVhdGlvbiB3aGVy
ZSBkaWZmZXJlbnQgZW5jb2RpbmdzIGFyZSB1c2VkPyBFLmcuLCBzb21lIHBlZXJzIHVzZSB0ZXh0
IGVuY29kaW5nIHdoaWxlIG90aGVycyB1c2UgYmluYXJ5Lg0KTGluZ2xpOiBUaGVyZSBpcyBkaWZm
ZXJlbnQgdW5kZXJzdGFuZGluZyBiZXR3ZWVuIFJ1aSBhbmQgdGhlIG90aGVyIGNvLWF1dGhvcnMu
IEJ5IGJpbmFyeSBlbmNvZGluZywgUnVpIHRoaW5rcyBpdKGvcyB0aGUgYmluYXJ5IGVuY29kaW5n
IG9mIHRoZSBYTUwsIHdoaWxlIG90aGVycyB0aGluayBpdKGvcyB0aGUgYmluYXJ5IGVuY29kaW5n
IG9mIHRoZSB0cmFja2VyIHByb3RvY29sLiBUaGVyZSBhcmUgc3RhbmRhcmRzIGZyb20gSVNPIGZv
ciBiaW5hcnkgZW5jb2Rpbmcgb2YgWE1MLCB3aGljaCBpcyBFWEkuDQpZdW5mZWk6IEJ1dCBFWEkg
Y2Fuoa90IGRvIHRoZSB0cmFuc2xhdGlvbiBiZXR3ZWVuIGJpbmFyeSBlbmNvZGluZyBvZiB0aGUg
bWVzc2FnZXMgdG8gWE1MIG9mIHRoZSBtZXNzYWdlcy4NCkxpbmdsaTogV2Vic29ja2V0IGhhcyBz
aW1pbGFyIG1lY2hhbmlzbXMgdG8gZG8gdGhpcyBraW5kIG9mIHRyYW5zbGF0aW9uLiBXZSBjYW4g
cmVmZXJlbmNlIGl0LiBJIGNhbiBoZWxwIHdpdGggdGhlIG5ldyB2ZXJzaW9uLg0KDQoNCg0KMTg6
MDUgRWZmaWNpZW50IENodW5rIEF2YWlsYWJpbGl0eSBDb21wcmVzc2lvbiAoTGluZ2xpLDIwIG1p
bnV0ZXMpLCBkcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAtMDMNCg0KQXJubzogaW4gcmVhbGl0eSwg
c3RyZWFtaW5nIGRvd25sb2FkaW5nIGhhcHBlbnMgc2VxdWVudGlhbGx5LCBoZW5jZSBzY29wZS1i
YXNlZCBzY2hlbWVzIHdvcmtzIHdlbGwuDQoNCkE6IGluIFZvRCBjYXNlcywgdXNlciBiZWhhdmlv
ciBjYW4gaW50ZXJydXB0IHRoZSBzZXF1ZW50aWFsIHZpZXdpbmcgcGF0dGVybi4gQW5kIGV2ZW4g
aW4gbGl2ZSBzdHJlYW1pbmcgY2FzZSwgYmVjYXVzZSB0aGUgY29uY3VycmVudGx5IHBlZXItdG8t
cGVlciBkb3dubG9hZGluZyBwYXR0ZXJuLCBvdXQtb2Ytb3JkZXIgY2h1bmsgdHJhbnNtaXNzaW9u
IGlzIGluZXZpdGFibGUuDQoNCkRhdmU6IHdoYXQgaXMgdGhlIG9iamVjdGl2ZSBvZiBpbnRyb2R1
Y2luZyBCRiBzY2hlbWU/DQoNCkE6IHRoZSBtb3RpdmUgaXMgZWxhYm9yYXRlZCBpbiB0aGUgbGFz
dCBtZWV0aW5noa9zIHByZXNlbnRhdGlvbi4gVGhlcmUgaXMgYW4gY29tcGFyaXNvbiBvZiB0aGUg
d29yc3QgY2FzZSBwZXJmb3JtYW5jZSBvZiBkaWZmZXJlbnQgYml0bWFwIGNvbXByZXNzaW9uIHNj
aGVtZXMgaW4gdGVybXMgb2YgdmFyaW91cyBiaXRtYXAgcmVsZXZhbnQgb3BlcmF0aW9ucyBpbiBQ
UFNQLg0KDQpBcm5vOiBpbiBwZWVyIHByb3RvY29sLCBwZWVycyBkb26hr3Qgc2hhcmUgYml0bWFw
cywgb25seSBjaHVuayByYW5nZXMgdXBkYXRlcyBhcmUgZXhjaGFuZ2VkLiBQZWVyIHByb3RvY29s
IGRvZXNuoa90IG5lZWQgYml0bWFwIGNvbXByZXNzaW9uLg0KDQpBOiByYW5nZXMgb3IgdXBkYXRl
cyBhcmUgc3BlY2lhbCBmb3JtcyBvZiBjb21wcmVzc2lvbi4gQkYgc2NoZW1lIGNhbiBiZSBpbnRy
b2R1Y2VkIGludG8gcGVlciBwcm90b2NvbCBhcyBhIG5ldyBjaHVuayBhZGRyZXNzaW5nIG1ldGhv
ZC4NCg0KDQoNCm9wZW4gaXNzdWUgMSCoQyBsb29rcyBsaWtlIHRoZSBwcm9wb3NlZCBvcHRpb24g
aXMgYmV0dGVyIG5vIG5lZWQgdG8gdHJhbnNsYXRpb24NCg0KT3BlbiBpc3N1ZSAyIKhDIGxvb2tz
IGxpa2UgaXQgaXMgaGVscGZ1bCB0byBpbmNsdWRlIGNvbnRlbnQgc2NvcGUgaW50byByZXF1ZXN0
cywgYnV0IG5vdCB0byB0aGUgcmVzcG9uc2VzLg0KDQpObyBhZG9wdGlvbiBhdCB0aGUgbW9tZW50
LiBOZWVkIG1vcmUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gYW5kIG9mZmxpbmUgd2l0aCB0aGUg
dHJhY2tlciBwcm90b2NvbCBhdXRob3IuDQoNCg0KDQpSYWNoZWw6IGluIGV4dGVuZGVkIHRyYWNr
ZXIgcHJvdG9jb2wsIHRoZSBjb250ZW50IHNjb3BlIGluZm9ybWF0aW9uIGlzIGFscmVhZHkgaW5j
b3Jwb3JhdGVkIGluIHRoZSByZXF1ZXN0cy4gQnV0IGlmIHdlIGluY29ycG9yYXRlIHRoZSBzYW1l
IGluZm9ybWF0aW9uIGludG8gdGhlIHJlc3BvbnNlcywgaXQgd291bGQgYmUgZHVwbGljYXRlZCB3
aXRoIHRoZSBzdWJzZXF1ZW50IHBlZXIgaW5mb3JtYXRpb24gaGFuZHNoYWtpbmcuDQoNCk5pbmc6
IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGluY3JlYXNlIG5laWdoYm9yaG9vZCBlc3RhYmxpc2ht
ZW50IGJ5IGFsd2F5cyBpbmNsdWRpbmcgU0VFREVSIHBlZXJzIGluIHJlc3BvbnNlPw0KDQpBOiBJ
IHRoaW5rIGl0IG1ha2Ugc2Vuc2UgdG8gZG8gc28gdG8gZW5zdXJlIEZJTkQgYWx3YXlzIGhpdCwg
YXMgbG9uZyBhcyB0aGUgc3BlY2lmaWMgY29udGVudCByYW5nZSBpbiBuZWVkIGlzIGluY29ycG9y
YXRlZCBpbiBjb3JyZXNwb25kaW5nIHJlcXVlc3RzLg0KDQoNCg0KMTg6MjUgQ29uY2x1c2lvbiBh
bmQgbmV4dCBzdGVwIChDaGFpcnMsIDEwIG1pbnV0ZXMpDQoNClBlZXIgZHJhZnQgbmVlZHMgbW9y
ZSByZXZpZXcuIFRyYWNrZXIgYmFzZSBkcmFmdCBuZWVkcyBjYWxsIGJldHdlZW4gY28tYXV0aG9y
cyB0byBwcm9ncmVzcyB0aGUgZHJhZnQgZmFzdGVyLiAybmQgV0dMQyBvbiBzdXJ2ZXkgZHJhZnQg
c3RhcnRzIHNvb24uDQoNCg0KDQoxODozNSBFbmQNCg0KPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClRoYW5rcywNCg0KLVl1bmZlaSAmIE5pbmcu
DQoNCg0KDQo=

--_000_B0D29E0424F2DE47A0B36779EC6667792585356Bnkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLChar
	{mso-style-name:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD";
	font-family:=CB=CE=CC=E5;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Hi, =
Folks,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Sorr=
y for the belated minutes and thanks Roni for taking the notes. Please see =
below and let us know any corrects needed.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">PPSP=
 Session@IETF 88&nbsp;</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">Plaza C,Tuesday Aftern=
oon Session III, Nov 5, 2013</span><span lang=3D"EN-US"><o:p></o:p></span><=
/pre>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:10 Agenda bashing (=
Chairs, 5 minutes)</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">No comments</span><spa=
n lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:15 Status of the WG=
 (Chairs, 10 minutes)</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">1)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt;color:#1F497D">Peer draft </span><span styl=
e=3D"font-size:13.5pt;color:#1F497D">=A8C <span lang=3D"EN-US">more review =
needed, especially on security and encoding perspectives.</span></span><spa=
n lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">2)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt;color:#1F497D">Tracker base draft </span><s=
pan style=3D"font-size:13.5pt;color:#1F497D">=A8C<span lang=3D"EN-US"> need=
 author team to progress the draft faster, more calls are needed.<o:p></o:p=
></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">3</span>=
<span style=3D"font-size:13.5pt;color:#1F497D">=A3=A9<span lang=3D"EN-US">S=
urvey draft </span>=A8C<span lang=3D"EN-US"> need 2<sup>nd</sup> WGLC befor=
e submitting to IESG.</span></span><span lang=3D"EN-US"><o:p></o:p></span><=
/pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=3D"E=
N-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:25 Peer Protocol (A=
rno remotely,50 minutes)</span><span lang=3D"EN-US">, </span><span lang=3D"=
EN-US" style=3D"font-size:13.5pt">draft-ietf-ppsp-peer-protocol-08</span><s=
pan lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">1)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt;color:#1F497D">New revision has addressed a=
ll comments from AD review.</span><span lang=3D"EN-US"><o:p></o:p></span></=
pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">2)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt">Some comments from Roni need to be address=
ed, e.g. if peer protocol need to define how to do NAT traversal<span style=
=3D"color:#1F497D">.</span> <span style=3D"color:#1F497D">T</span>o be disc=
ussed on the list<span style=3D"color:#1F497D">.</span></span><span lang=3D=
"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">3)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt;color:#1F497D">Chunk size issue from Yunfei=
?</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">4)</span><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-fami=
ly:&quot;Times New Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:13.5pt">Chunk addressing iss=
ue </span>
<span style=3D"font-size:13.5pt">=A8C<span lang=3D"EN-US"> negotiation is b=
etter. <o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">Lingli: in the latest version, the part for online translation be=
tween communicating peers using different chunk addressing schemes are remo=
ved. Why?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">A: It is too complicated and not necessary.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">17:15 Tracker Protocol=
 (Rui remotely, 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02&nbsp;=
 </span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">1)</span=
><span lang=3D"EN-US" style=3D"font-size:13.5pt;font-family:&quot;Times New=
 Roman&quot;,&quot;serif&quot;;color:#1F497D">&nbsp; </span><span lang=3D"E=
N-US" style=3D"font-size:13.5pt;color:#1F497D">In the draft, still XML form=
at in main body. Need to move XML example to appendix with more references.=
</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">Yunfei: The new version doesn</span><span style=3D"font-size:13.5=
pt;color:#1F497D">=A1=AF<span lang=3D"EN-US">t reflect the consensus made i=
n the last meeting, which is to move the encoding
 issues to the appendix while keep the main body to just define messages. C=
urrently the messages are still text based. Is there any consideration on t=
he situation where different encodings are used? E.g., some peers use text =
encoding while others use binary.<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">Lingli: There is different understanding between Rui and the othe=
r co-authors. By binary encoding, Rui thinks it</span><span style=3D"font-s=
ize:13.5pt;color:#1F497D">=A1=AF<span lang=3D"EN-US">s
 the binary encoding of the XML, while others think it</span>=A1=AF<span la=
ng=3D"EN-US">s the binary encoding of the tracker protocol. There are stand=
ards from ISO for binary encoding of XML, which is EXI.<o:p></o:p></span></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">Yunfei: But EXI can</span><span style=3D"font-size:13.5pt;color:#=
1F497D">=A1=AF<span lang=3D"EN-US">t do the translation between binary enco=
ding of the messages to XML of the messages.<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color=
:#1F497D">Lingli: Websocket has similar mechanisms to do this kind of trans=
lation. We can reference it. I can help with the new version.<o:p></o:p></s=
pan></p>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:05 Efficient Chunk =
Availability Compression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03</=
span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Arno: in=
 reality, streaming downloading happens sequentially, hence scope-based sch=
emes works well.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">A: in Vo=
D cases, user behavior can interrupt the sequential viewing pattern. And ev=
en in live streaming case, because the concurrently peer-to-peer downloadin=
g pattern, out-of-order chunk transmission is inevitable.<o:p></o:p></span>=
</pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Dave: wh=
at is the objective of introducing BF scheme?<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">A: the m=
otive is elaborated in the last meeting</span><span style=3D"font-size:13.5=
pt;color:#1F497D">=A1=AF<span lang=3D"EN-US">s presentation. There is an co=
mparison of the worst case performance of different bitmap compression sche=
mes in terms of various bitmap relevant operations in PPSP.<o:p></o:p></spa=
n></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Arno: in=
 peer protocol, peers don</span><span style=3D"font-size:13.5pt;color:#1F49=
7D">=A1=AF<span lang=3D"EN-US">t share bitmaps, only chunk ranges updates a=
re exchanged. Peer protocol doesn</span>=A1=AF<span lang=3D"EN-US">t need b=
itmap compression.<o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">A: range=
s or updates are special forms of compression. BF scheme can be introduced =
into peer protocol as a new chunk addressing method.<o:p></o:p></span></pre=
>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt"><o:p>&nbsp;</o:p></spa=
n></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">open issue 1 </span><s=
pan style=3D"font-size:13.5pt">=A8C<span lang=3D"EN-US"> looks like the pro=
posed option is better no need to translation</span></span><span lang=3D"EN=
-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Open iss=
ue 2 </span><span style=3D"font-size:13.5pt;color:#1F497D">=A8C<span lang=
=3D"EN-US"> looks like it is helpful to include content scope into requests=
, but not to the responses.<o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">No adoption at the mom=
ent. Need more mailing list discussion and offline with the tracker protoco=
l author.</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt"><o:p>&nbsp;</o:p></spa=
n></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Rachel: =
in extended tracker protocol, the content scope information is already inco=
rporated in the requests. But if we incorporate the same information into t=
he responses, it would be duplicated with the subsequent peer information h=
andshaking.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Ning: Wo=
uld it be possible to increase neighborhood establishment by always includi=
ng SEEDER peers in response?<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">A: I thi=
nk it make sense to do so to ensure FIND always hit, as long as the specifi=
c content range in need is incorporated in corresponding requests.<o:p></o:=
p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D"><o:p>&nb=
sp;</o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:25 Conclusion and n=
ext step (Chairs, 10 minutes)<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Peer dra=
ft needs more review.</span><span lang=3D"EN-US" style=3D"font-size:13.5pt;=
font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:#1F497D"> <=
/span><span lang=3D"EN-US" style=3D"font-size:13.5pt;color:#1F497D">Tracker=
 base draft needs call between co-authors to progress the draft faster. 2<s=
up>nd</sup> WGLC on survey draft starts soon.</span><span lang=3D"EN-US"><o=
:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:35 End<o:p></o:p></=
span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><span lang=
=3D"EN-US"><o:p></o:p></span></pre>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Than=
ks,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">-Yun=
fei &amp; Ning.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span>=
</p>
</div>
</body>
</html>

--_000_B0D29E0424F2DE47A0B36779EC6667792585356Bnkgeml501mbschi_--

From denglingli@chinamobile.com  Mon Nov 25 22:35:58 2013
Return-Path: <denglingli@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532581AE018 for <ppsp@ietfa.amsl.com>; Mon, 25 Nov 2013 22:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjFuVx1vPWmk for <ppsp@ietfa.amsl.com>; Mon, 25 Nov 2013 22:35:55 -0800 (PST)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 1F1C21AC3FA for <ppsp@ietf.org>; Mon, 25 Nov 2013 22:35:54 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2529440de781-f4781; Tue, 26 Nov 2013 14:34:07 +0800 (CST)
X-RM-TRANSID: 2ee2529440de781-f4781
Received: from cmccPC (unknown[117.134.5.61]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3529440dd4da-20cf4; Tue, 26 Nov 2013 14:34:06 +0800 (CST)
X-RM-TRANSID: 2ee3529440dd4da-20cf4
From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= <denglingli@chinamobile.com>
To: "'ppsp'" <ppsp@ietf.org>
References: <046501ced9be$d5fb1a60$81f14f20$@com>
In-Reply-To: <046501ced9be$d5fb1a60$81f14f20$@com>
Date: Tue, 26 Nov 2013 14:35:46 +0800
Message-ID: <007401ceea71$bf754220$3e5fc660$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Zvd4vKC0YBL0rTECah8T9+JzF9wAAElBQBCwqP6A=
Content-Language: zh-cn
Subject: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 Nov 2013 06:35:58 -0000

Hi all,

As requested in the Vancouver meeting, we are planning to elaborate the =
previous performance analysis for bitmap compression schemes in the =
following way.
Plz let me know if you have any comments or suggestion with this =
analysis setting.

1, we consider the following existing proposals for chunk availability =
information in this analysis
	a) Original bitmap Scheme uses a bit-array to represent the chunk set, =
and mark those bits corresponding to the locally available chunks.
	b) Chunk range scheme uses a array of starting+ending chunk index pairs =
to represent continuous intervals.=20
	c) Byte range scheme uses an array of starting+ending byte index pairs =
to represent continuous intervals.=20
	d) Bin number scheme uses a universally assigned bin number (integer) =
for any given continuous interval. =20
2, for simplicity, we assume that No hybrid is deployed. In other words, =
a single scheme is used for both storage and transmission.
3, Tracker/Peer operations on chunk availability information, which are =
to be considered include:=20
	a) Formation, to translate a specific set of available chunks of a =
given swarm into a compact form of representation.
		In this case, Representation storage overhead wrt. the number of all =
chunks n and available chunks k, is considered.
	b) Transmission, to transmit a specific representation of currently =
available chunks of a given swarm to another neighboring peer.
		In this case, Representation transmission overhead wrt. n and k, is =
considered.
	c) Update, to update a specific representation of currently available =
chunks of a given swarm as result of a given (group) of newly downloaded =
and verified chunk(s).
		A special type of update operation, Partial update, where the sender =
only transfer the relevant part of available chunks and requires a merge =
operation at the receiver=E2=80=99s side, is considered separately.
		For updates, Update computation overhead wrt. n, k and the number of =
new chunks p, is considered.
		In addition, Delta transmission overhead wrt. n, k and the number of =
new chunks d, is also considered.
	d) Inquiry, to check whether a specific representation of available =
chunks of a given swarm contains a given (group) of requesting chunk(s).
		In this case, Inquiry computation overhead wrt. n, k and the number of =
requesting chunks g, is considered.

BR
Lingli

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: ppsp-bounces@ietf.org =
[mailto:ppsp-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 =
=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B411=E6=9C=885=E6=97=A5 =
8:35
=E6=94=B6=E4=BB=B6=E4=BA=BA: 'ppsp'
=E4=B8=BB=E9=A2=98: [ppsp] =E8=BD=AC=E5=8F=91: New Version Notification =
for draft-deng-ppsp-bfbitmap-04.txt

Hi forks,

We are happy to announce the latest version of BFbitmap draft.
In this version, we discussed open issues for accommodating several =
chunk addressing schemes in general as well as how to integrate the BF =
scheme with PPSP protocols.
Your comments and suggestions would be highly appreciated.

BR
Lingli

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org =
[mailto:internet-drafts@ietf.org]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B411=E6=9C=885=E6=97=A5 =
8:29
=E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Yunfei Zhang; Yihong Huang; =
Jin Peng; Lingli Deng; Rachel Huang
=E4=B8=BB=E9=A2=98: New Version Notification for =
draft-deng-ppsp-bfbitmap-04.txt


A new version of I-D, draft-deng-ppsp-bfbitmap-04.txt
has been successfully submitted by Lingli Deng and posted to the
IETF repository.

Filename:	 draft-deng-ppsp-bfbitmap
Revision:	 04
Title:		 Efficient Chunk Availability Compression for PPSP
Creation date:	 2013-11-05
Group:		 Individual Submission
Number of pages: 13
URL:             =
http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-04.txt
Status:          =
http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap
Htmlized:        http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-04
Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfbitmap-04

Abstract:
   Bloom filters are proposed to be used in compressing chunk
   availability information, periodically exchanged between peers and
   the tracker through PPSP-TP and PPSPP protocols, to reduce relevant
   cost and enhance scalability.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of =
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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




From peer2peer@gmail.com  Tue Nov 26 01:16:46 2013
Return-Path: <peer2peer@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E291A1F00 for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 01:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.089
X-Spam-Level: *
X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usplkSZHsIBd for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 01:16:44 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E0A7F1AC863 for <ppsp@ietf.org>; Tue, 26 Nov 2013 01:16:43 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id u56so4954658wes.39 for <ppsp@ietf.org>; Tue, 26 Nov 2013 01:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vVYSUCA6ah1WBUCI8xGg9rzZluVJd7kvVTY1wYmd5+w=; b=JQiOsTtswGo5HPtnMrvGqBEzSe9Su4IqgSFIPVa/kdHLKeMPKhyy3rZHivpa5rAzKH SQZMsT52u875PD1YvabNDJ2aUqMCUBl/laZqhaUm0IVrv0LBsCnLVm1AuTQi5weZ/eec r7lQwxn/wvvPVFr9mr2sV0jXHNmuQ8pvrQnrzcVruYMHxXF7gLPKW9qAik6vjh8kEs7H Jdh5yS95GQbj1Dnlaw6xUyfuI4BPmu4jZpUUKckw9yNzm5Ev4kiduQFvAuuQDDK9WFU6 7KprNSu9w/kAa6X9SGLzvOOaYc7Hj5yDW51Mj5K+hYyrYOjfRYnQ3ttxt7usWOmwQ/qZ 5rvA==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr17367626wib.59.1385457403132; Tue, 26 Nov 2013 01:16:43 -0800 (PST)
Received: by 10.216.34.65 with HTTP; Tue, 26 Nov 2013 01:16:43 -0800 (PST)
In-Reply-To: <007401ceea71$bf754220$3e5fc660$@com>
References: <046501ced9be$d5fb1a60$81f14f20$@com> <007401ceea71$bf754220$3e5fc660$@com>
Date: Tue, 26 Nov 2013 10:16:43 +0100
Message-ID: <CAJYQ-fSF=SRHh=7FfMZ1JYfSys3enk9_0CuZvS0h_CYbYUm75Q@mail.gmail.com>
From: Johan Pouwelse <peer2peer@gmail.com>
To: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= <denglingli@chinamobile.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: ppsp <ppsp@ietf.org>
Subject: Re: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 Nov 2013 09:16:46 -0000

Dear Lingli Deng,
Please find a review of your I-D below. Apologies for the critical
nature of my remarks.

After reading of this proposal it was still unclear what problem is
being addressed and why it's needed.

Using Bloom filters adds a lot of complexity, while at this stage PPSP
needs I believe: simplicity, running code and additional real-world
trials.
PPSP has a unique and efficient datastructure of representing
availability of video chunks using "binmaps". Using one number to
compress both pieces and intervals is not easy to improve.  For the
given example of 2GByte, a binmap indicating the availability of the
whole file or an ongoing live stream is less than a KByte. Even in an
UltraHD scenario with bitrates of 42Mbps it should scale. Obviously
normal bitmaps get in trouble then, but not binmaps.

The I-D states "frequent exchange of large volume of bitmap
information, is among the key factors that set a limit to the system's
efficiency and scalability [P2P-limit]".
This cited INFOCOM paper does not support the claims made. It merely
states that the period T of periodic buffer map exchanges should not
be too short, then it will impact performance.


Prof. Johan Pouwelse
Delft University of Technology


----composed-on-my-mobile----

On Nov 26, 2013 7:36 AM, "=B5=CB=C1=E9=C0=F2/Lingli Deng" <denglingli@china=
mobile.com> wrote:
>
> Hi all,
>
> As requested in the Vancouver meeting, we are planning to elaborate the p=
revious performance analysis for bitmap compression schemes in the followin=
g way.
> Plz let me know if you have any comments or suggestion with this analysis=
 setting.
>
> 1, we consider the following existing proposals for chunk availability in=
formation in this analysis
>         a) Original bitmap Scheme uses a bit-array to represent the chunk=
 set, and mark those bits corresponding to the locally available chunks.
>         b) Chunk range scheme uses a array of starting+ending chunk index=
 pairs to represent continuous intervals.
>         c) Byte range scheme uses an array of starting+ending byte index =
pairs to represent continuous intervals.
>         d) Bin number scheme uses a universally assigned bin number (inte=
ger) for any given continuous interval.
> 2, for simplicity, we assume that No hybrid is deployed. In other words, =
a single scheme is used for both storage and transmission.
> 3, Tracker/Peer operations on chunk availability information, which are t=
o be considered include:
>         a) Formation, to translate a specific set of available chunks of =
a given swarm into a compact form of representation.
>                 In this case, Representation storage overhead wrt. the nu=
mber of all chunks n and available chunks k, is considered.
>         b) Transmission, to transmit a specific representation of current=
ly available chunks of a given swarm to another neighboring peer.
>                 In this case, Representation transmission overhead wrt. n=
 and k, is considered.
>         c) Update, to update a specific representation of currently avail=
able chunks of a given swarm as result of a given (group) of newly download=
ed and verified chunk(s).
>                 A special type of update operation, Partial update, where=
 the sender only transfer the relevant part of available chunks and require=
s a merge operation at the receiver=A1=AFs side, is considered separately.
>                 For updates, Update computation overhead wrt. n, k and th=
e number of new chunks p, is considered.
>                 In addition, Delta transmission overhead wrt. n, k and th=
e number of new chunks d, is also considered.
>         d) Inquiry, to check whether a specific representation of availab=
le chunks of a given swarm contains a given (group) of requesting chunk(s).
>                 In this case, Inquiry computation overhead wrt. n, k and =
the number of requesting chunks g, is considered.
>
> BR
> Lingli
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =
=B4=FA=B1=ED =B5=CB=C1=E9=C0=F2/Lingli Deng
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C25=C8=D5 8:35
> =CA=D5=BC=FE=C8=CB: 'ppsp'
> =D6=F7=CC=E2: [ppsp] =D7=AA=B7=A2: New Version Notification for draft-den=
g-ppsp-bfbitmap-04.txt
>
> Hi forks,
>
> We are happy to announce the latest version of BFbitmap draft.
> In this version, we discussed open issues for accommodating several chunk=
 addressing schemes in general as well as how to integrate the BF scheme wi=
th PPSP protocols.
> Your comments and suggestions would be highly appreciated.
>
> BR
> Lingli
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf=
.org]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C25=C8=D5 8:29
> =CA=D5=BC=FE=C8=CB: Deng Lingli; Yunfei Zhang; Yihong Huang; Jin Peng; Li=
ngli Deng; Rachel Huang
> =D6=F7=CC=E2: New Version Notification for draft-deng-ppsp-bfbitmap-04.tx=
t
>
>
> A new version of I-D, draft-deng-ppsp-bfbitmap-04.txt
> has been successfully submitted by Lingli Deng and posted to the
> IETF repository.
>
> Filename:        draft-deng-ppsp-bfbitmap
> Revision:        04
> Title:           Efficient Chunk Availability Compression for PPSP
> Creation date:   2013-11-05
> Group:           Individual Submission
> Number of pages: 13
> URL:             http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbi=
tmap-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap
> Htmlized:        http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-04
> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfbit=
map-04
>
> Abstract:
>    Bloom filters are proposed to be used in compressing chunk
>    availability information, periodically exchanged between peers and
>    the tracker through PPSP-TP and PPSPP protocols, to reduce relevant
>    cost and enhance scalability.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> ppsp mailing list
> ppsp@ietf.org
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
>
> _______________________________________________
> ppsp mailing list
> ppsp@ietf.org
> https://www.ietf.org/mailman/listinfo/ppsp

From hishigh@gmail.com  Tue Nov 26 05:04:34 2013
Return-Path: <hishigh@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC2C1AE1DA for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 05:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEH6_h3IuACB for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 05:04:31 -0800 (PST)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 57E191AE1D4 for <ppsp@ietf.org>; Tue, 26 Nov 2013 05:04:31 -0800 (PST)
Received: by mail-oa0-f50.google.com with SMTP id n16so5930006oag.37 for <ppsp@ietf.org>; Tue, 26 Nov 2013 05:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wSVKQ4YyoDh52gR4PHGqxN3I/CyW++qdWX6ClX8QaEI=; b=ytuboBFXW7oh2axMsN7wOelpIlGQQw555T/bbUqQLrJac8oCMLQyoPrkkfRqZcu9GR M511DBN5Nw6l9FOtfScgzPXng96hDHp3WkiCItJU2MtZH6cCAk0HY8mKkKkuEpgjWi9t zWNeLVvYfflctn9YBoXtzfkCBSpCS/6drqbDMfdjD/BTIjQziymepZb+SPHH2wUhuxhf mwHumjgpwOSXxSKI5g5/AZDw0YrQb2mzqhB0bs6hTlSXrIpX/DNjOHQe999WexmWgWZ1 MZg+f6SlPWxzyOfAIdL31eMWp1QxAixUpiWKxMAavmwzCWhBcxQUtpdlQM4Pqg6Y6gu/ MrYQ==
MIME-Version: 1.0
X-Received: by 10.60.117.225 with SMTP id kh1mr29214767oeb.15.1385471071084; Tue, 26 Nov 2013 05:04:31 -0800 (PST)
Received: by 10.76.98.43 with HTTP; Tue, 26 Nov 2013 05:04:30 -0800 (PST)
Date: Tue, 26 Nov 2013 21:04:30 +0800
Message-ID: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
From: yunfei zhang <hishigh@gmail.com>
To: "ppsp@ietf.org" <ppsp@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b3a9a7c09e5f104ec141f07
Subject: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 Nov 2013 13:04:34 -0000

--047d7b3a9a7c09e5f104ec141f07
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi all,
    According to the consensus of last IETF, we'll start a second round of
WGLC for the survey draft:
http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/
    The WGLC will last for 2 weeks before submitting for next step of
standardization.
     Your review are highly appreciated. Please note that your comments and
suggestions are very important for the forming of the RFC as well as the
development of the WG. Thanks.

BR
Yunfei
---------- Forwarded message ----------
From: Zongning <zongning@huawei.com>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "ppsp@ietf.org" <ppsp@ietf.org>

Hi, Folks,



Sorry for the belated minutes and thanks Roni for taking the notes. Please
see below and let us know any corrects needed.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

PPSP Session@IETF 88

Plaza C,Tuesday Afternoon Session III, Nov 5, 2013



16:10 Agenda bashing (Chairs, 5 minutes)

No comments



16:15 Status of the WG (Chairs, 10 minutes)

1)  Peer draft =A8C more review needed, especially on security and
encoding perspectives.

2)  Tracker base draft =A8C need author team to progress the draft
faster, more calls are needed.

3=A3=A9Survey draft =A8C need 2nd WGLC before submitting to IESG.



16:25 Peer Protocol (Arno remotely,50 minutes), draft-ietf-ppsp-peer-protoc=
ol-08

1)  New revision has addressed all comments from AD review.

2)  Some comments from Roni need to be addressed, e.g. if peer
protocol need to define how to do NAT traversal. To be discussed on
the list.

3)  Chunk size issue from Yunfei?

4)  Chunk addressing issue =A8C negotiation is better.

Lingli: in the latest version, the part for online translation between
communicating peers using different chunk addressing schemes are removed.
Why?

A: It is too complicated and not necessary.



17:15 Tracker Protocol (Rui remotely, 50 minutes),
draft-ietf-ppsp-base-tracker-protocol-02

1)  In the draft, still XML format in main body. Need to move XML
example to appendix with more references.

Yunfei: The new version doesn=A1=AFt reflect the consensus made in the last
meeting, which is to move the encoding issues to the appendix while keep
the main body to just define messages. Currently the messages are still
text based. Is there any consideration on the situation where different
encodings are used? E.g., some peers use text encoding while others use
binary.

Lingli: There is different understanding between Rui and the other
co-authors. By binary encoding, Rui thinks it=A1=AFs the binary encoding of=
 the
XML, while others think it=A1=AFs the binary encoding of the tracker protoc=
ol.
There are standards from ISO for binary encoding of XML, which is EXI.

Yunfei: But EXI can=A1=AFt do the translation between binary encoding of th=
e
messages to XML of the messages.

Lingli: Websocket has similar mechanisms to do this kind of translation. We
can reference it. I can help with the new version.



18:05 Efficient Chunk Availability Compression (Lingli,20 minutes),
draft-deng-ppsp-bfbitmap-03

Arno: in reality, streaming downloading happens sequentially, hence
scope-based schemes works well.

A: in VoD cases, user behavior can interrupt the sequential viewing
pattern. And even in live streaming case, because the concurrently
peer-to-peer downloading pattern, out-of-order chunk transmission is
inevitable.

Dave: what is the objective of introducing BF scheme?

A: the motive is elaborated in the last meeting=A1=AFs presentation. There
is an comparison of the worst case performance of different bitmap
compression schemes in terms of various bitmap relevant operations in
PPSP.

Arno: in peer protocol, peers don=A1=AFt share bitmaps, only chunk ranges
updates are exchanged. Peer protocol doesn=A1=AFt need bitmap compression.

A: ranges or updates are special forms of compression. BF scheme can
be introduced into peer protocol as a new chunk addressing method.



open issue 1 =A8C looks like the proposed option is better no need to trans=
lation

Open issue 2 =A8C looks like it is helpful to include content scope into
requests, but not to the responses.

No adoption at the moment. Need more mailing list discussion and
offline with the tracker protocol author.



Rachel: in extended tracker protocol, the content scope information is
already incorporated in the requests. But if we incorporate the same
information into the responses, it would be duplicated with the
subsequent peer information handshaking.

Ning: Would it be possible to increase neighborhood establishment by
always including SEEDER peers in response?

A: I think it make sense to do so to ensure FIND always hit, as long
as the specific content range in need is incorporated in corresponding
requests.



18:25 Conclusion and next step (Chairs, 10 minutes)

Peer draft needs more review. Tracker base draft needs call between
co-authors to progress the draft faster. 2nd WGLC on survey draft
starts soon.



18:35 End

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D



Thanks,



-Yunfei & Ning.







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

--047d7b3a9a7c09e5f104ec141f07
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br>Hi all,</div><div>&nbsp;&nbsp;&nbsp; According to=
 the&nbsp;consensus of last IETF, we&#39;ll start a second round of WGLC fo=
r the survey draft:</div><div><a href=3D"http://datatracker.ietf.org/doc/dr=
aft-ietf-ppsp-survey/">http://datatracker.ietf.org/doc/draft-ietf-ppsp-surv=
ey/</a></div>
<div>&nbsp;&nbsp;&nbsp; The WGLC will last for 2 weeks before submitting fo=
r next step of standardization.</div><div>&nbsp;&nbsp;&nbsp;&nbsp; Your rev=
iew&nbsp;are highly appreciated. Please note that your comments and suggest=
ions are very important for the forming of the RFC as well as the developme=
nt of the WG. Thanks.</div>
<div>&nbsp;</div><div>BR<br>Yunfei</div><div class=3D"gmail_quote">--------=
-- Forwarded message ----------<br>From: <b class=3D"gmail_sendername">Zong=
ning</b> <span dir=3D"ltr">&lt;<a href=3D"mailto:zongning@huawei.com">zongn=
ing@huawei.com</a>&gt;</span><br>
Date: 2013/11/25<br>Subject: [ppsp] Meeting minutes<br>To: &quot;<a href=3D=
"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&quot; &lt;<a href=3D"mailto:ppsp@i=
etf.org">ppsp@ietf.org</a>&gt;<br>





<div lang=3D"ZH-CN" vlink=3D"purple" link=3D"blue">
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Hi, =
Folks,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><u><=
/u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Sorr=
y for the belated minutes and thanks Roni for taking the notes. Please see =
below and let us know any corrects needed.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><u><=
/u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">PPSP=
 Session@IETF 88&nbsp;</span><span lang=3D"EN-US"><u></u><u></u></span></p>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">Plaza C,Tuesday Aftern=
oon Session III, Nov 5, 2013</span><span lang=3D"EN-US"><u></u><u></u></spa=
n></pre>
<pre><span lang=3D"EN-US"><u></u>&nbsp;<u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:10 Agenda bashing (=
Chairs, 5 minutes)</span><span lang=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">No comments</span><spa=
n lang=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US"><u></u>&nbsp;<u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:15 Status of the WG=
 (Chairs, 10 minutes)</span><span lang=3D"EN-US"><u></u><u></u></span></pre=
>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">1=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">Peer dr=
aft </span><span style=3D"color:rgb(31,73,125);font-size:13.5pt">&ndash; <s=
pan lang=3D"EN-US">more review needed, especially on security and encoding =
perspectives.</span></span><span lang=3D"EN-US"><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">2=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">Tracker=
 base draft </span><span style=3D"color:rgb(31,73,125);font-size:13.5pt">&n=
dash;<span lang=3D"EN-US"> need author team to progress the draft faster, m=
ore calls are needed.<u></u><u></u></span></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">3=
</span><span style=3D"color:rgb(31,73,125);font-size:13.5pt">=A3=A9<span la=
ng=3D"EN-US">Survey draft </span>&ndash;<span lang=3D"EN-US"> need 2<sup>nd=
</sup> WGLC before submitting to IESG.</span></span><span lang=3D"EN-US"><u=
></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;font-size:13.5pt">&nbsp;</span><span la=
ng=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">16:25 Peer Protocol (A=
rno remotely,50 minutes)</span><span lang=3D"EN-US">, </span><span lang=3D"=
EN-US" style=3D"font-size:13.5pt">draft-ietf-ppsp-peer-protocol-08</span><s=
pan lang=3D"EN-US"><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">1=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">New rev=
ision has addressed all comments from AD review.</span><span lang=3D"EN-US"=
><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">2=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"font-size:13.5pt">Some comments from Roni need=
 to be addressed, e.g. if peer protocol need to define how to do NAT traver=
sal<span style=3D"color:rgb(31,73,125)">.</span> <span style=3D"color:rgb(3=
1,73,125)">T</span>o be discussed on the list<span style=3D"color:rgb(31,73=
,125)">.</span></span><span lang=3D"EN-US"><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">3=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">Chunk s=
ize issue from Yunfei?</span><span lang=3D"EN-US"><u></u><u></u></span></pr=
e>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">4)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125=
);font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5p=
t">&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:13.5pt">Chunk addressing iss=
ue </span>
<span style=3D"font-size:13.5pt">&ndash;<span lang=3D"EN-US"> negotiation i=
s better. <u></u><u></u></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">Lingli: in the latest version, the part for online transla=
tion between communicating peers using different chunk addressing schemes a=
re removed. Why?<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">A: It is too complicated and not necessary.<u></u><u></u><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;font-size:10.5pt"><u>=
</u>&nbsp;<u></u></span></p>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">17:15 Tracker Protocol=
 (Rui remotely, 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02&nbsp;=
 </span><span lang=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">1=
)</span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-family:&quo=
t;Times New Roman&quot;,&quot;serif&quot;;font-size:13.5pt">&nbsp; </span><=
span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">In the =
draft, still XML format in main body. Need to move XML example to appendix =
with more references.</span><span lang=3D"EN-US"><u></u><u></u></span></pre=
>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">Yunfei: The new version doesn</span><span style=3D"color:r=
gb(31,73,125);font-size:13.5pt">&rsquo;<span lang=3D"EN-US">t reflect the c=
onsensus made in the last meeting, which is to move the encoding
 issues to the appendix while keep the main body to just define messages. C=
urrently the messages are still text based. Is there any consideration on t=
he situation where different encodings are used? E.g., some peers use text =
encoding while others use binary.<u></u><u></u></span></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">Lingli: There is different understanding between Rui and t=
he other co-authors. By binary encoding, Rui thinks it</span><span style=3D=
"color:rgb(31,73,125);font-size:13.5pt">&rsquo;<span lang=3D"EN-US">s
 the binary encoding of the XML, while others think it</span>&rsquo;<span l=
ang=3D"EN-US">s the binary encoding of the tracker protocol. There are stan=
dards from ISO for binary encoding of XML, which is EXI.<u></u><u></u></spa=
n></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">Yunfei: But EXI can</span><span style=3D"color:rgb(31,73,1=
25);font-size:13.5pt">&rsquo;<span lang=3D"EN-US">t do the translation betw=
een binary encoding of the messages to XML of the messages.<u></u><u></u></=
span></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);f=
ont-size:13.5pt">Lingli: Websocket has similar mechanisms to do this kind o=
f translation. We can reference it. I can help with the new version.<u></u>=
<u></u></span></p>

<pre><span lang=3D"EN-US"><u></u>&nbsp;<u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:05 Efficient Chunk =
Availability Compression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03</=
span><span lang=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
rno: in reality, streaming downloading happens sequentially, hence scope-ba=
sed schemes works well.<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
: in VoD cases, user behavior can interrupt the sequential viewing pattern.=
 And even in live streaming case, because the concurrently peer-to-peer dow=
nloading pattern, out-of-order chunk transmission is inevitable.<u></u><u><=
/u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">D=
ave: what is the objective of introducing BF scheme?<u></u><u></u></span></=
pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
: the motive is elaborated in the last meeting</span><span style=3D"color:r=
gb(31,73,125);font-size:13.5pt">&rsquo;<span lang=3D"EN-US">s presentation.=
 There is an comparison of the worst case performance of different bitmap c=
ompression schemes in terms of various bitmap relevant operations in PPSP.<=
u></u><u></u></span></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
rno: in peer protocol, peers don</span><span style=3D"color:rgb(31,73,125);=
font-size:13.5pt">&rsquo;<span lang=3D"EN-US">t share bitmaps, only chunk r=
anges updates are exchanged. Peer protocol doesn</span>&rsquo;<span lang=3D=
"EN-US">t need bitmap compression.<u></u><u></u></span></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
: ranges or updates are special forms of compression. BF scheme can be intr=
oduced into peer protocol as a new chunk addressing method.<u></u><u></u></=
span></pre>

<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt"><u></u>&nbsp;<u></u></=
span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">open issue 1 </span><s=
pan style=3D"font-size:13.5pt">&ndash;<span lang=3D"EN-US"> looks like the =
proposed option is better no need to translation</span></span><span lang=3D=
"EN-US"><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">O=
pen issue 2 </span><span style=3D"color:rgb(31,73,125);font-size:13.5pt">&n=
dash;<span lang=3D"EN-US"> looks like it is helpful to include content scop=
e into requests, but not to the responses.<u></u><u></u></span></span></pre=
>

<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">No adoption at the mom=
ent. Need more mailing list discussion and offline with the tracker protoco=
l author.</span><span lang=3D"EN-US"><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt"><u></u>&nbsp;<u></u></=
span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">R=
achel: in extended tracker protocol, the content scope information is alrea=
dy incorporated in the requests. But if we incorporate the same information=
 into the responses, it would be duplicated with the subsequent peer inform=
ation handshaking.<u></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">N=
ing: Would it be possible to increase neighborhood establishment by always =
including SEEDER peers in response?<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">A=
: I think it make sense to do so to ensure FIND always hit, as long as the =
specific content range in need is incorporated in corresponding requests.<u=
></u><u></u></span></pre>

<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt"><=
u></u>&nbsp;<u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:25 Conclusion and n=
ext step (Chairs, 10 minutes)<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font-size:13.5pt">P=
eer draft needs more review.</span><span lang=3D"EN-US" style=3D"color:rgb(=
31,73,125);font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;font-s=
ize:13.5pt"> </span><span lang=3D"EN-US" style=3D"color:rgb(31,73,125);font=
-size:13.5pt">Tracker base draft needs call between co-authors to progress =
the draft faster. 2<sup>nd</sup> WGLC on survey draft starts soon.</span><s=
pan lang=3D"EN-US"><u></u><u></u></span></pre>

<pre><span lang=3D"EN-US"><u></u>&nbsp;<u></u></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">18:35 End<u></u><u></u=
></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><span lang=
=3D"EN-US"><u></u><u></u></span></pre>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;font-size:10.5pt"><u></u>&nbsp;<u></u></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">Than=
ks,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt"><u><=
/u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt">-Yun=
fei &amp; Ning.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;font-size:10.5pt"><u></u>&nbsp;<u></u></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;font-size:10.5pt"><u></u>&nbsp;<u></u></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;font-size:10.5pt"><u></u>&nbsp;<u></u></sp=
an></p>
</div>
</div>

<br>_______________________________________________<br>
ppsp mailing list<br>
<a href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ppsp" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/ppsp</a><br>
<br></div><br></div>

--047d7b3a9a7c09e5f104ec141f07--

From a.bakker@vu.nl  Tue Nov 26 23:34:27 2013
Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA001AE23A for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 23:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level: 
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R2O1PMWq85C for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 23:34:24 -0800 (PST)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id B82101AE22C for <ppsp@ietf.org>; Tue, 26 Nov 2013 23:34:23 -0800 (PST)
Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 08:34:18 +0100
Received: from [192.168.0.102] (130.37.253.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 08:34:21 +0100
Message-ID: <5295A08D.2040603@cs.vu.nl>
Date: Wed, 27 Nov 2013 08:34:37 +0100
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: <ppsp@ietf.org>
References: <046501ced9be$d5fb1a60$81f14f20$@com> <007401ceea71$bf754220$3e5fc660$@com>
In-Reply-To: <007401ceea71$bf754220$3e5fc660$@com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [130.37.253.20]
Subject: Re: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: arno@cs.vu.nl
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, 27 Nov 2013 07:34:27 -0000

Hi all

IMHO, a comparison cannot be done until the all the methods to be
evaluated are clear. It is not clear how the fact that Bloomfilters
are lossy is handled to ensure that peers do not stall on false
negatives, as raised in my previous mail. The lossy property of
Bloomfilters also implies they cannot be used for storage, otherwise
you may continuously download a chunk because the Bloomfilter cannot
properly record that you already have it.

Regards,
   Arno


On 26/11/2013 07:35, 邓灵莉/Lingli Deng wrote:
> Hi all,
> 
> As requested in the Vancouver meeting, we are planning to elaborate the previous performance analysis for bitmap compression schemes in the following way.
> Plz let me know if you have any comments or suggestion with this analysis setting.
> 
> 1, we consider the following existing proposals for chunk availability information in this analysis
> 	a) Original bitmap Scheme uses a bit-array to represent the chunk set, and mark those bits corresponding to the locally available chunks.
> 	b) Chunk range scheme uses a array of starting+ending chunk index pairs to represent continuous intervals. 
> 	c) Byte range scheme uses an array of starting+ending byte index pairs to represent continuous intervals. 
> 	d) Bin number scheme uses a universally assigned bin number (integer) for any given continuous interval.  
> 2, for simplicity, we assume that No hybrid is deployed. In other words, a single scheme is used for both storage and transmission.
> 3, Tracker/Peer operations on chunk availability information, which are to be considered include: 
> 	a) Formation, to translate a specific set of available chunks of a given swarm into a compact form of representation.
> 		In this case, Representation storage overhead wrt. the number of all chunks n and available chunks k, is considered.
> 	b) Transmission, to transmit a specific representation of currently available chunks of a given swarm to another neighboring peer.
> 		In this case, Representation transmission overhead wrt. n and k, is considered.
> 	c) Update, to update a specific representation of currently available chunks of a given swarm as result of a given (group) of newly downloaded and verified chunk(s).
> 		A special type of update operation, Partial update, where the sender only transfer the relevant part of available chunks and requires a merge operation at the receiver’s side, is considered separately.
> 		For updates, Update computation overhead wrt. n, k and the number of new chunks p, is considered.
> 		In addition, Delta transmission overhead wrt. n, k and the number of new chunks d, is also considered.
> 	d) Inquiry, to check whether a specific representation of available chunks of a given swarm contains a given (group) of requesting chunk(s).
> 		In this case, Inquiry computation overhead wrt. n, k and the number of requesting chunks g, is considered.
> 
> BR
> Lingli
> 


From denglingli@chinamobile.com  Tue Nov 26 23:53:37 2013
Return-Path: <denglingli@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAFE1AE198 for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 23:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TJIRMiHwC7p for <ppsp@ietfa.amsl.com>; Tue, 26 Nov 2013 23:53:34 -0800 (PST)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id E8C0B1ADEA6 for <ppsp@ietf.org>; Tue, 26 Nov 2013 23:53:33 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15295a498feb-aefeb; Wed, 27 Nov 2013 15:51:52 +0800 (CST)
X-RM-TRANSID: 2ee15295a498feb-aefeb
Received: from cmccPC (unknown[10.2.53.145]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15295a496267-8e2a9; Wed, 27 Nov 2013 15:51:52 +0800 (CST)
X-RM-TRANSID: 2ee15295a496267-8e2a9
From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= <denglingli@chinamobile.com>
To: <arno@cs.vu.nl>, <ppsp@ietf.org>
References: <046501ced9be$d5fb1a60$81f14f20$@com> <007401ceea71$bf754220$3e5fc660$@com> <5295A08D.2040603@cs.vu.nl>
In-Reply-To: <5295A08D.2040603@cs.vu.nl>
Date: Wed, 27 Nov 2013 15:53:36 +0800
Message-ID: <017701ceeb45$c76bbac0$56433040$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7rQuFDVon9vNXRS+G8ytvSwTW8/QAAkHUQ
Content-Language: zh-cn
Subject: Re: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 27 Nov 2013 07:53:37 -0000

Hi Arno,

Thank you for pointing out the lossy nature of BF scheme. Yes, this =
needs to be considered.

Just for clarification, the problem that "you may continuously download =
a chunk because the Bloomfilter cannot properly record that you already =
have it" is not going to happen in reality.
An already downloaded chunk would never be missed by a BF-based inquiry.

BR
Lingli

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: ppsp [mailto:ppsp-bounces@ietf.org] =
=E4=BB=A3=E8=A1=A8 Arno Bakker
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: =
2013=E5=B9=B411=E6=9C=8827=E6=97=A5 15:35
=E6=94=B6=E4=BB=B6=E4=BA=BA: ppsp@ietf.org
=E4=B8=BB=E9=A2=98: Re: [ppsp] on performance analysis for chunk =
addressing schemes/bitmap compression methods

Hi all

IMHO, a comparison cannot be done until the all the methods to be
evaluated are clear. It is not clear how the fact that Bloomfilters
are lossy is handled to ensure that peers do not stall on false
negatives, as raised in my previous mail. The lossy property of
Bloomfilters also implies they cannot be used for storage, otherwise
you may continuously download a chunk because the Bloomfilter cannot
properly record that you already have it.

Regards,
   Arno


On 26/11/2013 07:35, =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote:
> Hi all,
>=20
> As requested in the Vancouver meeting, we are planning to elaborate =
the previous performance analysis for bitmap compression schemes in the =
following way.
> Plz let me know if you have any comments or suggestion with this =
analysis setting.
>=20
> 1, we consider the following existing proposals for chunk availability =
information in this analysis
> 	a) Original bitmap Scheme uses a bit-array to represent the chunk =
set, and mark those bits corresponding to the locally available chunks.
> 	b) Chunk range scheme uses a array of starting+ending chunk index =
pairs to represent continuous intervals.=20
> 	c) Byte range scheme uses an array of starting+ending byte index =
pairs to represent continuous intervals.=20
> 	d) Bin number scheme uses a universally assigned bin number (integer) =
for any given continuous interval. =20
> 2, for simplicity, we assume that No hybrid is deployed. In other =
words, a single scheme is used for both storage and transmission.
> 3, Tracker/Peer operations on chunk availability information, which =
are to be considered include:=20
> 	a) Formation, to translate a specific set of available chunks of a =
given swarm into a compact form of representation.
> 		In this case, Representation storage overhead wrt. the number of all =
chunks n and available chunks k, is considered.
> 	b) Transmission, to transmit a specific representation of currently =
available chunks of a given swarm to another neighboring peer.
> 		In this case, Representation transmission overhead wrt. n and k, is =
considered.
> 	c) Update, to update a specific representation of currently available =
chunks of a given swarm as result of a given (group) of newly downloaded =
and verified chunk(s).
> 		A special type of update operation, Partial update, where the sender =
only transfer the relevant part of available chunks and requires a merge =
operation at the receiver=E2=80=99s side, is considered separately.
> 		For updates, Update computation overhead wrt. n, k and the number of =
new chunks p, is considered.
> 		In addition, Delta transmission overhead wrt. n, k and the number of =
new chunks d, is also considered.
> 	d) Inquiry, to check whether a specific representation of available =
chunks of a given swarm contains a given (group) of requesting chunk(s).
> 		In this case, Inquiry computation overhead wrt. n, k and the number =
of requesting chunks g, is considered.
>=20
> BR
> Lingli
>=20

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




From dch@jsonified.com  Wed Nov 27 06:47:18 2013
Return-Path: <dch@jsonified.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5F1ADBE8 for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 06:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OttjBo1wCORX for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 06:47:15 -0800 (PST)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0F1ADAEA for <ppsp@ietf.org>; Wed, 27 Nov 2013 06:47:13 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id l9so4725815eaj.14 for <ppsp@ietf.org>; Wed, 27 Nov 2013 06:47:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jsonified.com; s=google; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:content-transfer-encoding:content-disposition; bh=MKst+6U5bti6x4rn3BeTocZRrT4KKwrGMuAeCE1uuwI=; b=d5IVnMrc89NbtCBYCrJMx8pmEZxkfohF+Gq+VJKFygoNAK0xQr51qH4Cvv7ZCjpkwV SGOrP89YHjnm8gge4dMTg6jp0ry3NdQeP150n8k9A50WZ9dg75mB9buffbZ3stYh/HM9 pMzbdU0mIGNoy/XQVRXagSVjIje349Eayovgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=MKst+6U5bti6x4rn3BeTocZRrT4KKwrGMuAeCE1uuwI=; b=AAVdHaTe9WzhJaDCJwSEd+Ztc1TBwQQ1ajDzaXCE7to46Mesfordx/L7nbE3b7Uz0H YHC3A9QJVOowFDUF5Mhnc/3mgyDBxTacQMiafv4WXmKDayibtkCYZC1GnFFreukFew4j W8z7TG6QjRaG4aZ36CZN9mCVsTmDAlg/Wh6z23brmd3V/WQqW0YPzSweIfJAoVfvJp5L GVJ5exSd06tY8kNGo1US1tX16UmHzJU+WGtcZFzMhBb56l95p288kM2GhXJZunDFAarE HavuSBorpy4leYen8ad56szr6dT9cMReEoXXSD4mbBrowZelJPcOwrDeD+v1YIxnLEtI WvYQ==
X-Gm-Message-State: ALoCoQmlsVNtdDBH/HOgarGom47iSDMj1IVFmma/roHqA9vPx+Z+DJ6KkHAInVwMyy3b7ghk43/2
X-Received: by 10.14.115.133 with SMTP id e5mr317248eeh.91.1385563633187; Wed, 27 Nov 2013 06:47:13 -0800 (PST)
Received: from akai.jsonified.com (chello084112019176.2.11.vie.surfer.at. [84.112.19.176]) by mx.google.com with ESMTPSA id e43sm9369683eep.7.2013.11.27.06.47.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 06:47:12 -0800 (PST)
Date: Wed, 27 Nov 2013 15:47:10 +0100
From: Dave Cottlehuber <dch@jsonified.com>
To: "=?utf-8?Q?ppsp=40ietf.org?=" <ppsp@ietf.org>
Message-ID: <etPan.529605ee.643c9869.13d53@akai.jsonified.com>
In-Reply-To: <007401ceea71$bf754220$3e5fc660$@com>
References: <046501ced9be$d5fb1a60$81f14f20$@com> <007401ceea71$bf754220$3e5fc660$@com>
X-Mailer: Airmail Beta (218)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: Re: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 27 Nov 2013 14:47:18 -0000

On 26. November 2013 at 07:36:02, =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng=
 (denglingli=40chinamobile.com) wrote:
> =20
> Hi all,
> =20
> As requested in the Vancouver meeting, we are planning to elaborate =20
> the previous performance analysis for bitmap compression schemes =20
> in the following way.
> Plz let me know if you have any comments or suggestion with this =20
> analysis setting.
> =20
> 1, we consider the following existing proposals for chunk availability =
=20
> information in this analysis
> a) Original bitmap Scheme uses a bit-array to represent the chunk =20
> set, and mark those bits corresponding to the locally available =20
> chunks.
> b) Chunk range scheme uses a array of starting+ending chunk index =20
> pairs to represent continuous intervals.
> c) Byte range scheme uses an array of starting+ending byte index =20
> pairs to represent continuous intervals.
> d) Bin number scheme uses a universally assigned bin number (integer) =20
> for any given continuous interval.

> 2, for simplicity, we assume that No hybrid is deployed. In other =20
> words, a single scheme is used for both storage and transmission.=C2=A0=


> 3, Tracker/Peer operations on chunk availability information, =20
> which are to be considered include:
> a) =46ormation, to translate a specific set of available chunks =20
> of a given swarm into a compact form of representation.
> In this case, Representation storage overhead wrt. the number =20
> of all chunks n and available chunks k, is considered.
> b) Transmission, to transmit a specific representation of currently =20
> available chunks of a given swarm to another neighboring peer. =20
> In this case, Representation transmission overhead wrt. n and =20
> k, is considered.
> c) Update, to update a specific representation of currently =20
> available chunks of a given swarm as result of a given (group) =20
> of newly downloaded and verified chunk(s).
> A special type of update operation, Partial update, where the =20
> sender only transfer the relevant part of available chunks and =20
> requires a merge operation at the receiver=E2=80=99s side, is considere=
d =20
> separately.
> =46or updates, Update computation overhead wrt. n, k and the number =20
> of new chunks p, is considered.
> In addition, Delta transmission overhead wrt. n, k and the number =20
> of new chunks d, is also considered.
> d) Inquiry, to check whether a specific representation of available =20
> chunks of a given swarm contains a given (group) of requesting =20
> chunk(s).
> In this case, Inquiry computation overhead wrt. n, k and the number =20
> of requesting chunks g, is considered.
> =20
> BR
> Lingli

Thanks Lingli,

This should be comprehensive.

We should consider these perspectives:

Swarm characteristics:
- total number of peers (view of tracker)
- average connected peer set (view of normal peer)
- size of file, and =23 of chunks

Peer type:
- a super-peer that has the full dataset available, and is actively seedi=
ng as many peers as possible
- user-level peer that is both retrieving and transmitting data, to a sma=
ll peer set
- tracker

Transfer mode:
- streaming, where keeping very old chunks makes no sense
- copying, where chunks are being written to e.g. disk, all data must be =
obtained

=46inally, I am very interested to see your constraints (n,k,p above, swa=
rm characteristics), as I hope this will provide the motivation that lead=
 you propose this enhancement. Did this arise in development, testing, si=
mulation etc=3F

A+
Dave



From rachel.huang@huawei.com  Wed Nov 27 22:25:52 2013
Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3E1AE129 for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnmDTYZzrYoM for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:25:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04B1AE10B for <ppsp@ietf.org>; Wed, 27 Nov 2013 22:25:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAU22288; Thu, 28 Nov 2013 06:25:46 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 06:25:15 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 06:25:45 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 14:25:39 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: yunfei zhang <hishigh@gmail.com>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] WGLC for the survey draft
Thread-Index: AQHO6qgU23QibfvjxUWMjwZIWxFpfJo6LCcw
Date: Thu, 28 Nov 2013 06:25:39 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB459068EB@nkgeml501-mbs.china.huawei.com>
References: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
In-Reply-To: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.94]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB459068EBnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 Nov 2013 06:25:52 -0000

--_000_51E6A56BD6A85142B9D172C87FC3ABBB459068EBnkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0cywgYW5kIGhhdmUgZm9sbG93aW5nIGNv
bW1lbnRzOg0KDQoNCjEuICAgICAgIFRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgbGFzdCBwYXJhZ3Jh
cGggb2YgU2VjdGlvbiAxIGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBvcmdhbml6YXRpb24gb2Yg
Y2hhcHRlcnMgLiBUaGlzIHNob3VsZCBiZSBmaXhlZC4NCg0KMi4gICAgICAgSW4gc2VjdGlvbiAy
LCBzb21lIHRlcm1pbm9sb2dpZXMgaGF2ZSBhbHJlYWR5IGRlZmluZWQgaW4gUkZDNjk3Mi4gSXSh
r3MgdW5uZWNlc3NhcnkgdG8gcmVwZWF0IHRoZSBkZWZpbml0aW9uLCBlLmcuLCBjaHVuaywgbGl2
ZSBzdHJlYW1pbmehrQ0KDQozLiAgICAgICBTZWN0aW9uIDEgdHlwbzogobB3ZSBhbHdheXMgdHJ5
IHRvIGlkZW50aXR5IHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2xzobEgc2hvdWxkIGJlIKGwd2Ug
YWx3YXlzIHRyeSB0byBpZGVudGlmeSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sc6GxDQoNCjQu
ICAgICAgIFNlY3Rpb24gMy4xLCB0eXBvIKGwdGhpcyBtYXkgdHVybiBhdCBlbmQgdXNlcnMgaW50
byBwbGF5YmFjayBxdWFsaXR5IGRlZ3JhZGF0aW9uobEgc2hvdWxkIGJlIKGwdGhpcyBtYXkgdHVy
biBlbmQgdXNlcnMgaW50byBwbGF5YmFjayBxdWFsaXR5IGRlZ3JhZGF0aW9uobENCg0KDQpCZXN0
IHJlZ2FyZHMsDQpSYWNoZWwNCg0KRnJvbTogcHBzcCBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIHl1bmZlaSB6aGFuZw0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIg
MjYsIDIwMTMgOTowNSBQTQ0KVG86IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFtwcHNwXSBXR0xD
IGZvciB0aGUgc3VydmV5IGRyYWZ0DQoNCg0KSGkgYWxsLA0KICAgIEFjY29yZGluZyB0byB0aGUg
Y29uc2Vuc3VzIG9mIGxhc3QgSUVURiwgd2UnbGwgc3RhcnQgYSBzZWNvbmQgcm91bmQgb2YgV0dM
QyBmb3IgdGhlIHN1cnZleSBkcmFmdDoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1wcHNwLXN1cnZleS8NCiAgICBUaGUgV0dMQyB3aWxsIGxhc3QgZm9yIDIgd2Vl
a3MgYmVmb3JlIHN1Ym1pdHRpbmcgZm9yIG5leHQgc3RlcCBvZiBzdGFuZGFyZGl6YXRpb24uDQog
ICAgIFlvdXIgcmV2aWV3IGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQuIFBsZWFzZSBub3RlIHRoYXQg
eW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHZlcnkgaW1wb3J0YW50IGZvciB0aGUg
Zm9ybWluZyBvZiB0aGUgUkZDIGFzIHdlbGwgYXMgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBXRy4g
VGhhbmtzLg0KDQpCUg0KWXVuZmVpDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t
LS0tLS0NCkZyb206IFpvbmduaW5nIDx6b25nbmluZ0BodWF3ZWkuY29tPG1haWx0bzp6b25nbmlu
Z0BodWF3ZWkuY29tPj4NCkRhdGU6IDIwMTMvMTEvMjUNClN1YmplY3Q6IFtwcHNwXSBNZWV0aW5n
IG1pbnV0ZXMNClRvOiAicHBzcEBpZXRmLm9yZzxtYWlsdG86cHBzcEBpZXRmLm9yZz4iIDxwcHNw
QGlldGYub3JnPG1haWx0bzpwcHNwQGlldGYub3JnPj4NCkhpLCBGb2xrcywNCg0KU29ycnkgZm9y
IHRoZSBiZWxhdGVkIG1pbnV0ZXMgYW5kIHRoYW5rcyBSb25pIGZvciB0YWtpbmcgdGhlIG5vdGVz
LiBQbGVhc2Ugc2VlIGJlbG93IGFuZCBsZXQgdXMga25vdyBhbnkgY29ycmVjdHMgbmVlZGVkLg0K
DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KUFBTUCBTZXNzaW9uQElFVEYgODgNCg0KUGxhemEgQyxUdWVzZGF5IEFmdGVybm9vbiBT
ZXNzaW9uIElJSSwgTm92IDUsIDIwMTMNCg0KDQoNCjE2OjEwIEFnZW5kYSBiYXNoaW5nIChDaGFp
cnMsIDUgbWludXRlcykNCg0KTm8gY29tbWVudHMNCg0KDQoNCjE2OjE1IFN0YXR1cyBvZiB0aGUg
V0cgKENoYWlycywgMTAgbWludXRlcykNCg0KMSkgIFBlZXIgZHJhZnQgqEMgbW9yZSByZXZpZXcg
bmVlZGVkLCBlc3BlY2lhbGx5IG9uIHNlY3VyaXR5IGFuZCBlbmNvZGluZyBwZXJzcGVjdGl2ZXMu
DQoNCjIpICBUcmFja2VyIGJhc2UgZHJhZnQgqEMgbmVlZCBhdXRob3IgdGVhbSB0byBwcm9ncmVz
cyB0aGUgZHJhZnQgZmFzdGVyLCBtb3JlIGNhbGxzIGFyZSBuZWVkZWQuDQoNCjOjqVN1cnZleSBk
cmFmdCCoQyBuZWVkIDJuZCBXR0xDIGJlZm9yZSBzdWJtaXR0aW5nIHRvIElFU0cuDQoNCg0KDQox
NjoyNSBQZWVyIFByb3RvY29sIChBcm5vIHJlbW90ZWx5LDUwIG1pbnV0ZXMpLCBkcmFmdC1pZXRm
LXBwc3AtcGVlci1wcm90b2NvbC0wOA0KDQoxKSAgTmV3IHJldmlzaW9uIGhhcyBhZGRyZXNzZWQg
YWxsIGNvbW1lbnRzIGZyb20gQUQgcmV2aWV3Lg0KDQoyKSAgU29tZSBjb21tZW50cyBmcm9tIFJv
bmkgbmVlZCB0byBiZSBhZGRyZXNzZWQsIGUuZy4gaWYgcGVlciBwcm90b2NvbCBuZWVkIHRvIGRl
ZmluZSBob3cgdG8gZG8gTkFUIHRyYXZlcnNhbC4gVG8gYmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0
Lg0KDQozKSAgQ2h1bmsgc2l6ZSBpc3N1ZSBmcm9tIFl1bmZlaT8NCjQpICBDaHVuayBhZGRyZXNz
aW5nIGlzc3VlIKhDIG5lZ290aWF0aW9uIGlzIGJldHRlci4NCkxpbmdsaTogaW4gdGhlIGxhdGVz
dCB2ZXJzaW9uLCB0aGUgcGFydCBmb3Igb25saW5lIHRyYW5zbGF0aW9uIGJldHdlZW4gY29tbXVu
aWNhdGluZyBwZWVycyB1c2luZyBkaWZmZXJlbnQgY2h1bmsgYWRkcmVzc2luZyBzY2hlbWVzIGFy
ZSByZW1vdmVkLiBXaHk/DQpBOiBJdCBpcyB0b28gY29tcGxpY2F0ZWQgYW5kIG5vdCBuZWNlc3Nh
cnkuDQoNCg0KMTc6MTUgVHJhY2tlciBQcm90b2NvbCAoUnVpIHJlbW90ZWx5LCA1MCBtaW51dGVz
KSwgZHJhZnQtaWV0Zi1wcHNwLWJhc2UtdHJhY2tlci1wcm90b2NvbC0wMg0KDQoxKSAgSW4gdGhl
IGRyYWZ0LCBzdGlsbCBYTUwgZm9ybWF0IGluIG1haW4gYm9keS4gTmVlZCB0byBtb3ZlIFhNTCBl
eGFtcGxlIHRvIGFwcGVuZGl4IHdpdGggbW9yZSByZWZlcmVuY2VzLg0KWXVuZmVpOiBUaGUgbmV3
IHZlcnNpb24gZG9lc26hr3QgcmVmbGVjdCB0aGUgY29uc2Vuc3VzIG1hZGUgaW4gdGhlIGxhc3Qg
bWVldGluZywgd2hpY2ggaXMgdG8gbW92ZSB0aGUgZW5jb2RpbmcgaXNzdWVzIHRvIHRoZSBhcHBl
bmRpeCB3aGlsZSBrZWVwIHRoZSBtYWluIGJvZHkgdG8ganVzdCBkZWZpbmUgbWVzc2FnZXMuIEN1
cnJlbnRseSB0aGUgbWVzc2FnZXMgYXJlIHN0aWxsIHRleHQgYmFzZWQuIElzIHRoZXJlIGFueSBj
b25zaWRlcmF0aW9uIG9uIHRoZSBzaXR1YXRpb24gd2hlcmUgZGlmZmVyZW50IGVuY29kaW5ncyBh
cmUgdXNlZD8gRS5nLiwgc29tZSBwZWVycyB1c2UgdGV4dCBlbmNvZGluZyB3aGlsZSBvdGhlcnMg
dXNlIGJpbmFyeS4NCkxpbmdsaTogVGhlcmUgaXMgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmcgYmV0
d2VlbiBSdWkgYW5kIHRoZSBvdGhlciBjby1hdXRob3JzLiBCeSBiaW5hcnkgZW5jb2RpbmcsIFJ1
aSB0aGlua3MgaXShr3MgdGhlIGJpbmFyeSBlbmNvZGluZyBvZiB0aGUgWE1MLCB3aGlsZSBvdGhl
cnMgdGhpbmsgaXShr3MgdGhlIGJpbmFyeSBlbmNvZGluZyBvZiB0aGUgdHJhY2tlciBwcm90b2Nv
bC4gVGhlcmUgYXJlIHN0YW5kYXJkcyBmcm9tIElTTyBmb3IgYmluYXJ5IGVuY29kaW5nIG9mIFhN
TCwgd2hpY2ggaXMgRVhJLg0KWXVuZmVpOiBCdXQgRVhJIGNhbqGvdCBkbyB0aGUgdHJhbnNsYXRp
b24gYmV0d2VlbiBiaW5hcnkgZW5jb2Rpbmcgb2YgdGhlIG1lc3NhZ2VzIHRvIFhNTCBvZiB0aGUg
bWVzc2FnZXMuDQpMaW5nbGk6IFdlYnNvY2tldCBoYXMgc2ltaWxhciBtZWNoYW5pc21zIHRvIGRv
IHRoaXMga2luZCBvZiB0cmFuc2xhdGlvbi4gV2UgY2FuIHJlZmVyZW5jZSBpdC4gSSBjYW4gaGVs
cCB3aXRoIHRoZSBuZXcgdmVyc2lvbi4NCg0KDQoNCjE4OjA1IEVmZmljaWVudCBDaHVuayBBdmFp
bGFiaWxpdHkgQ29tcHJlc3Npb24gKExpbmdsaSwyMCBtaW51dGVzKSwgZHJhZnQtZGVuZy1wcHNw
LWJmYml0bWFwLTAzDQoNCkFybm86IGluIHJlYWxpdHksIHN0cmVhbWluZyBkb3dubG9hZGluZyBo
YXBwZW5zIHNlcXVlbnRpYWxseSwgaGVuY2Ugc2NvcGUtYmFzZWQgc2NoZW1lcyB3b3JrcyB3ZWxs
Lg0KDQpBOiBpbiBWb0QgY2FzZXMsIHVzZXIgYmVoYXZpb3IgY2FuIGludGVycnVwdCB0aGUgc2Vx
dWVudGlhbCB2aWV3aW5nIHBhdHRlcm4uIEFuZCBldmVuIGluIGxpdmUgc3RyZWFtaW5nIGNhc2Us
IGJlY2F1c2UgdGhlIGNvbmN1cnJlbnRseSBwZWVyLXRvLXBlZXIgZG93bmxvYWRpbmcgcGF0dGVy
biwgb3V0LW9mLW9yZGVyIGNodW5rIHRyYW5zbWlzc2lvbiBpcyBpbmV2aXRhYmxlLg0KDQpEYXZl
OiB3aGF0IGlzIHRoZSBvYmplY3RpdmUgb2YgaW50cm9kdWNpbmcgQkYgc2NoZW1lPw0KDQpBOiB0
aGUgbW90aXZlIGlzIGVsYWJvcmF0ZWQgaW4gdGhlIGxhc3QgbWVldGluZ6GvcyBwcmVzZW50YXRp
b24uIFRoZXJlIGlzIGFuIGNvbXBhcmlzb24gb2YgdGhlIHdvcnN0IGNhc2UgcGVyZm9ybWFuY2Ug
b2YgZGlmZmVyZW50IGJpdG1hcCBjb21wcmVzc2lvbiBzY2hlbWVzIGluIHRlcm1zIG9mIHZhcmlv
dXMgYml0bWFwIHJlbGV2YW50IG9wZXJhdGlvbnMgaW4gUFBTUC4NCg0KQXJubzogaW4gcGVlciBw
cm90b2NvbCwgcGVlcnMgZG9uoa90IHNoYXJlIGJpdG1hcHMsIG9ubHkgY2h1bmsgcmFuZ2VzIHVw
ZGF0ZXMgYXJlIGV4Y2hhbmdlZC4gUGVlciBwcm90b2NvbCBkb2VzbqGvdCBuZWVkIGJpdG1hcCBj
b21wcmVzc2lvbi4NCg0KQTogcmFuZ2VzIG9yIHVwZGF0ZXMgYXJlIHNwZWNpYWwgZm9ybXMgb2Yg
Y29tcHJlc3Npb24uIEJGIHNjaGVtZSBjYW4gYmUgaW50cm9kdWNlZCBpbnRvIHBlZXIgcHJvdG9j
b2wgYXMgYSBuZXcgY2h1bmsgYWRkcmVzc2luZyBtZXRob2QuDQoNCg0KDQpvcGVuIGlzc3VlIDEg
qEMgbG9va3MgbGlrZSB0aGUgcHJvcG9zZWQgb3B0aW9uIGlzIGJldHRlciBubyBuZWVkIHRvIHRy
YW5zbGF0aW9uDQoNCk9wZW4gaXNzdWUgMiCoQyBsb29rcyBsaWtlIGl0IGlzIGhlbHBmdWwgdG8g
aW5jbHVkZSBjb250ZW50IHNjb3BlIGludG8gcmVxdWVzdHMsIGJ1dCBub3QgdG8gdGhlIHJlc3Bv
bnNlcy4NCg0KTm8gYWRvcHRpb24gYXQgdGhlIG1vbWVudC4gTmVlZCBtb3JlIG1haWxpbmcgbGlz
dCBkaXNjdXNzaW9uIGFuZCBvZmZsaW5lIHdpdGggdGhlIHRyYWNrZXIgcHJvdG9jb2wgYXV0aG9y
Lg0KDQoNCg0KUmFjaGVsOiBpbiBleHRlbmRlZCB0cmFja2VyIHByb3RvY29sLCB0aGUgY29udGVu
dCBzY29wZSBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGluY29ycG9yYXRlZCBpbiB0aGUgcmVxdWVz
dHMuIEJ1dCBpZiB3ZSBpbmNvcnBvcmF0ZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbnRvIHRoZSBy
ZXNwb25zZXMsIGl0IHdvdWxkIGJlIGR1cGxpY2F0ZWQgd2l0aCB0aGUgc3Vic2VxdWVudCBwZWVy
IGluZm9ybWF0aW9uIGhhbmRzaGFraW5nLg0KDQpOaW5nOiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0
byBpbmNyZWFzZSBuZWlnaGJvcmhvb2QgZXN0YWJsaXNobWVudCBieSBhbHdheXMgaW5jbHVkaW5n
IFNFRURFUiBwZWVycyBpbiByZXNwb25zZT8NCg0KQTogSSB0aGluayBpdCBtYWtlIHNlbnNlIHRv
IGRvIHNvIHRvIGVuc3VyZSBGSU5EIGFsd2F5cyBoaXQsIGFzIGxvbmcgYXMgdGhlIHNwZWNpZmlj
IGNvbnRlbnQgcmFuZ2UgaW4gbmVlZCBpcyBpbmNvcnBvcmF0ZWQgaW4gY29ycmVzcG9uZGluZyBy
ZXF1ZXN0cy4NCg0KDQoNCjE4OjI1IENvbmNsdXNpb24gYW5kIG5leHQgc3RlcCAoQ2hhaXJzLCAx
MCBtaW51dGVzKQ0KDQpQZWVyIGRyYWZ0IG5lZWRzIG1vcmUgcmV2aWV3LiBUcmFja2VyIGJhc2Ug
ZHJhZnQgbmVlZHMgY2FsbCBiZXR3ZWVuIGNvLWF1dGhvcnMgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0
IGZhc3Rlci4gMm5kIFdHTEMgb24gc3VydmV5IGRyYWZ0IHN0YXJ0cyBzb29uLg0KDQoNCg0KMTg6
MzUgRW5kDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KDQpUaGFua3MsDQoNCi1ZdW5mZWkgJiBOaW5nLg0KDQoNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBw
c3BAaWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3Bwc3ANCg0K

--_000_51E6A56BD6A85142B9D172C87FC3ABBB459068EBnkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.HTMLChar
	{mso-style-name:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:684138747;
	mso-list-type:hybrid;
	mso-list-template-ids:-114667742 67698703 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I have reviewed this draf=
ts, and have following comments:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The description i=
n the last paragraph of Section 1 is inconsistent with the organization of =
chapters . This should be fixed.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In section 2, som=
e terminologies have already defined in RFC6972. It=A1=AFs unnecessary to r=
epeat the definition, e.g., chunk, live streaming=A1=AD<o:p></o:p></span></=
p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Section 1 typo: =
=A1=B0we always try to identity tracker and peer protocols=A1=B1 should be =
=A1=B0we always try to identify tracker and peer protocols=A1=B1<o:p></o:p>=
</span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Section 3.1, typo=
 =A1=B0this may turn at end users into playback quality degradation=A1=B1 s=
hould be =A1=B0this may turn end users into playback quality degradation=A1=
=B1<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Rachel<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ppsp [ma=
ilto:ppsp-bounces@ietf.org]
<b>On Behalf Of </b>yunfei zhang<br>
<b>Sent:</b> Tuesday, November 26, 2013 9:05 PM<br>
<b>To:</b> ppsp@ietf.org<br>
<b>Subject:</b> [ppsp] WGLC for the survey draft<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class=3D"MsoNormal"><br>
Hi all,<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; According to the&nbsp;consensus o=
f last IETF, we'll start a second round of WGLC for the survey draft:<o:p><=
/o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://datatracker.ietf.org/doc/draft-iet=
f-ppsp-survey/">http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/</a>=
<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; The WGLC will last for 2 weeks be=
fore submitting for next step of standardization.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; Your review&nbsp;are highly=
 appreciated. Please note that your comments and suggestions are very impor=
tant for the forming of the RFC as well as the development of the WG. Thank=
s.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">BR<br>
Yunfei<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Zongning</b> &lt;<a href=3D"mailto:zongning@huawei.com">zongning@h=
uawei.com</a>&gt;<br>
Date: 2013/11/25<br>
Subject: [ppsp] Meeting minutes<br>
To: &quot;<a href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&quot; &lt;<a h=
ref=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&gt;<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Hi, Folks,</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Sorry for the belated minutes and=
 thanks Roni for taking the notes. Please see below and let us know any cor=
rects needed.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span=
><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">PPSP Session@IETF 88&nbsp;</span>=
<o:p></o:p></p>
<pre><span style=3D"font-size:13.5pt">Plaza C,Tuesday Afternoon Session III=
, Nov 5, 2013</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:10 Agenda bashing (Chairs, 5 minut=
es)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">No comments</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:15 Status of the WG (Chairs, 10 mi=
nutes)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Peer draft <span lang=3D"ZH-CN">=A8C</span> more review needed, especiall=
y on security and encoding perspectives.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">2)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Tracker base draft <span lang=3D"ZH-CN">=A8C</span> need author team to p=
rogress the draft faster, more calls are needed.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">3<span lang=3D"ZH-CN">=
=A3=A9</span>Survey draft <span lang=3D"ZH-CN">=A8C</span> need 2<sup>nd</s=
up> WGLC before submitting to IESG.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:25 Peer Protocol (Arno remotely,50=
 minutes)</span>, <span style=3D"font-size:13.5pt">draft-ietf-ppsp-peer-pro=
tocol-08</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">New revision has addressed all comments from AD review.</span><o:p></o:p>=
</pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">2)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt">Some comment=
s from Roni need to be addressed, e.g. if peer protocol need to define how =
to do NAT traversal<span style=3D"color:#1F497D">.</span> <span style=3D"co=
lor:#1F497D">T</span>o be discussed on the list<span style=3D"color:#1F497D=
">.</span></span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">3)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Chunk size issue from Yunfei?</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">4)</span><span styl=
e=3D"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&q=
uot;;color:#1F497D">&nbsp;
</span><span style=3D"font-size:13.5pt">Chunk addressing issue <span lang=
=3D"ZH-CN">=A8C</span> negotiation is better.
</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: in the late=
st version, the part for online translation between communicating peers usi=
ng different chunk addressing schemes
 are removed. Why?</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">A: It is too compli=
cated and not necessary.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<pre><span style=3D"font-size:13.5pt">17:15 Tracker Protocol (Rui remotely,=
 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02&nbsp; </span><o:p></=
o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">In the draft, still XML format in main body. Need to move XML example to =
appendix with more references.</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Yunfei: The new ver=
sion doesn<span lang=3D"ZH-CN">=A1=AF</span>t reflect the consensus made in=
 the last meeting, which is to move the encoding
 issues to the appendix while keep the main body to just define messages. C=
urrently the messages are still text based. Is there any consideration on t=
he situation where different encodings are used? E.g., some peers use text =
encoding while others use binary.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: There is di=
fferent understanding between Rui and the other co-authors. By binary encod=
ing, Rui thinks it<span lang=3D"ZH-CN">=A1=AF</span>s
 the binary encoding of the XML, while others think it<span lang=3D"ZH-CN">=
=A1=AF</span>s the binary encoding of the tracker protocol. There are stand=
ards from ISO for binary encoding of XML, which is EXI.</span><o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Yunfei: But EXI can=
<span lang=3D"ZH-CN">=A1=AF</span>t do the translation between binary encod=
ing of the messages to XML of the messages.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: Websocket h=
as similar mechanisms to do this kind of translation. We can reference it. =
I can help with the new version.</span><o:p></o:p></p>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">18:05 Efficient Chunk Availability Co=
mpression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03</span><o:p></o:p=
></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Arno: in reality, strea=
ming downloading happens sequentially, hence scope-based schemes works well=
.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: in VoD cases, user b=
ehavior can interrupt the sequential viewing pattern. And even in live stre=
aming case, because the concurrently peer-to-peer downloading pattern, out-=
of-order chunk transmission is inevitable.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Dave: what is the objec=
tive of introducing BF scheme?</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: the motive is elabor=
ated in the last meeting<span lang=3D"ZH-CN">=A1=AF</span>s presentation. T=
here is an comparison of the worst case performance of different bitmap com=
pression schemes in terms of various bitmap relevant operations in PPSP.</s=
pan><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Arno: in peer protocol,=
 peers don<span lang=3D"ZH-CN">=A1=AF</span>t share bitmaps, only chunk ran=
ges updates are exchanged. Peer protocol doesn<span lang=3D"ZH-CN">=A1=AF</=
span>t need bitmap compression.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: ranges or updates ar=
e special forms of compression. BF scheme can be introduced into peer proto=
col as a new chunk addressing method.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">open issue 1 <span lang=3D"ZH-CN">=A8=
C</span> looks like the proposed option is better no need to translation</s=
pan><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Open issue 2 <span lang=
=3D"ZH-CN">=A8C</span> looks like it is helpful to include content scope in=
to requests, but not to the responses.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">No adoption at the moment. Need more =
mailing list discussion and offline with the tracker protocol author.</span=
><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Rachel: in extended tra=
cker protocol, the content scope information is already incorporated in the=
 requests. But if we incorporate the same information into the responses, i=
t would be duplicated with the subsequent peer information handshaking.</sp=
an><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Ning: Would it be possi=
ble to increase neighborhood establishment by always including SEEDER peers=
 in response?</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: I think it make sens=
e to do so to ensure FIND always hit, as long as the specific content range=
 in need is incorporated in corresponding requests.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">&nbsp;</span><o:p></o:p=
></pre>
<pre><span style=3D"font-size:13.5pt">18:25 Conclusion and next step (Chair=
s, 10 minutes)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Peer draft needs more r=
eview.</span><span style=3D"font-size:13.5pt;font-family:&quot;Times New Ro=
man&quot;,&quot;serif&quot;;color:#1F497D"> </span><span style=3D"font-size=
:13.5pt;color:#1F497D">Tracker base draft needs call between co-authors to =
progress the draft faster. 2<sup>nd</sup> WGLC on survey draft starts soon.=
</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">18:35 End</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Thanks,</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">-Yunfei &amp; Ning.</span><o:p></=
o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
_______________________________________________<br>
ppsp mailing list<br>
<a href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ppsp" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/ppsp</a><o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_51E6A56BD6A85142B9D172C87FC3ABBB459068EBnkgeml501mbschi_--

From denglingli@gmail.com  Wed Nov 27 22:43:41 2013
Return-Path: <denglingli@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA97D1AE140 for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.771
X-Spam-Level: *
X-Spam-Status: No, score=1.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qlnJJrrTqRl for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:43:37 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4D1AE10B for <ppsp@ietf.org>; Wed, 27 Nov 2013 22:43:36 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id hz11so5594216vcb.31 for <ppsp@ietf.org>; Wed, 27 Nov 2013 22:43:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SKgqPCQWkI8FNENiKzHO3qN9QQHe4yu9Y7nAICK7jRg=; b=QCyiDAMtURb4HK8QUQhQOjTlm0kgCXj/7lAVWbNgRcpw4tpbXjBuHfg46dxvchIUND IAhNu4K3/iQyaom/f4uYx17bglWv9Sahi9igaromSggQqboCuGLFpEpOARt7n9UnIdEZ T0FwAgi37XTlu25Rk5w+bC6DsJUORjJQisb1YXlqLO1oo9AS71Jc0l7wvhUpNH3ipE/W R7RtHvshgp0WuE2Gw/Ku6dSMpgYo76Gtsx9tsjpNBEPdfB8tkuOoLpW3lNu621BzNNx1 BGhwm08iC9N9E0cn17CNGXg0GIeuAqyS+Ncy3pKJ6Quyz6pJjK5xJ+8RvDuz5re3Z1C0 rDpQ==
MIME-Version: 1.0
X-Received: by 10.220.58.1 with SMTP id e1mr37129049vch.0.1385621015776; Wed, 27 Nov 2013 22:43:35 -0800 (PST)
Received: by 10.58.118.142 with HTTP; Wed, 27 Nov 2013 22:43:35 -0800 (PST)
Date: Thu, 28 Nov 2013 14:43:35 +0800
Message-ID: <CAHWmbsOHW4b9KG2djAgJTjBF8ZZuupByWrQrVjZ+vd-Z2tfMpA@mail.gmail.com>
From: lingli deng <denglingli@gmail.com>
To: peer2peer@gmail.com, ppsp@ietf.org
Content-Type: multipart/alternative; boundary=001a11c2c7da7086f104ec37084f
Subject: Re: [ppsp] on performance analysis for chunk addressing schemes/bitmap compression methods
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 Nov 2013 06:43:42 -0000

--001a11c2c7da7086f104ec37084f
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Johan,



Thank you for the "critical" remarks.

Actually, as I understand it, there are basically two separate issues here:



1) Do we prefer to mandate a single scheme, such as binmap, or do we need
to allow different schemes to be available for implemention/trials?

  There are inconsistency between TP and Peer protocols about this issue,
(in terms of configuration, negotiation, translation, etc.) .

  Although we included relevant issues in the BF scheme discussions, it is
not necessarily bounded with the introduction of BF scheme.



2) Regarding the information exchange problem, I think there may be
different considerations for Tracker and Peer protocols.

  As for the tracker protocol, one may control the exchange frequency to
mitigate the problem, but at the cost of degraded accuracy of peer status
information.

  For peer protocol, the method is not feasible, as the peer needs to
report its latest content status to all neighbors as soon as a new chunk is
downloaded and verified.

  In case of unreliable transport, incremental update methods, as used in
binmap, may suffer from lossy channels and repeated application-level
retransmissions incurred.



As for BF scheme itself, whether it is a simple solution or not as compared
with other schemes (including binmap), is subject to analysis and testing.



BR

Lingli



-----=D3=CA=BC=FE=D4=AD=BC=FE-----

=B7=A2=BC=FE=C8=CB: Johan Pouwelse [mailto:peer2peer@gmail.com <peer2peer@g=
mail.com>]

=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C226=C8=D5 17:17

=CA=D5=BC=FE=C8=CB: =B5=CB=C1=E9=C0=F2/Lingli Deng

=B3=AD=CB=CD: ppsp

=D6=F7=CC=E2: Re: [ppsp] on performance analysis for chunk addressing schem=
es/bitmap
compression methods



Dear Lingli Deng,

Please find a review of your I-D below. Apologies for the critical nature
of my remarks.



After reading of this proposal it was still unclear what problem is being
addressed and why it's needed.



Using Bloom filters adds a lot of complexity, while at this stage PPSP
needs I believe: simplicity, running code and additional real-world trials.

PPSP has a unique and efficient datastructure of representing availability
of video chunks using "binmaps". Using one number to compress both pieces
and intervals is not easy to improve.  For the given example of 2GByte, a
binmap indicating the availability of the whole file or an ongoing live
stream is less than a KByte. Even in an UltraHD scenario with bitrates of
42Mbps it should scale. Obviously normal bitmaps get in trouble then, but
not binmaps.



The I-D states "frequent exchange of large volume of bitmap information, is
among the key factors that set a limit to the system's efficiency and
scalability [P2P-limit]".

This cited INFOCOM paper does not support the claims made. It merely states
that the period T of periodic buffer map exchanges should not be too short,
then it will impact performance.





Prof. Johan Pouwelse

Delft University of Technology





----composed-on-my-mobile----



On Nov 26, 2013 7:36 AM, "=B5=CB=C1=E9=C0=F2/Lingli Deng" <denglingli@china=
mobile.com>
wrote:

>

> Hi all,

>

> As requested in the Vancouver meeting, we are planning to elaborate the
previous performance analysis for bitmap compression schemes in the
following way.

> Plz let me know if you have any comments or suggestion with this analysis
setting.

>

> 1, we consider the following existing proposals for chunk availability
information in this analysis

>         a) Original bitmap Scheme uses a bit-array to represent the chunk
set, and mark those bits corresponding to the locally available chunks.

>         b) Chunk range scheme uses a array of starting+ending chunk index
pairs to represent continuous intervals.

>         c) Byte range scheme uses an array of starting+ending byte index
pairs to represent continuous intervals.

>         d) Bin number scheme uses a universally assigned bin number
(integer) for any given continuous interval.

> 2, for simplicity, we assume that No hybrid is deployed. In other words,
a single scheme is used for both storage and transmission.

> 3, Tracker/Peer operations on chunk availability information, which are
to be considered include:

>         a) Formation, to translate a specific set of available chunks of
a given swarm into a compact form of representation.

>                 In this case, Representation storage overhead wrt. the
number of all chunks n and available chunks k, is considered.

>         b) Transmission, to transmit a specific representation of
currently available chunks of a given swarm to another neighboring peer.

>                 In this case, Representation transmission overhead wrt. n
and k, is considered.

>         c) Update, to update a specific representation of currently
available chunks of a given swarm as result of a given (group) of newly
downloaded and verified chunk(s).

>                 A special type of update operation, Partial update, where
the sender only transfer the relevant part of available chunks and requires
a merge operation at the receiver=A1=AFs side, is considered separately.

>                 For updates, Update computation overhead wrt. n, k and
the number of new chunks p, is considered.

>                 In addition, Delta transmission overhead wrt. n, k and
the number of new chunks d, is also considered.

>         d) Inquiry, to check whether a specific representation of
available chunks of a given swarm contains a given (group) of requesting
chunk(s).

>                 In this case, Inquiry computation overhead wrt. n, k and
the number of requesting chunks g, is considered.

>

> BR

> Lingli

>

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org<p=
psp-bounces@ietf.org>]
=B4=FA=B1=ED

> =B5=CB=C1=E9=C0=F2/Lingli Deng

> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C25=C8=D5 8:35

> =CA=D5=BC=FE=C8=CB: 'ppsp'

> =D6=F7=CC=E2: [ppsp] =D7=AA=B7=A2: New Version Notification for

> draft-deng-ppsp-bfbitmap-04.txt

>

> Hi forks,

>

> We are happy to announce the latest version of BFbitmap draft.

> In this version, we discussed open issues for accommodating several chunk
addressing schemes in general as well as how to integrate the BF scheme
with PPSP protocols.

> Your comments and suggestions would be highly appreciated.

>

> BR

> Lingli

>

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf=
.org<internet-drafts@ietf.org>
]

> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C25=C8=D5 8:29

> =CA=D5=BC=FE=C8=CB: Deng Lingli; Yunfei Zhang; Yihong Huang; Jin Peng; Li=
ngli Deng;

> Rachel Huang

> =D6=F7=CC=E2: New Version Notification for draft-deng-ppsp-bfbitmap-04.tx=
t

>

>

> A new version of I-D, draft-deng-ppsp-bfbitmap-04.txt has been

> successfully submitted by Lingli Deng and posted to the IETF

> repository.

>

> Filename:        draft-deng-ppsp-bfbitmap

> Revision:        04

> Title:           Efficient Chunk Availability Compression for PPSP

> Creation date:   2013-11-05

> Group:           Individual Submission

> Number of pages: 13

> URL:
http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-04.txt

> Status:          http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap

> Htmlized:        http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-04

> Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfbitmap-04

>

> Abstract:

>    Bloom filters are proposed to be used in compressing chunk

>    availability information, periodically exchanged between peers and

>    the tracker through PPSP-TP and PPSPP protocols, to reduce relevant

>    cost and enhance scalability.

>

>

>

>

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at
tools.ietf.org.

>

> The IETF Secretariat

>

>

>

>

> _______________________________________________

> ppsp mailing list

> ppsp@ietf.org

> https://www.ietf.org/mailman/listinfo/ppsp

>

>

>

> _______________________________________________

> ppsp mailing list

> ppsp@ietf.org

> https://www.ietf.org/mailman/listinfo/ppsp


--=20
=B5=CB=C1=E9=C0=F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc=
h Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--001a11c2c7da7086f104ec37084f
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Hi Johan,</font></span></p><font color=
=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Thank you for the &quot;critical&quot;
remarks. </font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=
=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Actually, as I understand it, there ar=
e
basically two separate issues here:</font></span></p><font color=3D"#000000=
" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">1) Do we prefer to mandate a single
scheme, such as binmap, or do we need to allow different schemes to be
available for implemention/trials?</font></span></p><font color=3D"#000000"=
 size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font size=3D"3"><font color=3D"#000000"><span>&nbsp;
</span>There are inconsistency between TP and Peer protocols about this iss=
ue,
(in terms of configuration, negotiation, translation, etc.) . </font></font=
></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5"=
>

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font size=3D"3"><font color=3D"#000000"><span>&nbsp;
</span>Although we included relevant issues in the BF scheme discussions, i=
t is
not necessarily bounded with the introduction of BF scheme.</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">2) Regarding the information exchange =
problem,
I think there may be different considerations for Tracker and Peer protocol=
s. </font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=
=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font size=3D"3"><font color=3D"#000000"><span>&nbsp;
</span>As for the tracker protocol, one may control the exchange frequency =
to
mitigate the problem, but at the cost of degraded accuracy of peer status
information. </font></font></font></span></p><font color=3D"#000000" size=
=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font size=3D"3"><font color=3D"#000000"><span>&nbsp;
</span>For peer protocol, the method is not feasible, as the peer needs to
report its latest content status to all neighbors as soon as a new chunk is
downloaded and verified.</font></font></font></span></p><font color=3D"#000=
000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font size=3D"3"><font color=3D"#000000"><span>&nbsp;
</span>In case of unreliable transport, incremental update methods, as used=
 in
binmap, may suffer from lossy channels and repeated application-level
retransmissions incurred.</font></font></font></span></p><font color=3D"#00=
0000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">As for BF scheme itself, whether it is=
 a
simple solution or not as compared with other schemes (including binmap), i=
s
subject to analysis and testing. </font></span></p><font color=3D"#000000" =
size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">BR</font></span></p><font color=3D"#00=
0000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Lingli</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">-----</font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=D3=CA=BC=FE=D4=AD=BC=FE</span><span lang=
=3D"EN-US"><font face=3D"Calibri">-----</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><span style=3D"font=
-family:=CB=CE=CC=E5"><font color=3D"#000000">=B7=A2=BC=FE=C8=CB</font></sp=
an><span lang=3D"EN-US"><font color=3D"#000000" face=3D"Calibri">: Johan Po=
uwelse [</font><a href=3D"mailto:peer2peer@gmail.com"><font color=3D"#0000f=
f" face=3D"Calibri">mailto:peer2peer@gmail.com</font></a><font color=3D"#00=
0000" face=3D"Calibri">]</font></span></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span style=3D"font-family:=CB=CE=CC=E5">=B7=A2=CB=CD=CA=B1=BC=E4</spa=
n><span lang=3D"EN-US"><font face=3D"Calibri">: 2013</font></span><span sty=
le=3D"font-family:=CB=CE=CC=E5">=C4=EA</span><span lang=3D"EN-US"><font fac=
e=3D"Calibri">11</font></span><span style=3D"font-family:=CB=CE=CC=E5">=D4=
=C2</span><span lang=3D"EN-US"><font face=3D"Calibri">26</font></span><span=
 style=3D"font-family:=CB=CE=CC=E5">=C8=D5</span><span lang=3D"EN-US"><font=
 face=3D"Calibri"> 17:17</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span style=3D"font-family:=CB=CE=CC=E5">=CA=D5=BC=FE=C8=CB</span><spa=
n lang=3D"EN-US"><font face=3D"Calibri">: </font></span><span style=3D"font=
-family:=CB=CE=CC=E5">=B5=CB=C1=E9=C0=F2</span><span lang=3D"EN-US"><font f=
ace=3D"Calibri">/Lingli Deng</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span style=3D"font-family:=CB=CE=CC=E5">=B3=AD=CB=CD</span><span lang=
=3D"EN-US"><font face=3D"Calibri">: ppsp</font></span></font></font></p><fo=
nt color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span style=3D"font-family:=CB=CE=CC=E5">=D6=F7=CC=E2</span><span lang=
=3D"EN-US"><font face=3D"Calibri">: Re: [ppsp] on
performance analysis for chunk addressing schemes/bitmap compression method=
s</font></span></font></font></p><font color=3D"#000000" size=3D"3" face=3D=
"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Dear Lingli Deng,</font></span></p><fo=
nt color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Please find a review of your I-D below=
.
Apologies for the critical nature of my remarks.</font></span></p><font col=
or=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">After reading of this proposal it was
still unclear what problem is being addressed and why it&#39;s needed.</fon=
t></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Using Bloom filters adds a lot of
complexity, while at this stage PPSP needs I believe: simplicity, running c=
ode
and additional real-world trials.</font></span></p><font color=3D"#000000" =
size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">PPSP has a unique and efficient
datastructure of representing availability of video chunks using
&quot;binmaps&quot;. Using one number to compress both pieces and intervals=
 is
not easy to improve.<span>&nbsp; </span>For the given
example of 2GByte, a binmap indicating the availability of the whole file o=
r an
ongoing live stream is less than a KByte. Even in an UltraHD scenario with
bitrates of 42Mbps it should scale. Obviously normal bitmaps get in trouble
then, but not binmaps.</font></font></span></p><font color=3D"#000000" size=
=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">The I-D states &quot;frequent exchange
of large volume of bitmap information, is among the key factors that set a
limit to the system&#39;s efficiency and scalability [P2P-limit]&quot;.</fo=
nt></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">This cited INFOCOM paper does not
support the claims made. It merely states that the period T of periodic buf=
fer
map exchanges should not be too short, then it will impact performance.</fo=
nt></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Prof. Johan Pouwelse</font></span></p>=
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">Delft University of Technology</font><=
/span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">----composed-on-my-mobile----</font></=
span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&nbsp;</font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font color=3D"#000000"><font size=
=3D"3"><span lang=3D"EN-US"><font face=3D"Calibri">On Nov 26, 2013 7:36 AM,=
 &quot;</font></span><span style=3D"font-family:=CB=CE=CC=E5">=B5=CB=C1=E9=
=C0=F2</span></font></font><span lang=3D"EN-US"><font color=3D"#000000" siz=
e=3D"3" face=3D"Calibri">/Lingli Deng&quot; &lt;</font><a href=3D"mailto:de=
nglingli@chinamobile.com"><font color=3D"#0000ff" size=3D"3" face=3D"Calibr=
i">denglingli@chinamobile.com</font></a><font color=3D"#000000" size=3D"3" =
face=3D"Calibri">&gt;
wrote:</font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=
=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Hi all,</font></span></p><font co=
lor=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; As requested in the Vancouver
meeting, we are planning to elaborate the previous performance analysis for
bitmap compression schemes in the following way.</font></span></p><font col=
or=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Plz let me know if you have any
comments or suggestion with this analysis setting.</font></span></p><font c=
olor=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; 1, we consider the following
existing proposals for chunk availability information in this analysis</fon=
t></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>a) Original bitmap Scheme uses a
bit-array to represent the chunk set, and mark those bits corresponding to =
the
locally available chunks.</font></font></span></p><font color=3D"#000000" s=
ize=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>b) Chunk range scheme uses a array of
starting+ending chunk index pairs to represent continuous intervals.</font>=
</font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>c) Byte range scheme uses an array of
starting+ending byte index pairs to represent continuous intervals.</font><=
/font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>d) Bin number scheme uses a
universally assigned bin number (integer) for any given continuous interval=
.</font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=
=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; 2, for simplicity, we assume that
No hybrid is deployed. In other words, a single scheme is used for both sto=
rage
and transmission.</font></span></p><font color=3D"#000000" size=3D"3" face=
=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; 3, Tracker/Peer operations on chu=
nk
availability information, which are to be considered include:</font></span>=
</p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>a) Formation, to translate a specific
set of available chunks of a given swarm into a compact form of representat=
ion.</font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=
=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>In this case, Representation
storage overhead wrt. the number of all chunks n and available chunks k, is
considered.</font></font></span></p><font color=3D"#000000" size=3D"3" face=
=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>b) Transmission, to transmit a
specific representation of currently available chunks of a given swarm to
another neighboring peer.</font></font></span></p><font color=3D"#000000" s=
ize=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>In this case, Representation
transmission overhead wrt. n and k, is considered.</font></font></span></p>=
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>c) Update, to update a specific represent=
ation
of currently available chunks of a given swarm as result of a given (group)=
 of
newly downloaded and verified chunk(s).</font></font></span></p><font color=
=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt;<span>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; </span>A special type of update
operation, Partial update, where the sender only transfer the relevant part=
 of
available chunks and requires a merge operation at the receiver</font></spa=
n><span style=3D"font-family:&quot;Courier New&quot;" lang=3D"EN-US">&rsquo=
;</span><span lang=3D"EN-US"><font face=3D"Calibri">s side, is considered s=
eparately.</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>For updates, Update
computation overhead wrt. n, k and the number of new chunks p, is considere=
d.</font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=
=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>In addition, Delta transmission
overhead wrt. n, k and the number of new chunks d, is also considered.</fon=
t></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5=
">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>d) Inquiry, to check whether a
specific representation of available chunks of a given swarm contains a giv=
en
(group) of requesting chunk(s).</font></font></span></p><font color=3D"#000=
000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>In this case, Inquiry
computation overhead wrt. n, k and the number of requesting chunks g, is
considered.</font></font></span></p><font color=3D"#000000" size=3D"3" face=
=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; BR</font></span></p><font color=
=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Lingli</font></span></p><font col=
or=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; -----</font></span><s=
pan style=3D"font-family:=CB=CE=CC=E5">=D3=CA=BC=FE=D4=AD=BC=FE</span><span=
 lang=3D"EN-US"><font face=3D"Calibri">-----</font></span></font></font></p=
>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font color=3D"#000000"><font size=
=3D"3"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span=
 style=3D"font-family:=CB=CE=CC=E5">=B7=A2=BC=FE=C8=CB</span></font></font>=
<span lang=3D"EN-US"><font color=3D"#000000" size=3D"3" face=3D"Calibri">: =
</font><a href=3D"mailto:ppsp-bounces@ietf.org"><font color=3D"#0000ff" siz=
e=3D"3" face=3D"Calibri">ppsp-bounces@ietf.org</font></a><font color=3D"#00=
0000" size=3D"3" face=3D"Calibri"> [</font><a href=3D"mailto:ppsp-bounces@i=
etf.org"><font color=3D"#0000ff" size=3D"3" face=3D"Calibri">mailto:ppsp-bo=
unces@ietf.org</font></a><font color=3D"#000000" size=3D"3" face=3D"Calibri=
">] </font></span><font size=3D"3"><font color=3D"#000000"><span style=3D"f=
ont-family:=CB=CE=CC=E5">=B4=FA=B1=ED</span><font face=3D"Calibri">
</font></font></font></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=
=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=B5=CB=C1=E9=C0=F2</span><span lang=3D"EN=
-US"><font face=3D"Calibri">/Lingli Deng</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=B7=A2=CB=CD=CA=B1=BC=E4</span><span lang=
=3D"EN-US"><font face=3D"Calibri">: 2013</font></span><span style=3D"font-f=
amily:=CB=CE=CC=E5">=C4=EA</span><span lang=3D"EN-US"><font face=3D"Calibri=
">11</font></span><span style=3D"font-family:=CB=CE=CC=E5">=D4=C2</span><sp=
an lang=3D"EN-US"><font face=3D"Calibri">5</font></span><span style=3D"font=
-family:=CB=CE=CC=E5">=C8=D5</span><span lang=3D"EN-US"><font face=3D"Calib=
ri"> 8:35</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=CA=D5=BC=FE=C8=CB</span><span lang=3D"EN=
-US"><font face=3D"Calibri">: &#39;ppsp&#39;</font></span></font></font></p=
>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=D6=F7=CC=E2</span><span lang=3D"EN-US"><=
font face=3D"Calibri">: [ppsp] </font></span><span style=3D"font-family:=CB=
=CE=CC=E5">=D7=AA=B7=A2</span><span lang=3D"EN-US"><font face=3D"Calibri">:=
 New
Version Notification for </font></span></font></font></p><font color=3D"#00=
0000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; draft-deng-ppsp-bfbitmap-04.txt</=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Hi forks,</font></span></p><font =
color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; We are happy to announce the late=
st
version of BFbitmap draft.</font></span></p><font color=3D"#000000" size=3D=
"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; In this version, we discussed ope=
n
issues for accommodating several chunk addressing schemes in general as wel=
l as
how to integrate the BF scheme with PPSP protocols.</font></span></p><font =
color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Your comments and suggestions wou=
ld
be highly appreciated.</font></span></p><font color=3D"#000000" size=3D"3" =
face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; BR</font></span></p><font color=
=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Lingli</font></span></p><font col=
or=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; -----</font></span><s=
pan style=3D"font-family:=CB=CE=CC=E5">=D3=CA=BC=FE=D4=AD=BC=FE</span><span=
 lang=3D"EN-US"><font face=3D"Calibri">-----</font></span></font></font></p=
>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font color=3D"#000000"><font size=
=3D"3"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span=
 style=3D"font-family:=CB=CE=CC=E5">=B7=A2=BC=FE=C8=CB</span></font></font>=
<span lang=3D"EN-US"><font color=3D"#000000" size=3D"3" face=3D"Calibri">: =
</font><a href=3D"mailto:internet-drafts@ietf.org"><font color=3D"#0000ff" =
size=3D"3" face=3D"Calibri">internet-drafts@ietf.org</font></a><font color=
=3D"#000000" size=3D"3" face=3D"Calibri">
[</font><a href=3D"mailto:internet-drafts@ietf.org"><font color=3D"#0000ff"=
 size=3D"3" face=3D"Calibri">mailto:internet-drafts@ietf.org</font></a><fon=
t color=3D"#000000" size=3D"3" face=3D"Calibri">]</font></span></p><font co=
lor=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=B7=A2=CB=CD=CA=B1=BC=E4</span><span lang=
=3D"EN-US"><font face=3D"Calibri">: 2013</font></span><span style=3D"font-f=
amily:=CB=CE=CC=E5">=C4=EA</span><span lang=3D"EN-US"><font face=3D"Calibri=
">11</font></span><span style=3D"font-family:=CB=CE=CC=E5">=D4=C2</span><sp=
an lang=3D"EN-US"><font face=3D"Calibri">5</font></span><span style=3D"font=
-family:=CB=CE=CC=E5">=C8=D5</span><span lang=3D"EN-US"><font face=3D"Calib=
ri"> 8:29</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=CA=D5=BC=FE=C8=CB</span><span lang=3D"EN=
-US"><font face=3D"Calibri">: Deng Lingli; Yunfei Zhang; Yihong Huang; Jin =
Peng; Lingli Deng; </font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Rachel Huang</font></span></p><fo=
nt color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><font size=3D"3"><font color=3D"#000=
000"><span lang=3D"EN-US"><font face=3D"Calibri">&gt; </font></span><span s=
tyle=3D"font-family:=CB=CE=CC=E5">=D6=F7=CC=E2</span><span lang=3D"EN-US"><=
font face=3D"Calibri">: New Version Notification for draft-deng-ppsp-bfbitm=
ap-04.txt</font></span></font></font></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; A new version of I-D,
draft-deng-ppsp-bfbitmap-04.txt has been </font></span></p><font color=3D"#=
000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; successfully submitted by Lingli
Deng and posted to the IETF </font></span></p><font color=3D"#000000" size=
=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; repository.</font></span></p><fon=
t color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt; Filename:<span>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>draft-deng-ppsp-bfbitmap</font></font=
></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt; Revision:<span>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>04</font></font></span></p><font colo=
r=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt; Title:<span>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Efficient Chunk Availa=
bility
Compression for PPSP</font></font></span></p><font color=3D"#000000" size=
=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt; Creation date:<span>&nbsp;&=
nbsp; </span>2013-11-05</font></font></span></p><font color=3D"#000000" siz=
e=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt; Group:<span>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Individual Submission<=
/font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=
=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Number of pages: 13</font></span>=
</p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000"><font size=3D"3"><font face=3D"Calibri">&gt; URL:<span>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font=
></font></font><a href=3D"http://www.ietf.org/internet-drafts/draft-deng-pp=
sp-bfbitmap-04.txt"><font color=3D"#0000ff" size=3D"3" face=3D"Calibri">htt=
p://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-04.txt</font></a>=
</span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000"><font size=3D"3"><font face=3D"Calibri">&gt; Status:<span>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></font></font>=
<a href=3D"http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap"><font =
color=3D"#0000ff" size=3D"3" face=3D"Calibri">http://datatracker.ietf.org/d=
oc/draft-deng-ppsp-bfbitmap</font></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000"><font size=3D"3"><font face=3D"Calibri">&gt; Htmlized:<span>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></font></font><a href=3D=
"http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-04"><font color=3D"#00=
00ff" size=3D"3" face=3D"Calibri">http://tools.ietf.org/html/draft-deng-pps=
p-bfbitmap-04</font></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000"><font size=3D"3"><font face=3D"Calibri">&gt; Diff:<span>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></fo=
nt></font><a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfb=
itmap-04"><font color=3D"#0000ff" size=3D"3" face=3D"Calibri">http://www.ie=
tf.org/rfcdiff?url2=3Ddraft-deng-ppsp-bfbitmap-04</font></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Abstract:</font></span></p><font =
color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;
</span>Bloom filters are proposed to be used in compressing chunk</font></f=
ont></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;
</span>availability information, periodically exchanged between peers and</=
font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=
=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;
</span>the tracker through PPSP-TP and PPSPP protocols, to reduce relevant<=
/font></font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=
=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font face=3D"C=
alibri"><font color=3D"#000000" size=3D"3">&gt;<span>&nbsp;&nbsp;&nbsp;
</span>cost and enhance scalability.</font></font></span></p><font color=3D=
"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; Please note that it may take a
couple of minutes from the time of </font></span></p><font color=3D"#000000=
" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; submission until the htmlized
version and diff are available at <a href=3D"http://tools.ietf.org">tools.i=
etf.org</a>.</font></span></p><font color=3D"#000000" size=3D"3" face=3D"=
=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; The IETF Secretariat</font></span=
></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt;
_______________________________________________</font></span></p><font colo=
r=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; ppsp mailing list</font></span></=
p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; </font><a href=3D"mailto:ppsp@iet=
f.org"><font color=3D"#0000ff" size=3D"3" face=3D"Calibri">ppsp@ietf.org</f=
ont></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; </font><a href=3D"https://www.iet=
f.org/mailman/listinfo/ppsp"><font color=3D"#0000ff" size=3D"3" face=3D"Cal=
ibri">https://www.ietf.org/mailman/listinfo/ppsp</font></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font size=3D"3=
"><font color=3D"#000000"><font face=3D"Calibri">&gt;&nbsp;</font></font></=
font></span></p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt;
_______________________________________________</font></span></p><font colo=
r=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; ppsp mailing list</font></span></=
p><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; </font><a href=3D"mailto:ppsp@iet=
f.org"><font color=3D"#0000ff" size=3D"3" face=3D"Calibri">ppsp@ietf.org</f=
ont></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><p style=3D"margin:0cm 0cm 0pt"><span lang=3D"EN-US"><font color=3D"=
#000000" size=3D"3" face=3D"Calibri">&gt; </font><a href=3D"https://www.iet=
f.org/mailman/listinfo/ppsp"><font color=3D"#0000ff" size=3D"3" face=3D"Cal=
ibri">https://www.ietf.org/mailman/listinfo/ppsp</font></a></span></p>
<font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><br clear=3D"all"><br>-- <br>=B5=CB=C1=E9=C0=F2/Lingli Deng<br>=D6=
=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Research I=
nstitute<br>e-mail: <a href=3D"mailto:denglingli@chinamobile.com">denglingl=
i@chinamobile.com</a><br>tel: 15801696688-3367<br>mobile: 13810597148<br>

</div>

--001a11c2c7da7086f104ec37084f--

From ron.even.tlv@gmail.com  Thu Nov 28 06:20:08 2013
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28051AE125 for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 06:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFMOH8ZDf_3u for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 06:20:04 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id B49261ADF9D for <ppsp@ietf.org>; Thu, 28 Nov 2013 06:20:03 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so8257543wgg.27 for <ppsp@ietf.org>; Thu, 28 Nov 2013 06:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=iV8/avgCaPDa+UX/4N1I/FK2HnhTOMDSFbkuIUL13KU=; b=TJIaO9Chx6MRhP7VXzEQRoYtipuy9NVPh0tyHfUIpmcafcueASIbwK6rx8OzeQqjNO Hy5kiZFsot/fuT+aqFfHL81eKaqvnF7sr7AwxE9EtQjmBzYtiTIc2/QLW8CxKy8zJZuK VYOZocLJ5YdR4T2vabuTLcmDFxmLzMaV61KJNGrv/zqUry4Q1JyhlwyeQ8mq5ssTK5H7 /IaHkXvabRNzTtH+K2CHGRZzWpcB5MEP9d/P0nEaRf3Q8fqhQxHWGPndWC5xoVs9bsiw K5FQ4B53dreqdLblUtSpa9uk69Ph1BAdfkL3rOEkTPJSVzQJg/zO9JYitPQOos748LkJ ITng==
X-Received: by 10.180.80.233 with SMTP id u9mr2734826wix.6.1385648402430; Thu, 28 Nov 2013 06:20:02 -0800 (PST)
Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id ll10sm81828644wic.9.2013.11.28.06.19.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Nov 2013 06:20:01 -0800 (PST)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'yunfei zhang'" <hishigh@gmail.com>, <ppsp@ietf.org>
References: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
In-Reply-To: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
Date: Thu, 28 Nov 2013 16:16:38 +0200
Message-ID: <0dd901ceec44$76b50870$641f1950$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DDA_01CEEC55.3A4181F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG6VanJNHWNKwZOkorxQ2u1X9LqPZpiGB0Q
Content-Language: en-us
Subject: Re: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 Nov 2013 14:20:09 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0DDA_01CEEC55.3A4181F0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi,

I read the document. It looks good I just have some editorial comments





Some nits

1.       Figure 1 $B!H(Btraker$B!I(B should be $B!H(Btracker$B!I(B

2.       In section 3.1.2 on PPLive change $B!H(Bbeing the nature of PPLive
protocols and algorithm proprietary$B!I(B to $B!H(B Since the protocols and
algorithm of PPLIVE are proprietary$B!I(B

3.       In section 3.1.3 $B!H(B Authentication server is the first point of
contact for a peer the joins the system$B!I(B to $B!H(BAuthentication server is the
first point of contact for a peer that joins the system$B!I(B

4.       In section 3.1.3 $B!H(B can contact new more peers besides the ones
indicated by the rendezvous server$B!I(B to $B!H(Bcan contact new peers besides the
ones indicated by the rendezvous server$B!I(B

5.       In section 3.1.5 $B!H(BSince children could lie regarding the number of
chunks forwarded to others, Tribler peers do directly not ask their
children, but their grandchildren.$B!I(B To $B!H(BSince children could lie regarding
the number of chunks forwarded to others, Tribler peers do not ask their
children directly, but their grandchildren.$B!I(B

6.       In section 3.1.6 when first using CDN expand to Content Delivery
Network (CDN)





Roni Even























From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of yunfei zhang
Sent: 26 November, 2013 3:05 PM
To: ppsp@ietf.org
Subject: [ppsp] WGLC for the survey draft




Hi all,

    According to the consensus of last IETF, we'll start a second round of
WGLC for the survey draft:

http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/

    The WGLC will last for 2 weeks before submitting for next step of
standardization.

     Your review are highly appreciated. Please note that your comments and
suggestions are very important for the forming of the RFC as well as the
development of the WG. Thanks.



BR
Yunfei

---------- Forwarded message ----------
From: Zongning <zongning@huawei.com>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "ppsp@ietf.org" <ppsp@ietf.org>

Hi, Folks,



Sorry for the belated minutes and thanks Roni for taking the notes. Please
see below and let us know any corrects needed.



===========================================================

PPSP Session@IETF 88

Plaza C,Tuesday Afternoon Session III, Nov 5, 2013

16:10 Agenda bashing (Chairs, 5 minutes)
No comments

16:15 Status of the WG (Chairs, 10 minutes)
1)  Peer draft - more review needed, especially on security and encoding
perspectives.
2)  Tracker base draft - need author team to progress the draft faster, more
calls are needed.
3$B!K(BSurvey draft - need 2nd WGLC before submitting to IESG.

16:25 Peer Protocol (Arno remotely,50 minutes),
draft-ietf-ppsp-peer-protocol-08
1)  New revision has addressed all comments from AD review.
2)  Some comments from Roni need to be addressed, e.g. if peer protocol need
to define how to do NAT traversal. To be discussed on the list.
3)  Chunk size issue from Yunfei?

4)  Chunk addressing issue - negotiation is better.

Lingli: in the latest version, the part for online translation between
communicating peers using different chunk addressing schemes are removed.
Why?

A: It is too complicated and not necessary.



17:15 Tracker Protocol (Rui remotely, 50 minutes),
draft-ietf-ppsp-base-tracker-protocol-02
1)  In the draft, still XML format in main body. Need to move XML example to
appendix with more references.

Yunfei: The new version doesn$B!G(Bt reflect the consensus made in the last
meeting, which is to move the encoding issues to the appendix while keep the
main body to just define messages. Currently the messages are still text
based. Is there any consideration on the situation where different encodings
are used? E.g., some peers use text encoding while others use binary.

Lingli: There is different understanding between Rui and the other
co-authors. By binary encoding, Rui thinks it$B!G(Bs the binary encoding of the
XML, while others think it$B!G(Bs the binary encoding of the tracker protocol.
There are standards from ISO for binary encoding of XML, which is EXI.

Yunfei: But EXI can$B!G(Bt do the translation between binary encoding of the
messages to XML of the messages.

Lingli: Websocket has similar mechanisms to do this kind of translation. We
can reference it. I can help with the new version.


18:05 Efficient Chunk Availability Compression (Lingli,20 minutes),
draft-deng-ppsp-bfbitmap-03
Arno: in reality, streaming downloading happens sequentially, hence
scope-based schemes works well.
A: in VoD cases, user behavior can interrupt the sequential viewing pattern.
And even in live streaming case, because the concurrently peer-to-peer
downloading pattern, out-of-order chunk transmission is inevitable.
Dave: what is the objective of introducing BF scheme?
A: the motive is elaborated in the last meeting$B!G(Bs presentation. There is an
comparison of the worst case performance of different bitmap compression
schemes in terms of various bitmap relevant operations in PPSP.
Arno: in peer protocol, peers don$B!G(Bt share bitmaps, only chunk ranges
updates are exchanged. Peer protocol doesn$B!G(Bt need bitmap compression.
A: ranges or updates are special forms of compression. BF scheme can be
introduced into peer protocol as a new chunk addressing method.

open issue 1 - looks like the proposed option is better no need to
translation
Open issue 2 - looks like it is helpful to include content scope into
requests, but not to the responses.
No adoption at the moment. Need more mailing list discussion and offline
with the tracker protocol author.

Rachel: in extended tracker protocol, the content scope information is
already incorporated in the requests. But if we incorporate the same
information into the responses, it would be duplicated with the subsequent
peer information handshaking.
Ning: Would it be possible to increase neighborhood establishment by always
including SEEDER peers in response?
A: I think it make sense to do so to ensure FIND always hit, as long as the
specific content range in need is incorporated in corresponding requests.

18:25 Conclusion and next step (Chairs, 10 minutes)
Peer draft needs more review. Tracker base draft needs call between
co-authors to progress the draft faster. 2nd WGLC on survey draft starts
soon.

18:35 End
===================================================



Thanks,



-Yunfei & Ning.








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




------=_NextPart_000_0DDA_01CEEC55.3A4181F0
Content-Type: text/html;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-2022-jp"><meta name=3DGenerator content=3D"Microsoft Word =
14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;
	mso-fareast-language:ZH-CN;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;
	mso-fareast-language:ZH-CN;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:ZH-CN;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;
	mso-fareast-language:ZH-CN;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-fareast-language:ZH-CN;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:ZH-CN;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:767888764;
	mso-list-type:hybrid;
	mso-list-template-ids:306217764 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Hi,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I read the document. It looks good I just have some editorial =
comments<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Some nits<o:p></o:p></span></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times =
New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Figure 1 =1B$B!H=1B(Btraker=1B$B!I=1B(B should be =
=1B$B!H=1B(Btracker=1B$B!I=1B(B<o:p></o:p></span></p><p =
class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times =
New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>In section 3.1.2 on PPLive change =1B$B!H=1B(Bbeing the nature of =
PPLive protocols and algorithm proprietary=1B$B!I=1B(B to =1B$B!H=1B(B =
Since the protocols and algorithm of PPLIVE are =
proprietary=1B$B!I=1B(B<o:p></o:p></span></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><span style=3D'mso-list:Ignore'>3.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>In section 3.1.3 =1B$B!H=1B(B </span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'>Authentication server is the first point of =
contact for a peer the joins the system=1B$B!I=1B(B to =
=1B$B!H=1B(BAuthentication server is the first point of contact for a =
peer that joins the system=1B$B!I=1B(B<o:p></o:p></span></p><p =
class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><span style=3D'mso-list:Ignore'>4.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>In section 3.1.3 =1B$B!H=1B(B </span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'>can contact new more peers besides the ones =
indicated by the rendezvous server=1B$B!I=1B(B to =1B$B!H=1B(Bcan =
contact new peers besides the ones indicated by the rendezvous =
server=1B$B!I=1B(B<o:p></o:p></span></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><span style=3D'mso-list:Ignore'>5.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>In section 3.1.5 =1B$B!H=1B(B</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'>Since children could lie regarding the =
number of chunks forwarded to others, Tribler peers do directly not ask =
their children, but their grandchildren.=1B$B!I=1B(B To =
=1B$B!H=1B(BSince children could lie regarding the number of chunks =
forwarded to others, Tribler peers do not ask their children directly, =
but their grandchildren.=1B$B!I=1B(B<o:p></o:p></span></p><p =
class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><span style=3D'mso-list:Ignore'>6.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>In section 3.1.6 when first using CDN expand to Content Delivery =
Network (CDN)</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'>Roni Even<o:p></o:p></span></p><p =
class=3DMsoListParagraph style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoListParagraph style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoListParagraph style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal style=3D'page-break-before:always'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:black;=
mso-fareast-language:EN-US'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
ppsp [mailto:ppsp-bounces@ietf.org] <b>On Behalf Of </b>yunfei =
zhang<br><b>Sent:</b> 26 November, 2013 3:05 PM<br><b>To:</b> =
ppsp@ietf.org<br><b>Subject:</b> [ppsp] WGLC for the survey =
draft<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p =
class=3DMsoNormal><br>Hi all,<o:p></o:p></p></div><div><p =
class=3DMsoNormal>&nbsp;&nbsp;&nbsp; According to the&nbsp;consensus of =
last IETF, we'll start a second round of WGLC for the survey =
draft:<o:p></o:p></p></div><div><p class=3DMsoNormal><a =
href=3D"http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/">http://d=
atatracker.ietf.org/doc/draft-ietf-ppsp-survey/</a><o:p></o:p></p></div><=
div><p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; The WGLC will last for 2 =
weeks before submitting for next step of =
standardization.<o:p></o:p></p></div><div><p =
class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp; Your review&nbsp;are highly =
appreciated. Please note that your comments and suggestions are very =
important for the forming of the RFC as well as the development of the =
WG. Thanks.<o:p></o:p></p></div><div><p =
class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal>BR<br>Yunfei<o:p></o:p></p></div><div><p =
class=3DMsoNormal>---------- Forwarded message ----------<br>From: =
<b>Zongning</b> &lt;<a =
href=3D"mailto:zongning@huawei.com">zongning@huawei.com</a>&gt;<br>Date: =
2013/11/25<br>Subject: [ppsp] Meeting minutes<br>To: &quot;<a =
href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&quot; &lt;<a =
href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&gt;<o:p></o:p></p><div><d=
iv><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>Hi, Folks,</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>&nbsp;</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>Sorry for the belated minutes and thanks Roni =
for taking the notes. Please see below and let us know any corrects =
needed.</span><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>&nbsp;</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><o:p></o:p><=
/p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>PPSP Session@IETF =
88&nbsp;</span><o:p></o:p></p><pre><span =
style=3D'font-size:13.5pt'>Plaza C,Tuesday Afternoon Session III, Nov 5, =
2013</span><o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>16:10 Agenda bashing (Chairs, 5 =
minutes)</span><o:p></o:p></pre><pre><span style=3D'font-size:13.5pt'>No =
comments</span><o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>16:15 Status of the WG (Chairs, 10 =
minutes)</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>1)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>Peer draft <span =
lang=3DZH-CN>&#8211;</span> more review needed, especially on security =
and encoding perspectives.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>2)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>Tracker base draft <span =
lang=3DZH-CN>&#8211;</span> need author team to progress the draft =
faster, more calls are needed.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>3<span =
lang=3DZH-CN>=1B$B!K=1B(B</span>Survey draft <span =
lang=3DZH-CN>&#8211;</span> need 2<sup>nd</sup> WGLC before submitting =
to IESG.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>&nbsp;</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>16:25 Peer Protocol (Arno remotely,50 =
minutes)</span>, <span =
style=3D'font-size:13.5pt'>draft-ietf-ppsp-peer-protocol-08</span><o:p></=
o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>1)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>New revision has addressed all =
comments from AD review.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>2)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt'>Some comments from Roni need to be addressed, =
e.g. if peer protocol need to define how to do NAT traversal<span =
style=3D'color:#1F497D'>.</span> <span style=3D'color:#1F497D'>T</span>o =
be discussed on the list<span =
style=3D'color:#1F497D'>.</span></span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>3)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>Chunk size issue from =
Yunfei?</span><o:p></o:p></pre><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>4)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt'>Chunk addressing issue <span =
lang=3DZH-CN>&#8211;</span> negotiation is better. =
</span><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>Lingli: in the latest version, =
the part for online translation between communicating peers using =
different chunk addressing schemes are removed. =
Why?</span><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>A: It is too complicated and =
not necessary.</span><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>&nbsp;</span><o:p></o:p></p><pre><span =
style=3D'font-size:13.5pt'>17:15 Tracker Protocol (Rui remotely, 50 =
minutes), draft-ietf-ppsp-base-tracker-protocol-02&nbsp; =
</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>1)</span><span =
style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'>&nbsp; </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>In the draft, still XML format =
in main body. Need to move XML example to appendix with more =
references.</span><o:p></o:p></pre><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>Yunfei: The new version =
doesn<span lang=3DZH-CN>=1B$B!G=1B(B</span>t reflect the consensus made =
in the last meeting, which is to move the encoding issues to the =
appendix while keep the main body to just define messages. Currently the =
messages are still text based. Is there any consideration on the =
situation where different encodings are used? E.g., some peers use text =
encoding while others use binary.</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>Lingli: There is different =
understanding between Rui and the other co-authors. By binary encoding, =
Rui thinks it<span lang=3DZH-CN>=1B$B!G=1B(B</span>s the binary encoding =
of the XML, while others think it<span lang=3DZH-CN>=1B$B!G=1B(B</span>s =
the binary encoding of the tracker protocol. There are standards from =
ISO for binary encoding of XML, which is EXI.</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>Yunfei: But EXI can<span =
lang=3DZH-CN>=1B$B!G=1B(B</span>t do the translation between binary =
encoding of the messages to XML of the messages.</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt;color:#1F497D'>Lingli: Websocket has similar =
mechanisms to do this kind of translation. We can reference it. I can =
help with the new =
version.</span><o:p></o:p></p><pre>&nbsp;<o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>18:05 Efficient Chunk Availability =
Compression (Lingli,20 minutes), =
draft-deng-ppsp-bfbitmap-03</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Arno: in reality, streaming =
downloading happens sequentially, hence scope-based schemes works =
well.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>A: in VoD cases, user behavior =
can interrupt the sequential viewing pattern. And even in live streaming =
case, because the concurrently peer-to-peer downloading pattern, =
out-of-order chunk transmission is =
inevitable.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Dave: what is the objective of =
introducing BF scheme?</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>A: the motive is elaborated in =
the last meeting<span lang=3DZH-CN>=1B$B!G=1B(B</span>s presentation. =
There is an comparison of the worst case performance of different bitmap =
compression schemes in terms of various bitmap relevant operations in =
PPSP.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Arno: in peer protocol, peers =
don<span lang=3DZH-CN>=1B$B!G=1B(B</span>t share bitmaps, only chunk =
ranges updates are exchanged. Peer protocol doesn<span =
lang=3DZH-CN>=1B$B!G=1B(B</span>t need bitmap =
compression.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>A: ranges or updates are =
special forms of compression. BF scheme can be introduced into peer =
protocol as a new chunk addressing =
method.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>&nbsp;</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>open issue 1 <span =
lang=3DZH-CN>&#8211;</span> looks like the proposed option is better no =
need to translation</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Open issue 2 <span =
lang=3DZH-CN>&#8211;</span> looks like it is helpful to include content =
scope into requests, but not to the =
responses.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>No adoption at the moment. Need more mailing =
list discussion and offline with the tracker protocol =
author.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>&nbsp;</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Rachel: in extended tracker =
protocol, the content scope information is already incorporated in the =
requests. But if we incorporate the same information into the responses, =
it would be duplicated with the subsequent peer information =
handshaking.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Ning: Would it be possible to =
increase neighborhood establishment by always including SEEDER peers in =
response?</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>A: I think it make sense to do =
so to ensure FIND always hit, as long as the specific content range in =
need is incorporated in corresponding =
requests.</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>&nbsp;</span><o:p></o:p></pre><p=
re><span style=3D'font-size:13.5pt'>18:25 Conclusion and next step =
(Chairs, 10 minutes)</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt;color:#1F497D'>Peer draft needs more =
review.</span><span style=3D'font-size:13.5pt;font-family:"Times New =
Roman","serif";color:#1F497D'> </span><span =
style=3D'font-size:13.5pt;color:#1F497D'>Tracker base draft needs call =
between co-authors to progress the draft faster. 2<sup>nd</sup> WGLC on =
survey draft starts =
soon.</span><o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>18:35 End</span><o:p></o:p></pre><pre><span =
style=3D'font-size:13.5pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><o:p></o:p></pre><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>Thanks,</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>&nbsp;</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:13.5pt'>-Yunfei &amp; Ning.</span><o:p></o:p></p><p =
class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span =
style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><o:p></o:p></p></div></div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br>______________________________________=
_________<br>ppsp mailing list<br><a =
href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/ppsp" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/ppsp</a><o:p></o:=
p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></div></body></html>
------=_NextPart_000_0DDA_01CEEC55.3A4181F0--


From denglingli@gmail.com  Thu Nov 28 09:35:30 2013
Return-Path: <denglingli@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD9E1ADA74 for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 09:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.432
X-Spam-Level: *
X-Spam-Status: No, score=1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcGnrSp4Yl-j for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 09:35:27 -0800 (PST)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D43AC1AD7C0 for <ppsp@ietf.org>; Thu, 28 Nov 2013 09:35:26 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id ik5so6172522vcb.30 for <ppsp@ietf.org>; Thu, 28 Nov 2013 09:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+WG5FUmRms7nb6ffxzMUq6rZq2EMg6ykVKQ0c2ee2so=; b=IvWgUgAg3p8U6iMTa95L/zqmr9B6PdnrDOioJZkUN6YhfQQG7I5Wp8mEB8ry9bT9js DxIiV8PLiQVeElOmjkqM1kF1DbOpz+dc/Mo67OAt0I/FFiBNFK2hwKQKS+cWNpOLqTdf uUJX/V18BRP0xKN/PtDiYqdvb6dlBuWwDtS/NA8Zn4fTv4eahAhq42p9G3nw9+I/CVS3 6gxqqGDZM9kp3vaXm9RGwsoxWqzT9QV3+QAxiL/dLTQgPFTWS7GSnPX6S0uOC+2aFSQw AMLSwuAu4DfaJ15HUx88o8UYyFMQyl+gfKDPlRaOChVDPuEexrx2VW4fyz91r1VyTdnf SgOQ==
MIME-Version: 1.0
X-Received: by 10.58.23.33 with SMTP id j1mr1806459vef.27.1385660125702; Thu, 28 Nov 2013 09:35:25 -0800 (PST)
Received: by 10.58.118.130 with HTTP; Thu, 28 Nov 2013 09:35:25 -0800 (PST)
Date: Fri, 29 Nov 2013 01:35:25 +0800
Message-ID: <CAHWmbsM6gNU0-Vsn8ny5XLSw+wETp673DQDrdeBEedYoXYfKHg@mail.gmail.com>
From: lingli deng <denglingli@gmail.com>
To: hishigh@gmail.com, ppsp@ietf.org
Content-Type: multipart/alternative; boundary=047d7b339df9926ec404ec4023e9
Subject: Re: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 Nov 2013 17:35:30 -0000

--047d7b339df9926ec404ec4023e9
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Yunfei and all,



I have the following comments about the current survey draft:



1, it states as a "standard track" document, is that accurate?

2, in terminoloy section, "push" is defined as "Transmission of multimedia
content without any request from receiving peers.", which I think could be
better described as "Transmission of multimedia content that is not
initiated by receiving peers."

3, In section 3, "the topology that can be associated with overlay
connections among peers" could be rephrased into "the topology of overlay
connections among peers".
4, Also in section 3, "pull-based data delivery calls for large size
buffers where to store chunks" could be rephrased into "pull-based data
delivery calls for large size buffers to store chunks".

5, "buffer-maps" are used to refer to "chunk availability information" (as
used by RFC 6972). For sake of consistency, I think it is better to use the
latter instead.

6, In Section 3.2.1 =A1=B0channel server, that provides the list of availab=
le
channels (live TV or VoD content) to a PPLive, as soon as the peer joins
the system;=A1=B1 should be =A1=B0channel server, that provides the list of=
 available
channels (live TV or VoD content) to a PPLive peer, as soon as the peer
joins the system;=A1=B1

7, It seems to me that the content server may have played some sort of
tracker=A1=AFs role in Octoshape, otherwise, how would a joining peer gets =
to
know the initial address book of other peers?

8, In Section 3.2.3, =A1=B0a mechanism very similar to the one of TCP conge=
stion
window (double increase or linear increase depending on whether the
estimate is below or a given threshold)=A1=B1, should be like =A1=B0a mecha=
nism very
similar to the one of TCP congestion window (double increase or linear
increase depending on whether the estimate is below or above a given
threshold)=A1=B1

9, One may be curious about what is the difference between a =A1=B0repeater
node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description of a =A1=B0rep=
eater node=A1=B1 goes
like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able to
forward any sub-stream and implement the same peer protocol as simple
peers.=A1=B1

10, In Section 3.2.4, =A1=B0a PPStream peer selects peers to download sub-c=
hunks
from according to a rate-based algorithm=A1=B1 should be change into =A1=B0=
a PPStream
peer selects peers to download sub-chunks according to a rate-based
algorithm=A1=B1
11, In Section 3.1.5, =A1=B0As already said, Tribler supports video streami=
ng in
two different forms: video on demand and live streaming.=A1=B1 Is better to=
 be
changed into =A1=B0Tribler supports video streaming in two different forms:
video on demand and live streaming.=A1=B1, since there is no prior statemen=
t in
the draft.

12, Also in Section 3.1.5, =A1=B0Such a mechanism allows Tribler peers to u=
se
the public key included in torrent file and verity the integrity of each
chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler p=
eers to
use the public key included in torrent file and verify the integrity of
each chunk.=A1=B1

13, There is considerable reference and comparison to the Bitorrent
system/model in the Tribler=A1=AFs subsection, one may wonder why not pose =
a
separate section for introduction of Bittorrent instead?

14, It is noticeable that both the Tribler=A1=AFs peer selection algorithm =
and
security mechanisms are elaborated in such a detailed way? What about other
systems in terms of similar design issues? Since Section 3 is focus mainly
on the peer topology, maybe separate sections on algorithm/security are
more natural for better compression.

15, In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1=
=B0the client
use UDP to transfer the encrypted media streaming and not RTP/ RTCP.=A1=B1?

16, In Section 3.3.1, =A1=B0Parent re-selection is also applied in case of
leaving of the previous parent.=A1=B1 Is better to be changed into =A1=B0Pa=
rent
re-selection is also triggered for a peer when its previous parent leaves.=
=A1=B1
17, From the description in Section 3.3.1, it is not clear to me why the
QQLive=A1=AFs topology is a hybrid of mesh and tree.
BR
Lingli

--=20
=B5=CB=C1=E9=C0=F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc=
h Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--047d7b339df9926ec404ec4023e9
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=
=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">Hi Yun=
fei and all,</font></span></p>
<div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">&nbsp;=
</font></span></p>
<div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">I have=
 the following comments about the current survey
draft:</font></span></p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=
=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">&nbsp;=
</font></span></p>
<div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">1, it =
states as a &quot;standard track&quot; document,
is that accurate?</font></span></p><div><font color=3D"#000000" size=3D"3" =
face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">2, in =
terminoloy section, &quot;push&quot; is defined
as &quot;Transmission of multimedia content without any request from receiv=
ing
peers.&quot;, which I think could be better described as &quot;Transmission=
 of
multimedia content that is not initiated by receiving peers.&quot;</font></=
span></p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">3, In =
section 3, &quot;the topology that can be
associated with overlay<br>
connections among peers&quot; could be rephrased into &quot;the topology of
overlay connections among peers&quot;.<br>
4, Also in section 3, &quot;pull-based data delivery calls for large size b=
uffers
where to store chunks&quot; could be rephrased into &quot;pull-based data
delivery calls for large size buffers to store chunks&quot;.</font></span><=
/p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">5, &qu=
ot;buffer-maps&quot; are used to refer to
&quot;chunk availability information&quot; (as used by RFC 6972). For sake =
of
consistency, I think it is better to use the latter instead.</font></span><=
/p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">6, In =
Section 3.2.1 &ldquo;channel server, that provides the
list of available channels (live TV or VoD content) to a PPLive, as soon as=
 the
peer joins the system;&rdquo; should be &ldquo;channel server, that provide=
s the list of
available channels (live TV or VoD content) to a PPLive peer, as soon as th=
e
peer joins the system;&rdquo;</font></span></p><div><font color=3D"#000000"=
 size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">7, It =
seems to me that the content server may have
played some sort of tracker&rsquo;s role in Octoshape, otherwise, how would=
 a joining
peer gets to know the initial address book of other peers?</font></span></p=
><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">8, In =
Section 3.2.3, &ldquo;a mechanism very similar to the
one of TCP congestion window (double increase or linear increase depending =
on
whether the estimate is below or a given threshold)&rdquo;, should be like =
&ldquo;a
mechanism very similar to the one of TCP congestion window (double increase=
 or
linear increase depending on whether the estimate is below or above a given
threshold)&rdquo;</font></span></p><div><font color=3D"#000000" size=3D"3" =
face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">9, One=
 may be curious about what is the difference
between a &ldquo;repeater node&rdquo; and a &ldquo;simple peer&rdquo;, as t=
he description of a &ldquo;repeater
node&rdquo; goes like &ldquo;Repeater nodes, that serve as bandwidth multip=
lier, are able
to forward any sub-stream and implement the same peer protocol as simple pe=
ers.&rdquo;</font></span></p><div><font color=3D"#000000" size=3D"3" face=
=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">10, In=
 Section 3.2.4, &ldquo;a PPStream peer selects peers
to download sub-chunks from according to a rate-based algorithm&rdquo; shou=
ld be
change into &ldquo;a PPStream peer selects peers to download sub-chunks acc=
ording to
a rate-based algorithm&rdquo;<br clear=3D"all">
11, In Section 3.1.5, &ldquo;As already said, Tribler supports video stream=
ing in two
different forms: video on demand and live streaming.&rdquo; Is better to be=
 changed
into &ldquo;Tribler supports video streaming in two different forms: video =
on demand
and live streaming.&rdquo;, since there is no prior statement in the draft.=
</font></span></p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=
=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">12, Al=
so in Section 3.1.5, &ldquo;Such
a mechanism allows Tribler<span> </span>peers to use
the public key included in torrent file and verity the integrity of each ch=
unk.&rdquo;
should be changed into &ldquo;Such a mechanism allows Tribler peers to use =
the public
key included in torrent file and verify the integrity of each chunk.&rdquo;=
</font></span></p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=
=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">13, Th=
ere is considerable
reference and comparison to the Bitorrent system/model in the Tribler&rsquo=
;s
subsection, one may wonder why not pose a separate section for introduction=
 of
Bittorrent instead? </font></span></p><div><font color=3D"#000000" size=3D"=
3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">14, It=
 is noticeable that both
the Tribler&rsquo;s peer selection algorithm and security mechanisms are el=
aborated
in such a detailed way? What about other systems in terms of similar design
issues? Since Section 3 is focus mainly on the peer topology, maybe separat=
e
sections on algorithm/security are more natural for better compression.</fo=
nt></span></p><div><font color=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5"=
>

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">15, In=
 Section 3.1.6, what does
it mean by &ldquo;not RTP/RTCP&rdquo; in &ldquo;the client use UDP to trans=
fer the encrypted
media streaming and not RTP/ RTCP.&rdquo;?</font></span></p><div><font colo=
r=3D"#000000" size=3D"3" face=3D"=CB=CE=CC=E5">

</font></div><p style=3D"margin:0cm 0cm 0pt;text-align:left" class=3D"MsoNo=
rmal" align=3D"left"><span style=3D"font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">16, In=
 Section 3.3.1, &ldquo;Parent
re-selection is also applied in case of leaving of the previous parent.&rdq=
uo; Is better
to be changed into &ldquo;Parent re-selection is also triggered for a peer =
when its
previous parent leaves.&rdquo;</font></span></p><div><font color=3D"#000000=
" size=3D"3" face=3D"=CB=CE=CC=E5">

</font><span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;=
font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">17, From the descrip=
tion in
Section 3.3.1, it is not clear to me why the QQLive&rsquo;s topology is a h=
ybrid of
mesh and tree.<br>
BR</font></span></div><div><span style=3D"font-family:&quot;Arial&quot;,&qu=
ot;sans-serif&quot;;font-size:12pt" lang=3D"EN-US"><font color=3D"#000000">=
Lingli<br>
</font></span><br>-- <br>=B5=CB=C1=E9=C0=F2/Lingli Deng<br>=D6=D0=B9=FA=D2=
=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Research Institute<br>=
e-mail: <a href=3D"mailto:denglingli@chinamobile.com" target=3D"_blank">den=
glingli@chinamobile.com</a><br>tel: 15801696688-3367<br>mobile: 13810597148=
<br>


</div></div>

--047d7b339df9926ec404ec4023e9--

From rachel.huang@huawei.com  Thu Nov 28 17:07:27 2013
Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76CC1AE06A for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 17:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6qpsRqjxR-q for <ppsp@ietfa.amsl.com>; Thu, 28 Nov 2013 17:07:24 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 066281ADFE1 for <ppsp@ietf.org>; Thu, 28 Nov 2013 17:07:22 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYK76680; Fri, 29 Nov 2013 01:07:20 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Nov 2013 01:06:43 +0000
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Nov 2013 01:07:18 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 09:07:12 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: yunfei zhang <hishigh@gmail.com>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] WGLC for the survey draft
Thread-Index: AQHO6qgU23QibfvjxUWMjwZIWxFpfJo6LCcwgAE6AJA=
Date: Fri, 29 Nov 2013 01:07:12 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB45907A92@nkgeml501-mbs.china.huawei.com>
References: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com> <51E6A56BD6A85142B9D172C87FC3ABBB459068EB@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB459068EB@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.94]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB45907A92nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 29 Nov 2013 01:07:28 -0000

--_000_51E6A56BD6A85142B9D172C87FC3ABBB45907A92nkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

T25lIG1vcmUgY29tbWVudDoNCg0KSXShr3MgYmV0dGVyIHRvIGFkanVzdCB0aGUgb3JkZXIgb2Yg
dHlwZXMgb2YgUDJQIHN0cmVhbWluZyBhcHBsaWNhdGlvbnMgdG8gYmUgY29uc2lzdGVudCB3aXRo
IHRoZSBvcmRlciBvZiBzdWJzZWN0aW9ucywgd2hpY2ggbWVhbnMgobBtZXNoLWJhc2VkobEgc2hv
dWxkIGJlIGZpcnN0LCB0aGVuIKGwdHJlZS1iYXNlZKGxLg0KDQpCZXN0IHJlZ2FyZHMsDQpSYWNo
ZWwNCg0KRnJvbTogcHBzcCBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIEh1YW5neWlob25nIChSYWNoZWwpDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjgsIDIw
MTMgMjoyNiBQTQ0KVG86IHl1bmZlaSB6aGFuZzsgcHBzcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtwcHNwXSBXR0xDIGZvciB0aGUgc3VydmV5IGRyYWZ0DQoNCkhpLA0KDQpJIGhhdmUgcmV2aWV3
ZWQgdGhpcyBkcmFmdHMsIGFuZCBoYXZlIGZvbGxvd2luZyBjb21tZW50czoNCg0KDQoxLiAgICAg
ICBUaGUgZGVzY3JpcHRpb24gaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMSBpcyBp
bmNvbnNpc3RlbnQgd2l0aCB0aGUgb3JnYW5pemF0aW9uIG9mIGNoYXB0ZXJzIC4gVGhpcyBzaG91
bGQgYmUgZml4ZWQuDQoNCjIuICAgICAgIEluIHNlY3Rpb24gMiwgc29tZSB0ZXJtaW5vbG9naWVz
IGhhdmUgYWxyZWFkeSBkZWZpbmVkIGluIFJGQzY5NzIuIEl0oa9zIHVubmVjZXNzYXJ5IHRvIHJl
cGVhdCB0aGUgZGVmaW5pdGlvbiwgZS5nLiwgY2h1bmssIGxpdmUgc3RyZWFtaW5noa0NCg0KMy4g
ICAgICAgU2VjdGlvbiAxIHR5cG86IKGwd2UgYWx3YXlzIHRyeSB0byBpZGVudGl0eSB0cmFja2Vy
IGFuZCBwZWVyIHByb3RvY29sc6GxIHNob3VsZCBiZSChsHdlIGFsd2F5cyB0cnkgdG8gaWRlbnRp
ZnkgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbHOhsQ0KDQo0LiAgICAgICBTZWN0aW9uIDMuMSwg
dHlwbyChsHRoaXMgbWF5IHR1cm4gYXQgZW5kIHVzZXJzIGludG8gcGxheWJhY2sgcXVhbGl0eSBk
ZWdyYWRhdGlvbqGxIHNob3VsZCBiZSChsHRoaXMgbWF5IHR1cm4gZW5kIHVzZXJzIGludG8gcGxh
eWJhY2sgcXVhbGl0eSBkZWdyYWRhdGlvbqGxDQoNCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoN
CkZyb206IHBwc3AgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB5
dW5mZWkgemhhbmcNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI2LCAyMDEzIDk6MDUgUE0NClRv
OiBwcHNwQGlldGYub3JnDQpTdWJqZWN0OiBbcHBzcF0gV0dMQyBmb3IgdGhlIHN1cnZleSBkcmFm
dA0KDQoNCkhpIGFsbCwNCiAgICBBY2NvcmRpbmcgdG8gdGhlIGNvbnNlbnN1cyBvZiBsYXN0IElF
VEYsIHdlJ2xsIHN0YXJ0IGEgc2Vjb25kIHJvdW5kIG9mIFdHTEMgZm9yIHRoZSBzdXJ2ZXkgZHJh
ZnQ6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcHBzcC1zdXJ2
ZXkvDQogICAgVGhlIFdHTEMgd2lsbCBsYXN0IGZvciAyIHdlZWtzIGJlZm9yZSBzdWJtaXR0aW5n
IGZvciBuZXh0IHN0ZXAgb2Ygc3RhbmRhcmRpemF0aW9uLg0KICAgICBZb3VyIHJldmlldyBhcmUg
aGlnaGx5IGFwcHJlY2lhdGVkLiBQbGVhc2Ugbm90ZSB0aGF0IHlvdXIgY29tbWVudHMgYW5kIHN1
Z2dlc3Rpb25zIGFyZSB2ZXJ5IGltcG9ydGFudCBmb3IgdGhlIGZvcm1pbmcgb2YgdGhlIFJGQyBh
cyB3ZWxsIGFzIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgV0cuIFRoYW5rcy4NCg0KQlINCll1bmZl
aQ0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBab25nbmlu
ZyA8em9uZ25pbmdAaHVhd2VpLmNvbTxtYWlsdG86em9uZ25pbmdAaHVhd2VpLmNvbT4+DQpEYXRl
OiAyMDEzLzExLzI1DQpTdWJqZWN0OiBbcHBzcF0gTWVldGluZyBtaW51dGVzDQpUbzogInBwc3BA
aWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5vcmc+IiA8cHBzcEBpZXRmLm9yZzxtYWlsdG86cHBz
cEBpZXRmLm9yZz4+DQpIaSwgRm9sa3MsDQoNClNvcnJ5IGZvciB0aGUgYmVsYXRlZCBtaW51dGVz
IGFuZCB0aGFua3MgUm9uaSBmb3IgdGFraW5nIHRoZSBub3Rlcy4gUGxlYXNlIHNlZSBiZWxvdyBh
bmQgbGV0IHVzIGtub3cgYW55IGNvcnJlY3RzIG5lZWRlZC4NCg0KPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClBQU1AgU2Vzc2lvbkBJ
RVRGIDg4DQoNClBsYXphIEMsVHVlc2RheSBBZnRlcm5vb24gU2Vzc2lvbiBJSUksIE5vdiA1LCAy
MDEzDQoNCg0KDQoxNjoxMCBBZ2VuZGEgYmFzaGluZyAoQ2hhaXJzLCA1IG1pbnV0ZXMpDQoNCk5v
IGNvbW1lbnRzDQoNCg0KDQoxNjoxNSBTdGF0dXMgb2YgdGhlIFdHIChDaGFpcnMsIDEwIG1pbnV0
ZXMpDQoNCjEpICBQZWVyIGRyYWZ0IKhDIG1vcmUgcmV2aWV3IG5lZWRlZCwgZXNwZWNpYWxseSBv
biBzZWN1cml0eSBhbmQgZW5jb2RpbmcgcGVyc3BlY3RpdmVzLg0KDQoyKSAgVHJhY2tlciBiYXNl
IGRyYWZ0IKhDIG5lZWQgYXV0aG9yIHRlYW0gdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IGZhc3Rlciwg
bW9yZSBjYWxscyBhcmUgbmVlZGVkLg0KDQozo6lTdXJ2ZXkgZHJhZnQgqEMgbmVlZCAybmQgV0dM
QyBiZWZvcmUgc3VibWl0dGluZyB0byBJRVNHLg0KDQoNCg0KMTY6MjUgUGVlciBQcm90b2NvbCAo
QXJubyByZW1vdGVseSw1MCBtaW51dGVzKSwgZHJhZnQtaWV0Zi1wcHNwLXBlZXItcHJvdG9jb2wt
MDgNCg0KMSkgIE5ldyByZXZpc2lvbiBoYXMgYWRkcmVzc2VkIGFsbCBjb21tZW50cyBmcm9tIEFE
IHJldmlldy4NCg0KMikgIFNvbWUgY29tbWVudHMgZnJvbSBSb25pIG5lZWQgdG8gYmUgYWRkcmVz
c2VkLCBlLmcuIGlmIHBlZXIgcHJvdG9jb2wgbmVlZCB0byBkZWZpbmUgaG93IHRvIGRvIE5BVCB0
cmF2ZXJzYWwuIFRvIGJlIGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4NCg0KMykgIENodW5rIHNpemUg
aXNzdWUgZnJvbSBZdW5mZWk/DQo0KSAgQ2h1bmsgYWRkcmVzc2luZyBpc3N1ZSCoQyBuZWdvdGlh
dGlvbiBpcyBiZXR0ZXIuDQpMaW5nbGk6IGluIHRoZSBsYXRlc3QgdmVyc2lvbiwgdGhlIHBhcnQg
Zm9yIG9ubGluZSB0cmFuc2xhdGlvbiBiZXR3ZWVuIGNvbW11bmljYXRpbmcgcGVlcnMgdXNpbmcg
ZGlmZmVyZW50IGNodW5rIGFkZHJlc3Npbmcgc2NoZW1lcyBhcmUgcmVtb3ZlZC4gV2h5Pw0KQTog
SXQgaXMgdG9vIGNvbXBsaWNhdGVkIGFuZCBub3QgbmVjZXNzYXJ5Lg0KDQoNCjE3OjE1IFRyYWNr
ZXIgUHJvdG9jb2wgKFJ1aSByZW1vdGVseSwgNTAgbWludXRlcyksIGRyYWZ0LWlldGYtcHBzcC1i
YXNlLXRyYWNrZXItcHJvdG9jb2wtMDINCg0KMSkgIEluIHRoZSBkcmFmdCwgc3RpbGwgWE1MIGZv
cm1hdCBpbiBtYWluIGJvZHkuIE5lZWQgdG8gbW92ZSBYTUwgZXhhbXBsZSB0byBhcHBlbmRpeCB3
aXRoIG1vcmUgcmVmZXJlbmNlcy4NCll1bmZlaTogVGhlIG5ldyB2ZXJzaW9uIGRvZXNuoa90IHJl
ZmxlY3QgdGhlIGNvbnNlbnN1cyBtYWRlIGluIHRoZSBsYXN0IG1lZXRpbmcsIHdoaWNoIGlzIHRv
IG1vdmUgdGhlIGVuY29kaW5nIGlzc3VlcyB0byB0aGUgYXBwZW5kaXggd2hpbGUga2VlcCB0aGUg
bWFpbiBib2R5IHRvIGp1c3QgZGVmaW5lIG1lc3NhZ2VzLiBDdXJyZW50bHkgdGhlIG1lc3NhZ2Vz
IGFyZSBzdGlsbCB0ZXh0IGJhc2VkLiBJcyB0aGVyZSBhbnkgY29uc2lkZXJhdGlvbiBvbiB0aGUg
c2l0dWF0aW9uIHdoZXJlIGRpZmZlcmVudCBlbmNvZGluZ3MgYXJlIHVzZWQ/IEUuZy4sIHNvbWUg
cGVlcnMgdXNlIHRleHQgZW5jb2Rpbmcgd2hpbGUgb3RoZXJzIHVzZSBiaW5hcnkuDQpMaW5nbGk6
IFRoZXJlIGlzIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIGJldHdlZW4gUnVpIGFuZCB0aGUgb3Ro
ZXIgY28tYXV0aG9ycy4gQnkgYmluYXJ5IGVuY29kaW5nLCBSdWkgdGhpbmtzIGl0oa9zIHRoZSBi
aW5hcnkgZW5jb2Rpbmcgb2YgdGhlIFhNTCwgd2hpbGUgb3RoZXJzIHRoaW5rIGl0oa9zIHRoZSBi
aW5hcnkgZW5jb2Rpbmcgb2YgdGhlIHRyYWNrZXIgcHJvdG9jb2wuIFRoZXJlIGFyZSBzdGFuZGFy
ZHMgZnJvbSBJU08gZm9yIGJpbmFyeSBlbmNvZGluZyBvZiBYTUwsIHdoaWNoIGlzIEVYSS4NCll1
bmZlaTogQnV0IEVYSSBjYW6hr3QgZG8gdGhlIHRyYW5zbGF0aW9uIGJldHdlZW4gYmluYXJ5IGVu
Y29kaW5nIG9mIHRoZSBtZXNzYWdlcyB0byBYTUwgb2YgdGhlIG1lc3NhZ2VzLg0KTGluZ2xpOiBX
ZWJzb2NrZXQgaGFzIHNpbWlsYXIgbWVjaGFuaXNtcyB0byBkbyB0aGlzIGtpbmQgb2YgdHJhbnNs
YXRpb24uIFdlIGNhbiByZWZlcmVuY2UgaXQuIEkgY2FuIGhlbHAgd2l0aCB0aGUgbmV3IHZlcnNp
b24uDQoNCg0KDQoxODowNSBFZmZpY2llbnQgQ2h1bmsgQXZhaWxhYmlsaXR5IENvbXByZXNzaW9u
IChMaW5nbGksMjAgbWludXRlcyksIGRyYWZ0LWRlbmctcHBzcC1iZmJpdG1hcC0wMw0KDQpBcm5v
OiBpbiByZWFsaXR5LCBzdHJlYW1pbmcgZG93bmxvYWRpbmcgaGFwcGVucyBzZXF1ZW50aWFsbHks
IGhlbmNlIHNjb3BlLWJhc2VkIHNjaGVtZXMgd29ya3Mgd2VsbC4NCg0KQTogaW4gVm9EIGNhc2Vz
LCB1c2VyIGJlaGF2aW9yIGNhbiBpbnRlcnJ1cHQgdGhlIHNlcXVlbnRpYWwgdmlld2luZyBwYXR0
ZXJuLiBBbmQgZXZlbiBpbiBsaXZlIHN0cmVhbWluZyBjYXNlLCBiZWNhdXNlIHRoZSBjb25jdXJy
ZW50bHkgcGVlci10by1wZWVyIGRvd25sb2FkaW5nIHBhdHRlcm4sIG91dC1vZi1vcmRlciBjaHVu
ayB0cmFuc21pc3Npb24gaXMgaW5ldml0YWJsZS4NCg0KRGF2ZTogd2hhdCBpcyB0aGUgb2JqZWN0
aXZlIG9mIGludHJvZHVjaW5nIEJGIHNjaGVtZT8NCg0KQTogdGhlIG1vdGl2ZSBpcyBlbGFib3Jh
dGVkIGluIHRoZSBsYXN0IG1lZXRpbmehr3MgcHJlc2VudGF0aW9uLiBUaGVyZSBpcyBhbiBjb21w
YXJpc29uIG9mIHRoZSB3b3JzdCBjYXNlIHBlcmZvcm1hbmNlIG9mIGRpZmZlcmVudCBiaXRtYXAg
Y29tcHJlc3Npb24gc2NoZW1lcyBpbiB0ZXJtcyBvZiB2YXJpb3VzIGJpdG1hcCByZWxldmFudCBv
cGVyYXRpb25zIGluIFBQU1AuDQoNCkFybm86IGluIHBlZXIgcHJvdG9jb2wsIHBlZXJzIGRvbqGv
dCBzaGFyZSBiaXRtYXBzLCBvbmx5IGNodW5rIHJhbmdlcyB1cGRhdGVzIGFyZSBleGNoYW5nZWQu
IFBlZXIgcHJvdG9jb2wgZG9lc26hr3QgbmVlZCBiaXRtYXAgY29tcHJlc3Npb24uDQoNCkE6IHJh
bmdlcyBvciB1cGRhdGVzIGFyZSBzcGVjaWFsIGZvcm1zIG9mIGNvbXByZXNzaW9uLiBCRiBzY2hl
bWUgY2FuIGJlIGludHJvZHVjZWQgaW50byBwZWVyIHByb3RvY29sIGFzIGEgbmV3IGNodW5rIGFk
ZHJlc3NpbmcgbWV0aG9kLg0KDQoNCg0Kb3BlbiBpc3N1ZSAxIKhDIGxvb2tzIGxpa2UgdGhlIHBy
b3Bvc2VkIG9wdGlvbiBpcyBiZXR0ZXIgbm8gbmVlZCB0byB0cmFuc2xhdGlvbg0KDQpPcGVuIGlz
c3VlIDIgqEMgbG9va3MgbGlrZSBpdCBpcyBoZWxwZnVsIHRvIGluY2x1ZGUgY29udGVudCBzY29w
ZSBpbnRvIHJlcXVlc3RzLCBidXQgbm90IHRvIHRoZSByZXNwb25zZXMuDQoNCk5vIGFkb3B0aW9u
IGF0IHRoZSBtb21lbnQuIE5lZWQgbW9yZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBhbmQgb2Zm
bGluZSB3aXRoIHRoZSB0cmFja2VyIHByb3RvY29sIGF1dGhvci4NCg0KDQoNClJhY2hlbDogaW4g
ZXh0ZW5kZWQgdHJhY2tlciBwcm90b2NvbCwgdGhlIGNvbnRlbnQgc2NvcGUgaW5mb3JtYXRpb24g
aXMgYWxyZWFkeSBpbmNvcnBvcmF0ZWQgaW4gdGhlIHJlcXVlc3RzLiBCdXQgaWYgd2UgaW5jb3Jw
b3JhdGUgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW50byB0aGUgcmVzcG9uc2VzLCBpdCB3b3VsZCBi
ZSBkdXBsaWNhdGVkIHdpdGggdGhlIHN1YnNlcXVlbnQgcGVlciBpbmZvcm1hdGlvbiBoYW5kc2hh
a2luZy4NCg0KTmluZzogV291bGQgaXQgYmUgcG9zc2libGUgdG8gaW5jcmVhc2UgbmVpZ2hib3Jo
b29kIGVzdGFibGlzaG1lbnQgYnkgYWx3YXlzIGluY2x1ZGluZyBTRUVERVIgcGVlcnMgaW4gcmVz
cG9uc2U/DQoNCkE6IEkgdGhpbmsgaXQgbWFrZSBzZW5zZSB0byBkbyBzbyB0byBlbnN1cmUgRklO
RCBhbHdheXMgaGl0LCBhcyBsb25nIGFzIHRoZSBzcGVjaWZpYyBjb250ZW50IHJhbmdlIGluIG5l
ZWQgaXMgaW5jb3Jwb3JhdGVkIGluIGNvcnJlc3BvbmRpbmcgcmVxdWVzdHMuDQoNCg0KDQoxODoy
NSBDb25jbHVzaW9uIGFuZCBuZXh0IHN0ZXAgKENoYWlycywgMTAgbWludXRlcykNCg0KUGVlciBk
cmFmdCBuZWVkcyBtb3JlIHJldmlldy4gVHJhY2tlciBiYXNlIGRyYWZ0IG5lZWRzIGNhbGwgYmV0
d2VlbiBjby1hdXRob3JzIHRvIHByb2dyZXNzIHRoZSBkcmFmdCBmYXN0ZXIuIDJuZCBXR0xDIG9u
IHN1cnZleSBkcmFmdCBzdGFydHMgc29vbi4NCg0KDQoNCjE4OjM1IEVuZA0KDQo9PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KVGhhbmtzLA0KDQot
WXVuZmVpICYgTmluZy4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnPG1haWx0bzpw
cHNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw
DQoNCg==

--_000_51E6A56BD6A85142B9D172C87FC3ABBB45907A92nkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.HTMLChar
	{mso-style-name:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD";
	font-family:Consolas;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:684138747;
	mso-list-type:hybrid;
	mso-list-template-ids:-114667742 67698703 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">One more comment:<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It=A1=AFs better to adjus=
t the order of types of P2P streaming applications to be consistent with th=
e order of subsections, which means =A1=B0mesh-based=A1=B1 should be first,
 then =A1=B0tree-based=A1=B1.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Rachel<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ppsp [ma=
ilto:ppsp-bounces@ietf.org]
<b>On Behalf Of </b>Huangyihong (Rachel)<br>
<b>Sent:</b> Thursday, November 28, 2013 2:26 PM<br>
<b>To:</b> yunfei zhang; ppsp@ietf.org<br>
<b>Subject:</b> Re: [ppsp] WGLC for the survey draft<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I have reviewed this draf=
ts, and have following comments:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The description i=
n the last paragraph of Section 1 is inconsistent with the organization of =
chapters . This should be fixed.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In section 2, som=
e terminologies have already defined in RFC6972. It=A1=AFs unnecessary to r=
epeat the definition, e.g., chunk, live streaming=A1=AD<o:p></o:p></span></=
p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Section 1 typo: =
=A1=B0we always try to identity tracker and peer protocols=A1=B1 should be =
=A1=B0we always try to identify tracker and peer protocols=A1=B1<o:p></o:p>=
</span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso=
-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Section 3.1, typo=
 =A1=B0this may turn at end users into playback quality degradation=A1=B1 s=
hould be =A1=B0this may turn end users into playback quality degradation=A1=
=B1<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog=
raph"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">Rachel<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> ppsp [ma=
ilto:ppsp-bounces@ietf.org]
<b>On Behalf Of </b>yunfei zhang<br>
<b>Sent:</b> Tuesday, November 26, 2013 9:05 PM<br>
<b>To:</b> ppsp@ietf.org<br>
<b>Subject:</b> [ppsp] WGLC for the survey draft<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class=3D"MsoNormal"><br>
Hi all,<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; According to the&nbsp;consensus o=
f last IETF, we'll start a second round of WGLC for the survey draft:<o:p><=
/o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://datatracker.ietf.org/doc/draft-iet=
f-ppsp-survey/">http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/</a>=
<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; The WGLC will last for 2 weeks be=
fore submitting for next step of standardization.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; Your review&nbsp;are highly=
 appreciated. Please note that your comments and suggestions are very impor=
tant for the forming of the RFC as well as the development of the WG. Thank=
s.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">BR<br>
Yunfei<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Zongning</b> &lt;<a href=3D"mailto:zongning@huawei.com">zongning@h=
uawei.com</a>&gt;<br>
Date: 2013/11/25<br>
Subject: [ppsp] Meeting minutes<br>
To: &quot;<a href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&quot; &lt;<a h=
ref=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a>&gt;<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Hi, Folks,</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Sorry for the belated minutes and=
 thanks Roni for taking the notes. Please see below and let us know any cor=
rects needed.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span=
><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">PPSP Session@IETF 88&nbsp;</span>=
<o:p></o:p></p>
<pre><span style=3D"font-size:13.5pt">Plaza C,Tuesday Afternoon Session III=
, Nov 5, 2013</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:10 Agenda bashing (Chairs, 5 minut=
es)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">No comments</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:15 Status of the WG (Chairs, 10 mi=
nutes)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Peer draft <span lang=3D"ZH-CN">=A8C</span> more review needed, especiall=
y on security and encoding perspectives.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">2)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Tracker base draft <span lang=3D"ZH-CN">=A8C</span> need author team to p=
rogress the draft faster, more calls are needed.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">3<span lang=3D"ZH-CN">=
=A3=A9</span>Survey draft <span lang=3D"ZH-CN">=A8C</span> need 2<sup>nd</s=
up> WGLC before submitting to IESG.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">16:25 Peer Protocol (Arno remotely,50=
 minutes)</span>, <span style=3D"font-size:13.5pt">draft-ietf-ppsp-peer-pro=
tocol-08</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">New revision has addressed all comments from AD review.</span><o:p></o:p>=
</pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">2)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt">Some comment=
s from Roni need to be addressed, e.g. if peer protocol need to define how =
to do NAT traversal<span style=3D"color:#1F497D">.</span> <span style=3D"co=
lor:#1F497D">T</span>o be discussed on the list<span style=3D"color:#1F497D=
">.</span></span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">3)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">Chunk size issue from Yunfei?</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">4)</span><span styl=
e=3D"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&q=
uot;;color:#1F497D">&nbsp;
</span><span style=3D"font-size:13.5pt">Chunk addressing issue <span lang=
=3D"ZH-CN">=A8C</span> negotiation is better.
</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: in the late=
st version, the part for online translation between communicating peers usi=
ng different chunk addressing schemes
 are removed. Why?</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">A: It is too compli=
cated and not necessary.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<pre><span style=3D"font-size:13.5pt">17:15 Tracker Protocol (Rui remotely,=
 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02&nbsp; </span><o:p></=
o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">1)</span><span style=3D=
"font-size:13.5pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;=
;color:#1F497D">&nbsp; </span><span style=3D"font-size:13.5pt;color:#1F497D=
">In the draft, still XML format in main body. Need to move XML example to =
appendix with more references.</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Yunfei: The new ver=
sion doesn<span lang=3D"ZH-CN">=A1=AF</span>t reflect the consensus made in=
 the last meeting, which is to move the encoding
 issues to the appendix while keep the main body to just define messages. C=
urrently the messages are still text based. Is there any consideration on t=
he situation where different encodings are used? E.g., some peers use text =
encoding while others use binary.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: There is di=
fferent understanding between Rui and the other co-authors. By binary encod=
ing, Rui thinks it<span lang=3D"ZH-CN">=A1=AF</span>s
 the binary encoding of the XML, while others think it<span lang=3D"ZH-CN">=
=A1=AF</span>s the binary encoding of the tracker protocol. There are stand=
ards from ISO for binary encoding of XML, which is EXI.</span><o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Yunfei: But EXI can=
<span lang=3D"ZH-CN">=A1=AF</span>t do the translation between binary encod=
ing of the messages to XML of the messages.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt;color:#1F497D">Lingli: Websocket h=
as similar mechanisms to do this kind of translation. We can reference it. =
I can help with the new version.</span><o:p></o:p></p>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">18:05 Efficient Chunk Availability Co=
mpression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03</span><o:p></o:p=
></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Arno: in reality, strea=
ming downloading happens sequentially, hence scope-based schemes works well=
.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: in VoD cases, user b=
ehavior can interrupt the sequential viewing pattern. And even in live stre=
aming case, because the concurrently peer-to-peer downloading pattern, out-=
of-order chunk transmission is inevitable.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Dave: what is the objec=
tive of introducing BF scheme?</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: the motive is elabor=
ated in the last meeting<span lang=3D"ZH-CN">=A1=AF</span>s presentation. T=
here is an comparison of the worst case performance of different bitmap com=
pression schemes in terms of various bitmap relevant operations in PPSP.</s=
pan><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Arno: in peer protocol,=
 peers don<span lang=3D"ZH-CN">=A1=AF</span>t share bitmaps, only chunk ran=
ges updates are exchanged. Peer protocol doesn<span lang=3D"ZH-CN">=A1=AF</=
span>t need bitmap compression.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: ranges or updates ar=
e special forms of compression. BF scheme can be introduced into peer proto=
col as a new chunk addressing method.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">open issue 1 <span lang=3D"ZH-CN">=A8=
C</span> looks like the proposed option is better no need to translation</s=
pan><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Open issue 2 <span lang=
=3D"ZH-CN">=A8C</span> looks like it is helpful to include content scope in=
to requests, but not to the responses.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">No adoption at the moment. Need more =
mailing list discussion and offline with the tracker protocol author.</span=
><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Rachel: in extended tra=
cker protocol, the content scope information is already incorporated in the=
 requests. But if we incorporate the same information into the responses, i=
t would be duplicated with the subsequent peer information handshaking.</sp=
an><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Ning: Would it be possi=
ble to increase neighborhood establishment by always including SEEDER peers=
 in response?</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">A: I think it make sens=
e to do so to ensure FIND always hit, as long as the specific content range=
 in need is incorporated in corresponding requests.</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">&nbsp;</span><o:p></o:p=
></pre>
<pre><span style=3D"font-size:13.5pt">18:25 Conclusion and next step (Chair=
s, 10 minutes)</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt;color:#1F497D">Peer draft needs more r=
eview.</span><span style=3D"font-size:13.5pt;font-family:&quot;Times New Ro=
man&quot;,&quot;serif&quot;;color:#1F497D"> </span><span style=3D"font-size=
:13.5pt;color:#1F497D">Tracker base draft needs call between co-authors to =
progress the draft faster. 2<sup>nd</sup> WGLC on survey draft starts soon.=
</span><o:p></o:p></pre>
<pre>&nbsp;<o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">18:35 End</span><o:p></o:p></pre>
<pre><span style=3D"font-size:13.5pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><o:p></o:p></pre>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">Thanks,</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:13.5pt">-Yunfei &amp; Ning.</span><o:p></=
o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;">&nbsp;</span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
_______________________________________________<br>
ppsp mailing list<br>
<a href=3D"mailto:ppsp@ietf.org">ppsp@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ppsp" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/ppsp</a><o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_51E6A56BD6A85142B9D172C87FC3ABBB45907A92nkgeml501mbschi_--
