From Akbar.Rahman@InterDigital.com Tue Nov 2 10:45:55 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65543A69F9 for ; Tue, 2 Nov 2010 10:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_DOWNLD_SUB=0.85] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dEYH++Kti2S for ; Tue, 2 Nov 2010 10:45:54 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id DD6AD3A69F4 for ; Tue, 2 Nov 2010 10:45:50 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 13:45:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2010 13:45:54 -0400 Message-ID: In-Reply-To: <003801cb7637$ae5b50d0$3a298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) Thread-Index: Act12nsFtG/FRg5QSEuZnosJnKnvEAAAM7/gAAClSkAAATUcQAAU+VlgAR+9+mA= References: <003801cb7637$ae5b50d0$3a298a0a@china.huawei.com> From: "Rahman, Akbar" To: "Ning Zong" X-OriginalArrivalTime: 02 Nov 2010 17:45:54.0608 (UTC) FILETIME=[CC567B00:01CB7AB5] Cc: ppsp@ietf.org, Martin Stiemerling Subject: Re: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 17:45:55 -0000 Hi Ning, I think that is an excellent way to proceed. Thank you for considering my comments and I look forward to seeing you in Beijing. Sincerely, Akbar -----Original Message----- From: Ning Zong [mailto:zongning@huawei.com]=20 Sent: Wednesday, October 27, 2010 8:33 PM To: Rahman, Akbar; 'Martin Stiemerling' Cc: ppsp@ietf.org Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) Hi, Akbar and Martin Thank you very much for contributing to the requirement draft. My suggestion is that I will put these requirement changes to our presentation slides used on Beijing meeting so that we can get group consensus about how to incorporate the suggested text into PPSP requirement drafts. Although personally I agree with some of the changes, we need to get group consensus before adopting them into the WG draft, right? Sorry for the late response and, hope to see you all in Beijing. BR, Ning Zong -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Wednesday, October 27, 2010 10:28 PM To: Martin Stiemerling Cc: ppsp@ietf.org Subject: Re: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) Thanks, Martin. I will make your suggested changes for the battery status in the next revision of my draft. Or better yet, the PPSP Requirement draft will incorporate your and my suggestions for adding the mobility requirements into their WG draft (and I will no longer have to maintain my separate draft)! See you in Beijing. Akbar -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@neclab.eu]=20 Sent: Wednesday, October 27, 2010 9:53 AM To: Rahman, Akbar Cc: ppsp@ietf.org Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers and downloading bandwidth) Hi Akbar, Just browsed the points and I tend to agree with most points.=20 Mobility isn't covered at all in the requirements and not even reflected any of them. For the battery one - I guess it would make sense to say: Peers SHOULD be able to add specific parameters to their tracker request and to refine it in separate step to "this may include battery status information." Thanks, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Wednesday, October 27, 2010 3:35 PM > To: Martin Stiemerling > Cc: ppsp@ietf.org > Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers > and downloading bandwidth) >=20 > Hi Martin, >=20 >=20 > I agree with your comments. Also please note that I have previously > raised some other issues on the requirements for which I am still > waiting for some feedback on (see attached link) >=20 > http://www.ietf.org/mail-archive/web/ppsp/current/msg00720.html >=20 >=20 > Sincerely, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Wednesday, October 27, 2010 9:26 AM > To: ppsp@ietf.org > Subject: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers and > downloading bandwidth) >=20 > Hi, >=20 > A clarifying question to the requirements draft's PPSP.TP.REQ-4. It > says: > PPSP.TP.REQ-4: The tracker request message MAY include parameter of > requested number of downloading peers or preferred downloading > bandwidth. >=20 > First, wouldn't it be better to specify: > "The tracker request message SHOULD allow to include parameters set by > the peer to further refine the request." >=20 > I guess that this is the actual intention of the requirements. The next > requirements below would be a refinement of the above requirement or > examples: >=20 > Second, one more detailed requirement could be" > "The tracker request message SHOULD allow to include parameters which > denote the number of peers queried for." >=20 > Another requirement could be: > "The tracker request message SHOULD allow to include parameters which > denotes the minimum theoretical upload bandwidth of a peer." >=20 >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > _______________________________________________ > 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 zengw@huawei.com Tue Nov 2 21:37:57 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8785D3A6A5E for ; Tue, 2 Nov 2010 21:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PbgthB7EqJe for ; Tue, 2 Nov 2010 21:37:51 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 8B23B3A6A5A for ; Tue, 2 Nov 2010 21:37:47 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBA00G8CKV2D0@usaga03-in.huawei.com> for ppsp@ietf.org; Tue, 02 Nov 2010 23:37:50 -0500 (CDT) Received: from wenjunzeng (173-26-237-169.client.mchsi.com [173.26.237.169]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBA002X6KUPBA@usaga03-in.huawei.com> for ppsp@ietf.org; Tue, 02 Nov 2010 23:37:50 -0500 (CDT) Date: Tue, 02 Nov 2010 23:37:13 -0600 From: Kevin Zeng In-reply-to: <1287994843.2114.52.camel@bart3> To: 'Fabio Hecht' Message-id: <000001cb7b19$2bdeed60$839cc820$@com> Organization: Huawei MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Act0Hb1ccCx1SbeaRMaD+A6jmpbrywG+YKGA References: <000001cb717e$52b5b850$f82128f0$@com> <1287753459.2114.14.camel@bart3> <001a01cb723c$4e903930$ebb0ab90$@com> <1287994843.2114.52.camel@bart3> Cc: ppsp@ietf.org Subject: Re: [ppsp] FW: New Version Notification for draft-zeng-ppsp-protocol-pro-incentive-para-01 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: zengw@huawei.com List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 04:37:57 -0000 Dear Fabio, I agree that none of the current incentive mechanisms addresses all of the problems.=20 Personally, I feel it is difficult to have a generic protocol that can = address all the problems, and it is probably difficult to pick an = existing incentive mechanism and standardize it. But I do think it is = possible to identify the common parameters that are essential for most, = if not all, variations of the incentive mechanisms. We can standardize = the messaging protocol to support the exchange of those parameters, and = hopefully also leave room for future extension if necessary. How exactly = a particular incentive mechanism is going to use those parameters can be = left unspecified. I do believe the charter covers both live streaming and VoD. This should = be clear if you look at the requirement document. Best. -Kevin -----Original Message----- From: Fabio Hecht [mailto:hecht@ifi.uzh.ch]=20 Sent: Monday, October 25, 2010 3:21 AM To: zengw@huawei.com Cc: ppsp@ietf.org Subject: RE: [ppsp] FW: New Version Notification for = draft-zeng-ppsp-protocol-pro-incentive-para-01 On Fri, 2010-10-22 at 17:56 -0500, Kevin Zeng wrote: > Dear Fabio, >=20 > Thanks for your comments. Please see my response inline below, = starting with [Kevin]. >=20 > Best. >=20 > -Kevin >=20 > -----Original Message----- > From: Fabio Hecht [mailto:hecht@ifi.uzh.ch]=20 > Sent: Friday, October 22, 2010 8:18 AM > To: zengw@huawei.com > Cc: ppsp@ietf.org > Subject: Re: [ppsp] FW: New Version Notification for = draft-zeng-ppsp-protocol-pro-incentive-para-01 >=20 >=20 > >Dear Kevin, >=20 > >the introduction says "What makes this problem particularly difficult = is > >the unique set of challenges that P2P systems pose: large = populations, > >high turnover, asymmetry of interest, collusion, zero-cost = identities, > >and traitors [RobustIncentives]." Then, it goes on by proposing that = the > >peers themselves declare how well they are uploading. If they want to > >freeride, aren't they just going to lie about it? >=20 > [Kevin] Yes, peers in general are not necessarily trusted. Peer = contribution however is an important metric for deriving a robust = incentive-based system. There are probably different ways to measure = peer contribution. Self-reporting with corroborating evidence provided = by receiving peers may be one approach, in which case both = self-reporting of uploading and corroborating reporting of downloading = from other peers are necessary (the current draft proposes to have both = BytesUploaded and ByteDownloaded). Another approach, as suggested in = [Contracts], is to have the a reporting peer's BytesUploaded report = (like a receipt) signed by receiving peers (so technically speaking it = is not self-reporting any more). In BitTorrent, incentive is provided = through tit-for-tat, in which bilateral interaction is used. However, = tit-for-tat used in BitTorrent does not take into account the value of a = specific trunk to be traded or the value of a peer to trade with = measured at the swarm-level (vs simply bilateral). To address this = problem, other global parameters such as SeedNumber, PeerNumber, = ChunkCopies need to be conveyed to the peers to allow peers to have a = more global view in peer selection. Section 7 has some initial = discussion about trustworthiness and other security consideration.=20 I agree, my point being that none of the current incentive mechanisms addresses all of the problems cited above, i.e. if the peer self-reports he may be lying, and if another peer reports, it may well be a Sybil or colluding peer. Different mechanisms have been proposed but each one require their own set of messages and are not compatible with one another. The questions then are: is it possible to have a generic protocol? If not, what should be standardized? >=20 > >I also don't understand the meaning of "file". I thought PPSP was = doing > >live streaming, where the notion of file may not be clear. I imagine = a > >TV channel that has been broadcasting for years, the "total number of > >chunks of a file that a peer has" may need to be adapted accordingly. >=20 > [Kevin] If I understand correctly, ppsp addresses streaming of both = live and time-shifted content. For time-shifted content (e.g. VoD), file = (and the total # of chucks) makes sense. For live streaming or TV = channel, I agree that we need better definition. Maybe "file" is = associated with a program or sub-program. I agree that in live streaming = where the trading opportunity is more limited, a different approach, = e.g., based on global contribution measurement (e.g., through reporting = of peer's BytesUploaded to tracker or other peers), could be more = effective.=20 Maybe the charter should be clearer in what they mean by time-shifted content. Is it really VoD or just the ability of going back a short time period from the live stream? >=20 > >Regards >=20 > >Fabio >=20 >=20 > On Thu, 2010-10-21 at 19:16 -0500, Kevin Zeng wrote: > > Dear all, > >=20 > > A new version of draft-zeng-ppsp-protocol-pro-incentive-para-01 has = been submitted. It is accessible at = http://www.ietf.org/id/draft-zeng-ppsp-protocol-pro-incentive-para-01.txt= > >=20 > > This version incorporates a couple of more references, per = suggestion by Richard (Yang), and adds Section 4.1 and 4.2 that describe = suggested additions to the tracker protocol and peer protocol. In = addition, some discussion of security considerations have also been = added in Section 7.=20 > >=20 > > As incentive is an important part of the security requirements of a = P2P streaming system, we are looking forward to hearing additional = comments and suggestions. > >=20 > > Thanks. > >=20 > > -Kevin > >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > > Sent: Thursday, October 21, 2010 6:48 PM > > To: zengw@huawei.com > > Cc: guyingjie@huawei.com > > Subject: New Version Notification for = draft-zeng-ppsp-protocol-pro-incentive-para-01 > >=20 > >=20 > > A new version of I-D, = draft-zeng-ppsp-protocol-pro-incentive-para-01.txt has been successfully = submitted by Wenjun Zeng and posted to the IETF repository. > >=20 > > Filename: draft-zeng-ppsp-protocol-pro-incentive-para > > Revision: 01 > > Title: P2P Streaming Protocol Pro-incentive Parameters > > Creation_date: 2010-10-22 > > WG ID: Independent Submission > > Number_of_pages: 11 > >=20 > > Abstract: > > This document analyzes the common parameters that are essential for > > deriving incentive mechanisms to promote peer cooperation and system > > robustness in a P2P system, and proposes to incorporate these pro- > > incentive parameters in information exchanges in the P2P streaming > > protocols to be specified, e.g., in the tracker protocol proposed in > > [draft-gu-ppsp-tracker-protocol], and in the future in the peer > > protocol proposed in [draft-gu-ppsp-peer-protocol]. > > = =20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > ppsp mailing list > > ppsp@ietf.org > > https://www.ietf.org/mailman/listinfo/ppsp > >=20 >=20 --=20 Fabio Hecht University of Zurich - Department of Informatics (IfI) Binzm=C3=BChlestrasse 14 CH-8050 Z=C3=BCrich, Switzerland Ph.: +41 44 6357129 / 6350892 Fax: +41 44 6356809 VoIP sip:hecht@ifi.uzh.ch From wang.wei108@zte.com.cn Wed Nov 3 01:59:45 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7885A3A6866 for ; Wed, 3 Nov 2010 01:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYhYWrT38Xcq for ; Wed, 3 Nov 2010 01:59:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id EB23C3A68D0 for ; Wed, 3 Nov 2010 01:59:43 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595790912505; Wed, 3 Nov 2010 16:56:54 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 31724.3493788477; Wed, 3 Nov 2010 16:39:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oA38fRYm021642; Wed, 3 Nov 2010 16:41:28 +0800 (CST) (envelope-from wang.wei108@zte.com.cn) To: guyingjie@huawei.com, dbryan@ethernot.org MIME-Version: 1.0 X-KeepSent: 77E6B147:EE511671-482577D0:002AE6ED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.wei108@zte.com.cn Date: Wed, 3 Nov 2010 16:38:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-03 16:41:13, Serialize complete at 2010-11-03 16:41:13 Content-Type: multipart/alternative; boundary="=_alternative 002FB7E8482577D0_=" X-MAIL: mse2.zte.com.cn oA38fRYm021642 Cc: hao.zhenwu@zte.com.cn, "ppsp@ietf.org" Subject: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 08:59:45 -0000 This is a multipart message in MIME format. --=_alternative 002FB7E8482577D0_= Content-Type: text/plain; charset="US-ASCII" Hi all, In the latest draft of peer protocol and tracker protocol it is proposed that the peer list only contains Peer-ID, and RELOAD is used for peer location and NAT traversal: draft-gu-ppsp-peer-protocol-01:page 3-4 "The peer contacts the tracker to obtain a Peerlist containing a list of peers participating in the particular swarm the peer is interested in. ... * This list does not contain IP addresses, but rather RELOAD Peer-IDs." My concern about this design choice is that some related protocols, such as ALTO, implicitly assume that the IP address is used in the peerlist. If the tracker only records the Peer-ID, it will not be able to consult ALTO server using the RELOAD Peer-ID, which is specific to the overlay and possibly not known to the ALTO server maintained by the ISP. It would also quite difficult for the ALTO server to relate the Peer-ID to a network location. As ALTO aim to serve for similar applications as ppsp, we need to find out a way to use it for PPSP based systems. One solution would be asking the tracker to record both the IP address and the Peer ID. But, it would be strange not to return the IP address when it is already available in the tracker. Another way is to ask peers to consult the ALTO server after the ICE procedure. However, this solution brings much more overhead. Wang Wei ZTE Email: wang.wei108@zte.com -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002FB7E8482577D0_= Content-Type: text/html; charset="US-ASCII"
Hi all,

   In the latest draft of peer protocol and tracker protocol it is proposed that
the peer list only contains Peer-ID, and RELOAD is used for peer location and NAT
traversal:

draft-gu-ppsp-peer-protocol-01:page 3-4

"The peer contacts the tracker to obtain a Peerlist containing a
list of peers participating in the particular swarm the peer is
interested in.

...

* This list does not contain IP addresses, but rather RELOAD
Peer-IDs."


My concern about this design choice is that some related protocols, such as ALTO,
implicitly assume that the IP address is used in the peerlist. If the tracker
only records the Peer-ID, it will not be able to consult ALTO server using the
RELOAD Peer-ID, which is specific to the overlay and possibly not known to the ALTO
server maintained by the ISP. It would also quite difficult for the ALTO server to
relate the Peer-ID to a network location.

As ALTO aim to serve for similar applications as ppsp, we need to find out a way to use
it for PPSP based systems. One solution would be asking the tracker to record both the
IP address and the Peer ID. But, it would be strange not to return the IP address when it
is already available in the tracker. Another way is to ask peers to consult the ALTO server
after the ICE procedure. However, this solution brings much more overhead.  

 

Wang Wei

ZTE
Email: wang.wei108@zte.com


 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002FB7E8482577D0_=-- From Martin.Stiemerling@neclab.eu Wed Nov 3 05:40:34 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED70E3A6AB7 for ; Wed, 3 Nov 2010 05:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enxJjkDXA5fB for ; Wed, 3 Nov 2010 05:40:32 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id EC7E028C0D6 for ; Wed, 3 Nov 2010 05:39:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AE4AC28000178; Wed, 3 Nov 2010 13:38:52 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyYitAAc0nTe; Wed, 3 Nov 2010 13:38:52 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8E0C92800015D; Wed, 3 Nov 2010 13:38:37 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.152]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Wed, 3 Nov 2010 13:38:38 +0100 From: Martin Stiemerling To: Fabio Hecht , zhangyunfei Thread-Topic: [ppsp] Pull or Pushed-based P2P Streaming? Thread-Index: AQHLdz+8yBdkcoGGStqt/onxAOi0TZNXdWCAgAhCrMA= Date: Wed, 3 Nov 2010 12:38:36 +0000 Message-ID: References: <201010291439078752128@chinamobile.com> <201010291603144378146@chinamobile.com> <1288340667.2137.10.camel@bart3> In-Reply-To: <1288340667.2137.10.camel@bart3> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 12:40:34 -0000 SGkgRmFiaW8sIGFsbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBw cHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KPiBGYWJpbyBIZWNodA0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjksIDIwMTAg MTA6MjQgQU0NCj4gVG86IHpoYW5neXVuZmVpDQo+IENjOiBwcHNwQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbcHBzcF0gUHVsbCBvciBQdXNoZWQtYmFzZWQgUDJQIFN0cmVhbWluZz8NCj4gDQo+ IA0KPiBQdXNoIG9ubHkgd29ya3MgaWYgeW91IGNhbiBtYWtlIHJlYXNvbmFibGUgUW9TIGFzc3Vt cHRpb25zIGFuZCB0aGVyZSBpcw0KPiBhbiBvYnZpb3VzIHdheSBmb3IgcGVlcnMgdG8gY29vcmRp bmF0ZSB3aGF0IHRoZXkgc3Vic2NyaWJlIHRvLg0KPiBOb3JtYWxseSwNCj4gbXVsdGlwbGUgdHJl ZXMgYXJlIHVzZWQuIFRoaXMgbWFrZXMgdGhlIGRpc3RyaWJ1dGlvbiBub3QgdmVyeSBmbGV4aWJs ZSwNCj4gYXMgdGhlIHNvdXJjZSBuZWVkcyB0byBkZWZpbmUgaG93IG1hbnkgdHJlZXMgdGhlcmUg d2lsbCBiZSBiZWZvcmVoYW5kLg0KDQpUaGF0J3Mgb25lIHZpZXcsIGJ1dCB0aGVyZSBhcmUgcHVz aC1iYXNlZCBhcHByb2FjaGVzIGJhc2VkIG9uIG5ldHdvcmsgY29kaW5nIChpbiBwYXBlciB3b3Jr LCBidXQgYWxzbyBkZXBsb3llZCkuIA0KDQpIb3dldmVyLCBJIHZhZ3VlbHkgcmVtZW1iZXIgb25l IHAycCBzdHJlYW1pbmcgc3lzdGVtIHRoYXQgdXNlcyBhIGNvbWJpbmF0aW9uIG9mIHB1bGwgYXQg c3RhcnR1cCBhbmQgcHVzaCBhZnRlcndhcmRzLiANCg0KPiANCj4gUHVsbCB3b3JrcyBiZXR0ZXIg aW4gZW52aXJvbm1lbnRzIHdoaWNoIG1heSBjaGFuZ2UgY29uc3RhbnRseSAoY2h1cm4sDQo+IHVz ZXIgc3RhcnRlZCBhIGRvd25sb2FkIGV0Yy4pLCBzaW5jZSBwZWVycyBtYXkgcmVxdWVzdCBkaWZm ZXJlbnQgY2h1bmtzDQo+IHRvIGRpZmZlcmVudCBwZWVycyBmcmVlbHkuIENodXJuIG9yIGEgc3Vk ZGVuIGNoYW5nZSBpbiBhdmFpbGFibGUNCj4gYmFuZHdpZHRoIGFyZSBub3Qgc3BlY2lhbCBjYXNl cy4gWWVzLCB0aGVyZSBhcmUgZXh0cmEgbWVzc2FnZXMgdGhhdA0KPiBuZWVkDQo+IHRvIGJlIGV4 Y2hhbmdlZCwgYnV0IHRoZXkgYXJlIHZlcnkgc21hbGwgY29tcGFyZWQgd2l0aCB0aGUgYml0cmF0 ZSBvZg0KPiB0aGUgdmlkZW8gc3RyZWFtLg0KDQpXaGF0IGlzIHNtYWxsIGluIHRoYXQgY29udGV4 dD8gMjAgJSBvZiB0aGUgdG90YWwgdHJhZmZpYz8NCg0KQW55aG93LCBpdCBpcyB0b3VnaCB0byBk aXNjdXNzIGFib3V0IHByb3MgYW5kIGNvbnMgb2YgcHVsbCBvciBwdXNoIGFzIHRoaXMgbWF5IGJl IGluIHRoZSBleWUgb2YgdGhlIGJlaG9sZGVyIDspDQoNCj4gDQo+IFNvLCBpbiBteSBvcGluaW9u LCBQUFNQIHNob3VsZCBpbXBsZW1lbnQgYSBwdWxsIHByb3RvY29sLiBQZXJoYXBzIHRoZQ0KPiBh YmlsaXR5IG9mIHN3aXRjaGluZyB0byBwdXNoIGNvdWxkIGJlIGFkZGVkIGFzIGFuIGFkZGl0aW9u YWwgKG9wdGlvbmFsKQ0KPiBmZWF0dXJlLg0KDQpPcHRpb25hbCBmZWF0dXJlIGRvZXMgdHlwaWNh bGx5IG1lYW4gdGhhdCBpdCBpcyBub3QgaW1wbGVtZW50ZWQuIA0KDQpJIHdvdWxkIGFyZ3VlIGZv ciBsZXR0aW5nIHRoZSBwZWVycyB0byBmaWd1cmUgb3V0IHdoZW4gdGhleSBqb2luIHRoZSBzeXN0 ZW0gd2hhdCBzY2hlbWUgaXMgdXNlZCBmb3IgdGhlIGNodW5rIGRpZmZ1c2lvbi4gDQoNClRoZXJl IGNvdWxkIGEgYmUgInNlc3Npb24vc3lzdGVtIGpvaW4iIHdoZXJlIHRoZSBvdGhlciBwZWVycyAo b3IgdGhlIHRyYWNrZXIpIGFubm91bmNlIHdoZXRoZXIgcHVzaCwgcHVsbCwgcHVzaC9wdWxsIGlz IHVzZWQuIFRoaXMgd291bGQgYWxzbyBzdXBwb3J0IHRoZSBjYXNlIHdoZXJlIGEgc3lzdGVtIHN1 cHBvcnRzIGEgc3BlY2lhbCB2YW5pbGxhIGZsYXZvciBvZiBwdWxsLiANCg0KICBNYXJ0aW4gDQoN Cg0KDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVy b3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbg0KTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVn aXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJM IHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCg== From Martin.Stiemerling@neclab.eu Wed Nov 3 05:40:48 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C773A6AB7 for ; Wed, 3 Nov 2010 05:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, SARE_OBFU_DOWNLD_SUB=0.85, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlTxO6t9JoOD for ; Wed, 3 Nov 2010 05:40:34 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E5DC63A6ABC for ; Wed, 3 Nov 2010 05:40:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B11AC2C0001B0; Wed, 3 Nov 2010 13:39:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YxhsYedQl53; Wed, 3 Nov 2010 13:39:40 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 926D92C0001AD; Wed, 3 Nov 2010 13:39:25 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.152]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Wed, 3 Nov 2010 13:39:26 +0100 From: Martin Stiemerling To: Ning Zong , "'Rahman, Akbar'" Thread-Topic: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) Thread-Index: AQHLdjezet4bxWjyJk2XZE0rHkz0K5Nfu7DA Date: Wed, 3 Nov 2010 12:39:25 +0000 Message-ID: References: <003801cb7637$ae5b50d0$3a298a0a@china.huawei.com> In-Reply-To: <003801cb7637$ae5b50d0$3a298a0a@china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers anddownloading bandwidth) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 12:40:48 -0000 Fine with me.=20 However, there is no need to wait until we arrive at the meeting. The maili= ng list can simply do it. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Ning Zong [mailto:zongning@huawei.com] > Sent: Thursday, October 28, 2010 2:33 AM > To: 'Rahman, Akbar'; Martin Stiemerling > Cc: ppsp@ietf.org > Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers > anddownloading bandwidth) >=20 > Hi, Akbar and Martin > Thank you very much for contributing to the requirement draft. > My suggestion is that I will put these requirement changes to our > presentation slides used on Beijing meeting so that we can get group > consensus about how to incorporate the suggested text into PPSP > requirement > drafts. > Although personally I agree with some of the changes, we need to get > group > consensus before adopting them into the WG draft, right? > Sorry for the late response and, hope to see you all in Beijing. >=20 > BR, > Ning Zong >=20 > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Rahman, Akbar > Sent: Wednesday, October 27, 2010 10:28 PM > To: Martin Stiemerling > Cc: ppsp@ietf.org > Subject: Re: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers > anddownloading bandwidth) >=20 > Thanks, Martin. >=20 > I will make your suggested changes for the battery status in the next > revision of my draft. Or better yet, the PPSP Requirement draft will > incorporate your and my suggestions for adding the mobility > requirements > into their WG draft (and I will no longer have to maintain my separate > draft)! >=20 >=20 > See you in Beijing. >=20 >=20 > Akbar >=20 > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@neclab.eu] > Sent: Wednesday, October 27, 2010 9:53 AM > To: Rahman, Akbar > Cc: ppsp@ietf.org > Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers > and downloading bandwidth) >=20 > Hi Akbar, >=20 > Just browsed the points and I tend to agree with most points. >=20 > Mobility isn't covered at all in the requirements and not even > reflected > any of them. >=20 > For the battery one - I guess it would make sense to say: > Peers SHOULD be able to add specific parameters to their tracker > request >=20 > and to refine it in separate step to "this may include battery status > information." >=20 > Thanks, >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > > Sent: Wednesday, October 27, 2010 3:35 PM > > To: Martin Stiemerling > > Cc: ppsp@ietf.org > > Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers > > and downloading bandwidth) > > > > Hi Martin, > > > > > > I agree with your comments. Also please note that I have previously > > raised some other issues on the requirements for which I am still > > waiting for some feedback on (see attached link) > > > > http://www.ietf.org/mail-archive/web/ppsp/current/msg00720.html > > > > > > Sincerely, > > > > > > Akbar > > > > > > -----Original Message----- > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf > Of > > Martin Stiemerling > > Sent: Wednesday, October 27, 2010 9:26 AM > > To: ppsp@ietf.org > > Subject: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers and > > downloading bandwidth) > > > > Hi, > > > > A clarifying question to the requirements draft's PPSP.TP.REQ-4. It > > says: > > PPSP.TP.REQ-4: The tracker request message MAY include parameter of > > requested number of downloading peers or preferred downloading > > bandwidth. > > > > First, wouldn't it be better to specify: > > "The tracker request message SHOULD allow to include parameters set > by > > the peer to further refine the request." > > > > I guess that this is the actual intention of the requirements. The > next > > requirements below would be a refinement of the above requirement or > > examples: > > > > Second, one more detailed requirement could be" > > "The tracker request message SHOULD allow to include parameters which > > denote the number of peers queried for." > > > > Another requirement could be: > > "The tracker request message SHOULD allow to include parameters which > > denotes the minimum theoretical upload bandwidth of a peer." > > > > > > Martin > > > > martin.stiemerling@neclab.eu > > > > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > _______________________________________________ > > 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 Martin.Stiemerling@neclab.eu Wed Nov 3 06:02:41 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0484A3A6AA6 for ; Wed, 3 Nov 2010 06:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmbiqvMRoCY8 for ; Wed, 3 Nov 2010 06:02:40 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 387263A68DA for ; Wed, 3 Nov 2010 06:02:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E1DB928000178; Wed, 3 Nov 2010 14:02:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh+T7ue+mIAF; Wed, 3 Nov 2010 14:02:46 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C79672800015D; Wed, 3 Nov 2010 14:02:36 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.152]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Wed, 3 Nov 2010 14:02:37 +0100 From: Martin Stiemerling To: zhangyunfei , "ppsp@ietf.org" Thread-Topic: RE: [ppsp] Review of draft-ietf-ppsp-problem-statement-00 Thread-Index: Act1ILBQ94eTTubBQ/y3FbypeQIWhQAYBQH+ABdxt/AANPmn8QEpBpqg Date: Wed, 3 Nov 2010 13:02:36 +0000 Message-ID: References: <201010271043042504672@chinamobile.com> <201010282311126872630@chinamobile.com> In-Reply-To: <201010282311126872630@chinamobile.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.207] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] Review of draft-ietf-ppsp-problem-statement-00 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 13:02:41 -0000 Hi Yunfei,=20 > -----Original Message----- > From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] > Sent: Thursday, October 28, 2010 5:11 PM > To: Martin Stiemerling; ppsp@ietf.org > Subject: Re: RE: [ppsp] Review of draft-ietf-ppsp-problem-statement-00 >=20 > Hi Martin=1B$B!$=1B(B > Thanks for the comments.Some quick replies on the questions are as > follows: > Section7.2: Three screen refers to sharing video streaming contents > among hetergeneous terminals, say, PC screen, TV screen and mobile > terminal screen. The intention of this section is showing the > compatibility of PPSP for hetergeneous environments. Can you expand the text in 7.2 to better explain this? This is IMHO not wel= l-documented in Section 7.2 >=20 > Section7.3 wants to express two points. The first is for CDN vendors to > provide service. The small p2p vendors want to increase the streaming > delivery performance by the help of stable CDNs as the super-peers in > their systems. PPSP helps CDN nodes seamlessly join the P2P streaming > delivery without too much work. The second is for CDN internal > construction. PPSP helps scheduling the contents among these nodes. Same here, it 7.3 is not reflecting this. Martin =20 martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 From hecht@ifi.uzh.ch Wed Nov 3 06:18:47 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3440A3A6A5D for ; Wed, 3 Nov 2010 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBC4GCM3NJ80 for ; Wed, 3 Nov 2010 06:18:46 -0700 (PDT) Received: from gustav.ifi.uzh.ch (gustav.ifi.uzh.ch [130.60.156.10]) by core3.amsl.com (Postfix) with ESMTP id EBF563A6768 for ; Wed, 3 Nov 2010 06:18:45 -0700 (PDT) Received: from authenticated sender hecht by gustav.ifi.uzh.ch (postfix) with ESMTPSA id SA; 8FADE29051 From: Fabio Hecht To: Martin Stiemerling In-Reply-To: References: <201010291439078752128@chinamobile.com> <201010291603144378146@chinamobile.com> <1288340667.2137.10.camel@bart3> Content-Type: text/plain; charset="UTF-8" Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_Z=FCrich?= Date: Wed, 03 Nov 2010 14:18:50 +0100 Message-ID: <1288790330.2381.126.camel@bart3> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.4 at gustav X-Virus-Status: Clean Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 13:18:47 -0000 Hi Martin, On Wed, 2010-11-03 at 12:38 +0000, Martin Stiemerling wrote: > Hi Fabio, all, > > > -----Original Message----- > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > > Fabio Hecht > > Sent: Friday, October 29, 2010 10:24 AM > > To: zhangyunfei > > Cc: ppsp@ietf.org > > Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? > > > > > > Push only works if you can make reasonable QoS assumptions and there is > > an obvious way for peers to coordinate what they subscribe to. > > Normally, > > multiple trees are used. This makes the distribution not very flexible, > > as the source needs to define how many trees there will be beforehand. > > That's one view, but there are push-based approaches based on network coding (in paper work, but also deployed). True, that's also possible. Do you have a reference to a deployed one? > > However, I vaguely remember one p2p streaming system that uses a combination of pull at startup and push afterwards. > > > > > Pull works better in environments which may change constantly (churn, > > user started a download etc.), since peers may request different chunks > > to different peers freely. Churn or a sudden change in available > > bandwidth are not special cases. Yes, there are extra messages that > > need > > to be exchanged, but they are very small compared with the bitrate of > > the video stream. > > What is small in that context? 20 % of the total traffic? No, much less. A request for a chunk will be a few bytes, while the chunk itself will be several kilobytes. > > Anyhow, it is tough to discuss about pros and cons of pull or push as this may be in the eye of the beholder ;) It could be, but it's probably accurate to say that currently most (if not all) widely deployed systems use pull. > > > > > So, in my opinion, PPSP should implement a pull protocol. Perhaps the > > ability of switching to push could be added as an additional (optional) > > feature. > > Optional feature does typically mean that it is not implemented. > > I would argue for letting the peers to figure out when they join the system what scheme is used for the chunk diffusion. > > There could a be "session/system join" where the other peers (or the tracker) announce whether push, pull, push/pull is used. This would also support the case where a system supports a special vanilla flavor of pull. I think this may be complicated, since there are several ways to combine push and pull. Regards Fabio > > Martin > > > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -- Fabio Hecht University of Zurich - Department of Informatics (IfI) Binzmühlestrasse 14 CH-8050 Zürich, Switzerland Ph.: +41 44 6357129 / 6350892 Fax: +41 44 6356809 VoIP sip:hecht@ifi.uzh.ch From riccardo.bernardini@uniud.it Wed Nov 3 06:39:49 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C9328C0D6 for ; Wed, 3 Nov 2010 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVdvO4AyYkkh for ; Wed, 3 Nov 2010 06:39:47 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by core3.amsl.com (Postfix) with ESMTP id B2CC93A6A9D for ; Wed, 3 Nov 2010 06:39:25 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 6FD52B72416 for ; Wed, 3 Nov 2010 14:38:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.226]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id xff78bn9jA4y for ; Wed, 3 Nov 2010 14:38:37 +0100 (CET) Received: from webmail.uniud.it (webmail1.cc.uniud.it [158.110.1.17]) by smtp.uniud.it (Postfix) with ESMTPA id 0A1591E004 for ; Wed, 3 Nov 2010 14:38:37 +0100 (CET) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Wed, 03 Nov 2010 14:38:35 +0100 Message-ID: <20101103143835.20999y6e9op9jjdn@webmail.uniud.it> Date: Wed, 03 Nov 2010 14:38:35 +0100 From: Riccardo Bernardini To: ppsp@ietf.org References: <201010291439078752128@chinamobile.com> <201010291603144378146@chinamobile.com> <1288340667.2137.10.camel@bart3> <1288790330.2381.126.camel@bart3> In-Reply-To: <1288790330.2381.126.camel@bart3> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 13:39:50 -0000 Quoting Fabio Hecht : > Hi Martin, > > > On Wed, 2010-11-03 at 12:38 +0000, Martin Stiemerling wrote: >> Hi Fabio, all, >> >> > -----Original Message----- >> > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of >> > Fabio Hecht >> > Sent: Friday, October 29, 2010 10:24 AM >> > To: zhangyunfei >> > Cc: ppsp@ietf.org >> > Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? >> > >> > >> > Push only works if you can make reasonable QoS assumptions and there is >> > an obvious way for peers to coordinate what they subscribe to. >> > Normally, >> > multiple trees are used. This makes the distribution not very flexible, >> > as the source needs to define how many trees there will be beforehand. >> >> That's one view, but there are push-based approaches based on =20 >> network coding (in paper work, but also deployed). > > True, that's also possible. Do you have a reference to a deployed one? Well... not really "deployed," but maybe close enough... Let me point you to http://tools.ietf.org/html/draft-bernardini-ppetp-00 It is an I-D =20 relative to a "pure transport" protocol of "push type" based on =20 network coding. We have a working software implementation of it, =20 hosted on SourceForge (http://corallo.sourceforge.net). The current =20 version is working, but not clean enough for public release. We are =20 currently doing some code reorganization and we plan to make the first =20 public release soon (hopefully). So, it is not really "deployed," but we are working to make it. > >> >> However, I vaguely remember one p2p streaming system that uses a =20 >> combination of pull at startup and push afterwards. >> >> > >> > Pull works better in environments which may change constantly (churn, >> > user started a download etc.), since peers may request different chunks >> > to different peers freely. Churn or a sudden change in available >> > bandwidth are not special cases. Yes, there are extra messages that >> > need >> > to be exchanged, but they are very small compared with the bitrate of >> > the video stream. >> >> What is small in that context? 20 % of the total traffic? > > No, much less. A request for a chunk will be a few bytes, while the > chunk itself will be several kilobytes. > >> >> Anyhow, it is tough to discuss about pros and cons of pull or push =20 >> as this may be in the eye of the beholder ;) > > It could be, but it's probably accurate to say that currently most (if > not all) widely deployed systems use pull. > >> >> > >> > So, in my opinion, PPSP should implement a pull protocol. Perhaps the >> > ability of switching to push could be added as an additional (optional) >> > feature. >> >> Optional feature does typically mean that it is not implemented. >> >> I would argue for letting the peers to figure out when they join =20 >> the system what scheme is used for the chunk diffusion. >> >> There could a be "session/system join" where the other peers (or =20 >> the tracker) announce whether push, pull, push/pull is used. This =20 >> would also support the case where a system supports a special =20 >> vanilla flavor of pull. > > I think this may be complicated, since there are several ways to combine > push and pull. > > Regards > > Fabio > >> >> Martin >> >> >> >> martin.stiemerling@neclab.eu >> >> NEC Laboratories Europe - Network Research Division >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =20 >> London W3 6BL | Registered in England 2832014 > > -- > Fabio Hecht > > University of Zurich - Department of Informatics (IfI) > Binzm=C3=BChlestrasse 14 CH-8050 Z=C3=BCrich, Switzerland > Ph.: +41 44 6357129 / 6350892 Fax: +41 44 6356809 > VoIP sip:hecht@ifi.uzh.ch > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > --=20 Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - CSIT -Universita' di Udine From davidbryan@gmail.com Wed Nov 3 07:43:23 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA933A69B3 for ; Wed, 3 Nov 2010 07:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMhyayXjpSox for ; Wed, 3 Nov 2010 07:43:22 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 65FCF3A69C0 for ; Wed, 3 Nov 2010 07:43:22 -0700 (PDT) Received: by wyb28 with SMTP id 28so668908wyb.31 for ; Wed, 03 Nov 2010 07:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QNbUxQR3hScNHwSFVeoAPr5u7JFbA/Q0t6w+0C3PEag=; b=tBoy3H3ot5WOC4u0bVllavLaPhvMx8l4lbOwpdGd9uAQkTSLvmYgTfysi5FC4bhHeQ KU98/nXO2IliHaUDObxg6SWYUB4T56gmJCmRBZbskHJAofW659pbMtMnnsaZTRCtla6i X3hCPVAxQK6M+MnZyqut8k1FChCbhid7EcV8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=K2msjQQwEutoDirbzbdrYpp4+D+64AxgvAE9+HV+GzfsBfNGZf+UL7UsoEG6BbZbjP 0PmZO81i9bIDu/1MjindMj4nyVkLzUuTnIp0Oi17k9O84PurHYOLSzPzN97G2aFZnYAM 61Upp3lG+1o0hpCkG46Zig8cD3Z7H8GcWHaOQ= MIME-Version: 1.0 Received: by 10.227.29.204 with SMTP id r12mr18553102wbc.110.1288795408701; Wed, 03 Nov 2010 07:43:28 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.207.195 with HTTP; Wed, 3 Nov 2010 07:43:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Nov 2010 10:43:28 -0400 X-Google-Sender-Auth: GZdGPJuMwzAAD1sdsmEdAdy5O4w Message-ID: From: "David A. Bryan" To: "wang.wei108" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ppsp@ietf.org" , "hao.zhenwu" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 14:43:23 -0000 Yep, this needs to be included in the design, but I still think peer-IDs are the right way to go for transport. We may very well need to include IP address in the supplemental information that is carried in a peerlist (or provided in a search for find peers) to let peers select appropriate matches. There will be many bits of supplemental information (often self-reported, so used as a guide only) that may be included in a peerlist returned from a tracker to help peers choose which other peers they should connect to. These could include IP address (which can then be used with ALTO), capabilities such as connection type or CPU, etc. Using Peer-ID for the actual connection/routing ensures all peers are reachable via messages before NAT traversal (and RELOAD then provides a good mechanism for NAT traversal). IP addresses can be provided along with other supplemental information to be used to select which peer(s) are best to connect to, but using them for connectivity is a bad idea. When peers are behind certain kinds of NATs, even having valid peer addresses will not allow them to connect. With a DHT structure and using Peer-IDs, this isn't a concern. If ALTO is used and requires IP addresses, this can be included as supplemental information, but at least in my thoughts so far, Peer-IDs seem like a better choice for location and initial message routing between peers. David On Wed, Nov 3, 2010 at 4:38 AM, wrote: > > Hi all, > > =A0 =A0In the latest draft of peer protocol and tracker protocol it is pr= oposed > that > the peer list only contains Peer-ID, and RELOAD is used for peer location > and NAT > traversal: > > draft-gu-ppsp-peer-protocol-01:page 3-4 > > "The peer contacts the tracker to obtain a Peerlist containing a > list of peers participating in the particular swarm the peer is > interested in. > > ... > > * This list does not contain IP addresses, but rather RELOAD > Peer-IDs." > > > My concern about this design choice is that some related protocols, such = as > ALTO, > implicitly assume that the IP address is used in the peerlist. If the > tracker > only records the Peer-ID, it will not be able to consult ALTO server usin= g > the > RELOAD Peer-ID, which is specific to the overlay and possibly not known t= o > the ALTO > server maintained by the ISP. It would also quite difficult for the ALTO > server to > relate the Peer-ID to a network location. > > As ALTO aim to serve for similar applications as ppsp, we need to find ou= t a > way to use > it for PPSP based systems. One solution would be asking the tracker to > record both the > IP address and the Peer ID. But, it would be strange not to return the IP > address when it > is already available in the tracker. Another way is to ask peers to consu= lt > the ALTO server > after the ICE procedure. However, this solution brings much more overhead= . > > > > Wang Wei > > ZTE > Email: wang.wei108@zte.com > > > > > -------------------------------------------------------- > ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0= in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organizat= ion.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0name= d=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=A0p= ermitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=A0to= =A0others. > This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confid= ential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. > From ye.wang@yale.edu Wed Nov 3 13:52:37 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD5B3A69DF for ; Wed, 3 Nov 2010 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlLntSNexYqV for ; Wed, 3 Nov 2010 13:52:36 -0700 (PDT) Received: from pantheon-po31.its.yale.edu (pantheon-po31.its.yale.edu [130.132.50.82]) by core3.amsl.com (Postfix) with ESMTP id 4C0FF3A66B4 for ; Wed, 3 Nov 2010 13:52:35 -0700 (PDT) Received: from [128.36.233.131] (p4p-8.cs.yale.edu [128.36.233.131]) by pantheon-po31.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oA3KqZl6005737; Wed, 3 Nov 2010 16:52:35 -0400 From: Ye Wang To: "David A. Bryan" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Yale University, Computer Science Date: Wed, 03 Nov 2010 16:53:09 -0400 Message-ID: <1288817589.16826.42.camel@p4p-8.cs.yale.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: "hao.zhenwu" , "ppsp@ietf.org" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 20:52:37 -0000 On Wed, 2010-11-03 at 10:43 -0400, David A. Bryan wrote: > Yep, this needs to be included in the design, but I still think > peer-IDs are the right way to go for transport. I agree. Using peer ID in protocols can enable more general transport solutions and more general application designs. For example, we can have an application that allows a client to concurrently participate in multiple streaming channels (P2P sessions) like this: the client listens on a single IP address:port, while it uses different peer IDs in different channels. > We may very well need > to include IP address in the supplemental information that is carried > in a peerlist (or provided in a search for find peers) to let peers > select appropriate matches. There will be many bits of supplemental > information (often self-reported, so used as a guide only) that may be > included in a peerlist returned from a tracker to help peers choose > which other peers they should connect to. These could include IP > address (which can then be used with ALTO), capabilities such as > connection type or CPU, etc. Encoding IP address in peer list certainly allows each peer to use this info in its peering. However, we probably don't want to force the peer list to always include IP address, as we can envision that some applications may not like this, due to privacy or other concerns. We just want to make sure it is easy to extend protocol messaging so that the supplement peer info (including IP address) can be added. Another comment is: since the tracker has IP address information of each peer, the tracker can directly apply ALTO info in its peer selection process. The application should already enjoy a lot of ALTO benefits using this approach. > > Using Peer-ID for the actual connection/routing ensures all peers are > reachable via messages before NAT traversal (and RELOAD then provides > a good mechanism for NAT traversal). IP addresses can be provided > along with other supplemental information to be used to select which > peer(s) are best to connect to, but using them for connectivity is a > bad idea. When peers are behind certain kinds of NATs, even having > valid peer addresses will not allow them to connect. With a DHT > structure and using Peer-IDs, this isn't a concern. If ALTO is used > and requires IP addresses, this can be included as supplemental > information, but at least in my thoughts so far, Peer-IDs seem like a > better choice for location and initial message routing between peers. > > David > > > > On Wed, Nov 3, 2010 at 4:38 AM, wrote: > > > > Hi all, > > > > In the latest draft of peer protocol and tracker protocol it is proposed > > that > > the peer list only contains Peer-ID, and RELOAD is used for peer location > > and NAT > > traversal: > > > > draft-gu-ppsp-peer-protocol-01:page 3-4 > > > > "The peer contacts the tracker to obtain a Peerlist containing a > > list of peers participating in the particular swarm the peer is > > interested in. > > > > ... > > > > * This list does not contain IP addresses, but rather RELOAD > > Peer-IDs." > > > > > > My concern about this design choice is that some related protocols, such as > > ALTO, > > implicitly assume that the IP address is used in the peerlist. If the > > tracker > > only records the Peer-ID, it will not be able to consult ALTO server using > > the > > RELOAD Peer-ID, which is specific to the overlay and possibly not known to > > the ALTO > > server maintained by the ISP. It would also quite difficult for the ALTO > > server to > > relate the Peer-ID to a network location. > > > > As ALTO aim to serve for similar applications as ppsp, we need to find out a > > way to use > > it for PPSP based systems. One solution would be asking the tracker to > > record both the > > IP address and the Peer ID. But, it would be strange not to return the IP > > address when it > > is already available in the tracker. Another way is to ask peers to consult > > the ALTO server > > after the ICE procedure. However, this solution brings much more overhead. > > > > > > > > Wang Wei > > > > ZTE > > Email: wang.wei108@zte.com > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From wang.wei108@zte.com.cn Wed Nov 3 17:26:51 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870F33A69CE for ; Wed, 3 Nov 2010 17:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgzV0OzUym9P for ; Wed, 3 Nov 2010 17:26:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 366453A69E8 for ; Wed, 3 Nov 2010 17:26:48 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510790912505; Thu, 4 Nov 2010 08:25:28 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.5454139818; Thu, 4 Nov 2010 08:26:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oA40Qn54086840; Thu, 4 Nov 2010 08:26:49 +0800 (CST) (envelope-from wang.wei108@zte.com.cn) In-Reply-To: To: "David A. Bryan" MIME-Version: 1.0 X-KeepSent: B01F0E98:23A72846-482577D1:00011402; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.wei108@zte.com.cn Date: Thu, 4 Nov 2010 08:24:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-04 08:26:44, Serialize complete at 2010-11-04 08:26:44 Content-Type: multipart/alternative; boundary="=_alternative 0002730F482577D1_=" X-MAIL: mse2.zte.com.cn oA40Qn54086840 Cc: davidbryan@gmail.com, "hao.zhenwu" , "ppsp@ietf.org" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 00:26:51 -0000 This is a multipart message in MIME format. --=_alternative 0002730F482577D1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlIHRoYXQgUGVlci1JRCBpcyBhIGJldHRlciB3YXkgZm9yIHRyYW5zcG9ydC4g TWF5YmUgd2Ugc2hvdWxkIA0KYWxsb3cNCklQIGFkZHJlc3MgYW5kIG90aGVyIGlkZW50aXRpZXMg aW4gdGhlIHN1cHBsZW1lbnRhbCBpbmZvcm1hdGlvbiwgYXMgdGhlcmUgDQphcmUgDQpjYXNlcyB3 aGVyZSBQZWVyLUlEcyBhcmUgbm90IGF2YWlsYWJsZToNCiAgLS0gVGhpcmQgcGFydHkgQ0ROIHNl cnZlcnMgd2hpY2ggZG8gbm90IHdpc2ggdG8gcGFydGljaXBhdGUgaW4gUkVMT0FEDQogIC0tIE90 aGVyIHBwc3Agc3lzdGVtcyB3aGljaCBvcGVyYXRlcyBvbiB0aGVpciBvd24gUkVMT0FEIG92ZXJs YXlzDQogIC0tIENETiBzeXN0ZW1zIHdoaWNoIHdpc2ggdG8gZG8gbG9hZCBibGFuY2luZyBieSB0 aGVtc2VsdmVzDQoNCk1heWJlIGFsbG93aW5nIGRpZmZlcmVudCB0eXBlcyBvZiBpZGVudGl0aWVz IGFuZCBsZXR0aW5nIHRoZSBwZWVycyBjaG9vc2UgDQp0aGUgd2F5IGZvcg0KdHJhbnNwb3J0IGlz IGEgbW9yZSBmbGV4aWJsZSB3YXkuDQoNCg0KV2FuZyBXZWkNCg0KWlRFDQpFbWFpbDogd2FuZy53 ZWkxMDhAenRlLmNvbQ0KDQogDQoNCg0KDQoiRGF2aWQgQS4gQnJ5YW4iIDxkYnJ5YW5AZXRoZXJu b3Qub3JnPiANCreivP7IyzogIGRhdmlkYnJ5YW5AZ21haWwuY29tDQoyMDEwLTExLTAzIDIyOjQz DQoNCsrVvP7Iyw0KIndhbmcud2VpMTA4IiA8d2FuZy53ZWkxMDhAenRlLmNvbS5jbj4NCrOty80N Cmd1eWluZ2ppZSA8Z3V5aW5namllQGh1YXdlaS5jb20+LCAicHBzcEBpZXRmLm9yZyIgPHBwc3BA aWV0Zi5vcmc+LCANCiJtZW5nLnl1IiA8bWVuZy55dUB6dGUuY29tLmNuPiwgImhhby56aGVud3Ui IDxoYW8uemhlbnd1QHp0ZS5jb20uY24+LCANCiJsaS5saWNodW4xIiA8bGkubGljaHVuMUB6dGUu Y29tLmNuPg0K1vfM4g0KUmU6IFF1ZXN0aW9uIGFib3V0IHVzaW5nIFBlZXItSUQgaW4gcGVlciBs aXN0DQoNCg0KDQoNCg0KDQpZZXAsIHRoaXMgbmVlZHMgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIGRl c2lnbiwgYnV0IEkgc3RpbGwgdGhpbmsNCnBlZXItSURzIGFyZSB0aGUgcmlnaHQgd2F5IHRvIGdv IGZvciB0cmFuc3BvcnQuIFdlIG1heSB2ZXJ5IHdlbGwgbmVlZA0KdG8gaW5jbHVkZSBJUCBhZGRy ZXNzIGluIHRoZSBzdXBwbGVtZW50YWwgaW5mb3JtYXRpb24gdGhhdCBpcyBjYXJyaWVkDQppbiBh IHBlZXJsaXN0IChvciBwcm92aWRlZCBpbiBhIHNlYXJjaCBmb3IgZmluZCBwZWVycykgdG8gbGV0 IHBlZXJzDQpzZWxlY3QgYXBwcm9wcmlhdGUgbWF0Y2hlcy4gVGhlcmUgd2lsbCBiZSBtYW55IGJp dHMgb2Ygc3VwcGxlbWVudGFsDQppbmZvcm1hdGlvbiAob2Z0ZW4gc2VsZi1yZXBvcnRlZCwgc28g dXNlZCBhcyBhIGd1aWRlIG9ubHkpIHRoYXQgbWF5IGJlDQppbmNsdWRlZCBpbiBhIHBlZXJsaXN0 IHJldHVybmVkIGZyb20gYSB0cmFja2VyIHRvIGhlbHAgcGVlcnMgY2hvb3NlDQp3aGljaCBvdGhl ciBwZWVycyB0aGV5IHNob3VsZCBjb25uZWN0IHRvLiBUaGVzZSBjb3VsZCBpbmNsdWRlIElQDQph ZGRyZXNzICh3aGljaCBjYW4gdGhlbiBiZSB1c2VkIHdpdGggQUxUTyksIGNhcGFiaWxpdGllcyBz dWNoIGFzDQpjb25uZWN0aW9uIHR5cGUgb3IgQ1BVLCBldGMuDQoNClVzaW5nIFBlZXItSUQgZm9y IHRoZSBhY3R1YWwgY29ubmVjdGlvbi9yb3V0aW5nIGVuc3VyZXMgYWxsIHBlZXJzIGFyZQ0KcmVh Y2hhYmxlIHZpYSBtZXNzYWdlcyBiZWZvcmUgTkFUIHRyYXZlcnNhbCAoYW5kIFJFTE9BRCB0aGVu IHByb3ZpZGVzDQphIGdvb2QgbWVjaGFuaXNtIGZvciBOQVQgdHJhdmVyc2FsKS4gSVAgYWRkcmVz c2VzIGNhbiBiZSBwcm92aWRlZA0KYWxvbmcgd2l0aCBvdGhlciBzdXBwbGVtZW50YWwgaW5mb3Jt YXRpb24gdG8gYmUgdXNlZCB0byBzZWxlY3Qgd2hpY2gNCnBlZXIocykgYXJlIGJlc3QgdG8gY29u bmVjdCB0bywgYnV0IHVzaW5nIHRoZW0gZm9yIGNvbm5lY3Rpdml0eSBpcyBhDQpiYWQgaWRlYS4g V2hlbiBwZWVycyBhcmUgYmVoaW5kIGNlcnRhaW4ga2luZHMgb2YgTkFUcywgZXZlbiBoYXZpbmcN CnZhbGlkIHBlZXIgYWRkcmVzc2VzIHdpbGwgbm90IGFsbG93IHRoZW0gdG8gY29ubmVjdC4gV2l0 aCBhIERIVA0Kc3RydWN0dXJlIGFuZCB1c2luZyBQZWVyLUlEcywgdGhpcyBpc24ndCBhIGNvbmNl cm4uIElmIEFMVE8gaXMgdXNlZA0KYW5kIHJlcXVpcmVzIElQIGFkZHJlc3NlcywgdGhpcyBjYW4g YmUgaW5jbHVkZWQgYXMgc3VwcGxlbWVudGFsDQppbmZvcm1hdGlvbiwgYnV0IGF0IGxlYXN0IGlu IG15IHRob3VnaHRzIHNvIGZhciwgUGVlci1JRHMgc2VlbSBsaWtlIGENCmJldHRlciBjaG9pY2Ug Zm9yIGxvY2F0aW9uIGFuZCBpbml0aWFsIG1lc3NhZ2Ugcm91dGluZyBiZXR3ZWVuIHBlZXJzLg0K DQpEYXZpZA0KDQoNCg0KT24gV2VkLCBOb3YgMywgMjAxMCBhdCA0OjM4IEFNLCAgPHdhbmcud2Vp MTA4QHp0ZS5jb20uY24+IHdyb3RlOg0KPg0KPiBIaSBhbGwsDQo+DQo+ICAgIEluIHRoZSBsYXRl c3QgZHJhZnQgb2YgcGVlciBwcm90b2NvbCBhbmQgdHJhY2tlciBwcm90b2NvbCBpdCBpcyANCnBy b3Bvc2VkDQo+IHRoYXQNCj4gdGhlIHBlZXIgbGlzdCBvbmx5IGNvbnRhaW5zIFBlZXItSUQsIGFu ZCBSRUxPQUQgaXMgdXNlZCBmb3IgcGVlciANCmxvY2F0aW9uDQo+IGFuZCBOQVQNCj4gdHJhdmVy c2FsOg0KPg0KPiBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wtMDE6cGFnZSAzLTQNCj4NCj4g IlRoZSBwZWVyIGNvbnRhY3RzIHRoZSB0cmFja2VyIHRvIG9idGFpbiBhIFBlZXJsaXN0IGNvbnRh aW5pbmcgYQ0KPiBsaXN0IG9mIHBlZXJzIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHBhcnRpY3VsYXIg c3dhcm0gdGhlIHBlZXIgaXMNCj4gaW50ZXJlc3RlZCBpbi4NCj4NCj4gLi4uDQo+DQo+ICogVGhp cyBsaXN0IGRvZXMgbm90IGNvbnRhaW4gSVAgYWRkcmVzc2VzLCBidXQgcmF0aGVyIFJFTE9BRA0K PiBQZWVyLUlEcy4iDQo+DQo+DQo+IE15IGNvbmNlcm4gYWJvdXQgdGhpcyBkZXNpZ24gY2hvaWNl IGlzIHRoYXQgc29tZSByZWxhdGVkIHByb3RvY29scywgc3VjaCANCmFzDQo+IEFMVE8sDQo+IGlt cGxpY2l0bHkgYXNzdW1lIHRoYXQgdGhlIElQIGFkZHJlc3MgaXMgdXNlZCBpbiB0aGUgcGVlcmxp c3QuIElmIHRoZQ0KPiB0cmFja2VyDQo+IG9ubHkgcmVjb3JkcyB0aGUgUGVlci1JRCwgaXQgd2ls bCBub3QgYmUgYWJsZSB0byBjb25zdWx0IEFMVE8gc2VydmVyIA0KdXNpbmcNCj4gdGhlDQo+IFJF TE9BRCBQZWVyLUlELCB3aGljaCBpcyBzcGVjaWZpYyB0byB0aGUgb3ZlcmxheSBhbmQgcG9zc2li bHkgbm90IGtub3duIA0KdG8NCj4gdGhlIEFMVE8NCj4gc2VydmVyIG1haW50YWluZWQgYnkgdGhl IElTUC4gSXQgd291bGQgYWxzbyBxdWl0ZSBkaWZmaWN1bHQgZm9yIHRoZSBBTFRPDQo+IHNlcnZl ciB0bw0KPiByZWxhdGUgdGhlIFBlZXItSUQgdG8gYSBuZXR3b3JrIGxvY2F0aW9uLg0KPg0KPiBB cyBBTFRPIGFpbSB0byBzZXJ2ZSBmb3Igc2ltaWxhciBhcHBsaWNhdGlvbnMgYXMgcHBzcCwgd2Ug bmVlZCB0byBmaW5kIA0Kb3V0IGENCj4gd2F5IHRvIHVzZQ0KPiBpdCBmb3IgUFBTUCBiYXNlZCBz eXN0ZW1zLiBPbmUgc29sdXRpb24gd291bGQgYmUgYXNraW5nIHRoZSB0cmFja2VyIHRvDQo+IHJl Y29yZCBib3RoIHRoZQ0KPiBJUCBhZGRyZXNzIGFuZCB0aGUgUGVlciBJRC4gQnV0LCBpdCB3b3Vs ZCBiZSBzdHJhbmdlIG5vdCB0byByZXR1cm4gdGhlIA0KSVANCj4gYWRkcmVzcyB3aGVuIGl0DQo+ IGlzIGFscmVhZHkgYXZhaWxhYmxlIGluIHRoZSB0cmFja2VyLiBBbm90aGVyIHdheSBpcyB0byBh c2sgcGVlcnMgdG8gDQpjb25zdWx0DQo+IHRoZSBBTFRPIHNlcnZlcg0KPiBhZnRlciB0aGUgSUNF IHByb2NlZHVyZS4gSG93ZXZlciwgdGhpcyBzb2x1dGlvbiBicmluZ3MgbXVjaCBtb3JlIA0Kb3Zl cmhlYWQuDQo+DQo+DQo+DQo+IFdhbmcgV2VpDQo+DQo+IFpURQ0KPiBFbWFpbDogd2FuZy53ZWkx MDhAenRlLmNvbQ0KPg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gDQpUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIuDQo+IA0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo+DQoNCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0002730F482577D1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPlllcywgSSBhZ3JlZSB0aGF0IFBlZXItSUQgaXMgYSBiZXR0ZXIg d2F5IGZvciB0cmFuc3BvcnQuDQpNYXliZSB3ZSBzaG91bGQgYWxsb3c8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPklQIGFkZHJlc3MgYW5kIG90aGVyIGlkZW50aXRpZXMgaW4gdGhlIHN1cHBsZW1l bnRhbCBpbmZvcm1hdGlvbiwNCmFzIHRoZXJlIGFyZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y PmNhc2VzIHdoZXJlIFBlZXItSURzIGFyZSBub3QgYXZhaWxhYmxlOjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+Jm5ic3A7IC0tIFRoaXJkIHBhcnR5IENETiBzZXJ2ZXJzIHdoaWNoIGRvIG5vdCB3 aXNoIHRvDQpwYXJ0aWNpcGF0ZSBpbiBSRUxPQUQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZu YnNwOyAtLSBPdGhlciBwcHNwIHN5c3RlbXMgd2hpY2ggb3BlcmF0ZXMgb24gdGhlaXIgb3duDQpS RUxPQUQgb3ZlcmxheXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAtLSBDRE4gc3lz dGVtcyB3aGljaCB3aXNoIHRvIGRvIGxvYWQgYmxhbmNpbmcgYnkNCnRoZW1zZWx2ZXM8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPk1heWJlIGFsbG93aW5nIGRpZmZlcmVudCB0eXBlcyBv ZiBpZGVudGl0aWVzIGFuZCBsZXR0aW5nDQp0aGUgcGVlcnMgY2hvb3NlIHRoZSB3YXkgZm9yPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj50cmFuc3BvcnQgaXMgYSBtb3JlIGZsZXhpYmxlIHdheS48 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XYW5nIFdlaTxicj4NCjxi cj4NClpURTxicj4NCkVtYWlsOiB3YW5nLndlaTEwOEB6dGUuY29tPC9mb250PjwvdHQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtEYXZpZCBBLiBCcnlhbiZxdW90Ow0KJmx0O2RicnlhbkBl dGhlcm5vdC5vcmcmZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPreivP7IyzogJm5ic3A7ZGF2aWRicnlhbkBnbWFpbC5jb208L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0xMS0wMyAyMjo0MzwvZm9udD4NCjx0ZCB3 aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt3YW5nLndl aTEwOCZxdW90OyAmbHQ7d2FuZy53ZWkxMDhAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPmd1eWluZ2ppZSAmbHQ7Z3V5aW5namllQGh1YXdlaS5jb20mZ3Q7LA0KJnF1b3Q7cHBzcEBp ZXRmLm9yZyZxdW90OyAmbHQ7cHBzcEBpZXRmLm9yZyZndDssICZxdW90O21lbmcueXUmcXVvdDsg Jmx0O21lbmcueXVAenRlLmNvbS5jbiZndDssDQomcXVvdDtoYW8uemhlbnd1JnF1b3Q7ICZsdDto YW8uemhlbnd1QHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtsaS5saWNodW4xJnF1b3Q7DQombHQ7bGku bGljaHVuMUB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFF1ZXN0aW9uIGFi b3V0IHVzaW5nIFBlZXItSUQgaW4NCnBlZXIgbGlzdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWVwLCB0aGlzIG5lZWRzIHRvIGJlIGlu Y2x1ZGVkIGluIHRoZSBkZXNpZ24sIGJ1dA0KSSBzdGlsbCB0aGluazxicj4NCnBlZXItSURzIGFy ZSB0aGUgcmlnaHQgd2F5IHRvIGdvIGZvciB0cmFuc3BvcnQuIFdlIG1heSB2ZXJ5IHdlbGwgbmVl ZDxicj4NCnRvIGluY2x1ZGUgSVAgYWRkcmVzcyBpbiB0aGUgc3VwcGxlbWVudGFsIGluZm9ybWF0 aW9uIHRoYXQgaXMgY2FycmllZDxicj4NCmluIGEgcGVlcmxpc3QgKG9yIHByb3ZpZGVkIGluIGEg c2VhcmNoIGZvciBmaW5kIHBlZXJzKSB0byBsZXQgcGVlcnM8YnI+DQpzZWxlY3QgYXBwcm9wcmlh dGUgbWF0Y2hlcy4gVGhlcmUgd2lsbCBiZSBtYW55IGJpdHMgb2Ygc3VwcGxlbWVudGFsPGJyPg0K aW5mb3JtYXRpb24gKG9mdGVuIHNlbGYtcmVwb3J0ZWQsIHNvIHVzZWQgYXMgYSBndWlkZSBvbmx5 KSB0aGF0IG1heSBiZTxicj4NCmluY2x1ZGVkIGluIGEgcGVlcmxpc3QgcmV0dXJuZWQgZnJvbSBh IHRyYWNrZXIgdG8gaGVscCBwZWVycyBjaG9vc2U8YnI+DQp3aGljaCBvdGhlciBwZWVycyB0aGV5 IHNob3VsZCBjb25uZWN0IHRvLiBUaGVzZSBjb3VsZCBpbmNsdWRlIElQPGJyPg0KYWRkcmVzcyAo d2hpY2ggY2FuIHRoZW4gYmUgdXNlZCB3aXRoIEFMVE8pLCBjYXBhYmlsaXRpZXMgc3VjaCBhczxi cj4NCmNvbm5lY3Rpb24gdHlwZSBvciBDUFUsIGV0Yy48YnI+DQo8YnI+DQpVc2luZyBQZWVyLUlE IGZvciB0aGUgYWN0dWFsIGNvbm5lY3Rpb24vcm91dGluZyBlbnN1cmVzIGFsbCBwZWVycyBhcmU8 YnI+DQpyZWFjaGFibGUgdmlhIG1lc3NhZ2VzIGJlZm9yZSBOQVQgdHJhdmVyc2FsIChhbmQgUkVM T0FEIHRoZW4gcHJvdmlkZXM8YnI+DQphIGdvb2QgbWVjaGFuaXNtIGZvciBOQVQgdHJhdmVyc2Fs KS4gSVAgYWRkcmVzc2VzIGNhbiBiZSBwcm92aWRlZDxicj4NCmFsb25nIHdpdGggb3RoZXIgc3Vw cGxlbWVudGFsIGluZm9ybWF0aW9uIHRvIGJlIHVzZWQgdG8gc2VsZWN0IHdoaWNoPGJyPg0KcGVl cihzKSBhcmUgYmVzdCB0byBjb25uZWN0IHRvLCBidXQgdXNpbmcgdGhlbSBmb3IgY29ubmVjdGl2 aXR5IGlzIGE8YnI+DQpiYWQgaWRlYS4gV2hlbiBwZWVycyBhcmUgYmVoaW5kIGNlcnRhaW4ga2lu ZHMgb2YgTkFUcywgZXZlbiBoYXZpbmc8YnI+DQp2YWxpZCBwZWVyIGFkZHJlc3NlcyB3aWxsIG5v dCBhbGxvdyB0aGVtIHRvIGNvbm5lY3QuIFdpdGggYSBESFQ8YnI+DQpzdHJ1Y3R1cmUgYW5kIHVz aW5nIFBlZXItSURzLCB0aGlzIGlzbid0IGEgY29uY2Vybi4gSWYgQUxUTyBpcyB1c2VkPGJyPg0K YW5kIHJlcXVpcmVzIElQIGFkZHJlc3NlcywgdGhpcyBjYW4gYmUgaW5jbHVkZWQgYXMgc3VwcGxl bWVudGFsPGJyPg0KaW5mb3JtYXRpb24sIGJ1dCBhdCBsZWFzdCBpbiBteSB0aG91Z2h0cyBzbyBm YXIsIFBlZXItSURzIHNlZW0gbGlrZSBhPGJyPg0KYmV0dGVyIGNob2ljZSBmb3IgbG9jYXRpb24g YW5kIGluaXRpYWwgbWVzc2FnZSByb3V0aW5nIGJldHdlZW4gcGVlcnMuPGJyPg0KPGJyPg0KRGF2 aWQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBXZWQsIE5vdiAzLCAyMDEwIGF0IDQ6MzggQU0s ICZuYnNwOyZsdDt3YW5nLndlaTEwOEB6dGUuY29tLmNuJmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0luIHRoZSBs YXRlc3QgZHJhZnQgb2YgcGVlciBwcm90b2NvbCBhbmQgdHJhY2tlciBwcm90b2NvbA0KaXQgaXMg cHJvcG9zZWQ8YnI+DQomZ3Q7IHRoYXQ8YnI+DQomZ3Q7IHRoZSBwZWVyIGxpc3Qgb25seSBjb250 YWlucyBQZWVyLUlELCBhbmQgUkVMT0FEIGlzIHVzZWQgZm9yIHBlZXIgbG9jYXRpb248YnI+DQom Z3Q7IGFuZCBOQVQ8YnI+DQomZ3Q7IHRyYXZlcnNhbDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFm dC1ndS1wcHNwLXBlZXItcHJvdG9jb2wtMDE6cGFnZSAzLTQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm cXVvdDtUaGUgcGVlciBjb250YWN0cyB0aGUgdHJhY2tlciB0byBvYnRhaW4gYSBQZWVybGlzdCBj b250YWluaW5nDQphPGJyPg0KJmd0OyBsaXN0IG9mIHBlZXJzIHBhcnRpY2lwYXRpbmcgaW4gdGhl IHBhcnRpY3VsYXIgc3dhcm0gdGhlIHBlZXIgaXM8YnI+DQomZ3Q7IGludGVyZXN0ZWQgaW4uPGJy Pg0KJmd0Ozxicj4NCiZndDsgLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsgKiBUaGlzIGxpc3QgZG9l cyBub3QgY29udGFpbiBJUCBhZGRyZXNzZXMsIGJ1dCByYXRoZXIgUkVMT0FEPGJyPg0KJmd0OyBQ ZWVyLUlEcy4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTXkgY29uY2VybiBh Ym91dCB0aGlzIGRlc2lnbiBjaG9pY2UgaXMgdGhhdCBzb21lIHJlbGF0ZWQgcHJvdG9jb2xzLA0K c3VjaCBhczxicj4NCiZndDsgQUxUTyw8YnI+DQomZ3Q7IGltcGxpY2l0bHkgYXNzdW1lIHRoYXQg dGhlIElQIGFkZHJlc3MgaXMgdXNlZCBpbiB0aGUgcGVlcmxpc3QuIElmDQp0aGU8YnI+DQomZ3Q7 IHRyYWNrZXI8YnI+DQomZ3Q7IG9ubHkgcmVjb3JkcyB0aGUgUGVlci1JRCwgaXQgd2lsbCBub3Qg YmUgYWJsZSB0byBjb25zdWx0IEFMVE8gc2VydmVyDQp1c2luZzxicj4NCiZndDsgdGhlPGJyPg0K Jmd0OyBSRUxPQUQgUGVlci1JRCwgd2hpY2ggaXMgc3BlY2lmaWMgdG8gdGhlIG92ZXJsYXkgYW5k IHBvc3NpYmx5IG5vdA0Ka25vd24gdG88YnI+DQomZ3Q7IHRoZSBBTFRPPGJyPg0KJmd0OyBzZXJ2 ZXIgbWFpbnRhaW5lZCBieSB0aGUgSVNQLiBJdCB3b3VsZCBhbHNvIHF1aXRlIGRpZmZpY3VsdCBm b3IgdGhlDQpBTFRPPGJyPg0KJmd0OyBzZXJ2ZXIgdG88YnI+DQomZ3Q7IHJlbGF0ZSB0aGUgUGVl ci1JRCB0byBhIG5ldHdvcmsgbG9jYXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgQUxUTyBh aW0gdG8gc2VydmUgZm9yIHNpbWlsYXIgYXBwbGljYXRpb25zIGFzIHBwc3AsIHdlIG5lZWQgdG8N CmZpbmQgb3V0IGE8YnI+DQomZ3Q7IHdheSB0byB1c2U8YnI+DQomZ3Q7IGl0IGZvciBQUFNQIGJh c2VkIHN5c3RlbXMuIE9uZSBzb2x1dGlvbiB3b3VsZCBiZSBhc2tpbmcgdGhlIHRyYWNrZXINCnRv PGJyPg0KJmd0OyByZWNvcmQgYm90aCB0aGU8YnI+DQomZ3Q7IElQIGFkZHJlc3MgYW5kIHRoZSBQ ZWVyIElELiBCdXQsIGl0IHdvdWxkIGJlIHN0cmFuZ2Ugbm90IHRvIHJldHVybg0KdGhlIElQPGJy Pg0KJmd0OyBhZGRyZXNzIHdoZW4gaXQ8YnI+DQomZ3Q7IGlzIGFscmVhZHkgYXZhaWxhYmxlIGlu IHRoZSB0cmFja2VyLiBBbm90aGVyIHdheSBpcyB0byBhc2sgcGVlcnMgdG8NCmNvbnN1bHQ8YnI+ DQomZ3Q7IHRoZSBBTFRPIHNlcnZlcjxicj4NCiZndDsgYWZ0ZXIgdGhlIElDRSBwcm9jZWR1cmUu IEhvd2V2ZXIsIHRoaXMgc29sdXRpb24gYnJpbmdzIG11Y2ggbW9yZSBvdmVyaGVhZC48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdhbmcgV2VpPGJyPg0KJmd0Ozxicj4N CiZndDsgWlRFPGJyPg0KJmd0OyBFbWFpbDogd2FuZy53ZWkxMDhAenRlLmNvbTxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuPGJyPg0KJmd0OyBU aGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0 dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5k Jm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3Rv Jm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtp biZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2lu YXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZu YnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJz cDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci48YnI+ DQomZ3Q7IFRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQm bmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRF Jm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLjxicj4NCiZndDs8YnI+DQo8YnI+DQo8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJp dHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9w ZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5i c3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRl bnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJz cDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZu YnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJz cDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24m bmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZu YnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJz cDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2Zv ciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNw O2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNw O3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3Rp ZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdl LiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVu Jm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5i c3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0002730F482577D1_=-- From lilichun@gmail.com Thu Nov 4 06:17:32 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691D83A6821 for ; Thu, 4 Nov 2010 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPhlUJpe+NYM for ; Thu, 4 Nov 2010 06:17:31 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E5D233A68FB for ; Thu, 4 Nov 2010 06:17:30 -0700 (PDT) Received: by ewy27 with SMTP id 27so995321ewy.31 for ; Thu, 04 Nov 2010 06:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OdrybMg4wrlNSw2braI56PYNZJEjh5qMgxgM+o45wsM=; b=r64sQqw9tiTQzS1g+2vy/zXLWjrPPo8gwmFcLcxGE14KUuqvgHqaEQMupFLUYI+yGO yfW+FkTYeMmPPkmTZ44uE1F6RRvXK+wij/Wj+fmArOHByO0bPFJLzvGr5Ar2pD/eR/y7 e3xxbUQ/NyYlAacUldg9cmTwDxv3mJtAY8hZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vbExRX6t3HRzqce6Pou0ZvlZ8t2Zh8QeQenz35Gwa+RbQor6OWNbjJOvFbUsOnER3K 1QrcHImfH0YMxGF9Kvrr94+wlkPR6exKiPXTEnJl803OQ36jnF4dQlwiacoRZtgH9/vi rNgC7bwBsim100RU3cw9IeQabre7cIRZslpgw= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr1899737wee.52.1288876653042; Thu, 04 Nov 2010 06:17:33 -0700 (PDT) Received: by 10.216.70.13 with HTTP; Thu, 4 Nov 2010 06:17:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Nov 2010 21:17:32 +0800 Message-ID: From: lichun li To: "David A. Bryan" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "hao.zhenwu" , "ppsp@ietf.org" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 13:17:32 -0000 Hi, David A peer may have multiple IPs, and mobile peers may change their IPs. So I believe that using peer ID to identify peer is a must. But using RELOAD should be an opt= ion. In RELOAD's NAT traversal mechanism, RELOAD protocol is only used to exchan= ge ICE parameters including candidate addresses and other parameters for connectivity checks. Then ICE connectivity checks are used to test connectivity of address pairs= . If candidate addresses can be extracted from peer list, there is no need to= use RELOAD for NAT traversal. When peers are behind certain kinds of NATs, they can=92t be connected via their host addresses or reflexive addresses. But they can be connected via their relayed addresses or proxy addresses. If these peers=92 relayed addresses or proxy addresses can be found in peer list, there is no need to use RELOAD for NAT traversal. There are also some disadvantages of using RELOAD. First, RELOAD is a heavy protocol. Introducing RELOAD complicates the implementation of PPSP peer, and requires deploying RELOAD's configuration/enrollment server. Second, exchanging ICE parameters with RELOAD APPATTACH requires O(log N) overlay hops, which causes high latency. Third, using RELOAD to discover TURN service node also requires O(log N) overlay hops. BR Lichun Li ZTE Corporation On Wed, Nov 3, 2010 at 10:43 PM, David A. Bryan wrote= : > Yep, this needs to be included in the design, but I still think > peer-IDs are the right way to go for transport. We may very well need > to include IP address in the supplemental information that is carried > in a peerlist (or provided in a search for find peers) to let peers > select appropriate matches. There will be many bits of supplemental > information (often self-reported, so used as a guide only) that may be > included in a peerlist returned from a tracker to help peers choose > which other peers they should connect to. These could include IP > address (which can then be used with ALTO), capabilities such as > connection type or CPU, etc. > > Using Peer-ID for the actual connection/routing ensures all peers are > reachable via messages before NAT traversal (and RELOAD then provides > a good mechanism for NAT traversal). IP addresses can be provided > along with other supplemental information to be used to select which > peer(s) are best to connect to, but using them for connectivity is a > bad idea. When peers are behind certain kinds of NATs, even having > valid peer addresses will not allow them to connect. With a DHT > structure and using Peer-IDs, this isn't a concern. If ALTO is used > and requires IP addresses, this can be included as supplemental > information, but at least in my thoughts so far, Peer-IDs seem like a > better choice for location and initial message routing between peers. > > David > > > > On Wed, Nov 3, 2010 at 4:38 AM, =A0 wrote: >> >> Hi all, >> >> =A0 =A0In the latest draft of peer protocol and tracker protocol it is p= roposed >> that >> the peer list only contains Peer-ID, and RELOAD is used for peer locatio= n >> and NAT >> traversal: >> >> draft-gu-ppsp-peer-protocol-01:page 3-4 >> >> "The peer contacts the tracker to obtain a Peerlist containing a >> list of peers participating in the particular swarm the peer is >> interested in. >> >> ... >> >> * This list does not contain IP addresses, but rather RELOAD >> Peer-IDs." >> >> >> My concern about this design choice is that some related protocols, such= as >> ALTO, >> implicitly assume that the IP address is used in the peerlist. If the >> tracker >> only records the Peer-ID, it will not be able to consult ALTO server usi= ng >> the >> RELOAD Peer-ID, which is specific to the overlay and possibly not known = to >> the ALTO >> server maintained by the ISP. It would also quite difficult for the ALTO >> server to >> relate the Peer-ID to a network location. >> >> As ALTO aim to serve for similar applications as ppsp, we need to find o= ut a >> way to use >> it for PPSP based systems. One solution would be asking the tracker to >> record both the >> IP address and the Peer ID. But, it would be strange not to return the I= P >> address when it >> is already available in the tracker. Another way is to ask peers to cons= ult >> the ALTO server >> after the ICE procedure. However, this solution brings much more overhea= d. >> >> >> >> Wang Wei >> >> ZTE >> Email: wang.wei108@zte.com >> >> >> >> >> -------------------------------------------------------- >> ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained= =A0in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organi= zation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0n= amed=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not= =A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication= =A0to=A0others. >> This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confi= dential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. >> This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. >> > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > From davidbryan@gmail.com Thu Nov 4 07:54:38 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37EA3A6A1A for ; Thu, 4 Nov 2010 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcEL7HYbK8Vm for ; Thu, 4 Nov 2010 07:54:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3998A3A69C9 for ; Thu, 4 Nov 2010 07:54:36 -0700 (PDT) Received: by wyb28 with SMTP id 28so1971541wyb.31 for ; Thu, 04 Nov 2010 07:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bkjPa9RT8LUCV1ueJG19YlFXehgfYwyqbp3m1jus5N8=; b=LhXlhx8OeJc/js2pw0/8CbbalPihrcU044PXiQxcp68EUeBllq+F912/ySIuoKwtf9 mOofRDUfIsmhlo/L3DLTTuKpSQCRcs5IsE734E9huWro7HXhPuqGZJv5+4ity46HT80u sMEA+Rikjn5gJ+DdAkY9ma9Mv1l9JPsgw1vv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Pc2EjbQPQ7uhyrqrPuwVKVMZ428Mk9yM/5DPO0LBVo9zlbJi4Lrh4DXqz+VgyBeCfk 14Z1LAqaejNC3+/PYAqTrhh2uMOc1d8XK+2Z7y9sTjaa7OGT2ewECEgvHdIaioCjhTvf NR6HGZDpbr/WmGJEjwUJa/5s6u5UQ5O47alb4= MIME-Version: 1.0 Received: by 10.227.127.66 with SMTP id f2mr849156wbs.81.1288882484245; Thu, 04 Nov 2010 07:54:44 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.207.195 with HTTP; Thu, 4 Nov 2010 07:54:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Nov 2010 10:54:44 -0400 X-Google-Sender-Auth: bFIxcLr0Nl5Su01cdnu606BVvMc Message-ID: From: "David A. Bryan" To: lichun li Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "hao.zhenwu" , "ppsp@ietf.org" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 14:54:38 -0000 Hi, comments inline... On Thu, Nov 4, 2010 at 9:17 AM, lichun li wrote: > Hi, David > > A peer may have multiple IPs, and mobile peers may change their IPs. > So I believe that > using peer ID to identify peer is a must. But using RELOAD should be an o= ption. Yep, that is another good reason to use Peer-ID. I'm a bit confused what you have in mind here, however. If you want to use PeerIDs for routing, you need to provide some mechanism to locate peers based on that ID. The alternatives I see off the top of my head are a large unstructured P2P network, which has many problems (including no guarantee of routing success), defining a completely new DHT and protocol (which seems pointless since the IETF has a protocol for this already) or the tracker must serve as a registration server ala SIP (I ask it to provide the IP address/relay address for a given PeerID everytime I need to connect). I really don't like the idea of a centralized registration server. I might be missing another possibility however, so I'd be curious what you had in mind to allow you to locate a peer given the Peer-Id. I'd definitely be fine with designing the tracker protocol in such a way that you could use different peer protocols, with a RELOAD style peer protocol being only one option. For example, I could imagine small deployments wanting to just use an unstructured mesh between the peers or something. In a private, managed network, they may not even need to worry about NAT traversal. However, for an internet wide deployment, after thinking for a while, it really looks like we need something like RELOAD, although I'm certainly still interested in hearing other options and recognize the complexity it introduces. more comments below... > In RELOAD's NAT traversal mechanism, RELOAD protocol is only used to exch= ange > ICE parameters including candidate addresses and other parameters for > connectivity checks. > Then ICE connectivity checks are used to test connectivity of address pai= rs. > If candidate addresses can be extracted from peer list, there is no need = to use > RELOAD for NAT traversal. > > When peers are behind certain kinds of NATs, they can=92t be connected > via their host addresses > or reflexive addresses. But they can be connected via their relayed > addresses or proxy addresses. > If these peers=92 relayed addresses or proxy addresses can be found in > peer list, there is no need to > use RELOAD for NAT traversal. Peers can of course be reached via relayed or proxy addresses, but if this information is stored in the tracker, it seems like a big problem with churn. With RELOAD you have multiple paths to route via the DHT to reach the peer. I have only taken a quick look, so I may be missing something, but in an approach were some peer is serving as a designated relay or proxy (for example the proposal in draft-li-ppsp-nat-traversal), don't we need to build in a new mechanism to keep multiple connections, and would need to send an update to the tracker each time a relay or proxy leaves? I'm also worried about orphans here. If I am connected via a proxy peer and my proxy dies or leaves, no one (except maybe the tracker, who I have a direct connection to?) could reach me. We then need to add protocol mechanisms to: 1) Provide registrar-style capabilities that need to be built into the tracker to provide Peer-ID to IP/relay peer IP mapping in place of DHT-style routing 2) Detect that my proxy has failed (tracker pings? peer pings? How often) 3) Decide which address to try if I have multiple relays, or else send requests over many paths? 4) Update the proxy and peers I am providing proxy services to when I leave= . 5) Fall back that if I fail to a reach a peer via relay, I need to notify the tracker, which then either has to serve as a relay or else it must have mechanisms to invalidate the current proxy peer on record, contact the target peer, inform it that it has a new proxy, negotiate the connection and then finally provide the new proxy to the sending peer. With all these extra capabilities added, I'm personally not convinced this is actually simpler than a DHT. If you don't add this, this approach does have less overhead than a full DHT, but also provides a far more brittle system. I'm not saying it isn't worth considering, but the current proposal is far too simplistic to actually work, and until I see a proposal that addresses all these concerns and is still lightweight, I don't think the overhead of a RELOAD style DHT is so high when you consider what it gains you. > There are also some disadvantages of using RELOAD. First, RELOAD is a > heavy protocol. Well, that is debatable. It certainly isn't tiny, but the capabilities it provides are quite large, and the encoding is actually rather light (personally I like text protocols, but since RELOAD is binary, it is lighter). I'm not yet convinced that by the time you build in all the things needed for an approach like draft-li-ppsp-nat-traversal, with the error handling capabilities I mentioned above, plus add registrar-style peer-ID to address mapping in the tracker that you won't actually have just as much complexity. > Introducing RELOAD complicates the implementation of PPSP peer, and > requires deploying > RELOAD's configuration/enrollment server. It is true that RELOAD will complicate the implementation of the peer slightly, but again, see above, I don't think it is much more than other approaches. The configuration/enrollment server is contacted once, at enrollment, not even at join time. Second, exchanging ICE > parameters with RELOAD > APPATTACH requires O(log N) overlay hops, which causes high latency. > Third, using RELOAD to discover TURN service node also requires O(log > N) overlay hops. True, but the O(log N) cost is not on each data packet, it is at setup time. Not sure about this yet, but my gut tells me that this isn't likely to be a problem, although we need to carefully consider channel changes. A topology aware DHT, combined with an ALTO server for peer selection could radically reduce this cost. This is a big concern however, and I'd like to hear the experiences of those who have deployed systems. I'm certainly not saying RELOAD is the only choice. We have been debating this ourselves for sometime. As you point out, there are some drawbacks, but I think the complexity of other solutions, and particularly the difficulty in making them properly handle NAT traversal under high churn is a major problem. If we can make a simpler approach than a DHT work, that would be great, I'm just not convinced we can yet. David > > > BR > Lichun Li > ZTE Corporation > > On Wed, Nov 3, 2010 at 10:43 PM, David A. Bryan wro= te: >> Yep, this needs to be included in the design, but I still think >> peer-IDs are the right way to go for transport. We may very well need >> to include IP address in the supplemental information that is carried >> in a peerlist (or provided in a search for find peers) to let peers >> select appropriate matches. There will be many bits of supplemental >> information (often self-reported, so used as a guide only) that may be >> included in a peerlist returned from a tracker to help peers choose >> which other peers they should connect to. These could include IP >> address (which can then be used with ALTO), capabilities such as >> connection type or CPU, etc. >> >> Using Peer-ID for the actual connection/routing ensures all peers are >> reachable via messages before NAT traversal (and RELOAD then provides >> a good mechanism for NAT traversal). IP addresses can be provided >> along with other supplemental information to be used to select which >> peer(s) are best to connect to, but using them for connectivity is a >> bad idea. When peers are behind certain kinds of NATs, even having >> valid peer addresses will not allow them to connect. With a DHT >> structure and using Peer-IDs, this isn't a concern. If ALTO is used >> and requires IP addresses, this can be included as supplemental >> information, but at least in my thoughts so far, Peer-IDs seem like a >> better choice for location and initial message routing between peers. >> >> David >> >> >> >> On Wed, Nov 3, 2010 at 4:38 AM, =A0 wrote: >>> >>> Hi all, >>> >>> =A0 =A0In the latest draft of peer protocol and tracker protocol it is = proposed >>> that >>> the peer list only contains Peer-ID, and RELOAD is used for peer locati= on >>> and NAT >>> traversal: >>> >>> draft-gu-ppsp-peer-protocol-01:page 3-4 >>> >>> "The peer contacts the tracker to obtain a Peerlist containing a >>> list of peers participating in the particular swarm the peer is >>> interested in. >>> >>> ... >>> >>> * This list does not contain IP addresses, but rather RELOAD >>> Peer-IDs." >>> >>> >>> My concern about this design choice is that some related protocols, suc= h as >>> ALTO, >>> implicitly assume that the IP address is used in the peerlist. If the >>> tracker >>> only records the Peer-ID, it will not be able to consult ALTO server us= ing >>> the >>> RELOAD Peer-ID, which is specific to the overlay and possibly not known= to >>> the ALTO >>> server maintained by the ISP. It would also quite difficult for the ALT= O >>> server to >>> relate the Peer-ID to a network location. >>> >>> As ALTO aim to serve for similar applications as ppsp, we need to find = out a >>> way to use >>> it for PPSP based systems. One solution would be asking the tracker to >>> record both the >>> IP address and the Peer ID. But, it would be strange not to return the = IP >>> address when it >>> is already available in the tracker. Another way is to ask peers to con= sult >>> the ALTO server >>> after the ICE procedure. However, this solution brings much more overhe= ad. >>> >>> >>> >>> Wang Wei >>> >>> ZTE >>> Email: wang.wei108@zte.com >>> >>> >>> >>> >>> -------------------------------------------------------- >>> ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained= =A0in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organi= zation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0n= amed=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not= =A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication= =A0to=A0others. >>> This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0conf= idential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individua= l=A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0r= eceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0= of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are= =A0those=A0of=A0the=A0individual=A0sender. >>> This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. >>> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> > From lilichun@gmail.com Thu Nov 4 20:02:50 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638393A67C2 for ; Thu, 4 Nov 2010 20:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeDp6ggM74rE for ; Thu, 4 Nov 2010 20:02:49 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 8A46D3A67AE for ; Thu, 4 Nov 2010 20:02:48 -0700 (PDT) Received: by wwb22 with SMTP id 22so125220wwb.1 for ; Thu, 04 Nov 2010 20:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7p7nQp8suSM7b7pkmlOBI82CLbqnLx6qqc/dfwmFksA=; b=wa1GJDuRXtv+gcfQovlbsu/sPpJnQTxnNXNPyIdl4+vsCkqZjwe0S6IfPqTluVAZCL IruyzNW689s5/d5kpoUAQmTiO8JyezGKsollHNwJgMXg2DocLGmh5vouXolHDlMkj7JX EW65pEATXUEPbJp2n1AlTj0Mm0LGxgHgm2JxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GtOSgpRsaumb3oUboAWtkxNoLqo4fieKkGLsBUZe641Abj9IXKKMcOFqMO9H+bAsQf uiiKbwIDtsSVfPhr7hSZl57TcXezpE6q142PCTSCf1ASHUU/6JvjsRQ9Y3iYs8wp4oO5 Fj1GjRQ9K7+Tnjkhy4N9Ni5Mvt8U7DceP3YQM= MIME-Version: 1.0 Received: by 10.216.87.20 with SMTP id x20mr615592wee.52.1288926178887; Thu, 04 Nov 2010 20:02:58 -0700 (PDT) Received: by 10.216.70.13 with HTTP; Thu, 4 Nov 2010 20:02:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Nov 2010 11:02:58 +0800 Message-ID: From: lichun li To: "David A. Bryan" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "hao.zhenwu" , "ppsp@ietf.org" Subject: Re: [ppsp] Question about using Peer-ID in peer list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 03:02:50 -0000 Hi, comments inline On Thu, Nov 4, 2010 at 10:54 PM, David A. Bryan wrote= : > Hi, comments inline... > > On Thu, Nov 4, 2010 at 9:17 AM, lichun li wrote: >> Hi, David >> >> A peer may have multiple IPs, and mobile peers may change their IPs. >> So I believe that >> using peer ID to identify peer is a must. But using RELOAD should be an = option. > > Yep, that is another good reason to use Peer-ID. I'm a bit confused > what you have in mind here, however. If you want to use PeerIDs for > routing, you need to provide some mechanism to locate peers based on > that ID. The alternatives I see off the top of my head are a large > unstructured P2P network, which has many problems (including no > guarantee of routing success), defining a completely new DHT and > protocol (which seems pointless since the IETF has a protocol for this > already) or the tracker must serve as a registration server ala SIP (I > ask it to provide the IP address/relay address for a given PeerID > everytime I need to connect). I really don't like the idea of a > centralized registration server. I might be missing another > possibility however, so I'd be curious what you had in mind to allow > you to locate a peer given the Peer-Id. > > I'd definitely be fine with designing the tracker protocol in such a > way that you could use different peer protocols, with a RELOAD style > peer protocol being only one option. For example, I could imagine > small deployments wanting to just use an unstructured mesh between the > peers or something. In a private, managed network, they may not even > need to worry about NAT traversal. However, for an internet wide > deployment, after thinking for a while, it really looks like we need > something like RELOAD, although I'm certainly still interested in > hearing other options and recognize the complexity it introduces. > I didn't say locating peer with peer ID. I think using RELOAD is an option, because RELOAD is not the best solution for locating peer and NAT traversal at least in some scenarios. I have proposed another solution without RELOAD in draft-li-ppsp-nat-traversal. Both solutions have some pros and cons. Also, as you pointed out, NAT traversal is not required in some scenarios. > more comments below... > >> In RELOAD's NAT traversal mechanism, RELOAD protocol is only used to exc= hange >> ICE parameters including candidate addresses and other parameters for >> connectivity checks. >> Then ICE connectivity checks are used to test connectivity of address pa= irs. >> If candidate addresses can be extracted from peer list, there is no need= to use >> RELOAD for NAT traversal. >> >> When peers are behind certain kinds of NATs, they can=92t be connected >> via their host addresses >> or reflexive addresses. But they can be connected via their relayed >> addresses or proxy addresses. >> If these peers=92 relayed addresses or proxy addresses can be found in >> peer list, there is no need to >> use RELOAD for NAT traversal. > > Peers can of course be reached via relayed or proxy addresses, but if > this information is stored in the tracker, it seems like a big problem > with churn. With RELOAD you have multiple paths to route via the DHT > to reach the peer. > > I have only taken a quick look, so I may be missing something, but in > an approach were some peer is serving as a designated relay or proxy > (for example the proposal in draft-li-ppsp-nat-traversal), don't we > need to build in a new mechanism to keep multiple connections, and > would need to send an update to the tracker each time a relay or proxy > leaves? I'm also worried about orphans here. If I am connected via a > proxy peer and my proxy dies or leaves, no one (except maybe the > tracker, who I have a direct connection to?) could reach me. > > We then need to add protocol mechanisms to:> 1) Provide registrar-style c= apabilities that need to be built into the > tracker to provide Peer-ID to IP/relay peer IP mapping in place of > DHT-style routing > 2) Detect that my proxy has failed (tracker pings? peer pings? How often) > 3) Decide which address to try if I have multiple relays, or else send > requests over many paths? > 4) Update the proxy and peers I am providing proxy services to when I lea= ve. > 5) Fall back that if I fail to a reach a peer via relay, I need to > notify the tracker, which then either has to serve as a relay or else > it must have mechanisms to invalidate the current proxy peer on > record, contact the target peer, inform it that it has a new proxy, > negotiate the connection and then finally provide the new proxy to the > sending peer. > > > With all these extra capabilities added, I'm personally not convinced > this is actually simpler than a DHT. If you don't add this, this > approach does have less overhead than a full DHT, but also provides a > far more brittle system. > > I'm not saying it isn't worth considering, but the current proposal is > far too simplistic to actually work, and until I see a proposal that > addresses all these concerns and is still lightweight, I don't think > the overhead of a RELOAD style DHT is so high when you consider what > it gains you. > About the 5 mechanisms you proposed, I agree that most of them are required. However, Reload's client routing also requires similar mechanisms. Moreover, comparing with RELOAD's other mechanisms (peer routing, overlay maintaining, fetching/storing/replicating, diagnostics, self-tuning and TURN service discovery), these mechanisms are much simpler. Mechanism 1) is also required by using ALTO and STAT_QUERY. NAT traversal just utilizes this existing mechanism. About mechanism 2), tracker protocol has a keepalive message. I think peer protocol may also need a keepalive message not just for NAT traversal. Mechanism 5) is not necessary. Peer can simply update peer list, and let mechanism 3) and 4) update relayed/proxy address. >> There are also some disadvantages of using RELOAD. First, RELOAD is a >> heavy protocol. > > Well, that is debatable. It certainly isn't tiny, but the capabilities > it provides are quite large, and the encoding is actually rather light > (personally I like text protocols, but since RELOAD is binary, it is > lighter). > > I'm not yet convinced that by the time you build in all the things > needed for an approach like draft-li-ppsp-nat-traversal, with the > error handling capabilities I mentioned above, plus add > registrar-style peer-ID to address mapping in the tracker that you > won't actually have just as much complexity. > >> Introducing RELOAD complicates the implementation of PPSP peer, and >> requires deploying >> RELOAD's configuration/enrollment server. > > It is true that RELOAD will complicate the implementation of the peer > slightly, but again, see above, I don't think it is much more than > other approaches. The configuration/enrollment server is contacted > once, at enrollment, not even at join time. > > > Second, exchanging ICE >> parameters with RELOAD >> APPATTACH requires O(log N) overlay hops, which causes high latency. >> Third, using RELOAD to discover TURN service node also requires O(log >> N) overlay hops. > > True, but the O(log N) cost is not on each data packet, it is at setup > time. Not sure about this yet, but my gut tells me that this isn't > likely to be a problem, although we need to carefully consider channel > changes. A topology aware DHT, combined with an ALTO server for peer > selection could radically reduce this cost. This is a big concern > however, and I'd like to hear the experiences of those who have > deployed systems. > Some scenarios have strict requirements on latency. We should consider not using RELOAD in these scenarios > I'm certainly not saying RELOAD is the only choice. We have been > debating this ourselves for sometime. As you point out, there are some > drawbacks, but I think the complexity of other solutions, and > particularly the difficulty in making them properly handle NAT > traversal under high churn is a major problem. If we can make a > simpler approach than a DHT work, that would be great, I'm just not > convinced we can yet. > > David > With the mechanisms you proposed, handling churn wouldn't be a problem. As I analyzed above, I think these mechanisms are much simpler compared with RELOAD. >> >> >> BR >> Lichun Li >> ZTE Corporation >> >> On Wed, Nov 3, 2010 at 10:43 PM, David A. Bryan wr= ote: >>> Yep, this needs to be included in the design, but I still think >>> peer-IDs are the right way to go for transport. We may very well need >>> to include IP address in the supplemental information that is carried >>> in a peerlist (or provided in a search for find peers) to let peers >>> select appropriate matches. There will be many bits of supplemental >>> information (often self-reported, so used as a guide only) that may be >>> included in a peerlist returned from a tracker to help peers choose >>> which other peers they should connect to. These could include IP >>> address (which can then be used with ALTO), capabilities such as >>> connection type or CPU, etc. >>> >>> Using Peer-ID for the actual connection/routing ensures all peers are >>> reachable via messages before NAT traversal (and RELOAD then provides >>> a good mechanism for NAT traversal). IP addresses can be provided >>> along with other supplemental information to be used to select which >>> peer(s) are best to connect to, but using them for connectivity is a >>> bad idea. When peers are behind certain kinds of NATs, even having >>> valid peer addresses will not allow them to connect. With a DHT >>> structure and using Peer-IDs, this isn't a concern. If ALTO is used >>> and requires IP addresses, this can be included as supplemental >>> information, but at least in my thoughts so far, Peer-IDs seem like a >>> better choice for location and initial message routing between peers. >>> >>> David >>> >>> >>> >>> On Wed, Nov 3, 2010 at 4:38 AM, =A0 wrote: >>>> >>>> Hi all, >>>> >>>> =A0 =A0In the latest draft of peer protocol and tracker protocol it is= proposed >>>> that >>>> the peer list only contains Peer-ID, and RELOAD is used for peer locat= ion >>>> and NAT >>>> traversal: >>>> >>>> draft-gu-ppsp-peer-protocol-01:page 3-4 >>>> >>>> "The peer contacts the tracker to obtain a Peerlist containing a >>>> list of peers participating in the particular swarm the peer is >>>> interested in. >>>> >>>> ... >>>> >>>> * This list does not contain IP addresses, but rather RELOAD >>>> Peer-IDs." >>>> >>>> >>>> My concern about this design choice is that some related protocols, su= ch as >>>> ALTO, >>>> implicitly assume that the IP address is used in the peerlist. If the >>>> tracker >>>> only records the Peer-ID, it will not be able to consult ALTO server u= sing >>>> the >>>> RELOAD Peer-ID, which is specific to the overlay and possibly not know= n to >>>> the ALTO >>>> server maintained by the ISP. It would also quite difficult for the AL= TO >>>> server to >>>> relate the Peer-ID to a network location. >>>> >>>> As ALTO aim to serve for similar applications as ppsp, we need to find= out a >>>> way to use >>>> it for PPSP based systems. One solution would be asking the tracker to >>>> record both the >>>> IP address and the Peer ID. But, it would be strange not to return the= IP >>>> address when it >>>> is already available in the tracker. Another way is to ask peers to co= nsult >>>> the ALTO server >>>> after the ICE procedure. However, this solution brings much more overh= ead. >>>> >>>> >>>> >>>> Wang Wei >>>> >>>> ZTE >>>> Email: wang.wei108@zte.com >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------- >>>> ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained= =A0in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organi= zation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0n= amed=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not= =A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication= =A0to=A0others. >>>> This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0con= fidential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individu= al=A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0= received=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator= =A0of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0ar= e=A0those=A0of=A0the=A0individual=A0sender. >>>> This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0b= y=A0ZTE=A0Anti-Spam=A0system. >>>> >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >>> >> > --=20 Sincerely yours, Lichun Li ZTE Corporation From haibinsong.cn@gmail.com Thu Nov 4 23:39:57 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEFB3A68A7; Thu, 4 Nov 2010 23:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCWXW34hle1t; Thu, 4 Nov 2010 23:39:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 490003A68A5; Thu, 4 Nov 2010 23:39:56 -0700 (PDT) Received: by ywp6 with SMTP id 6so2112223ywp.31 for ; Thu, 04 Nov 2010 23:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:references; bh=qx6J8dIXMrk/CCelm9GCLGqMloBe9wNSeX/VmKbxNXM=; b=Tu5umpoU5ITWZ08yhXJ991y8FrXt4PBRsEGBAH50S2U+5OxIfkPkI0FJT8DgBComIX ypByUW9OITFMjUA+RBTMlq7pJ1PDE0wewDORTOwcluqYx17XT3xVOYBq74iWRb+0ZWNn smnOD90N56P8pO8qdE19s0F0hhrnvi+x/4pTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date :references; b=FA0XM3LWa8NXcy0Zwe6xUTKN+tpxyPJBL5LSkrm47pjALgCC13qQJhTYaaRnchw7va 9jZetgo8uiVpU9DaOg/lB938azXdsfUJXx+E0hiZKkei6HhdHVcu58i3VvcPNDAPiB4m NQh60apdqXvx3y0bkQddu5F65h3z8pKMbTT5M= Received: by 10.150.230.7 with SMTP id c7mr701962ybh.72.1288939208057; Thu, 04 Nov 2010 23:40:08 -0700 (PDT) Received: from [192.168.11.2] ([123.120.31.209]) by mx.google.com with ESMTPS id r18sm707409yba.15.2010.11.04.23.39.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 23:40:02 -0700 (PDT) Message-Id: <0ED29060-E8CE-4310-AFF1-5DA30C8FF04F@gmail.com> From: Haibin To: "p2prg-owner@irtf.org" , "decade@ietf.org" , "ppsp@ietf.org" , "alto@ietf.org" , "p2psip@ietf.org" In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Date: Fri, 5 Nov 2010 14:40:33 +0800 References: Subject: [ppsp] The International Industrial and Academic Symposium on DECADE and ALTO cancelled X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 06:39:57 -0000 Dear guys, Thank you for your attention to this meeting. We have received some = emails of confirmation. But because of some active experts can not make = to this meeting, we have decided to cancel it. I'm very sorry for the = late notification.=20 Thanks, Haibin= From Martin.Stiemerling@neclab.eu Fri Nov 5 02:09:29 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB90B3A6768 for ; Fri, 5 Nov 2010 02:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6YAGoARi3iX for ; Fri, 5 Nov 2010 02:09:28 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 2BC973A6778 for ; Fri, 5 Nov 2010 02:09:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 960B328000178; Fri, 5 Nov 2010 10:09:39 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo-KUD8+ovXO; Fri, 5 Nov 2010 10:09:39 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 76B352800015D; Fri, 5 Nov 2010 10:09:24 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.152]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Fri, 5 Nov 2010 10:09:24 +0100 From: Martin Stiemerling To: Fabio Hecht Thread-Topic: [ppsp] Pull or Pushed-based P2P Streaming? Thread-Index: AQHLdz+8yBdkcoGGStqt/onxAOi0TZNXdWCAgAhCrMD///v/AIAC7l0Q Date: Fri, 5 Nov 2010 09:09:23 +0000 Message-ID: References: <201010291439078752128@chinamobile.com> <201010291603144378146@chinamobile.com> <1288340667.2137.10.camel@bart3> <1288790330.2381.126.camel@bart3> In-Reply-To: <1288790330.2381.126.camel@bart3> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.207] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 09:09:29 -0000 SGkgRmFiaWFuLA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBG YWJpbyBIZWNodCBbbWFpbHRvOmhlY2h0QGlmaS51emguY2hdDQo+IFNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgMDMsIDIwMTAgMjoxOSBQTQ0KPiBUbzogTWFydGluIFN0aWVtZXJsaW5nDQo+IENj OiB6aGFuZ3l1bmZlaTsgcHBzcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3Bwc3BdIFB1bGwg b3IgUHVzaGVkLWJhc2VkIFAyUCBTdHJlYW1pbmc/DQo+IA0KPiBIaSBNYXJ0aW4sDQo+IA0KPiAN Cj4gT24gV2VkLCAyMDEwLTExLTAzIGF0IDEyOjM4ICswMDAwLCBNYXJ0aW4gU3RpZW1lcmxpbmcg d3JvdGU6DQo+ID4gSGkgRmFiaW8sIGFsbCwNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBwc3At Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mDQo+ID4gPiBGYWJpbyBIZWNodA0KPiA+ ID4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDI5LCAyMDEwIDEwOjI0IEFNDQo+ID4gPiBUbzogemhh bmd5dW5mZWkNCj4gPiA+IENjOiBwcHNwQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW3Bw c3BdIFB1bGwgb3IgUHVzaGVkLWJhc2VkIFAyUCBTdHJlYW1pbmc/DQo+ID4gPg0KPiA+ID4NCj4g PiA+IFB1c2ggb25seSB3b3JrcyBpZiB5b3UgY2FuIG1ha2UgcmVhc29uYWJsZSBRb1MgYXNzdW1w dGlvbnMgYW5kDQo+IHRoZXJlIGlzDQo+ID4gPiBhbiBvYnZpb3VzIHdheSBmb3IgcGVlcnMgdG8g Y29vcmRpbmF0ZSB3aGF0IHRoZXkgc3Vic2NyaWJlIHRvLg0KPiA+ID4gTm9ybWFsbHksDQo+ID4g PiBtdWx0aXBsZSB0cmVlcyBhcmUgdXNlZC4gVGhpcyBtYWtlcyB0aGUgZGlzdHJpYnV0aW9uIG5v dCB2ZXJ5DQo+IGZsZXhpYmxlLA0KPiA+ID4gYXMgdGhlIHNvdXJjZSBuZWVkcyB0byBkZWZpbmUg aG93IG1hbnkgdHJlZXMgdGhlcmUgd2lsbCBiZQ0KPiBiZWZvcmVoYW5kLg0KPiA+DQo+ID4gVGhh dCdzIG9uZSB2aWV3LCBidXQgdGhlcmUgYXJlIHB1c2gtYmFzZWQgYXBwcm9hY2hlcyBiYXNlZCBv biBuZXR3b3JrDQo+IGNvZGluZyAoaW4gcGFwZXIgd29yaywgYnV0IGFsc28gZGVwbG95ZWQpLg0K PiANCj4gVHJ1ZSwgdGhhdCdzIGFsc28gcG9zc2libGUuIERvIHlvdSBoYXZlIGEgcmVmZXJlbmNl IHRvIGEgZGVwbG95ZWQgb25lPw0KDQpTb3JyeSBmb3IgdGFraW5nIHNvIGxvbmcsIGl0IHRvb2sg YSB3aGlsZSB0byBmaW5kIHRoaXMgYWdhaW46DQpodHRwOi8vd3d3LnJhdnkuY29tLw0KDQpIb3dl dmVyLCBpdCBzZWVtcyB0aGF0IHRoZSB3ZWIgc2l0ZSBpcyBnb25lLiANCg0KWy4uLl0NCg0KPiA+ DQo+ID4gPg0KPiA+ID4gU28sIGluIG15IG9waW5pb24sIFBQU1Agc2hvdWxkIGltcGxlbWVudCBh IHB1bGwgcHJvdG9jb2wuIFBlcmhhcHMNCj4gdGhlDQo+ID4gPiBhYmlsaXR5IG9mIHN3aXRjaGlu ZyB0byBwdXNoIGNvdWxkIGJlIGFkZGVkIGFzIGFuIGFkZGl0aW9uYWwNCj4gKG9wdGlvbmFsKQ0K PiA+ID4gZmVhdHVyZS4NCj4gPg0KPiA+IE9wdGlvbmFsIGZlYXR1cmUgZG9lcyB0eXBpY2FsbHkg bWVhbiB0aGF0IGl0IGlzIG5vdCBpbXBsZW1lbnRlZC4NCj4gPg0KPiA+IEkgd291bGQgYXJndWUg Zm9yIGxldHRpbmcgdGhlIHBlZXJzIHRvIGZpZ3VyZSBvdXQgd2hlbiB0aGV5IGpvaW4gdGhlDQo+ IHN5c3RlbSB3aGF0IHNjaGVtZSBpcyB1c2VkIGZvciB0aGUgY2h1bmsgZGlmZnVzaW9uLg0KPiA+ DQo+ID4gVGhlcmUgY291bGQgYSBiZSAic2Vzc2lvbi9zeXN0ZW0gam9pbiIgd2hlcmUgdGhlIG90 aGVyIHBlZXJzIChvciB0aGUNCj4gdHJhY2tlcikgYW5ub3VuY2Ugd2hldGhlciBwdXNoLCBwdWxs LCBwdXNoL3B1bGwgaXMgdXNlZC4gVGhpcyB3b3VsZA0KPiBhbHNvIHN1cHBvcnQgdGhlIGNhc2Ug d2hlcmUgYSBzeXN0ZW0gc3VwcG9ydHMgYSBzcGVjaWFsIHZhbmlsbGEgZmxhdm9yDQo+IG9mIHB1 bGwuDQo+IA0KPiBJIHRoaW5rIHRoaXMgbWF5IGJlIGNvbXBsaWNhdGVkLCBzaW5jZSB0aGVyZSBh cmUgc2V2ZXJhbCB3YXlzIHRvDQo+IGNvbWJpbmUNCj4gcHVzaCBhbmQgcHVsbC4NCg0KUmlnaHQs IGJ1dCBQUFNQIGp1c3QgbmVlZHMgdG8gZGVmaW5lIGEgbWVjaGFuaXNtIGhvdyB0aGUgcGVlcnMg bGVhcm4gd2hpY2ggaXMgdXNlZCwgaS5lLiwgYSB0YWcgb3IgYSBmaWVsZCBpbiB0aGUgcHJvdG9j b2wuDQoNCiAgTWFydGluDQoNCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEZhYmlvDQo+IA0KPiA+DQo+ ID4gICBNYXJ0aW4NCj4gPg0KPiA+DQoNCg0KDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1 DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbg0K TkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0 b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQN Cg== From omer@rayv.com Fri Nov 5 03:47:42 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EE63A684B for ; Fri, 5 Nov 2010 03:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDcEEMmWE-Au for ; Fri, 5 Nov 2010 03:47:41 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DCA3D3A681F for ; Fri, 5 Nov 2010 03:47:40 -0700 (PDT) Received: by iwn40 with SMTP id 40so2676533iwn.31 for ; Fri, 05 Nov 2010 03:47:52 -0700 (PDT) Received: by 10.42.1.6 with SMTP id 6mr1265110ice.100.1288954072236; Fri, 05 Nov 2010 03:47:52 -0700 (PDT) From: Omer Luzzatti References: <201010291439078752128@chinamobile.com> <201010291603144378146@chinamobile.com> <1288340667.2137.10.camel@bart3> <1288790330.2381.126.camel@bart3> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLdz+8yBdkcoGGStqt/onxAOi0TZNXdWCAgAhCrMD///v/AIAC7l0QgAAbTvA= Date: Fri, 5 Nov 2010 12:48:33 +0200 Message-ID: <203e3bb11753aaf6e212385bfe502374@mail.gmail.com> To: Martin Stiemerling , Fabio Hecht Content-Type: text/plain; charset=ISO-8859-1 Cc: ppsp@ietf.org Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 10:47:42 -0000 Hey Martin and Fabio, Sorry for not following this thread before. We at RayV are indeed combining push-pull protocols utilizing Network-coding/PET techniques. Generally speaking the way it works is that the peers push only among themselves, however to guarantee SLAs the reliable sources, based in our own POPs, are being called with a Pull protocol to provide the missing data (e.g. the base vectors). We have a few millions downloads, providing services to several Tier-1 customers, and reached more than 100,000 concurrent viewers watching in high qualities (1.2Mpbs and 2.0Mpbs). Would love to describe more, however, due to other meetings I won't be coming this time to Beijing. Please feel free to contact me Omer Luzzatti RayV co-founder and CTO -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Friday, November 05, 2010 11:09 AM To: Fabio Hecht Cc: ppsp@ietf.org Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? Hi Fabian, > -----Original Message----- > From: Fabio Hecht [mailto:hecht@ifi.uzh.ch] > Sent: Wednesday, November 03, 2010 2:19 PM > To: Martin Stiemerling > Cc: zhangyunfei; ppsp@ietf.org > Subject: RE: [ppsp] Pull or Pushed-based P2P Streaming? > > Hi Martin, > > > On Wed, 2010-11-03 at 12:38 +0000, Martin Stiemerling wrote: > > Hi Fabio, all, > > > > > -----Original Message----- > > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On > Behalf Of > > > Fabio Hecht > > > Sent: Friday, October 29, 2010 10:24 AM > > > To: zhangyunfei > > > Cc: ppsp@ietf.org > > > Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming? > > > > > > > > > Push only works if you can make reasonable QoS assumptions and > there is > > > an obvious way for peers to coordinate what they subscribe to. > > > Normally, > > > multiple trees are used. This makes the distribution not very > flexible, > > > as the source needs to define how many trees there will be > beforehand. > > > > That's one view, but there are push-based approaches based on network > coding (in paper work, but also deployed). > > True, that's also possible. Do you have a reference to a deployed one? Sorry for taking so long, it took a while to find this again: http://www.ravy.com/ However, it seems that the web site is gone. [...] > > > > > > > > So, in my opinion, PPSP should implement a pull protocol. Perhaps > the > > > ability of switching to push could be added as an additional > (optional) > > > feature. > > > > Optional feature does typically mean that it is not implemented. > > > > I would argue for letting the peers to figure out when they join the > system what scheme is used for the chunk diffusion. > > > > There could a be "session/system join" where the other peers (or the > tracker) announce whether push, pull, push/pull is used. This would > also support the case where a system supports a special vanilla flavor > of pull. > > I think this may be complicated, since there are several ways to > combine > push and pull. Right, but PPSP just needs to define a mechanism how the peers learn which is used, i.e., a tag or a field in the protocol. Martin > > Regards > > Fabio > > > > > Martin > > > > martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp From zongning@huawei.com Wed Nov 10 07:55:01 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294863A681D for ; Wed, 10 Nov 2010 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.619 X-Spam-Level: X-Spam-Status: No, score=-99.619 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtHGTfNVeU4S for ; Wed, 10 Nov 2010 07:55:00 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2B6CC3A63CB for ; Wed, 10 Nov 2010 07:55:00 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBO0099UEW4EV@szxga05-in.huawei.com> for ppsp@ietf.org; Wed, 10 Nov 2010 23:55:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBO001J9EW05R@szxga05-in.huawei.com> for ppsp@ietf.org; Wed, 10 Nov 2010 23:55:16 +0800 (CST) Received: from z-20684ca876cc4 ([125.35.86.138]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBO00K41EW08A@szxml01-in.huawei.com> for ppsp@ietf.org; Wed, 10 Nov 2010 23:55:12 +0800 (CST) Date: Wed, 10 Nov 2010 23:55:19 +0800 From: Ning Zong To: ppsp Message-id: <0LBO00K42EW08A@szxml01-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Subject: [ppsp] link for subscribing HTTP streaming mailing list X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:55:01 -0000 Hi, Folks, Just let you know the link for subscribing HTTP streaming mailing list https://www.ietf.org/mailman/listinfo/httpstreaming ,as I saw several PPSP faces on the HTTP streaming bar BoF tonight and wants to make sure that they can take part in the list discussion in the future. Sorry for disturbing others. BR, Ning Zong From zhangyunfei@chinamobile.com Wed Nov 10 21:29:29 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6FD3A68C5 for ; Wed, 10 Nov 2010 21:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.586 X-Spam-Level: X-Spam-Status: No, score=-96.586 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_40=-0.185, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVc4DJXNBp-Y for ; Wed, 10 Nov 2010 21:29:28 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 841163A69BB for ; Wed, 10 Nov 2010 21:29:28 -0800 (PST) Received: from zyf ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with ESMTP id 2010111113295057-9015 ; Thu, 11 Nov 2010 13:29:50 +0800 Date: Thu, 11 Nov 2010 13:29:48 +0800 From: "zhangyunfei" To: "ppsp@ietf.org" Message-ID: <201011111329479681672@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-11-11 13:29:50, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-11-11 13:29:57, Serialize complete at 2010-11-11 13:29:57 Content-Type: multipart/alternative; boundary="=====003_Dragon253661877168_=====" Subject: [ppsp] PPSP agenda and meeting materials available X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 05:29:29 -0000 This is a multi-part message in MIME format. --=====003_Dragon253661877168_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Hi folks, The PPSP final agenda (http://www.ietf.org/proceedings/79/agenda/ppsp.txt ) and meeting materials has already been available in IETF website. I really had a hard choice with Cullen and Roni on the talks according to the discussion on the mailing list, importance and relevence due to our limited time.Thanks for your understandings. If there is any slides update, please send me before 6:00 PM,Thursday.See you tommorow. BR Yunfei zhangyunfei 2010-11-11 --=====003_Dragon253661877168_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="gb2312"
Hi folks,
   The PPSP final agenda (http://www.ietf.org/proceedings/79/agenda/ppsp.txt ) and meeting materials has already been available in IETF website. I really had a hard choice with Cullen and Roni on the talks according to the discussion on the mailing list, importance and relevence due to our limited time.Thanks for your understandings.
   If there is any slides update, please send me before 6:00 PM,Thursday.See you tommorow.
 
BR
Yunfei
 
zhangyunfei
2010-11-11
 --=====003_Dragon253661877168_=====-- From lars.eggert@nokia.com Thu Nov 11 14:41:58 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501743A657C for ; Thu, 11 Nov 2010 14:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edd6A-ymB3zu for ; Thu, 11 Nov 2010 14:41:54 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id DC10B3A6A7C for ; Thu, 11 Nov 2010 14:41:45 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oABMg7xB023222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Nov 2010 00:42:07 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Nov 2010 06:42:00 +0800 References: <0E372751-3FE5-49F4-8D28-7DDA53C31385@farber.net> To: ppsp@ietf.org Message-Id: <0470B13B-0050-4B5B-B1AA-2DB021C192B8@nokia.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 12 Nov 2010 00:42:05 +0200 (EET) X-Nokia-AV: Clean Subject: [ppsp] Fwd: [IP] Bram Cohen on the Future of BitTorrent X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 22:41:58 -0000 FYI Begin forwarded message: > From: David Farber > Date: November 11, 2010 16:54:30 GMT+08:00 > To: ip > Subject: [IP] Bram Cohen on the Future of BitTorrent > Reply-To: >=20 >=20 >=20 > Begin forwarded message: >=20 > From: Dewayne Hendricks > Date: November 10, 2010 10:04:40 PM EST > To: Multiple recipients of Dewayne-Net > Subject: [Dewayne-Net] Bram Cohen on the Future of BitTorrent > Reply-To: dewayne-net@warpspeed.com >=20 > Bram Cohen on the Future of BitTorrent > By Josie Garthwaite=20 > Nov. 10, 2010, 5:29pm PDT > >=20 > What=92s next for BitTorrent, a company that initially tried to = establish a peer-to-peer-based download store for mainstream Hollywood, = then aimed to help publishers distribute bits more effectively? = BitTorrent co-founder and chief scientist Bram Cohen explained today at = GigaOM=92s NewTeeVee Liveconference that the company hopes to help = content creators reach its sprawling user base (80 million active users = per month) and, within a matter of months, release itslong-awaited P2P = solution for live streaming. >=20 > BitTorrent is about sending around large, previously created files, = said Cohen. =93Live streaming is about watching content as quickly as = possible after it=92s created.=94 He said he=92s =93shooting for around = 5 second latency from when the content goes out to when it=92s actually = displayed on people=92s machines. >=20 > [snip] >=20 > Dewayne-Net RSS Feed: >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------- > Archives: https://www.listbox.com/member/archive/247/=3Dnow > RSS Feed: = https://www.listbox.com/member/archive/rss/247/5548937-080cdcbf > Modify Your Subscription: = https://www.listbox.com/member/?member_id=3D5548937&id_secret=3D5548937-3c= d253d4 > Unsubscribe Now: = https://www.listbox.com/unsubscribe/?member_id=3D5548937&id_secret=3D55489= 37-f6d5c528 > Powered by Listbox: http://www.listbox.com From zongning@huawei.com Thu Nov 11 18:18:16 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2125F3A6A9F for ; Thu, 11 Nov 2010 18:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnDbr0OTEwex for ; Thu, 11 Nov 2010 18:18:15 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 42EC53A67F7 for ; Thu, 11 Nov 2010 18:18:15 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR009JC2F0O7@szxga03-in.huawei.com> for ppsp@ietf.org; Fri, 12 Nov 2010 10:18:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00JT02EVBP@szxga03-in.huawei.com> for ppsp@ietf.org; Fri, 12 Nov 2010 10:18:36 +0800 (CST) Received: from z-20684ca876cc4 (dhcp-75b5.meeting.ietf.org [130.129.117.181]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBR00IZ02ESLC@szxml01-in.huawei.com> for ppsp@ietf.org; Fri, 12 Nov 2010 10:18:32 +0800 (CST) Date: Fri, 12 Nov 2010 10:18:39 +0800 From: Ning Zong To: ppsp Message-id: <0LBR00IZ42EULC@szxml01-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Subject: [ppsp] mobility requirements X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:18:16 -0000 Firstly, thanks to Akbar to put together these mobility requirements. IMHO, I think the following 3 requirements are valuable and can be merged into the current PPSP requirements draft: PPSP.REQ-1: Change in IP address of a Peer device MUST immediately be reported via the Tracker Protocol and Peer Protocol. (removing "immediately") PPSP.REQ-2: Available uplink and downlink bandwidth of a Peer device MAY be reported via the Tracker Protocol and Peer Protocol. PPSP.REQ-3: Battery status of a Peer device SHOULD be reported via the Tracker Protocol and Peer Protocol. But I still think that the last one is subject to further discussion on the list: PPSP.REQ-4: Location of a Peer device SHOULD be reported via the Tracker Protocol and Peer Protocol. The reasoning of doing this for operational purpose is not a good argue to me, as I think all the requirements so far is towards building a open & better performed streaming system. The service operators can do some policy control, AAA, etc by themselves, but that is operational issue and should not cause a requirement (like location report) to the protocol itself. My two cents. BR, Ning Zong From fluffy@cisco.com Thu Nov 11 19:28:26 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8EE3A698D for ; Thu, 11 Nov 2010 19:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdTWzte658qj for ; Thu, 11 Nov 2010 19:28:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 10AB53A6927 for ; Thu, 11 Nov 2010 19:28:24 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMJD3EyrR7H+/2dsb2JhbACiTHGkH5sfgnGCWQSEWoV+gws X-IronPort-AV: E=Sophos;i="4.59,186,1288569600"; d="scan'208";a="618533101" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2010 03:28:55 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAC3SrS6001875 for ; Fri, 12 Nov 2010 03:28:53 GMT From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 20:29:17 -0700 Message-Id: To: ppsp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [ppsp] Notes from PPSP meeting at IETF 79 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:28:26 -0000 Chair introduction and agenda bashing =20 Thank you to Roni Even for co-chairing the meeting with Yunfei Zhang as = Cullen Jennings could not make this meeting.=20 About 30 People in Room. --------------------------------------------- Protocol requirements Problem Statement and general questions on PPSP =20 Open Issue #1 Suggestion we look (on the mailing list) of what would change in the = peer protocol to support push Point made this changes the amount of signaling Summary from Roni: This will need to go to the regiments of what we = need.=20 Open Issue #2 - No discussion Open Issue #3 - No answer yet but possible to do both Open Issue #4 - - point raised that 40% behind a full code still need NAT traversal - point raised that RELOAD is awfully big just to get NAT traversal=20 Open Issue #5 Point main that a peer-id could be a hash of public key which could make = the data self certifying=20 Point made if you route with a DHT you don=92t need an IP but if you = don=92t, then need the IP address Question of what happens when they don=92t match and what to do=20 --------------------------------------------- Second part of requirements (start at 9:25 )=20 PPSP.PP.REQ-5=20 What if a peer wants to choke another peer? So a MUST is not quite = right. Should change to say there MUST be a method to do this but not = that a give peer MUST provide the information.=20 PPSP.TP.REQ-4=20 Point made to if we find other properties are needed or can be provided, = do we need to add more requirements?=20 --------------=20 Additional requirements Start 9:35=20 PPSP.REQ-1=20 Why does this need to happen =93immediately=94 and MUST - we have = redundancy. Immediate may be too strong. Even for live streaming there = could be 100 peer. Might not need ti immediately.=20 This could also apply to peer that is acting as a relay. PPSP.REQ-2:=20 This can change 5 seconds later so might now be useful for algorithm. = Comment made we needed to report on congestion. There are also privacy = issues such as determining the wealth of a person based on the bandwidth = provisioned.=20 PPSP.REQ-3=20 PPSP.REQ-4=20 Controversial topic. Question asked why this is? Answer was sometimes = the content distribution wants to control which countries this gets = distributed to. Another example is how a sports game might be blocked = out in the city where the game takes place.=20 Some question if the slide meant to say, it SHOULD be possible to report = location. Not that the location SHOULD be reported.=20 Some proposal this could be learned from IP and not needed in protocol.=20= Roni conclusion was to take it to the list=20 Point raised there are no requirements on how to identify content.=20 --------------------------------------------- Tracker Protocol (started at 9:54 ) Discussion around how much data we can move out of the tracker to peer.=20= David Harrington - provided some comparison of ASN.1 vs XML for a SNMP = like task. Suggested we should consider what would make it easier for = operator to use not what would compress it down the smallest. Strongly = recommend we consider how that statistical information flowing across = the wire might be used. READ RFC 1052 by Vint Cert. Also should read the = RFC 3444 with difference between data model and information model.=20 --------------------------------------------- Distributed Tracker Usage =20 Skipped this preso=20 --------------------------------------------- Peer Protocol =20 David Harrington as an individual - don=92t spend too much time = designing stuff that works thought too many types of NATs. IESG is = pushing back hard on things that keep v4 around longer because want to = cause things to move to v6. He said more but go listen to the recording = around 10:25 Harald - big fan of removable cruft but what part of we need to ship = does the IESG not get. --------------------------------------------- Peer protocol on NAT traversal =20 Concern raised about robustness under churn.=20 Very few people had read this.=20 --------------------------------------------- Surveys (start 10:44 ) Question asked on adopting the WG milestone. Will take the question to = the list.=20 --------------------------------------------- PPSP design considerations (start at 10:53 )=20 Overview of Napa-Wine project. Cool stuff.=20 You would not want to query the Alto server for every chunk - that is = too fine grain but it is useful for peer selection.=20 --------------------------------------------- Layered P2P streaming ( start at 11:07 ) No discussion on this draft.=20 --------------------------------------------- PPSP Secure naming ( start at 11:19 ) David brought up the this type of naming made some problems much easier = and we should look at this.=20 Roni - reed this and see if this can help the architecture --------------------------------------------- PPSP Incentive parameters =20 Ran out of time and did not present.=20 --------------------------------------------- P2P-vod system =20 Ran out of time and did not present.= From zhangyunfei@chinamobile.com Thu Nov 11 22:28:09 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82F13A67AD for ; Thu, 11 Nov 2010 22:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.921 X-Spam-Level: X-Spam-Status: No, score=-95.921 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6IBl274SbKw for ; Thu, 11 Nov 2010 22:28:04 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 651F93A6ABE for ; Thu, 11 Nov 2010 22:28:03 -0800 (PST) Received: from zyf ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with ESMTP id 2010111214282351-9585 ; Fri, 12 Nov 2010 14:28:23 +0800 Date: Fri, 12 Nov 2010 14:28:18 +0800 From: "zhangyunfei" To: "Cullen Jennings" , "ppsp@ietf.org" References: Message-ID: <201011121428169374412@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-11-12 14:28:25, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-11-12 14:28:35, Serialize complete at 2010-11-12 14:28:35 Content-Type: multipart/alternative; boundary="=====003_Dragon848450801682_=====" Subject: Re: [ppsp] Notes from PPSP meeting at IETF 79 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 06:28:10 -0000 This is a multi-part message in MIME format. --=====003_Dragon848450801682_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" VGhhbmtzIEN1bGxlbiBmb3IgeW91ciBxdWljayBub3RlcyBhbHRob3VnaCB5b3UgYXJlIG5vdCBw cmVzZW50LkknbGwgc3VtbWFyaXplIHRoZSBub3RlcyBhY2NvcmRpbmcgdG8geW91ciBhbmQgUm9u aSdzIGNvbGxlY3Rpb24gb24gb3RoZXIgbm90ZXMuVGhhbmtzIGFnYWluIGZvciBSb25pJ3MgY28t Y2hhaXJpbmcgdGhlIHNlc3Npb24uDQoNCll1bmZlaQ0KDQoNCg0KDQoNCg0KDQoNCnpoYW5neXVu ZmVpDQoyMDEwLTExLTEyDQoNCg0KDQq3orz+yMujuiBDdWxsZW4gSmVubmluZ3MNCreiy83Ksbzk o7ogMjAxMC0xMS0xMiAxMToyOTowOA0KytW8/sjLo7ogcHBzcEBpZXRmLm9yZw0Ks63LzaO6IA0K 1vfM4qO6IFtwcHNwXSBOb3RlcyBmcm9tIFBQU1AgbWVldGluZyBhdCBJRVRGIDc5DQoNCkNoYWly ICBpbnRyb2R1Y3Rpb24gIGFuZCAgYWdlbmRhICBiYXNoaW5nICAgIA0KDQpUaGFuayAgeW91ICB0 byAgUm9uaSAgRXZlbiAgZm9yICBjby1jaGFpcmluZyAgdGhlICBtZWV0aW5nICB3aXRoICBZdW5m ZWkgIFpoYW5nICBhcyAgQ3VsbGVuICBKZW5uaW5ncyAgY291bGQgIG5vdCAgbWFrZSAgdGhpcyAg bWVldGluZy4gIA0KDQpBYm91dCAgMzAgIFBlb3BsZSAgaW4gIFJvb20uDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUHJvdG9jb2wgIHJlcXVp cmVtZW50cw0KDQpQcm9ibGVtICBTdGF0ZW1lbnQgIGFuZCAgZ2VuZXJhbCAgcXVlc3Rpb25zICBv biAgUFBTUCAgICAgIA0KDQpPcGVuICBJc3N1ZSAgIzENCg0KU3VnZ2VzdGlvbiAgd2UgIGxvb2sg IChvbiAgdGhlICBtYWlsaW5nICBsaXN0KSAgb2YgIHdoYXQgIHdvdWxkICBjaGFuZ2UgIGluICB0 aGUgIHBlZXIgIHByb3RvY29sICB0byAgc3VwcG9ydCAgcHVzaA0KDQpQb2ludCAgbWFkZSAgdGhp cyAgY2hhbmdlcyAgdGhlICBhbW91bnQgIG9mICBzaWduYWxpbmcNCg0KU3VtbWFyeSAgZnJvbSAg Um9uaTogIFRoaXMgIHdpbGwgIG5lZWQgIHRvICBnbyAgdG8gIHRoZSAgcmVnaW1lbnRzICBvZiAg d2hhdCAgd2UgIG5lZWQuICANCg0KT3BlbiAgSXNzdWUgICMyICAtICBObyAgZGlzY3Vzc2lvbg0K DQpPcGVuICBJc3N1ZSAgIzMgIC0gIE5vICBhbnN3ZXIgIHlldCAgYnV0ICBwb3NzaWJsZSAgdG8g IGRvICBib3RoDQoNCk9wZW4gIElzc3VlICAjNCAgLQ0KLSAgcG9pbnQgIHJhaXNlZCAgdGhhdCAg NDAlICBiZWhpbmQgIGEgIGZ1bGwgIGNvZGUgIHN0aWxsICBuZWVkICBOQVQgIHRyYXZlcnNhbA0K LSAgcG9pbnQgIHJhaXNlZCAgdGhhdCAgUkVMT0FEICBpcyAgYXdmdWxseSAgYmlnICBqdXN0ICB0 byAgZ2V0ICBOQVQgIHRyYXZlcnNhbCAgDQoNCk9wZW4gIElzc3VlICAjNQ0KDQpQb2ludCAgbWFp biAgdGhhdCAgYSAgcGVlci1pZCAgY291bGQgIGJlICBhICBoYXNoICBvZiAgcHVibGljICBrZXkg IHdoaWNoICBjb3VsZCAgbWFrZSAgdGhlICBkYXRhICBzZWxmICBjZXJ0aWZ5aW5nICANCg0KUG9p bnQgIG1hZGUgIGlmICB5b3UgIHJvdXRlICB3aXRoICBhICBESFQgIHlvdSAgZG9uoa90ICBuZWVk ICBhbiAgSVAgIGJ1dCAgaWYgIHlvdSAgZG9uoa90LCAgdGhlbiAgbmVlZCAgdGhlICBJUCAgYWRk cmVzcw0KDQpRdWVzdGlvbiAgb2YgIHdoYXQgIGhhcHBlbnMgIHdoZW4gIHRoZXkgIGRvbqGvdCAg bWF0Y2ggIGFuZCAgd2hhdCAgdG8gIGRvICANCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTZWNvbmQgIHBhcnQgIG9mICByZXF1aXJlbWVudHMg ICAgICAoc3RhcnQgIGF0ICA5OjI1ICApICANCg0KUFBTUC5QUC5SRVEtNSAgDQoNCldoYXQgIGlm ICBhICBwZWVyICB3YW50cyAgdG8gIGNob2tlICBhbm90aGVyICBwZWVyPyAgU28gIGEgIE1VU1Qg IGlzICBub3QgIHF1aXRlICByaWdodC4gIFNob3VsZCAgY2hhbmdlICB0byAgc2F5ICB0aGVyZSAg TVVTVCAgYmUgIGEgIG1ldGhvZCAgdG8gIGRvICB0aGlzICBidXQgIG5vdCAgdGhhdCAgYSAgZ2l2 ZSAgcGVlciAgTVVTVCAgcHJvdmlkZSAgdGhlICBpbmZvcm1hdGlvbi4gIA0KDQpQUFNQLlRQLlJF US00ICANCg0KUG9pbnQgIG1hZGUgIHRvICBpZiAgd2UgIGZpbmQgIG90aGVyICBwcm9wZXJ0aWVz ICBhcmUgIG5lZWRlZCAgb3IgIGNhbiAgYmUgIHByb3ZpZGVkLCAgZG8gIHdlICBuZWVkICB0byAg YWRkICBtb3JlICByZXF1aXJlbWVudHM/ICANCg0KDQotLS0tLS0tLS0tLS0tLSAgDQpBZGRpdGlv bmFsICByZXF1aXJlbWVudHMgICAgICAgICAgICBTdGFydCAgOTozNSAgDQoNClBQU1AuUkVRLTEg IA0KV2h5ICBkb2VzICB0aGlzICBuZWVkICB0byAgaGFwcGVuICChsGltbWVkaWF0ZWx5obEgIGFu ZCAgTVVTVCAgLSAgd2UgIGhhdmUgIHJlZHVuZGFuY3kuICBJbW1lZGlhdGUgIG1heSAgYmUgIHRv byAgc3Ryb25nLiAgRXZlbiAgZm9yICBsaXZlICBzdHJlYW1pbmcgIHRoZXJlICBjb3VsZCAgYmUg IDEwMCAgcGVlci4gIE1pZ2h0ICBub3QgIG5lZWQgIHRpICBpbW1lZGlhdGVseS4gIA0KDQpUaGlz ICBjb3VsZCAgYWxzbyAgYXBwbHkgIHRvICBwZWVyICB0aGF0ICBpcyAgYWN0aW5nICBhcyAgYSAg cmVsYXkuDQoNClBQU1AuUkVRLTI6ICANCg0KVGhpcyAgY2FuICBjaGFuZ2UgIDUgIHNlY29uZHMg IGxhdGVyICBzbyAgbWlnaHQgIG5vdyAgYmUgIHVzZWZ1bCAgZm9yICBhbGdvcml0aG0uICBDb21t ZW50ICBtYWRlICB3ZSAgbmVlZGVkICB0byAgcmVwb3J0ICBvbiAgY29uZ2VzdGlvbi4gIFRoZXJl ICBhcmUgIGFsc28gIHByaXZhY3kgIGlzc3VlcyAgc3VjaCAgYXMgIGRldGVybWluaW5nICB0aGUg IHdlYWx0aCAgb2YgIGEgIHBlcnNvbiAgYmFzZWQgIG9uICB0aGUgIGJhbmR3aWR0aCAgcHJvdmlz aW9uZWQuICANCg0KUFBTUC5SRVEtMyAgDQoNCg0KUFBTUC5SRVEtNCAgDQoNCkNvbnRyb3ZlcnNp YWwgIHRvcGljLiAgUXVlc3Rpb24gIGFza2VkICB3aHkgIHRoaXMgIGlzPyAgQW5zd2VyICB3YXMg IHNvbWV0aW1lcyAgdGhlICBjb250ZW50ICBkaXN0cmlidXRpb24gIHdhbnRzICB0byAgY29udHJv bCAgd2hpY2ggIGNvdW50cmllcyAgdGhpcyAgZ2V0cyAgZGlzdHJpYnV0ZWQgIHRvLiAgQW5vdGhl ciAgZXhhbXBsZSAgaXMgIGhvdyAgYSAgc3BvcnRzICBnYW1lICBtaWdodCAgYmUgIGJsb2NrZWQg IG91dCAgaW4gIHRoZSAgY2l0eSAgd2hlcmUgIHRoZSAgZ2FtZSAgdGFrZXMgIHBsYWNlLiAgDQoN ClNvbWUgIHF1ZXN0aW9uICBpZiAgdGhlICBzbGlkZSAgbWVhbnQgIHRvICBzYXksICBpdCAgU0hP VUxEICBiZSAgcG9zc2libGUgIHRvICByZXBvcnQgIGxvY2F0aW9uLiAgTm90ICB0aGF0ICB0aGUg IGxvY2F0aW9uICBTSE9VTEQgIGJlICByZXBvcnRlZC4gIA0KDQpTb21lICBwcm9wb3NhbCAgdGhp cyAgY291bGQgIGJlICBsZWFybmVkICBmcm9tICBJUCAgYW5kICBub3QgIG5lZWRlZCAgaW4gIHBy b3RvY29sLiAgDQoNClJvbmkgIGNvbmNsdXNpb24gIHdhcyAgdG8gIHRha2UgIGl0ICB0byAgdGhl ICBsaXN0ICANCg0KUG9pbnQgIHJhaXNlZCAgdGhlcmUgIGFyZSAgbm8gIHJlcXVpcmVtZW50cyAg b24gIGhvdyAgdG8gIGlkZW50aWZ5ICBjb250ZW50LiAgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUcmFja2VyICBQcm90b2NvbCAgICAoc3RhcnRl ZCAgYXQgIDk6NTQgICkNCg0KRGlzY3Vzc2lvbiAgYXJvdW5kICBob3cgIG11Y2ggIGRhdGEgIHdl ICBjYW4gIG1vdmUgIG91dCAgb2YgIHRoZSAgdHJhY2tlciAgdG8gIHBlZXIuICANCg0KRGF2aWQg IEhhcnJpbmd0b24gIC0gIHByb3ZpZGVkICBzb21lICBjb21wYXJpc29uICBvZiAgQVNOLjEgIHZz ICBYTUwgIGZvciAgYSAgU05NUCAgbGlrZSAgdGFzay4gIFN1Z2dlc3RlZCAgd2UgIHNob3VsZCAg Y29uc2lkZXIgIHdoYXQgIHdvdWxkICBtYWtlICBpdCAgZWFzaWVyICBmb3IgIG9wZXJhdG9yICB0 byAgdXNlICBub3QgIHdoYXQgIHdvdWxkICBjb21wcmVzcyAgaXQgIGRvd24gIHRoZSAgc21hbGxl c3QuICBTdHJvbmdseSAgcmVjb21tZW5kICB3ZSAgY29uc2lkZXIgIGhvdyAgdGhhdCAgc3RhdGlz dGljYWwgIGluZm9ybWF0aW9uICBmbG93aW5nICBhY3Jvc3MgIHRoZSAgd2lyZSAgbWlnaHQgIGJl ICB1c2VkLiAgUkVBRCAgUkZDICAxMDUyICBieSAgVmludCAgQ2VydC4gIEFsc28gIHNob3VsZCAg cmVhZCAgdGhlICBSRkMgIDM0NDQgIHdpdGggIGRpZmZlcmVuY2UgIGJldHdlZW4gIGRhdGEgIG1v ZGVsICBhbmQgIGluZm9ybWF0aW9uICBtb2RlbC4gIA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRpc3RyaWJ1dGVkICBUcmFja2VyICBVc2Fn ZSAgICAgIA0KDQpTa2lwcGVkICB0aGlzICBwcmVzbyAgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClBlZXIgIFByb3RvY29sICAgICAgDQoNCkRh dmlkICBIYXJyaW5ndG9uICBhcyAgYW4gIGluZGl2aWR1YWwgIC0gIGRvbqGvdCAgc3BlbmQgIHRv byAgbXVjaCAgdGltZSAgZGVzaWduaW5nICBzdHVmZiAgdGhhdCAgd29ya3MgIHRob3VnaHQgIHRv byAgbWFueSAgdHlwZXMgIG9mICBOQVRzLiAgSUVTRyAgaXMgIHB1c2hpbmcgIGJhY2sgIGhhcmQg IG9uICB0aGluZ3MgIHRoYXQgIGtlZXAgIHY0ICBhcm91bmQgIGxvbmdlciAgYmVjYXVzZSAgd2Fu dCAgdG8gIGNhdXNlICB0aGluZ3MgIHRvICBtb3ZlICB0byAgdjYuICBIZSAgc2FpZCAgbW9yZSAg YnV0ICBnbyAgbGlzdGVuICB0byAgdGhlICByZWNvcmRpbmcgIGFyb3VuZCAgMTA6MjUNCg0KSGFy YWxkICAtICBiaWcgIGZhbiAgb2YgIHJlbW92YWJsZSAgY3J1ZnQgIGJ1dCAgd2hhdCAgcGFydCAg b2YgIHdlICBuZWVkICB0byAgc2hpcCAgZG9lcyAgdGhlICBJRVNHICBub3QgIGdldC4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClBlZXIgIHByb3Rv Y29sICBvbiAgTkFUICB0cmF2ZXJzYWwgICAgICAgIA0KDQpDb25jZXJuICByYWlzZWQgIGFib3V0 ICByb2J1c3RuZXNzICB1bmRlciAgY2h1cm4uICANCg0KVmVyeSAgZmV3ICBwZW9wbGUgIGhhZCAg cmVhZCAgdGhpcy4gIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KU3VydmV5cyAgICAgICAgKHN0YXJ0ICAxMDo0NCAgKQ0KDQpRdWVzdGlvbiAgYXNr ZWQgIG9uICBhZG9wdGluZyAgdGhlICBXRyAgbWlsZXN0b25lLiAgV2lsbCAgdGFrZSAgdGhlICBx dWVzdGlvbiAgdG8gIHRoZSAgbGlzdC4gIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KUFBTUCAgZGVzaWduICBjb25zaWRlcmF0aW9ucyAgICAoc3Rh cnQgIGF0ICAxMDo1MyAgKSAgDQoNCk92ZXJ2aWV3ICBvZiAgTmFwYS1XaW5lICBwcm9qZWN0LiAg Q29vbCAgc3R1ZmYuICANCg0KWW91ICB3b3VsZCAgbm90ICB3YW50ICB0byAgcXVlcnkgIHRoZSAg QWx0byAgc2VydmVyICBmb3IgIGV2ZXJ5ICBjaHVuayAgLSAgdGhhdCAgaXMgIHRvbyAgZmluZSAg Z3JhaW4gIGJ1dCAgaXQgIGlzICB1c2VmdWwgIGZvciAgcGVlciAgc2VsZWN0aW9uLiAgDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkxheWVyZWQg IFAyUCAgc3RyZWFtaW5nICAgICggIHN0YXJ0ICBhdCAgMTE6MDcgICkNCg0KTm8gIGRpc2N1c3Np b24gIG9uICB0aGlzICBkcmFmdC4gIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KUFBTUCAgU2VjdXJlICBuYW1pbmcgICAgKCAgc3RhcnQgIGF0ICAx MToxOSAgKQ0KDQpEYXZpZCAgYnJvdWdodCAgdXAgIHRoZSAgdGhpcyAgdHlwZSAgb2YgIG5hbWlu ZyAgbWFkZSAgc29tZSAgcHJvYmxlbXMgIG11Y2ggIGVhc2llciAgYW5kICB3ZSAgc2hvdWxkICBs b29rICBhdCAgdGhpcy4gIA0KDQpSb25pICAtICByZWVkICB0aGlzICBhbmQgIHNlZSAgaWYgIHRo aXMgIGNhbiAgaGVscCAgdGhlICBhcmNoaXRlY3R1cmUNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUFBTUCAgSW5jZW50aXZlICBwYXJhbWV0ZXJz ICAgIA0KDQpSYW4gIG91dCAgb2YgIHRpbWUgIGFuZCAgZGlkICBub3QgIHByZXNlbnQuICANCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpQMlAtdm9kICBz eXN0ZW0gICAgICANCg0KUmFuICBvdXQgIG9mICB0aW1lICBhbmQgIGRpZCAgbm90ICBwcmVzZW50 Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3Ag IG1haWxpbmcgIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcHBzcA0K --=====003_Dragon848450801682_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE3MDgwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGFua3MgQ3VsbGVuIGZvciB5b3Vy IHF1aWNrIG5vdGVzIA0KYWx0aG91Z2ggeW91IGFyZSBub3QgcHJlc2VudC5JJ2xsIHN1bW1hcml6 ZSB0aGUgbm90ZXMgYWNjb3JkaW5nIHRvIHlvdXIgYW5kIA0KUm9uaSdzIGNvbGxlY3Rpb24gb24g b3RoZXIgbm90ZXMuVGhhbmtzIGFnYWluIGZvciBSb25pJ3MgY28tY2hhaXJpbmcgdGhlIA0Kc2Vz c2lvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZm IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xv cj0jMDAwMGZmIHNpemU9Mj5ZdW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPiZuYnNwOzwvRElWPg0KPERJ Vj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgU0laRT0yPg0KPC9ESVY+ PC9GT05UPg0KPERJViBhbGlnbj1sZWZ0Pg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+emhhbmd5dW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+MjAxMC0xMS0xMjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63orz+yMujujwvU1RS T05HPiBDdWxsZW4gDQpKZW5uaW5nczwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IA0KMjAx MC0xMS0xMiZuYnNwOzExOjI5OjA4PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IA0KcHBzcEBp ZXRmLm9yZzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9O VCBzaXplPTI+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gPC9GT05UPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05H PiBbcHBzcF0gTm90ZXMgZnJvbSBQUFNQIA0KbWVldGluZyBhdCBJRVRGIDc5PC9GT05UPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkNoYWlyICZuYnNwO2lu dHJvZHVjdGlvbiAmbmJzcDthbmQgJm5ic3A7YWdlbmRhICZuYnNwO2Jhc2hpbmcgJm5ic3A7IA0K Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGFuayAmbmJzcDt5b3UgJm5i c3A7dG8gJm5ic3A7Um9uaSAmbmJzcDtFdmVuICZuYnNwO2ZvciAmbmJzcDtjby1jaGFpcmluZyAN CiZuYnNwO3RoZSAmbmJzcDttZWV0aW5nICZuYnNwO3dpdGggJm5ic3A7WXVuZmVpICZuYnNwO1po YW5nICZuYnNwO2FzIA0KJm5ic3A7Q3VsbGVuICZuYnNwO0plbm5pbmdzICZuYnNwO2NvdWxkICZu YnNwO25vdCAmbmJzcDttYWtlICZuYnNwO3RoaXMgDQombmJzcDttZWV0aW5nLiAmbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFib3V0ICZuYnNwOzMwICZuYnNwO1Blb3BsZSAm bmJzcDtpbiAmbmJzcDtSb29tLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlByb3Rv Y29sICZuYnNwO3JlcXVpcmVtZW50czwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UHJv YmxlbSAmbmJzcDtTdGF0ZW1lbnQgJm5ic3A7YW5kICZuYnNwO2dlbmVyYWwgJm5ic3A7cXVlc3Rp b25zICZuYnNwO29uIA0KJm5ic3A7UFBTUCAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+T3BlbiAmbmJzcDtJc3N1ZSAmbmJzcDsjMTwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+U3VnZ2VzdGlvbiAmbmJzcDt3ZSAmbmJzcDtsb29rICZuYnNw OyhvbiAmbmJzcDt0aGUgJm5ic3A7bWFpbGluZyANCiZuYnNwO2xpc3QpICZuYnNwO29mICZuYnNw O3doYXQgJm5ic3A7d291bGQgJm5ic3A7Y2hhbmdlICZuYnNwO2luICZuYnNwO3RoZSANCiZuYnNw O3BlZXIgJm5ic3A7cHJvdG9jb2wgJm5ic3A7dG8gJm5ic3A7c3VwcG9ydCAmbmJzcDtwdXNoPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Qb2ludCAmbmJzcDttYWRlICZuYnNwO3RoaXMg Jm5ic3A7Y2hhbmdlcyAmbmJzcDt0aGUgJm5ic3A7YW1vdW50ICZuYnNwO29mIA0KJm5ic3A7c2ln bmFsaW5nPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TdW1tYXJ5ICZuYnNwO2Zyb20g Jm5ic3A7Um9uaTogJm5ic3A7VGhpcyAmbmJzcDt3aWxsICZuYnNwO25lZWQgJm5ic3A7dG8gDQom bmJzcDtnbyAmbmJzcDt0byAmbmJzcDt0aGUgJm5ic3A7cmVnaW1lbnRzICZuYnNwO29mICZuYnNw O3doYXQgJm5ic3A7d2UgDQombmJzcDtuZWVkLiAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPk9wZW4gJm5ic3A7SXNzdWUgJm5ic3A7IzIgJm5ic3A7LSAmbmJzcDtObyAmbmJz cDtkaXNjdXNzaW9uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5PcGVuICZuYnNwO0lz c3VlICZuYnNwOyMzICZuYnNwOy0gJm5ic3A7Tm8gJm5ic3A7YW5zd2VyICZuYnNwO3lldCAmbmJz cDtidXQgDQombmJzcDtwb3NzaWJsZSAmbmJzcDt0byAmbmJzcDtkbyAmbmJzcDtib3RoPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5PcGVuICZuYnNwO0lzc3VlICZuYnNwOyM0ICZuYnNw Oy08L0RJVj4NCjxESVY+LSAmbmJzcDtwb2ludCAmbmJzcDtyYWlzZWQgJm5ic3A7dGhhdCAmbmJz cDs0MCUgJm5ic3A7YmVoaW5kICZuYnNwO2EgDQombmJzcDtmdWxsICZuYnNwO2NvZGUgJm5ic3A7 c3RpbGwgJm5ic3A7bmVlZCAmbmJzcDtOQVQgJm5ic3A7dHJhdmVyc2FsPC9ESVY+DQo8RElWPi0g Jm5ic3A7cG9pbnQgJm5ic3A7cmFpc2VkICZuYnNwO3RoYXQgJm5ic3A7UkVMT0FEICZuYnNwO2lz ICZuYnNwO2F3ZnVsbHkgDQombmJzcDtiaWcgJm5ic3A7anVzdCAmbmJzcDt0byAmbmJzcDtnZXQg Jm5ic3A7TkFUICZuYnNwO3RyYXZlcnNhbCAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPk9wZW4gJm5ic3A7SXNzdWUgJm5ic3A7IzU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPlBvaW50ICZuYnNwO21haW4gJm5ic3A7dGhhdCAmbmJzcDthICZuYnNwO3BlZXItaWQg Jm5ic3A7Y291bGQgJm5ic3A7YmUgDQombmJzcDthICZuYnNwO2hhc2ggJm5ic3A7b2YgJm5ic3A7 cHVibGljICZuYnNwO2tleSAmbmJzcDt3aGljaCAmbmJzcDtjb3VsZCANCiZuYnNwO21ha2UgJm5i c3A7dGhlICZuYnNwO2RhdGEgJm5ic3A7c2VsZiAmbmJzcDtjZXJ0aWZ5aW5nICZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UG9pbnQgJm5ic3A7bWFkZSAmbmJzcDtpZiAmbmJz cDt5b3UgJm5ic3A7cm91dGUgJm5ic3A7d2l0aCAmbmJzcDthIA0KJm5ic3A7REhUICZuYnNwO3lv dSAmbmJzcDtkb26hr3QgJm5ic3A7bmVlZCAmbmJzcDthbiAmbmJzcDtJUCAmbmJzcDtidXQgJm5i c3A7aWYgDQombmJzcDt5b3UgJm5ic3A7ZG9uoa90LCAmbmJzcDt0aGVuICZuYnNwO25lZWQgJm5i c3A7dGhlICZuYnNwO0lQIA0KJm5ic3A7YWRkcmVzczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+UXVlc3Rpb24gJm5ic3A7b2YgJm5ic3A7d2hhdCAmbmJzcDtoYXBwZW5zICZuYnNwO3do ZW4gJm5ic3A7dGhleSANCiZuYnNwO2RvbqGvdCAmbmJzcDttYXRjaCAmbmJzcDthbmQgJm5ic3A7 d2hhdCAmbmJzcDt0byAmbmJzcDtkbyAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5TZWNvbmQgJm5ic3A7cGFydCAmbmJzcDtvZiAmbmJzcDtyZXF1aXJlbWVudHMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsoc3RhcnQgDQombmJzcDthdCAmbmJzcDs5OjI1ICZuYnNwOykgJm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QUFNQLlBQLlJFUS01ICZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+V2hhdCAmbmJzcDtpZiAmbmJzcDthICZuYnNwO3Bl ZXIgJm5ic3A7d2FudHMgJm5ic3A7dG8gJm5ic3A7Y2hva2UgDQombmJzcDthbm90aGVyICZuYnNw O3BlZXI/ICZuYnNwO1NvICZuYnNwO2EgJm5ic3A7TVVTVCAmbmJzcDtpcyAmbmJzcDtub3QgDQom bmJzcDtxdWl0ZSAmbmJzcDtyaWdodC4gJm5ic3A7U2hvdWxkICZuYnNwO2NoYW5nZSAmbmJzcDt0 byAmbmJzcDtzYXkgDQombmJzcDt0aGVyZSAmbmJzcDtNVVNUICZuYnNwO2JlICZuYnNwO2EgJm5i c3A7bWV0aG9kICZuYnNwO3RvICZuYnNwO2RvIA0KJm5ic3A7dGhpcyAmbmJzcDtidXQgJm5ic3A7 bm90ICZuYnNwO3RoYXQgJm5ic3A7YSAmbmJzcDtnaXZlICZuYnNwO3BlZXIgDQombmJzcDtNVVNU ICZuYnNwO3Byb3ZpZGUgJm5ic3A7dGhlICZuYnNwO2luZm9ybWF0aW9uLiAmbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlBQU1AuVFAuUkVRLTQgJm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5Qb2ludCAmbmJzcDttYWRlICZuYnNwO3RvICZuYnNwO2lmICZu YnNwO3dlICZuYnNwO2ZpbmQgJm5ic3A7b3RoZXIgDQombmJzcDtwcm9wZXJ0aWVzICZuYnNwO2Fy ZSAmbmJzcDtuZWVkZWQgJm5ic3A7b3IgJm5ic3A7Y2FuICZuYnNwO2JlIA0KJm5ic3A7cHJvdmlk ZWQsICZuYnNwO2RvICZuYnNwO3dlICZuYnNwO25lZWQgJm5ic3A7dG8gJm5ic3A7YWRkICZuYnNw O21vcmUgDQombmJzcDtyZXF1aXJlbWVudHM/ICZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tICZuYnNwOzwvRElWPg0K PERJVj5BZGRpdGlvbmFsICZuYnNwO3JlcXVpcmVtZW50cyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IA0KJm5ic3A7U3RhcnQgJm5ic3A7OTozNSAmbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPlBQU1AuUkVRLTEgJm5ic3A7PC9ESVY+DQo8RElWPldoeSAmbmJz cDtkb2VzICZuYnNwO3RoaXMgJm5ic3A7bmVlZCAmbmJzcDt0byAmbmJzcDtoYXBwZW4gDQombmJz cDuhsGltbWVkaWF0ZWx5obEgJm5ic3A7YW5kICZuYnNwO01VU1QgJm5ic3A7LSAmbmJzcDt3ZSAm bmJzcDtoYXZlIA0KJm5ic3A7cmVkdW5kYW5jeS4gJm5ic3A7SW1tZWRpYXRlICZuYnNwO21heSAm bmJzcDtiZSAmbmJzcDt0b28gJm5ic3A7c3Ryb25nLiANCiZuYnNwO0V2ZW4gJm5ic3A7Zm9yICZu YnNwO2xpdmUgJm5ic3A7c3RyZWFtaW5nICZuYnNwO3RoZXJlICZuYnNwO2NvdWxkICZuYnNwO2Jl IA0KJm5ic3A7MTAwICZuYnNwO3BlZXIuICZuYnNwO01pZ2h0ICZuYnNwO25vdCAmbmJzcDtuZWVk ICZuYnNwO3RpIA0KJm5ic3A7aW1tZWRpYXRlbHkuICZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+VGhpcyAmbmJzcDtjb3VsZCAmbmJzcDthbHNvICZuYnNwO2FwcGx5ICZuYnNw O3RvICZuYnNwO3BlZXIgJm5ic3A7dGhhdCANCiZuYnNwO2lzICZuYnNwO2FjdGluZyAmbmJzcDth cyAmbmJzcDthICZuYnNwO3JlbGF5LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UFBT UC5SRVEtMjogJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGlzICZuYnNw O2NhbiAmbmJzcDtjaGFuZ2UgJm5ic3A7NSAmbmJzcDtzZWNvbmRzICZuYnNwO2xhdGVyICZuYnNw O3NvIA0KJm5ic3A7bWlnaHQgJm5ic3A7bm93ICZuYnNwO2JlICZuYnNwO3VzZWZ1bCAmbmJzcDtm b3IgJm5ic3A7YWxnb3JpdGhtLiANCiZuYnNwO0NvbW1lbnQgJm5ic3A7bWFkZSAmbmJzcDt3ZSAm bmJzcDtuZWVkZWQgJm5ic3A7dG8gJm5ic3A7cmVwb3J0ICZuYnNwO29uIA0KJm5ic3A7Y29uZ2Vz dGlvbi4gJm5ic3A7VGhlcmUgJm5ic3A7YXJlICZuYnNwO2Fsc28gJm5ic3A7cHJpdmFjeSAmbmJz cDtpc3N1ZXMgDQombmJzcDtzdWNoICZuYnNwO2FzICZuYnNwO2RldGVybWluaW5nICZuYnNwO3Ro ZSAmbmJzcDt3ZWFsdGggJm5ic3A7b2YgJm5ic3A7YSANCiZuYnNwO3BlcnNvbiAmbmJzcDtiYXNl ZCAmbmJzcDtvbiAmbmJzcDt0aGUgJm5ic3A7YmFuZHdpZHRoICZuYnNwO3Byb3Zpc2lvbmVkLiAN CiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UFBTUC5SRVEtMyAmbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QUFNQLlJF US00ICZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Q29udHJvdmVyc2lhbCAm bmJzcDt0b3BpYy4gJm5ic3A7UXVlc3Rpb24gJm5ic3A7YXNrZWQgJm5ic3A7d2h5ICZuYnNwO3Ro aXMgDQombmJzcDtpcz8gJm5ic3A7QW5zd2VyICZuYnNwO3dhcyAmbmJzcDtzb21ldGltZXMgJm5i c3A7dGhlICZuYnNwO2NvbnRlbnQgDQombmJzcDtkaXN0cmlidXRpb24gJm5ic3A7d2FudHMgJm5i c3A7dG8gJm5ic3A7Y29udHJvbCAmbmJzcDt3aGljaCANCiZuYnNwO2NvdW50cmllcyAmbmJzcDt0 aGlzICZuYnNwO2dldHMgJm5ic3A7ZGlzdHJpYnV0ZWQgJm5ic3A7dG8uICZuYnNwO0Fub3RoZXIg DQombmJzcDtleGFtcGxlICZuYnNwO2lzICZuYnNwO2hvdyAmbmJzcDthICZuYnNwO3Nwb3J0cyAm bmJzcDtnYW1lICZuYnNwO21pZ2h0IA0KJm5ic3A7YmUgJm5ic3A7YmxvY2tlZCAmbmJzcDtvdXQg Jm5ic3A7aW4gJm5ic3A7dGhlICZuYnNwO2NpdHkgJm5ic3A7d2hlcmUgDQombmJzcDt0aGUgJm5i c3A7Z2FtZSAmbmJzcDt0YWtlcyAmbmJzcDtwbGFjZS4gJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5Tb21lICZuYnNwO3F1ZXN0aW9uICZuYnNwO2lmICZuYnNwO3RoZSAmbmJz cDtzbGlkZSAmbmJzcDttZWFudCAmbmJzcDt0byANCiZuYnNwO3NheSwgJm5ic3A7aXQgJm5ic3A7 U0hPVUxEICZuYnNwO2JlICZuYnNwO3Bvc3NpYmxlICZuYnNwO3RvICZuYnNwO3JlcG9ydCANCiZu YnNwO2xvY2F0aW9uLiAmbmJzcDtOb3QgJm5ic3A7dGhhdCAmbmJzcDt0aGUgJm5ic3A7bG9jYXRp b24gJm5ic3A7U0hPVUxEIA0KJm5ic3A7YmUgJm5ic3A7cmVwb3J0ZWQuICZuYnNwOzwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+U29tZSAmbmJzcDtwcm9wb3NhbCAmbmJzcDt0aGlzICZu YnNwO2NvdWxkICZuYnNwO2JlICZuYnNwO2xlYXJuZWQgDQombmJzcDtmcm9tICZuYnNwO0lQICZu YnNwO2FuZCAmbmJzcDtub3QgJm5ic3A7bmVlZGVkICZuYnNwO2luICZuYnNwO3Byb3RvY29sLiAN CiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Um9uaSAmbmJzcDtjb25jbHVz aW9uICZuYnNwO3dhcyAmbmJzcDt0byAmbmJzcDt0YWtlICZuYnNwO2l0ICZuYnNwO3RvIA0KJm5i c3A7dGhlICZuYnNwO2xpc3QgJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Q b2ludCAmbmJzcDtyYWlzZWQgJm5ic3A7dGhlcmUgJm5ic3A7YXJlICZuYnNwO25vICZuYnNwO3Jl cXVpcmVtZW50cyANCiZuYnNwO29uICZuYnNwO2hvdyAmbmJzcDt0byAmbmJzcDtpZGVudGlmeSAm bmJzcDtjb250ZW50LiAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+VHJhY2tlciAmbmJzcDtQcm90b2NvbCAmbmJzcDsgJm5ic3A7KHN0YXJ0 ZWQgJm5ic3A7YXQgJm5ic3A7OTo1NCANCiZuYnNwOyk8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPkRpc2N1c3Npb24gJm5ic3A7YXJvdW5kICZuYnNwO2hvdyAmbmJzcDttdWNoICZuYnNw O2RhdGEgJm5ic3A7d2UgJm5ic3A7Y2FuIA0KJm5ic3A7bW92ZSAmbmJzcDtvdXQgJm5ic3A7b2Yg Jm5ic3A7dGhlICZuYnNwO3RyYWNrZXIgJm5ic3A7dG8gJm5ic3A7cGVlci4gDQombmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkRhdmlkICZuYnNwO0hhcnJpbmd0b24gJm5ic3A7 LSAmbmJzcDtwcm92aWRlZCAmbmJzcDtzb21lICZuYnNwO2NvbXBhcmlzb24gDQombmJzcDtvZiAm bmJzcDtBU04uMSAmbmJzcDt2cyAmbmJzcDtYTUwgJm5ic3A7Zm9yICZuYnNwO2EgJm5ic3A7U05N UCAmbmJzcDtsaWtlIA0KJm5ic3A7dGFzay4gJm5ic3A7U3VnZ2VzdGVkICZuYnNwO3dlICZuYnNw O3Nob3VsZCAmbmJzcDtjb25zaWRlciAmbmJzcDt3aGF0IA0KJm5ic3A7d291bGQgJm5ic3A7bWFr ZSAmbmJzcDtpdCAmbmJzcDtlYXNpZXIgJm5ic3A7Zm9yICZuYnNwO29wZXJhdG9yICZuYnNwO3Rv IA0KJm5ic3A7dXNlICZuYnNwO25vdCAmbmJzcDt3aGF0ICZuYnNwO3dvdWxkICZuYnNwO2NvbXBy ZXNzICZuYnNwO2l0ICZuYnNwO2Rvd24gDQombmJzcDt0aGUgJm5ic3A7c21hbGxlc3QuICZuYnNw O1N0cm9uZ2x5ICZuYnNwO3JlY29tbWVuZCAmbmJzcDt3ZSAmbmJzcDtjb25zaWRlciANCiZuYnNw O2hvdyAmbmJzcDt0aGF0ICZuYnNwO3N0YXRpc3RpY2FsICZuYnNwO2luZm9ybWF0aW9uICZuYnNw O2Zsb3dpbmcgDQombmJzcDthY3Jvc3MgJm5ic3A7dGhlICZuYnNwO3dpcmUgJm5ic3A7bWlnaHQg Jm5ic3A7YmUgJm5ic3A7dXNlZC4gJm5ic3A7UkVBRCANCiZuYnNwO1JGQyAmbmJzcDsxMDUyICZu YnNwO2J5ICZuYnNwO1ZpbnQgJm5ic3A7Q2VydC4gJm5ic3A7QWxzbyAmbmJzcDtzaG91bGQgDQom bmJzcDtyZWFkICZuYnNwO3RoZSAmbmJzcDtSRkMgJm5ic3A7MzQ0NCAmbmJzcDt3aXRoICZuYnNw O2RpZmZlcmVuY2UgDQombmJzcDtiZXR3ZWVuICZuYnNwO2RhdGEgJm5ic3A7bW9kZWwgJm5ic3A7 YW5kICZuYnNwO2luZm9ybWF0aW9uICZuYnNwO21vZGVsLiANCiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkRpc3RyaWJ1dGVkICZuYnNwO1RyYWNrZXIgJm5ic3A7VXNhZ2Ug Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlNraXBw ZWQgJm5ic3A7dGhpcyAmbmJzcDtwcmVzbyAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlBlZXIgJm5ic3A7 UHJvdG9jb2wgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPkRhdmlkICZuYnNwO0hhcnJpbmd0b24gJm5ic3A7YXMgJm5ic3A7YW4gJm5ic3A7aW5kaXZp ZHVhbCAmbmJzcDstIA0KJm5ic3A7ZG9uoa90ICZuYnNwO3NwZW5kICZuYnNwO3RvbyAmbmJzcDtt dWNoICZuYnNwO3RpbWUgJm5ic3A7ZGVzaWduaW5nIA0KJm5ic3A7c3R1ZmYgJm5ic3A7dGhhdCAm bmJzcDt3b3JrcyAmbmJzcDt0aG91Z2h0ICZuYnNwO3RvbyAmbmJzcDttYW55IA0KJm5ic3A7dHlw ZXMgJm5ic3A7b2YgJm5ic3A7TkFUcy4gJm5ic3A7SUVTRyAmbmJzcDtpcyAmbmJzcDtwdXNoaW5n ICZuYnNwO2JhY2sgDQombmJzcDtoYXJkICZuYnNwO29uICZuYnNwO3RoaW5ncyAmbmJzcDt0aGF0 ICZuYnNwO2tlZXAgJm5ic3A7djQgJm5ic3A7YXJvdW5kIA0KJm5ic3A7bG9uZ2VyICZuYnNwO2Jl Y2F1c2UgJm5ic3A7d2FudCAmbmJzcDt0byAmbmJzcDtjYXVzZSAmbmJzcDt0aGluZ3MgJm5ic3A7 dG8gDQombmJzcDttb3ZlICZuYnNwO3RvICZuYnNwO3Y2LiAmbmJzcDtIZSAmbmJzcDtzYWlkICZu YnNwO21vcmUgJm5ic3A7YnV0ICZuYnNwO2dvIA0KJm5ic3A7bGlzdGVuICZuYnNwO3RvICZuYnNw O3RoZSAmbmJzcDtyZWNvcmRpbmcgJm5ic3A7YXJvdW5kICZuYnNwOzEwOjI1PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5IYXJhbGQgJm5ic3A7LSAmbmJzcDtiaWcgJm5ic3A7ZmFuICZu YnNwO29mICZuYnNwO3JlbW92YWJsZSAmbmJzcDtjcnVmdCANCiZuYnNwO2J1dCAmbmJzcDt3aGF0 ICZuYnNwO3BhcnQgJm5ic3A7b2YgJm5ic3A7d2UgJm5ic3A7bmVlZCAmbmJzcDt0byAmbmJzcDtz aGlwIA0KJm5ic3A7ZG9lcyAmbmJzcDt0aGUgJm5ic3A7SUVTRyAmbmJzcDtub3QgJm5ic3A7Z2V0 LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QZWVy ICZuYnNwO3Byb3RvY29sICZuYnNwO29uICZuYnNwO05BVCAmbmJzcDt0cmF2ZXJzYWwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQombmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNv bmNlcm4gJm5ic3A7cmFpc2VkICZuYnNwO2Fib3V0ICZuYnNwO3JvYnVzdG5lc3MgJm5ic3A7dW5k ZXIgJm5ic3A7Y2h1cm4uIA0KJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5W ZXJ5ICZuYnNwO2ZldyAmbmJzcDtwZW9wbGUgJm5ic3A7aGFkICZuYnNwO3JlYWQgJm5ic3A7dGhp cy4gJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPlN1cnZleXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KHN0YXJ0ICZuYnNwOzEwOjQ0 ICZuYnNwOyk8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlF1ZXN0aW9uICZuYnNwO2Fz a2VkICZuYnNwO29uICZuYnNwO2Fkb3B0aW5nICZuYnNwO3RoZSAmbmJzcDtXRyANCiZuYnNwO21p bGVzdG9uZS4gJm5ic3A7V2lsbCAmbmJzcDt0YWtlICZuYnNwO3RoZSAmbmJzcDtxdWVzdGlvbiAm bmJzcDt0byANCiZuYnNwO3RoZSAmbmJzcDtsaXN0LiAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UFBTUCAmbmJzcDtkZXNpZ24gJm5ic3A7 Y29uc2lkZXJhdGlvbnMgJm5ic3A7ICZuYnNwOyhzdGFydCAmbmJzcDthdCANCiZuYnNwOzEwOjUz ICZuYnNwOykgJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5PdmVydmlldyAm bmJzcDtvZiAmbmJzcDtOYXBhLVdpbmUgJm5ic3A7cHJvamVjdC4gJm5ic3A7Q29vbCAmbmJzcDtz dHVmZi4gDQombmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPllvdSAmbmJzcDt3 b3VsZCAmbmJzcDtub3QgJm5ic3A7d2FudCAmbmJzcDt0byAmbmJzcDtxdWVyeSAmbmJzcDt0aGUg DQombmJzcDtBbHRvICZuYnNwO3NlcnZlciAmbmJzcDtmb3IgJm5ic3A7ZXZlcnkgJm5ic3A7Y2h1 bmsgJm5ic3A7LSAmbmJzcDt0aGF0IA0KJm5ic3A7aXMgJm5ic3A7dG9vICZuYnNwO2ZpbmUgJm5i c3A7Z3JhaW4gJm5ic3A7YnV0ICZuYnNwO2l0ICZuYnNwO2lzIA0KJm5ic3A7dXNlZnVsICZuYnNw O2ZvciAmbmJzcDtwZWVyICZuYnNwO3NlbGVjdGlvbi4gJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5MYXll cmVkICZuYnNwO1AyUCAmbmJzcDtzdHJlYW1pbmcgJm5ic3A7ICZuYnNwOyggJm5ic3A7c3RhcnQg Jm5ic3A7YXQgDQombmJzcDsxMTowNyAmbmJzcDspPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5ObyAmbmJzcDtkaXNjdXNzaW9uICZuYnNwO29uICZuYnNwO3RoaXMgJm5ic3A7ZHJhZnQu ICZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5QUFNQICZuYnNwO1NlY3VyZSAmbmJzcDtuYW1pbmcgJm5ic3A7ICZuYnNwOyggJm5ic3A7c3Rh cnQgJm5ic3A7YXQgDQombmJzcDsxMToxOSAmbmJzcDspPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5EYXZpZCAmbmJzcDticm91Z2h0ICZuYnNwO3VwICZuYnNwO3RoZSAmbmJzcDt0aGlz ICZuYnNwO3R5cGUgJm5ic3A7b2YgDQombmJzcDtuYW1pbmcgJm5ic3A7bWFkZSAmbmJzcDtzb21l ICZuYnNwO3Byb2JsZW1zICZuYnNwO211Y2ggJm5ic3A7ZWFzaWVyIA0KJm5ic3A7YW5kICZuYnNw O3dlICZuYnNwO3Nob3VsZCAmbmJzcDtsb29rICZuYnNwO2F0ICZuYnNwO3RoaXMuICZuYnNwOzwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Um9uaSAmbmJzcDstICZuYnNwO3JlZWQgJm5i c3A7dGhpcyAmbmJzcDthbmQgJm5ic3A7c2VlICZuYnNwO2lmICZuYnNwO3RoaXMgDQombmJzcDtj YW4gJm5ic3A7aGVscCAmbmJzcDt0aGUgJm5ic3A7YXJjaGl0ZWN0dXJlPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Q UFNQICZuYnNwO0luY2VudGl2ZSAmbmJzcDtwYXJhbWV0ZXJzICZuYnNwOyAmbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlJhbiAmbmJzcDtvdXQgJm5ic3A7b2YgJm5ic3A7dGlt ZSAmbmJzcDthbmQgJm5ic3A7ZGlkICZuYnNwO25vdCANCiZuYnNwO3ByZXNlbnQuICZuYnNwOzwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPlAyUC12b2QgJm5ic3A7c3lzdGVtICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5SYW4gJm5ic3A7 b3V0ICZuYnNwO29mICZuYnNwO3RpbWUgJm5ic3A7YW5kICZuYnNwO2RpZCAmbmJzcDtub3QgDQom bmJzcDtwcmVzZW50LjwvRElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj5wcHNwICZuYnNwO21haWxpbmcgJm5ic3A7bGlz dDwvRElWPg0KPERJVj5wcHNwQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcHBzcDwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M Pg0K --=====003_Dragon848450801682_=====-- From Akbar.Rahman@InterDigital.com Wed Nov 17 09:10:36 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F23A3A693C for ; Wed, 17 Nov 2010 09:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydoDspVNP+UC for ; Wed, 17 Nov 2010 09:10:35 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 6A3303A6936 for ; Wed, 17 Nov 2010 09:10:35 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 12:11:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB867A.73BCE85A" Date: Wed, 17 Nov 2010 12:11:19 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] mobility requirements Thread-Index: AcuGenPxx3b9pulmRr6ptM2QSouhNw== From: "Rahman, Akbar" To: X-OriginalArrivalTime: 17 Nov 2010 17:11:20.0228 (UTC) FILETIME=[741B7640:01CB867A] Cc: ppsp@ietf.org Subject: [ppsp] mobility requirements X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 17:10:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB867A.73BCE85A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ning, =20 =20 It was very nice talking to you in Beijing. I am just catching up with all my emails. I agree with your proposal for incorporating the three agreed upon mobility requirements (as per the Beijing WG session) into the PPSP requirements draft. =20 http://www.ietf.org/mail-archive/web/ppsp/current/msg00809.html =20 Thanks for agreeing to that. Also, as per your suggestion, I will do some further investigation on the proposed requirement for location of the peer device. I will get back to you and the working group in the near future with the results of my investigation. =20 =20 Sincerely, =20 =20 Akbar =20 ------_=_NextPart_001_01CB867A.73BCE85A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 

 

It was very nice talking to you in Beijing.  I = am just catching up with all my emails.  I agree with your proposal for = incorporating the three agreed upon mobility requirements (as per the Beijing WG session) = into the PPSP requirements draft.

 

= http://www.ietf.org/mail-archive/web/ppsp/current/msg00809.html<= /o:p>

 

Thanks for agreeing to that.  Also, as per = your suggestion, I will do some further investigation on the proposed requirement for = location of the peer device.  I will get back to you and the working group = in the near future with the results of my investigation.

 

 

Sincerely,

 

 

Akbar

 

------_=_NextPart_001_01CB867A.73BCE85A-- From zongning@huawei.com Wed Nov 17 16:36:02 2010 Return-Path: X-Original-To: ppsp@core3.amsl.com Delivered-To: ppsp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FF73A659C for ; Wed, 17 Nov 2010 16:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.494 X-Spam-Level: X-Spam-Status: No, score=-100.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 402Uspfzq9JT for ; Wed, 17 Nov 2010 16:36:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id DCEEA3A63D3 for ; Wed, 17 Nov 2010 16:36:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC200EVV1P02H@szxga04-in.huawei.com> for ppsp@ietf.org; Thu, 18 Nov 2010 08:36:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC200L4Q1P0ZC@szxga04-in.huawei.com> for ppsp@ietf.org; Thu, 18 Nov 2010 08:36:36 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC2000KN1P09N@szxml06-in.huawei.com> for ppsp@ietf.org; Thu, 18 Nov 2010 08:36:36 +0800 (CST) Date: Thu, 18 Nov 2010 08:36:40 +0800 From: Ning Zong In-reply-to: To: "'Rahman, Akbar'" Message-id: <004501cb86b8$aab404e0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_h/m1/LMcSkgdQKZadfcqlw)" Thread-index: AcuGenPxx3b9pulmRr6ptM2QSouhNwAPgfZQ Cc: ppsp@ietf.org Subject: Re: [ppsp] mobility requirements X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 00:36:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_h/m1/LMcSkgdQKZadfcqlw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Akbar, Thank you for contributing these requirements. I will incorporate them into the next version of PPSP requirements draft. BR, Ning Zong _____ From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Thursday, November 18, 2010 1:11 AM To: zongning@huawei.com Cc: ppsp@ietf.org Subject: [ppsp] mobility requirements Hi Ning, It was very nice talking to you in Beijing. I am just catching up with all my emails. I agree with your proposal for incorporating the three agreed upon mobility requirements (as per the Beijing WG session) into the PPSP requirements draft. http://www.ietf.org/mail-archive/web/ppsp/current/msg00809.html Thanks for agreeing to that. Also, as per your suggestion, I will do some further investigation on the proposed requirement for location of the peer device. I will get back to you and the working group in the near future with the results of my investigation. Sincerely, Akbar --Boundary_(ID_h/m1/LMcSkgdQKZadfcqlw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, = Akbar,

 <= /span>

Thank you for = contributing these requirements. I will incorporate them into the next version of = PPSP requirements draft.

 <= /span>

BR,

Ning = Zong

 <= /span>

From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: Thursday, November = 18, 2010 1:11 AM
To: = zongning@huawei.com
Cc: ppsp@ietf.org
Subject: [ppsp] mobility requirements

 

Hi = Ning,

 

 

It was very nice talking to you in Beijing.  I am just catching up = with all my emails.  I agree with your proposal for incorporating the three = agreed upon mobility requirements (as per the Beijing WG session) into the PPSP requirements draft.

 

= http://www.ietf.org/mail-archive/web/ppsp/current/msg00809.html<= /o:p>

 

Thanks for agreeing to that.  Also, as per your suggestion, = I will do some further investigation on the proposed requirement for location = of the peer device.  I will get back to you and the working group in the = near future with the results of my investigation.

 

 

Sincerely,

 

 

Akbar

 

--Boundary_(ID_h/m1/LMcSkgdQKZadfcqlw)--