From melodysong@huawei.com Tue Nov 3 18:39:38 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F76728C10E for ; Tue, 3 Nov 2009 18:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=1.705, 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 pXg-FFuhBGg6 for ; Tue, 3 Nov 2009 18:39:38 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B3E8E28C0FC for ; Tue, 3 Nov 2009 18:39:37 -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 <0KSK00L4NCQIWY@szxga04-in.huawei.com> for decade@ietf.org; Wed, 04 Nov 2009 10:39:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSK00L61CQIAV@szxga04-in.huawei.com> for decade@ietf.org; Wed, 04 Nov 2009 10:39:54 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSK00111CQHIL@szxml04-in.huawei.com> for decade@ietf.org; Wed, 04 Nov 2009 10:39:54 +0800 (CST) Date: Wed, 04 Nov 2009 10:39:53 +0800 From: Song Haibin In-reply-to: <4AEBFB28.5050403@telecomitalia.it> To: 'Enrico Marocco' Message-id: <001801ca5cf8$16e917e0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpaB7flwLQy57vISsGfid9hZNZnuAC8Cgnw Cc: decade@ietf.org Subject: Re: [decade] Draft agenda for DECADE BOF @IETF76 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 02:39:38 -0000 Hi Enrico, Thank you. Please check the updated agenda. http://trac.tools.ietf.org/area/app/trac/wiki/DecadeAgenda Xie Xie, Haibin >-----Original Message----- >From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] >Sent: Saturday, October 31, 2009 4:54 PM >To: Song Haibin >Cc: decade@ietf.org >Subject: Re: [decade] Draft agenda for DECADE BOF @IETF76 > >Song Haibin wrote: >> I just updated our draft agenda for DECADE BOF in Hiroshima. >> >> http://trac.tools.ietf.org/area/app/trac/wiki/DecadeAgenda > >The agenda looks good, but I'd suggest to move the charter >discussion after the problem statement and the other >introductory presentations. >After all, this is the first time the topic is presented to >the wider community and it seems a bit odd to start a meeting >discussing how to address the problem without first telling >what the problem is. > >-- >Ciao, >Enrico > From melodysong@huawei.com Wed Nov 4 17:39:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD773A6837 for ; Wed, 4 Nov 2009 17:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.21 X-Spam-Level: * X-Spam-Status: No, score=1.21 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xiEDWt+xFef5 for ; Wed, 4 Nov 2009 17:39:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 357323A6A40 for ; Wed, 4 Nov 2009 17:39:35 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSM00K904MAT2@szxga01-in.huawei.com> for decade@ietf.org; Thu, 05 Nov 2009 09:39:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSM00BQB4MAOR@szxga01-in.huawei.com> for decade@ietf.org; Thu, 05 Nov 2009 09:39:46 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSM00KVA4MAFM@szxml04-in.huawei.com> for decade@ietf.org; Thu, 05 Nov 2009 09:39:46 +0800 (CST) Date: Thu, 05 Nov 2009 09:39:49 +0800 From: Song Haibin To: decade@ietf.org Message-id: <001401ca5db8$dcea7900$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpduNyu7y5g4DMwRsepkFswPIM3Bw== Subject: [decade] wiki page for DECADE X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 01:39:49 -0000 Hi folks, I created a wiki page for DECADE BOF. All materials about DECADE could be found here. Comments are appreciated. http://trac.tools.ietf.org/bof/trac/wiki/decade Best Regards, Haibin Skype: alexsonghw From melodysong@huawei.com Sat Nov 7 23:14:54 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA623A6873 for ; Sat, 7 Nov 2009 23:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] 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 WSS3p5DqAa-O for ; Sat, 7 Nov 2009 23:14:53 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4EB2F3A685D for ; Sat, 7 Nov 2009 23:14:53 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSS00MEV457MT@szxga01-in.huawei.com> for decade@ietf.org; Sun, 08 Nov 2009 15:15:08 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSS004DJ457LP@szxga01-in.huawei.com> for decade@ietf.org; Sun, 08 Nov 2009 15:15:07 +0800 (CST) Received: from 975DEF9223E44C7 (host-17-228.meeting.ietf.org [133.93.17.228]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSS00BEI456MN@szxml02-in.huawei.com>; Sun, 08 Nov 2009 15:15:07 +0800 (CST) Date: Sun, 08 Nov 2009 16:14:57 +0800 From: Haibin Song To: decade Message-id: <200911081614569681220@huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 6, 15, 201, 22 [cn] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Subject: [decade] Agenda for DECADE BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 07:14:54 -0000 Hi everyone, Here is the agenda for the DECADE BOF. 1. Agenda Bashing (10 min) 2. Presentations (1). Presentation of problem statement (20 min) (2). Presentation of requirements (10 min) (3). Presentation of survey (10 min) 3. Open discussion and detailed charter discussion (50 min) 4. Conclusion and next steps (5 min) 5. Strawman proposal presentation (May skip over depends on interests and time at the meeting) (15 min) Please check the link below for more information. http://trac.tools.ietf.org/bof/trac/wiki/decade 2009-11-08 Haibin Song From richard_woundy@cable.comcast.com Sun Nov 8 15:34:07 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909403A68D6 for ; Sun, 8 Nov 2009 15:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-1.686, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 DPlqOO52zdXr for ; Sun, 8 Nov 2009 15:34:07 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C18123A677E for ; Sun, 8 Nov 2009 15:34:06 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.72395871; Sun, 08 Nov 2009 18:34:10 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 18:34:11 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 18:31:15 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB0438E2@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Volunteers for Decade jabber scribe and note taker Thread-Index: Acpgy5C7r61ql+5xQoyuSet0f0dnwQ== From: "Woundy, Richard" To: X-OriginalArrivalTime: 08 Nov 2009 23:34:11.0552 (UTC) FILETIME=[F996D600:01CA60CB] Subject: [decade] Volunteers for Decade jabber scribe and note taker X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:34:07 -0000 Folks, =20 Haibin and I are looking for volunteers for a jabber scribe and for a = note taker for the Decade BoF. =20 If you would like to volunteer, please send a private email to myself or = Haibin (we are cc'ed). Thanks in advance. =20 -- Rich From melodysong@huawei.com Sun Nov 8 17:54:22 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6F43A67F3 for ; Sun, 8 Nov 2009 17:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 gTPdt0dUkFMx for ; Sun, 8 Nov 2009 17:54:22 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 185093A635F for ; Sun, 8 Nov 2009 17:54:22 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST00KNIJZ1C6@szxga02-in.huawei.com> for decade@ietf.org; Mon, 09 Nov 2009 09:54:37 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST00GSIJZ1RQ@szxga02-in.huawei.com> for decade@ietf.org; Mon, 09 Nov 2009 09:54:37 +0800 (CST) Received: from 975DEF9223E44C7 (host-17-228.meeting.ietf.org [133.93.17.228]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KST00JGKJZ0TO@szxml01-in.huawei.com> for decade@ietf.org; Mon, 09 Nov 2009 09:54:37 +0800 (CST) Date: Mon, 09 Nov 2009 10:54:26 +0800 From: Haibin Song To: decade Message-id: <200911091054035931944@huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 6, 15, 201, 22 [cn] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Subject: [decade] storage cost vs bandwidth cost X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:54:22 -0000 The existing problem is that P2P applications consume a lot of traffic in the network. With investing more in bandwidth, you can maybe solve this problem, but maybe at great expense. However, the existing web host and content delivery services are mature businesses, you can enable your own business solutions with providing in-network storage. What do people on this list think about this trade-off? Here is one perspective on the relative economics (from Nick Weaver): http://www.tprcweb.com/images/stories/papers/paper.pdf. 09-11-09 Haibin Song Rich Woundy From lucyyong@huawei.com Tue Nov 10 20:33:39 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE37D3A6C0F for ; Tue, 10 Nov 2009 20:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 sF1h5uYw8+Zt for ; Tue, 10 Nov 2009 20:33:39 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 27CB03A67EB for ; Tue, 10 Nov 2009 20:33:39 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX0091CGOU7S@usaga01-in.huawei.com> for decade@ietf.org; Tue, 10 Nov 2009 20:34:07 -0800 (PST) Received: from y736742 (host-16-252.meeting.ietf.org [133.93.16.252]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00HOTGOO5X@usaga01-in.huawei.com> for decade@ietf.org; Tue, 10 Nov 2009 20:34:06 -0800 (PST) Date: Tue, 10 Nov 2009 22:34:20 -0600 From: Yong Lucy In-reply-to: <8A82D1BFEDDE7E4597978355239BBBCB0438E2@PACDCEXCMB06.cable.comcast.com> To: "'Woundy, Richard'" Message-id: <011501ca6288$3e6dad90$fc105d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpgy5C7r61ql+5xQoyuSet0f0dnwQBvIkqA References: <8A82D1BFEDDE7E4597978355239BBBCB0438E2@PACDCEXCMB06.cable.comcast.com> Cc: decade@ietf.org Subject: Re: [decade] Volunteers for Decade jabber scribe and note taker X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:33:39 -0000 I volunteer to be note taker. Lucy > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Woundy, Richard > Sent: Sunday, November 08, 2009 5:31 PM > To: decade@ietf.org > Subject: [decade] Volunteers for Decade jabber scribe and note taker > > Folks, > > Haibin and I are looking for volunteers for a jabber scribe and for a note > taker for the Decade BoF. > > If you would like to volunteer, please send a private email to myself or > Haibin (we are cc'ed). Thanks in advance. > > -- Rich > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Tue Nov 10 23:00:11 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A5628C2C4 for ; Tue, 10 Nov 2009 23:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 bujJw0HpGcmD for ; Tue, 10 Nov 2009 23:00:10 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id ED6F33A6C18 for ; Tue, 10 Nov 2009 23:00:01 -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 <0KSX00ETENB1H1@szxga04-in.huawei.com> for decade@ietf.org; Wed, 11 Nov 2009 14:57:01 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX00I1FNB1PY@szxga04-in.huawei.com> for decade@ietf.org; Wed, 11 Nov 2009 14:57:01 +0800 (CST) Received: from 975DEF9223E44C7 (host-17-228.meeting.ietf.org [133.93.17.228]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00BSLN8DND@szxml01-in.huawei.com>; Wed, 11 Nov 2009 14:57:01 +0800 (CST) Date: Wed, 11 Nov 2009 15:56:14 +0800 From: Haibin Song To: Yong Lucy , "'Woundy, Richard'" Message-id: <200911111555035623768@huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 6, 15, 201, 22 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT References: <8A82D1BFEDDE7E4597978355239BBBCB0438E2@PACDCEXCMB06.cable.comcast.com> Cc: "decade@ietf.org" Subject: Re: [decade] Volunteers for Decade jabber scribe and note taker X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 07:00:11 -0000 >I volunteer to be note taker. Thank you very much : ) Haibin & Rich >Lucy > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Woundy, Richard > Sent: Sunday, November 08, 2009 5:31 PM > To: decade@ietf.org > Subject: [decade] Volunteers for Decade jabber scribe and note taker > > Folks, > > Haibin and I are looking for volunteers for a jabber scribe and for a note > taker for the Decade BoF. > > If you would like to volunteer, please send a private email to myself or > Haibin (we are cc'ed). Thanks in advance. > > -- Rich > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard_woundy@cable.comcast.com Wed Nov 11 15:57:37 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFA63A6B7A for ; Wed, 11 Nov 2009 15:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=2.620, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 ueMkN8+dMw53 for ; Wed, 11 Nov 2009 15:57:37 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B53323A6968 for ; Wed, 11 Nov 2009 15:57:33 -0800 (PST) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60492304; Wed, 11 Nov 2009 18:57:59 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 18:58:00 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 18:57:47 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB04390E@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE BoF slides Thread-Index: AcpjKsR9IDg35DGFQzSulcvc8kF3vA== From: "Woundy, Richard" To: X-OriginalArrivalTime: 11 Nov 2009 23:58:00.0407 (UTC) FILETIME=[CC7E0E70:01CA632A] Subject: [decade] DECADE BoF slides X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:57:37 -0000 Folks, =20 All of our session slides have been uploaded to the IETF 76 meeting = materials website, = https://datatracker.ietf.org/meeting/76/materials.html, under DECADE. =20 We have received a last minute request for a session presentation, which = we will upload shortly. =20 -- Rich & Haibin, BoF co-chairs From flefauch@cisco.com Fri Nov 20 06:28:16 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7703A6ADB for ; Fri, 20 Nov 2009 06:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HA5q16eQRStL for ; Fri, 20 Nov 2009 06:28:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 11CE43A6930 for ; Fri, 20 Nov 2009 06:28:14 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,777,1249257600"; d="scan'208";a="54848098" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2009 14:28:09 +0000 Received: from ams-flefauch-87110.cisco.com (ams-flefauch-87110.cisco.com [10.55.161.203]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAKES8hx025484; Fri, 20 Nov 2009 14:28:09 GMT Content-Transfer-Encoding: quoted-printable From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Message-Id: <4763A813-4FA4-4B46-BC82-FB226497A111@cisco.com> Date: Fri, 20 Nov 2009 15:28:07 +0100 To: decade@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:28:16 -0000 Hello, Here are some comments/suggestions re decade-problem-statement: * section 3.1: "Recently, the IETF Application Layer Traffic Optimization (ALTO) = Working Group is formed to provide P2P applications with network = information so that they can perform better-than-random initial peer = selection [I-D.ietf-alto-problem-statement]. " I believe ALTO can be used for peer selection at any time (ie not just = initially). The information provided by ALTO is not necessarily "network = information" (e.g. could be just a list of selected peers). Also, some P2P Apps use other criteria than pure random, but still not = necessarily optimal. So how about, something like: "The IETF Application Layer Traffic Optimization (ALTO) Working Group = specifies mechanisms that allow P2P applications to perform selection of = peers that is superior to random selection or selection based on = information deducted from partial observation = [I-D.ietf-alto-problem-statement]. " * section 3.1: "On the other hand, it is reported that P2P traffic is becoming the = dominating traffic on the access networks of some networks, reaching as = high as 50-60% at the down-links and 60-90% at the uplinks ([DCIA], = [ICNP], [ipoque.P2P_survey.], [P2P_file_sharing]). Consequently, it = becomes increasingly important to complement the ALTO effort and reduce = upload access traffic, in addition to cross-domain and backbone traffic. " I think it would be worth discussing how LEDBAT relates to the above. Perhaps adding something along the lines of: " The IETF Low Extra Delay Background Transport (LEDBAT) Working Group = is focusing on broadly applicable techniques that allow large amounts of = data to be consistently transmitted without substantially affecting the = delays experienced by other users and applications. It is expected that = some P2P applications would start using such techniques, thereby = somewhat alleviating the perceivable impact (at least on other = applications) of their high volume traffic . However, such techniques do = not remove all inefficiencies, such as those associated with traffic = being sent upstream as many times as there are remote peers interested = in getting the corresponding information." * section 3.1: The current text discusses inefficiencies in terms of access network = bandwidth being effectively wasted from the viewpoint of the network = operator. Perhaps it would also be worth making explicit the = consequences from the P2P applications viewpoint i.e. likely longer time = to retrieve complete content as well as likely higher latency for some = real time applications (e.g. PPSP). * section 4: "Note that DECADE is independent of current IETF work on P2P, e.g. = P2PSIP, ALTO, PPSP. For example, peers discovered by either RELOAD or = ALTO can all use DECADE to share data. DECADE will focus on the = problems of P2P applications, although the solution might be used in = other context." The relationship between DECADE and PPSP deserves clarification. In = particular, because the PP2P problem statement document = (draft-zhang-ppsp-problem-statement-05): * in its section 4.2 : describes Edge Caches as one of the = motivations for developing PPSP standards protocols * in its section 7.1 : describes a PPSP use case with in-network = CDN nodes for enhanced P2P streaming. I think DECADE and PP2P may both contribute independently, and possibly = simultaneously, to making content available closer to peers. For = example, I can picture the following situations for PPSP and DECADE = coexistense: * a given network supports DECADE in-network caching, and its = CDN nodes do not participate as PPSP Peers for a given "stream" (e.g. = say because no CDN arrangement has been put in place between the Content = Provider and the considered network provider). In that case, PPSP Peers = will all be "off-net" but will be able to use DECADE in-network caching = to exchange chunks. (*) * a given network does not support DECADE in-network caching, = and (some of) its CDN nodes participate as PPSP Peers for a given = "stream" (e.g. say because an arrangement has been put in place between = the Content Provider and the considered network provider). In that case, = the CDN nodes will participate as in-network PPSP Peers. The off-net = PP2P Peers (ie endusers) will be able to get chunks from the in-network = CDN nodes (using PP2P protocols with the CDN nodes). * a given network supports DECADE in-network caching, and (some = of) its CDN nodes participate as PPSP Peers for a given "stream" (e.g. = say because an arrangement has been put in place between the Content = Provider and the considered network provider). In that case, the CDN = nodes will participate as in-network PPSP Peers. The off-net PP2P Peers = (ie endusers) will be able to get chunks from the in-network CDN nodes = (using PP2P protocols with the CDN nodes) _as well as_ be able to get = chunks from DECADE in-network Caching populated (using DECADE protocols) = by PPSP Peers (both off-net end-users and in-network CDN Nodes). (For simplicity I discussed the use of DECADE and PPSP Peering in the = same single network, but those could happen in different networks and = same would apply). (*) a particular case of that is when the Content Publisher behaves as a = Peer and uses DECADE to populate in-network content as discussed in = section 5.2 of DECADE problem statement. Is this how you also see DECADE and PPSP relate? can this be explicitly = discussed? * section 4.2: would be worth clarifying who controls the authorization. At least, one = case is that authorization is controlled by the DECADE user that places = the content in the cache. * Figures 2, 3, 4 and 5: I suggest you also illustrate the actual transfer of data (in addition = to the DECADE requests). It is done in Fig 5 but not in previous ones. = also I think it will make sequentiality clearer. For example in Fig 2, the data transfer from Sb to B would not happen = right after step 3 ("3 IAP get"); it would happen after a data transfer = from Sa to Sb , which would happen after "4 IAP get" from Sb to Sa. * Figure 4: It may be more intuitive to swap the order of step 2 and 3 (ie show A = storing the object in Sb before A responds to B). Hope that helps. Francois From lucyyong@huawei.com Fri Nov 20 14:30:24 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FF93A6884 for ; Fri, 20 Nov 2009 14:30:24 -0800 (PST) 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, 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 i5+o3EfwazhK for ; Fri, 20 Nov 2009 14:30:22 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id CE01E3A67D3 for ; Fri, 20 Nov 2009 14:30:22 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTF00JDJIIHR7@usaga04-in.huawei.com> for decade@ietf.org; Fri, 20 Nov 2009 16:30:17 -0600 (CST) Received: from y736742 ([10.124.12.82]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTF00C9QIICRH@usaga04-in.huawei.com> for decade@ietf.org; Fri, 20 Nov 2009 16:30:16 -0600 (CST) Date: Fri, 20 Nov 2009 16:30:08 -0600 From: Yong Lucy To: decade@ietf.org Message-id: <000901ca6a31$0645a610$520c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_YaXAEZMNI20EP6RfPZA+7A)" Thread-index: AcpqMQQOxzXZaK95SK6Ri9UIxdNs/g== Subject: [decade] DECADE minute notes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:30:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YaXAEZMNI20EP6RfPZA+7A) Content-type: multipart/alternative; boundary="Boundary_(ID_qyGPUzrMOTT8z5qr+ENT9g)" --Boundary_(ID_qyGPUzrMOTT8z5qr+ENT9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Here are minute notes from the meeting. Welcome to add on or correct it. Lucy --Boundary_(ID_qyGPUzrMOTT8z5qr+ENT9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Here are minute notes from the meeting. Welcome to add on or correct it.

Lucy

--Boundary_(ID_qyGPUzrMOTT8z5qr+ENT9g)-- --Boundary_(ID_YaXAEZMNI20EP6RfPZA+7A) Content-type: text/plain; name="decade minutes.txt" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="decade minutes.txt" Decade BOF notes Chair: Rich Woundy, Haibin Song Jabber: Enrico Marrocco slides are on Web. Rich goes thr. the agenda the goal is to work out achievable scope background and overview Rich Woundy: this was P2PChaching Bof @IETF75, overview, p2p has in-network storage. Problem statement Rich Alimi presenting Rich Alimi: p2p content distribution paradigm. scale, robust, space for innovation. p2p contribute significant traffic. p2p stress on infrastructure. the way to address this is to introduce storage in network, Problem 1: weakness of existing p2p caches: tight coupling w/ p2p application protocol. Problem 2: weak on integration with app. DECADE overview, reduce complexity and provide open access, integration with application policies. goal: design standard protocol for diverse P2P applications to utilize in-network storage. benefit: avoid complex of existing p2p caching; allow integration with application policies, etc. scope: in-scope: A standard, lightweight control protocol between in-network storage and P2P applications, and a standard, lightweight data-plane protocol for P2P applications to read from / write to in-network storage, and integration examples with one or two P2P protocols out-scope: the standard about how p2p app has to use network storage. Question: Ed Justevicius: network storage discovery totally free, Rich: ISP offer storage account. Leif Joh.: how does this differ from Alto? Rich: alto gives info. for peers to use. Leif: if I have info, I don't need this. Rich W. alto tell who is close, this gives standard way to store/read Rich A.: alto need p2p protocol, Leif: BT already has this. Barry: jabber is lost DY Kim: does decade take care of data ownership? Rich A.: yes, need auth. for access Stuart Cheshair: ISPs use it to reduce traffic. We create it for a purpose. But people may use for other things. Result may not decrease traffic. Rich: ISP provide Internet storage. we did not talk about the app. Enrico M: this work has economics. Omer: app. for it are 1) net meeting-caching, broadcast, 2) security Rich R.: protecting usage of content from other users requirements- Rich Alimi presenting Rich Almi: Data access: read/write/delete operations Resource control: Allow user to decide how to manage resource allocation for operations performed by remote users Authorization: ability for individual to read, write, store content. Data management: client decides time to live for content or delete explicitly. Error conditions handling David B.:ne issue that I think also needs to be discussed is if this group will actually make a protocol that handles the actual transfer or we "wrap" some existing IETF protocol that actually does the transfer of data HaiBin: can use existing transport protocol for data transfer Barry Leiba: about create list? organize content? atomatic move among storages? Rich A.: we have this in mind Ed.: store close to where I am. indication how close I am to the storage. is that relevant to scope? rich: if one storage location is available, then discovery. if multi storages, alto helps. Stuart A: Don't these services already exist? why we need a new file system? Lisa: would like to see a gap analysis. requirement is very clear. Web server with storage. missing right tickets. Lisa: There's a very close match with existing system (Webdav?). What's stopping client applications from using this? Rich W. some already have such functions. Lids: client use caching, why does p2p not use CDN? Rich W. this will impact forming WG. David Brian (Jabber): consider to use existing transport protocols presentation of survey: Ning Zong presenting Zong Ning: decade system components: discovery and a set of operations. transparent p2p cache: decade do not do this. Web cache: HPTPL extension to p2p CDN: NFS: allow client to access local storage. draft have more cases. Questions: xx: use existing protocol. protocol enable you for p2p like this: Rick W.: So the working group would do a survey The Elephant in the Room -- Illegal Content" Co-chair presenting Rich: illegal content. user use this to store illegal content. illegal content has different from copy right. copy right holder. this is out scope of this working group. example: operators are forced to remove or quarantine "illegal content" from storage. Barry: summary here is to work on protocol not policy. there are other things belong to policy. Rich W.: policy has technical influence. may good or bad, or change. Dave crocker: reality of world are social and complex. don't get distracted by them. reasonable and useful way to distinguish from them. to perceive this paradigm. suggestion to improve the way to address this. Peter Resnick: RFC2804, creating protocol should not help particular laws to accomplish or be enforced. Leif: Rich A: up to user which to go storage. possible legal Rich W. ISP doe not face the same issue. need to optimize all traffic. Leif: liaison to implementer. Rich: pplive platform. interest to use this and integrate with their own software. Dave B. (Jabber): an advantage to the implementers in that content will be available more widely (potentially when peers are offline) and from better connections. There are incentives for implementers. xx: be good to see that analysis in the survey Open discussion and charter discussion (50min) where are charter: ahout half in the room have read the charter -- there are perhaps 50-70 people in the room Lisa: channel tap here: form WG and shorter, suggest to have individual survey. give divergence. collaborating. slipt over Rich: implication? Lisa: is there critical mass. Rich: how relate to requirement presented before? Lisa: waterfall model. requirement, solution, rethink requ. jogger them to, use lib and software. avoid to keep coming back. Lisa: if there is critical mass for people who want to do this, we passed the ambiguity. Barry: have clear milestone. (few bof has feasible milestone.) Strawman Proposal 1: Rich: architecture proposal. service provider provides multiple storage servers. data locker server can offer multiple accounts. Lars: this is like network file system. Rich: there are differences. Hierarchical and weighted partitioning. Lisa: partition balancing is not in requirement, missed? may revise requirement. Rich: access protocol and requirements. Authorization using token. Lisa: HTTP usage security is about use of http and differences between remote procedure inquiry and remote process and remote data access Borjie Ohlman: network information is matter of moving from node oriented to information oriented network. how to identify information. info may move from different places and store in many places.Security is important. API to access any type of object. Organize information: model. NetInfo naming, flat approach. Netinfo architecture. Lisa: scope is too far. hard to standardlize that many choices. Rich W.: we want to have a focused scope. WG may not able to solve your problem . Song: this is valuable input. thanks Craig white: look for simple way to strawman. Rich: not look up yet. Lars Eggert: suggest to look at latest NFS, don't want duplicate work. Rich: we will look at it. Leif: where client should use this at OS level or other? not clear in current requirement. Rich: p2p app. to use this. hidden. Lars: implement subset benefit for client. not put into OS. Masato: does this only for ISP, can be provided by others, independent storage provider? Song: good question. ISP can provide web hosting. Rich W.: I don't think that this limit to ISP only. CDN is not ISP. but this is unscoped topic. Lida: this is better than mmov bof(??). solution well described. feedback and requirements are work well here. Alexy: humm Process Question appears to be to cover multiple topics. So hum was mixed 1. Is the problem statement clear? 70/30 2. Is the problem useful to solve? 80/20 3. Is the problem well-scoped? not enough humm. The Working Group (WG) will design and specify a standard protocol for P2P applications to utilize in-network storage. The protocol will include operations for a P2P applications system to (1) store and retrieve data (2) specify access control on who can store into and retrieve from its allocated storage, and (3) indicate resource sharing policies. Tim: diagram between storage meant me that NFS may be just miss server to server stuff. Lars: afraid that NFS solution is dismissed to quickly and existing protocol does not support this. Barry: figure out need to do and existing protocal may solve this. Stuart: comment on attentence: good stuff, no people do it, so we need new protocol. Lisa: believe you can have ISP run storage. huge benefits to use it. Joe: if you use Amazon S3, you've got exactly what we're talking about, in a protocol-inspecific manner. One of the claims for DECADE is to let service providers (ISP) implement one. Joe Hildebrand: so let's add *another* protocol? Barry: Or pick one that's close, and extend it Lars: ISP just use one protocol. is it risk for ISP? Barry: Google is doing this. there is no standard way to do it. XX: storage is not problem. problem is control. Craig: NFS does not have legal issue. why this have to address. Lucy: use this as offered service. NFS does not have this aspect. Lisa: reason to take so long on requirement, because cycle for requirements Lars: no problem with requirement. problem is the proposal. miss more detail on rules and how to do it. Alexy: Hum: re: working group for gap analysis: unanimous hum Joe H.: quantify decent, please. Rich W.: hand raise for reviewing document and comment on list: 20 Rich W.: hand raise for comparison protocols and heavy text contribution 9 --Boundary_(ID_YaXAEZMNI20EP6RfPZA+7A)-- From melodysong@huawei.com Sun Nov 22 19:12:16 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1623A3A67BE for ; Sun, 22 Nov 2009 19:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.849 X-Spam-Level: * X-Spam-Status: No, score=1.849 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_73=0.6, RDNS_NONE=0.1] 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 0c-78NkMm-nf for ; Sun, 22 Nov 2009 19:12:14 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 575573A67B2 for ; Sun, 22 Nov 2009 19:12:14 -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 <0KTJ00A1BKVXKX@szxga04-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 11:11:57 +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 <0KTJ0018NKVX6G@szxga04-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 11:11:57 +0800 (CST) Received: from s64081 ([10.164.12.12]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ00CN8KVW2V@szxml04-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 11:11:57 +0800 (CST) Date: Mon, 23 Nov 2009 11:11:56 +0800 From: Song Haibin In-reply-to: <4763A813-4FA4-4B46-BC82-FB226497A111@cisco.com> To: 'Francois Le Faucheur' , decade@ietf.org Message-id: <010801ca6bea$b6e969b0$0c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpp7bUZYfaZ1dPHSmO7Gmnn4H4YtgB6wEbg Subject: Re: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:12:16 -0000 Hi Francois, Good comments. >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Francois Le Faucheur >Sent: Friday, November 20, 2009 10:28 PM >To: decade@ietf.org >Subject: [decade] Comments on draft-song-decade-problem-statement > >Hello, > >Here are some comments/suggestions re decade-problem-statement: > >* section 3.1: >"Recently, the IETF Application Layer Traffic Optimization >(ALTO) Working Group is formed to provide P2P applications >with network information so that they can perform >better-than-random initial peer selection >[I-D.ietf-alto-problem-statement]. " >I believe ALTO can be used for peer selection at any time (ie >not just initially). It is in paragraph 4 of "Description of Working Group" in ALTO WG charter. You are right that P2P applications can do the peer selection with the help of ALTO server at any time. But I think here "initial peer selection" means it (ALTO) is the first step for peer selection, and after that P2P application users can do another round of peer selection based on other things, such like chunk availability(e.g. "rarest piece first") and per pair connection quality. >The information provided by ALTO is not necessarily "network >information" (e.g. could be just a list of selected peers). The peer selection is mainly based on network cost information. But you are right, we should delete the word "network" here. >Also, some P2P Apps use other criteria than pure random, but >still not necessarily optimal. >So how about, something like: >"The IETF Application Layer Traffic Optimization (ALTO) >Working Group specifies mechanisms that allow P2P applications >to perform selection of peers that is superior to random >selection or selection based on information deducted from >partial observation [I-D.ietf-alto-problem-statement]. " > It's okay. I prefer to just delete the word "network", just like what is said in the ALTO charter. > >* section 3.1: >"On the other hand, it is reported that P2P traffic is >becoming the dominating traffic on the access networks of some >networks, reaching as high as 50-60% at the down-links and >60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], >[P2P_file_sharing]). Consequently, it becomes increasingly >important to complement the ALTO effort and reduce upload >access traffic, in addition to cross-domain and backbone traffic. >" >I think it would be worth discussing how LEDBAT relates to the above. >Perhaps adding something along the lines of: >" The IETF Low Extra Delay Background Transport (LEDBAT) >Working Group is focusing on broadly applicable techniques >that allow large amounts of data to be consistently >transmitted without substantially affecting the delays >experienced by other users and applications. It is expected >that some P2P applications would start using such techniques, >thereby somewhat alleviating the perceivable impact (at least >on other applications) of their high volume traffic . However, >such techniques do not remove all inefficiencies, such as >those associated with traffic being sent upstream as many >times as there are remote peers interested in getting the >corresponding information." > I agree with what you said here. But LEDBAT is not so relevant to DECADE as ALTO. ALTO can reduce the backbone traffic of ISP's network by do better peer selection, while DECADE can save much of your uplink bandwidth by putting your contents into network and allowing others to download from there (need standard resource control). By putting the contents into network, P2P applications can also improve the availability of the content. LEDBAT focuses on the techniques that will alleviate the impact among transport for different applications. It is a little different. > >* section 3.1: >The current text discusses inefficiencies in terms of access >network bandwidth being effectively wasted from the viewpoint >of the network operator. Perhaps it would also be worth making >explicit the consequences from the P2P applications viewpoint >i.e. likely longer time to retrieve complete content as well >as likely higher latency for some real time applications (e.g. PPSP). > Good point. >* section 4: >"Note that DECADE is independent of current IETF work on P2P, >e.g. P2PSIP, ALTO, PPSP. For example, peers discovered by >either RELOAD or ALTO can all use DECADE to share data. >DECADE will focus on the problems of P2P applications, >although the solution might be used in other context." > >The relationship between DECADE and PPSP deserves >clarification. In particular, because the PP2P problem >statement document (draft-zhang-ppsp-problem-statement-05): > * in its section 4.2 : describes Edge Caches as one of >the motivations for developing PPSP standards protocols > * in its section 7.1 : describes a PPSP use case with >in-network CDN nodes for enhanced P2P streaming. > DECADE is quite different from PPSP while then can collaborate in a system. P2P streaming applications (e.g. those who use PPSP protocol) can use DECADE to distribute their services. DECADE is more generic, and focues on the standard interface between P2P client and the in-network storage(esp. resource control). The purpose of existing P2P caches are good and they are beneficial to both ISPs and P2P applications, but they have to support a lot of on-evolving P2P application protocols. DECADE will allow P2P applications users to use their in-network storage and share their in-network resources in a standard way, so as to reduce the complexity of existing p2p cache and allow better integration of p2p policies. >I think DECADE and PP2P may both contribute independently, and >possibly simultaneously, to making content available closer to >peers. For example, I can picture the following situations for >PPSP and DECADE coexistense: > * a given network supports DECADE in-network caching, >and its CDN nodes do not participate as PPSP Peers for a given >"stream" (e.g. say because no CDN arrangement has been put in >place between the Content Provider and the considered network >provider). In that case, PPSP Peers will all be "off-net" but >will be able to use DECADE in-network caching to exchange chunks. (*) > * a given network does not support DECADE in-network >caching, and (some of) its CDN nodes participate as PPSP Peers >for a given "stream" (e.g. say because an arrangement has been >put in place between the Content Provider and the considered >network provider). In that case, the CDN nodes will >participate as in-network PPSP Peers. The off-net PP2P Peers >(ie endusers) will be able to get chunks from the in-network >CDN nodes (using PP2P protocols with the CDN nodes). > * a given network supports DECADE in-network caching, >and (some of) its CDN nodes participate as PPSP Peers for a >given "stream" (e.g. say because an arrangement has been put >in place between the Content Provider and the considered >network provider). In that case, the CDN nodes will >participate as in-network PPSP Peers. The off-net PP2P Peers >(ie endusers) will be able to get chunks from the in-network >CDN nodes (using PP2P protocols with the CDN nodes) _as well >as_ be able to get chunks from DECADE in-network Caching >populated (using DECADE protocols) by PPSP Peers (both off-net >end-users and in-network CDN Nodes). > >(For simplicity I discussed the use of DECADE and PPSP Peering >in the same single network, but those could happen in >different networks and same would apply). > >(*) a particular case of that is when the Content Publisher >behaves as a Peer and uses DECADE to populate in-network >content as discussed in section 5.2 of DECADE problem statement. > Thank you for good examples: ) >Is this how you also see DECADE and PPSP relate? can this be >explicitly discussed? > We can regard PPSP as a specific protocol of a streaming application, which could use DECADE just like other p2p applications. >* section 4.2: >would be worth clarifying who controls the authorization. At >least, one case is that authorization is controlled by the >DECADE user that places the content in the cache. > Yes. The user can authorize others to access "its" in-network storage. > >* Figures 2, 3, 4 and 5: >I suggest you also illustrate the actual transfer of data (in >addition to the DECADE requests). It is done in Fig 5 but not >in previous ones. also I think it will make sequentiality clearer. >For example in Fig 2, the data transfer from Sb to B would not >happen right after step 3 ("3 IAP get"); it would happen after >a data transfer from Sa to Sb , which would happen after "4 >IAP get" from Sb to Sa. > We will add lines to illustrate the data transfer: ) >* Figure 4: >It may be more intuitive to swap the order of step 2 and 3 (ie >show A storing the object in Sb before A responds to B). > It's a little tricky here and P2P applications can use different ways to do it. When A gets the request to store object to Sb, it can simply reply with "Okay", and then do the store operation. Also it can start to store the object to Sb and then reply to B with a message " I have started to transfer...". Thanks, Haibin > >Hope that helps. > >Francois > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From zhangyunfei@chinamobile.com Sun Nov 22 20:04:53 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687AC3A69FB for ; Sun, 22 Nov 2009 20:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.514 X-Spam-Level: X-Spam-Status: No, score=-92.514 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_73=0.6, 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 ePD75YOAS3tP for ; Sun, 22 Nov 2009 20:04:51 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 9CDFD28C0F1 for ; Sun, 22 Nov 2009 20:04:50 -0800 (PST) Received: from LENOVO-917FFE55 ([10.1.4.16]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009112312115370-8254 ; Mon, 23 Nov 2009 12:11:53 +0800 Date: Mon, 23 Nov 2009 12:04:37 +0800 From: "zhangyunfei" To: "Song Haibin" , "'Francois Le Faucheur'" , "decade@ietf.org" References: <010801ca6bea$b6e969b0$0c0ca40a@china.huawei.com> Message-ID: <200911231204374682705@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 2009-11-23 12:11:53, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-11-23 12:04:46, Serialize complete at 2009-11-23 12:04:46 Content-Type: multipart/alternative; boundary="=====003_Dragon078352785458_=====" Subject: Re: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:04:53 -0000 This is a multi-part message in MIME format. --=====003_Dragon078352785458_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGksDQoNCiAgICBJdCBzZWVtcyBncmVhdCB0aGF0IEZyYW5jb2lzIGhhcyBnaXZlbiB1cyBhIGNs ZWFyZXIgcGljdHVyZSBvbiB0aGUgdXNhZ2Ugb2YgUFBTUCBhbmQgREVDQURFLlRoYW5rcyBhIGxv dC4NCiAgICBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSB0aGF0IGFsdGhvdWdoIGJvdGggUFBTUCBh bmQgREVDQURFIGhhdmUgYW4gZWRnZSBjYWNoZXMgdXNhZ2VzLCB0aGV5IGhhdmUgc2V2ZXJhbCBu b3RpY2VhYmxlIGRpZmZlcmVuY2VzOg0KICAgIDEpTW90aXZhdGlvbjoNCiAgICAgICAgICAgUFBT UCwgb3BlcmF0b3IvSVNQIG9yIG90aGVyIHZlbmRvcnMgdG8gbGF1bmNoIHAycCBzdHJlYW1pbmcg c2VydmljZTsgDQogICAgICAgICAgIERFQ0FERSwgb3BlcmF0b3IvSVNQIHRvIGRlY3JlYXNlIHRy YWZmaWMgcHJlc3N1cmUuVGhlIHNlcnZpY2UgaXMgbm90IHJ1biBieSBvcGVydG9yL0lTUC4NCiAg ICAyKVRhc2s6IA0KICAgICAgICAgIFBQU1AsdW5pZnlpbmcgcGVlci90cmFja2VyIHByb3RvY29s cyBib3RoIGZvciBDRE4gYW5kIGNvbW1vbiBwZWVycy4gQ0ROIGFzIHN1cGVycGVlcnMgZXF1aXBw aW5nIFBQU1AgcHJvdG9jb2xzLlBQU1AgcHJvdG9jb2xzIGFyZSAgIHAycCBwcm90b2NvbHMuDQog ICAgICAgICAgREVDQURFLGNyZWF0aW5nIHBlZXIvbm9uLXBlZXIgY2xpZW50IHRvIENETiBhY2Nl c3MgcHJvdG9jb2wsIHdoaWNoIGlzIG5vdCBhIFAyUCBwcm90b2NvbCBpdHNlbGYuIFBlZXIvY2xp ZW50IG5lZWRzIHRvIHVwZGF0ZSB0byAgICAgICBzdXBwb3J0IERFQ0FERSBwcm90b2NvbC4NCiAg IDMpU2NvcGU6IFBQU1AsIHAycCBzdHJlYW1pbmcgc2VuYXJpb3M7IERFQ0FERSwgcDJwIGRhdGEt aW50ZW5zaXZlIHNlbmFyaW9zOw0KICAgNClQdXJwb3NlOg0KICAgICAgICBQUFNQOmVmZmljaWVu dCBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHBlZXJzDQogICAgICAgIERFQ0FERTpwZWVy L2NsaWVudCBhbmQgY2FjaGUgY29tbWFuZCB0byBhc2sgY2FjaGVzIHRvIHBlcmZvcm0gY29ycmVz cG9uZGluZyBhY3Rpb25zDQogICAgSW4gYSB3b3JkLCBQUFNQIGFuZCBERUNBREUgbWF5IG9jY3Vy IGluIHRoZSBzYW1lIHNlbmFyaW8scDJwIHN0cmVhbWluZyB3aGlsZSB0aGVpciBmdW5jdGlvbmFs aXRpZXMgYXJlIHF1aXRlIGRpZmZlcmVudC4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1 bmZlaQ0KMjAwOS0xMS0yMw0KDQoNCg0Kt6K8/sjLo7ogU29uZyBIYWliaW4NCreiy83Ksbzko7og MjAwOS0xMS0yMyAxMToxOTozMg0KytW8/sjLo7ogJ0ZyYW5jb2lzIExlIEZhdWNoZXVyJzsgZGVj YWRlQGlldGYub3JnDQqzrcvNo7ogDQrW98zio7ogUmU6IFtkZWNhZGVdIENvbW1lbnRzIG9uIGRy YWZ0LXNvbmctZGVjYWRlLXByb2JsZW0tc3RhdGVtZW50DQoNCkhpICBGcmFuY29pcywNCg0KR29v ZCAgY29tbWVudHMuICANCiAgIA0KDQo+LS0tLS1PcmlnaW5hbCAgTWVzc2FnZS0tLS0tDQo+RnJv bTogIGRlY2FkZS1ib3VuY2VzQGlldGYub3JnICBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYu b3JnXSAgDQo+T24gIEJlaGFsZiAgT2YgIEZyYW5jb2lzICBMZSAgRmF1Y2hldXINCj5TZW50OiAg RnJpZGF5LCAgTm92ZW1iZXIgIDIwLCAgMjAwOSAgMTA6MjggIFBNDQo+VG86ICBkZWNhZGVAaWV0 Zi5vcmcNCj5TdWJqZWN0OiAgW2RlY2FkZV0gIENvbW1lbnRzICBvbiAgZHJhZnQtc29uZy1kZWNh ZGUtcHJvYmxlbS1zdGF0ZW1lbnQNCj4NCj5IZWxsbywNCj4NCj5IZXJlICBhcmUgIHNvbWUgIGNv bW1lbnRzL3N1Z2dlc3Rpb25zICByZSAgZGVjYWRlLXByb2JsZW0tc3RhdGVtZW50Og0KPg0KPiog IHNlY3Rpb24gIDMuMToNCj4iUmVjZW50bHksICB0aGUgIElFVEYgIEFwcGxpY2F0aW9uICBMYXll ciAgVHJhZmZpYyAgT3B0aW1pemF0aW9uICANCj4oQUxUTykgIFdvcmtpbmcgIEdyb3VwICBpcyAg Zm9ybWVkICB0byAgcHJvdmlkZSAgUDJQICBhcHBsaWNhdGlvbnMgIA0KPndpdGggIG5ldHdvcmsg IGluZm9ybWF0aW9uICBzbyAgdGhhdCAgdGhleSAgY2FuICBwZXJmb3JtICANCj5iZXR0ZXItdGhh bi1yYW5kb20gIGluaXRpYWwgIHBlZXIgIHNlbGVjdGlvbiAgDQo+W0ktRC5pZXRmLWFsdG8tcHJv YmxlbS1zdGF0ZW1lbnRdLiAgIg0KPkkgIGJlbGlldmUgIEFMVE8gIGNhbiAgYmUgIHVzZWQgIGZv ciAgcGVlciAgc2VsZWN0aW9uICBhdCAgYW55ICB0aW1lICAoaWUgIA0KPm5vdCAganVzdCAgaW5p dGlhbGx5KS4NCg0KSXQgIGlzICBpbiAgcGFyYWdyYXBoICA0ICBvZiAgIkRlc2NyaXB0aW9uICBv ZiAgV29ya2luZyAgR3JvdXAiICBpbiAgQUxUTyAgV0cgIGNoYXJ0ZXIuDQpZb3UgIGFyZSAgcmln aHQgIHRoYXQgIFAyUCAgYXBwbGljYXRpb25zICBjYW4gIGRvICB0aGUgIHBlZXIgIHNlbGVjdGlv biAgd2l0aCAgdGhlICBoZWxwDQpvZiAgQUxUTyAgc2VydmVyICBhdCAgYW55ICB0aW1lLiAgQnV0 ICAgIEkgIHRoaW5rICBoZXJlICAiaW5pdGlhbCAgcGVlciAgc2VsZWN0aW9uIiAgbWVhbnMNCml0 ICAoQUxUTykgIGlzICB0aGUgIGZpcnN0ICBzdGVwICBmb3IgIHBlZXIgIHNlbGVjdGlvbiwgIGFu ZCAgYWZ0ZXIgIHRoYXQgIFAyUA0KYXBwbGljYXRpb24gIHVzZXJzICBjYW4gIGRvICBhbm90aGVy ICByb3VuZCAgb2YgIHBlZXIgIHNlbGVjdGlvbiAgYmFzZWQgIG9uICBvdGhlcg0KdGhpbmdzLCAg c3VjaCAgbGlrZSAgY2h1bmsgIGF2YWlsYWJpbGl0eShlLmcuICAicmFyZXN0ICBwaWVjZSAgZmly c3QiKSAgYW5kICBwZXIgIHBhaXINCmNvbm5lY3Rpb24gIHF1YWxpdHkuDQoNCj5UaGUgIGluZm9y bWF0aW9uICBwcm92aWRlZCAgYnkgIEFMVE8gIGlzICBub3QgIG5lY2Vzc2FyaWx5ICAibmV0d29y ayAgDQo+aW5mb3JtYXRpb24iICAoZS5nLiAgY291bGQgIGJlICBqdXN0ICBhICBsaXN0ICBvZiAg c2VsZWN0ZWQgIHBlZXJzKS4NCg0KVGhlICBwZWVyICBzZWxlY3Rpb24gIGlzICBtYWlubHkgIGJh c2VkICBvbiAgbmV0d29yayAgY29zdCAgaW5mb3JtYXRpb24uICBCdXQgIHlvdSAgYXJlDQpyaWdo dCwgIHdlICBzaG91bGQgIGRlbGV0ZSAgdGhlICB3b3JkICAibmV0d29yayIgIGhlcmUuDQoNCj5B bHNvLCAgc29tZSAgUDJQICBBcHBzICB1c2UgIG90aGVyICBjcml0ZXJpYSAgdGhhbiAgcHVyZSAg cmFuZG9tLCAgYnV0ICANCj5zdGlsbCAgbm90ICBuZWNlc3NhcmlseSAgb3B0aW1hbC4NCj5TbyAg aG93ICBhYm91dCwgIHNvbWV0aGluZyAgbGlrZToNCj4iVGhlICBJRVRGICBBcHBsaWNhdGlvbiAg TGF5ZXIgIFRyYWZmaWMgIE9wdGltaXphdGlvbiAgKEFMVE8pICANCj5Xb3JraW5nICBHcm91cCAg c3BlY2lmaWVzICBtZWNoYW5pc21zICB0aGF0ICBhbGxvdyAgUDJQICBhcHBsaWNhdGlvbnMgIA0K PnRvICBwZXJmb3JtICBzZWxlY3Rpb24gIG9mICBwZWVycyAgdGhhdCAgaXMgIHN1cGVyaW9yICB0 byAgcmFuZG9tICANCj5zZWxlY3Rpb24gIG9yICBzZWxlY3Rpb24gIGJhc2VkICBvbiAgaW5mb3Jt YXRpb24gIGRlZHVjdGVkICBmcm9tICANCj5wYXJ0aWFsICBvYnNlcnZhdGlvbiAgW0ktRC5pZXRm LWFsdG8tcHJvYmxlbS1zdGF0ZW1lbnRdLiAgIg0KPg0KDQpJdCdzICBva2F5LiAgSSAgcHJlZmVy ICB0byAganVzdCAgZGVsZXRlICB0aGUgIHdvcmQgICJuZXR3b3JrIiwgIGp1c3QgIGxpa2UgIHdo YXQgIGlzDQpzYWlkICBpbiAgdGhlICBBTFRPICBjaGFydGVyLg0KDQo+DQo+KiAgc2VjdGlvbiAg My4xOg0KPiJPbiAgdGhlICBvdGhlciAgaGFuZCwgIGl0ICBpcyAgcmVwb3J0ZWQgIHRoYXQgIFAy UCAgdHJhZmZpYyAgaXMgIA0KPmJlY29taW5nICB0aGUgIGRvbWluYXRpbmcgIHRyYWZmaWMgIG9u ICB0aGUgIGFjY2VzcyAgbmV0d29ya3MgIG9mICBzb21lICANCj5uZXR3b3JrcywgIHJlYWNoaW5n ICBhcyAgaGlnaCAgYXMgIDUwLTYwJSAgYXQgIHRoZSAgZG93bi1saW5rcyAgYW5kICANCj42MC05 MCUgIGF0ICB0aGUgIHVwbGlua3MgIChbRENJQV0sICBbSUNOUF0sICBbaXBvcXVlLlAyUF9zdXJ2 ZXkuXSwgIA0KPltQMlBfZmlsZV9zaGFyaW5nXSkuICAgIENvbnNlcXVlbnRseSwgIGl0ICBiZWNv bWVzICBpbmNyZWFzaW5nbHkgIA0KPmltcG9ydGFudCAgdG8gIGNvbXBsZW1lbnQgIHRoZSAgQUxU TyAgZWZmb3J0ICBhbmQgIHJlZHVjZSAgdXBsb2FkICANCj5hY2Nlc3MgIHRyYWZmaWMsICBpbiAg YWRkaXRpb24gIHRvICBjcm9zcy1kb21haW4gIGFuZCAgYmFja2JvbmUgIHRyYWZmaWMuDQo+Ig0K PkkgIHRoaW5rICBpdCAgd291bGQgIGJlICB3b3J0aCAgZGlzY3Vzc2luZyAgaG93ICBMRURCQVQg IHJlbGF0ZXMgIHRvICB0aGUgIGFib3ZlLg0KPlBlcmhhcHMgIGFkZGluZyAgc29tZXRoaW5nICBh bG9uZyAgdGhlICBsaW5lcyAgb2Y6DQo+IiAgVGhlICBJRVRGICBMb3cgIEV4dHJhICBEZWxheSAg QmFja2dyb3VuZCAgVHJhbnNwb3J0ICAoTEVEQkFUKSAgDQo+V29ya2luZyAgR3JvdXAgIGlzICBm b2N1c2luZyAgb24gIGJyb2FkbHkgIGFwcGxpY2FibGUgIHRlY2huaXF1ZXMgIA0KPnRoYXQgIGFs bG93ICBsYXJnZSAgYW1vdW50cyAgb2YgIGRhdGEgIHRvICBiZSAgY29uc2lzdGVudGx5ICANCj50 cmFuc21pdHRlZCAgd2l0aG91dCAgc3Vic3RhbnRpYWxseSAgYWZmZWN0aW5nICB0aGUgIGRlbGF5 cyAgDQo+ZXhwZXJpZW5jZWQgIGJ5ICBvdGhlciAgdXNlcnMgIGFuZCAgYXBwbGljYXRpb25zLiAg SXQgIGlzICBleHBlY3RlZCAgDQo+dGhhdCAgc29tZSAgUDJQICBhcHBsaWNhdGlvbnMgIHdvdWxk ICBzdGFydCAgdXNpbmcgIHN1Y2ggIHRlY2huaXF1ZXMsICANCj50aGVyZWJ5ICBzb21ld2hhdCAg YWxsZXZpYXRpbmcgIHRoZSAgcGVyY2VpdmFibGUgIGltcGFjdCAgKGF0ICBsZWFzdCAgDQo+b24g IG90aGVyICBhcHBsaWNhdGlvbnMpICBvZiAgdGhlaXIgIGhpZ2ggIHZvbHVtZSAgdHJhZmZpYyAg LiAgSG93ZXZlciwgIA0KPnN1Y2ggIHRlY2huaXF1ZXMgIGRvICBub3QgIHJlbW92ZSAgYWxsICBp bmVmZmljaWVuY2llcywgIHN1Y2ggIGFzICANCj50aG9zZSAgYXNzb2NpYXRlZCAgd2l0aCAgdHJh ZmZpYyAgYmVpbmcgIHNlbnQgIHVwc3RyZWFtICBhcyAgbWFueSAgDQo+dGltZXMgIGFzICB0aGVy ZSAgYXJlICByZW1vdGUgIHBlZXJzICBpbnRlcmVzdGVkICBpbiAgZ2V0dGluZyAgdGhlICANCj5j b3JyZXNwb25kaW5nICBpbmZvcm1hdGlvbi4iDQo+DQoNCkkgIGFncmVlICB3aXRoICB3aGF0ICB5 b3UgIHNhaWQgIGhlcmUuICBCdXQgIExFREJBVCAgaXMgIG5vdCAgc28gIHJlbGV2YW50ICB0byAg REVDQURFICBhcw0KQUxUTy4gIEFMVE8gIGNhbiAgcmVkdWNlICB0aGUgIGJhY2tib25lICB0cmFm ZmljICBvZiAgSVNQJ3MgIG5ldHdvcmsgIGJ5ICBkbyAgYmV0dGVyDQpwZWVyICBzZWxlY3Rpb24s ICB3aGlsZSAgREVDQURFICBjYW4gIHNhdmUgIG11Y2ggIG9mICB5b3VyICB1cGxpbmsgIGJhbmR3 aWR0aCAgYnkNCnB1dHRpbmcgIHlvdXIgIGNvbnRlbnRzICBpbnRvICBuZXR3b3JrICBhbmQgIGFs bG93aW5nICBvdGhlcnMgIHRvICBkb3dubG9hZCAgZnJvbQ0KdGhlcmUgIChuZWVkICBzdGFuZGFy ZCAgcmVzb3VyY2UgIGNvbnRyb2wpLiAgQnkgIHB1dHRpbmcgIHRoZSAgY29udGVudHMgIGludG8N Cm5ldHdvcmssICBQMlAgIGFwcGxpY2F0aW9ucyAgY2FuICBhbHNvICBpbXByb3ZlICB0aGUgIGF2 YWlsYWJpbGl0eSAgb2YgIHRoZSAgY29udGVudC4NCkxFREJBVCAgZm9jdXNlcyAgb24gIHRoZSAg dGVjaG5pcXVlcyAgdGhhdCAgd2lsbCAgYWxsZXZpYXRlICB0aGUgIGltcGFjdCAgYW1vbmcNCnRy YW5zcG9ydCAgZm9yICBkaWZmZXJlbnQgIGFwcGxpY2F0aW9ucy4gIEl0ICBpcyAgYSAgbGl0dGxl ICBkaWZmZXJlbnQuDQoNCj4NCj4qICBzZWN0aW9uICAzLjE6DQo+VGhlICBjdXJyZW50ICB0ZXh0 ICBkaXNjdXNzZXMgIGluZWZmaWNpZW5jaWVzICBpbiAgdGVybXMgIG9mICBhY2Nlc3MgIA0KPm5l dHdvcmsgIGJhbmR3aWR0aCAgYmVpbmcgIGVmZmVjdGl2ZWx5ICB3YXN0ZWQgIGZyb20gIHRoZSAg dmlld3BvaW50ICANCj5vZiAgdGhlICBuZXR3b3JrICBvcGVyYXRvci4gIFBlcmhhcHMgIGl0ICB3 b3VsZCAgYWxzbyAgYmUgIHdvcnRoICBtYWtpbmcgIA0KPmV4cGxpY2l0ICB0aGUgIGNvbnNlcXVl bmNlcyAgZnJvbSAgdGhlICBQMlAgIGFwcGxpY2F0aW9ucyAgdmlld3BvaW50ICANCj5pLmUuICBs aWtlbHkgIGxvbmdlciAgdGltZSAgdG8gIHJldHJpZXZlICBjb21wbGV0ZSAgY29udGVudCAgYXMg IHdlbGwgIA0KPmFzICBsaWtlbHkgIGhpZ2hlciAgbGF0ZW5jeSAgZm9yICBzb21lICByZWFsICB0 aW1lICBhcHBsaWNhdGlvbnMgIChlLmcuICBQUFNQKS4NCj4NCg0KR29vZCAgcG9pbnQuICANCg0K PiogIHNlY3Rpb24gIDQ6DQo+Ik5vdGUgIHRoYXQgIERFQ0FERSAgaXMgIGluZGVwZW5kZW50ICBv ZiAgY3VycmVudCAgSUVURiAgd29yayAgb24gIFAyUCwgIA0KPmUuZy4gIFAyUFNJUCwgIEFMVE8s ICBQUFNQLiAgICBGb3IgIGV4YW1wbGUsICBwZWVycyAgZGlzY292ZXJlZCAgYnkgIA0KPmVpdGhl ciAgUkVMT0FEICBvciAgQUxUTyAgY2FuICBhbGwgIHVzZSAgREVDQURFICB0byAgc2hhcmUgIGRh dGEuICAgIA0KPkRFQ0FERSAgd2lsbCAgZm9jdXMgIG9uICB0aGUgICAgcHJvYmxlbXMgIG9mICBQ MlAgIGFwcGxpY2F0aW9ucywgIA0KPmFsdGhvdWdoICB0aGUgIHNvbHV0aW9uICBtaWdodCAgYmUg IHVzZWQgIGluICBvdGhlciAgY29udGV4dC4iDQo+DQo+VGhlICByZWxhdGlvbnNoaXAgIGJldHdl ZW4gIERFQ0FERSAgYW5kICBQUFNQICBkZXNlcnZlcyAgDQo+Y2xhcmlmaWNhdGlvbi4gIEluICBw YXJ0aWN1bGFyLCAgYmVjYXVzZSAgdGhlICBQUDJQICBwcm9ibGVtICANCj5zdGF0ZW1lbnQgIGRv Y3VtZW50ICAoZHJhZnQtemhhbmctcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0wNSk6DQo+ICogIGlu ICBpdHMgIHNlY3Rpb24gIDQuMiAgOiAgZGVzY3JpYmVzICBFZGdlICBDYWNoZXMgIGFzICBvbmUg IG9mICANCj50aGUgIG1vdGl2YXRpb25zICBmb3IgIGRldmVsb3BpbmcgIFBQU1AgIHN0YW5kYXJk cyAgcHJvdG9jb2xzDQo+ICogIGluICBpdHMgIHNlY3Rpb24gIDcuMSAgOiAgZGVzY3JpYmVzICBh ICBQUFNQICB1c2UgIGNhc2UgIHdpdGggIA0KPmluLW5ldHdvcmsgIENETiAgbm9kZXMgIGZvciAg ZW5oYW5jZWQgIFAyUCAgc3RyZWFtaW5nLg0KPg0KDQpERUNBREUgIGlzICBxdWl0ZSAgZGlmZmVy ZW50ICBmcm9tICBQUFNQICB3aGlsZSAgdGhlbiAgY2FuICBjb2xsYWJvcmF0ZSAgaW4gIGEgIHN5 c3RlbS4NClAyUCAgc3RyZWFtaW5nICBhcHBsaWNhdGlvbnMgIChlLmcuICB0aG9zZSAgd2hvICB1 c2UgIFBQU1AgIHByb3RvY29sKSAgY2FuICB1c2UgIERFQ0FERQ0KdG8gIGRpc3RyaWJ1dGUgIHRo ZWlyICBzZXJ2aWNlcy4gIERFQ0FERSAgaXMgIG1vcmUgIGdlbmVyaWMsICBhbmQgIGZvY3VlcyAg b24gIHRoZQ0Kc3RhbmRhcmQgIGludGVyZmFjZSAgYmV0d2VlbiAgUDJQICBjbGllbnQgIGFuZCAg dGhlICBpbi1uZXR3b3JrICBzdG9yYWdlKGVzcC4NCnJlc291cmNlICBjb250cm9sKS4gIFRoZSAg cHVycG9zZSAgb2YgIGV4aXN0aW5nICBQMlAgIGNhY2hlcyAgYXJlICBnb29kICBhbmQgIHRoZXkg IGFyZQ0KYmVuZWZpY2lhbCAgdG8gIGJvdGggIElTUHMgIGFuZCAgUDJQICBhcHBsaWNhdGlvbnMs ICBidXQgIHRoZXkgIGhhdmUgIHRvICBzdXBwb3J0ICBhICBsb3QNCm9mICBvbi1ldm9sdmluZyAg UDJQICBhcHBsaWNhdGlvbiAgcHJvdG9jb2xzLiAgREVDQURFICB3aWxsICBhbGxvdyAgUDJQICBh cHBsaWNhdGlvbnMNCnVzZXJzICB0byAgdXNlICB0aGVpciAgaW4tbmV0d29yayAgc3RvcmFnZSAg YW5kICBzaGFyZSAgdGhlaXIgIGluLW5ldHdvcmsgIHJlc291cmNlcw0KaW4gIGEgIHN0YW5kYXJk ICB3YXksICBzbyAgYXMgIHRvICByZWR1Y2UgIHRoZSAgY29tcGxleGl0eSAgb2YgIGV4aXN0aW5n ICBwMnAgIGNhY2hlICBhbmQNCmFsbG93ICBiZXR0ZXIgIGludGVncmF0aW9uICBvZiAgcDJwICBw b2xpY2llcy4NCg0KDQo+SSAgdGhpbmsgIERFQ0FERSAgYW5kICBQUDJQICBtYXkgIGJvdGggIGNv bnRyaWJ1dGUgIGluZGVwZW5kZW50bHksICBhbmQgIA0KPnBvc3NpYmx5ICBzaW11bHRhbmVvdXNs eSwgIHRvICBtYWtpbmcgIGNvbnRlbnQgIGF2YWlsYWJsZSAgY2xvc2VyICB0byAgDQo+cGVlcnMu ICBGb3IgIGV4YW1wbGUsICBJICBjYW4gIHBpY3R1cmUgIHRoZSAgZm9sbG93aW5nICBzaXR1YXRp b25zICBmb3IgIA0KPlBQU1AgIGFuZCAgREVDQURFICBjb2V4aXN0ZW5zZToNCj4gKiAgYSAgZ2l2 ZW4gIG5ldHdvcmsgIHN1cHBvcnRzICBERUNBREUgIGluLW5ldHdvcmsgIGNhY2hpbmcsICANCj5h bmQgIGl0cyAgQ0ROICBub2RlcyAgZG8gIG5vdCAgcGFydGljaXBhdGUgIGFzICBQUFNQICBQZWVy cyAgZm9yICBhICBnaXZlbiAgDQo+InN0cmVhbSIgIChlLmcuICBzYXkgIGJlY2F1c2UgIG5vICBD RE4gIGFycmFuZ2VtZW50ICBoYXMgIGJlZW4gIHB1dCAgaW4gIA0KPnBsYWNlICBiZXR3ZWVuICB0 aGUgIENvbnRlbnQgIFByb3ZpZGVyICBhbmQgIHRoZSAgY29uc2lkZXJlZCAgbmV0d29yayAgDQo+ cHJvdmlkZXIpLiAgSW4gIHRoYXQgIGNhc2UsICBQUFNQICBQZWVycyAgd2lsbCAgYWxsICBiZSAg Im9mZi1uZXQiICBidXQgIA0KPndpbGwgIGJlICBhYmxlICB0byAgdXNlICBERUNBREUgIGluLW5l dHdvcmsgIGNhY2hpbmcgIHRvICBleGNoYW5nZSAgY2h1bmtzLiAgKCopDQo+ICogIGEgIGdpdmVu ICBuZXR3b3JrICBkb2VzICBub3QgIHN1cHBvcnQgIERFQ0FERSAgaW4tbmV0d29yayAgDQo+Y2Fj aGluZywgIGFuZCAgKHNvbWUgIG9mKSAgaXRzICBDRE4gIG5vZGVzICBwYXJ0aWNpcGF0ZSAgYXMg IFBQU1AgIFBlZXJzICANCj5mb3IgIGEgIGdpdmVuICAic3RyZWFtIiAgKGUuZy4gIHNheSAgYmVj YXVzZSAgYW4gIGFycmFuZ2VtZW50ICBoYXMgIGJlZW4gIA0KPnB1dCAgaW4gIHBsYWNlICBiZXR3 ZWVuICB0aGUgIENvbnRlbnQgIFByb3ZpZGVyICBhbmQgIHRoZSAgY29uc2lkZXJlZCAgDQo+bmV0 d29yayAgcHJvdmlkZXIpLiAgSW4gIHRoYXQgIGNhc2UsICB0aGUgIENETiAgbm9kZXMgIHdpbGwg IA0KPnBhcnRpY2lwYXRlICBhcyAgaW4tbmV0d29yayAgUFBTUCAgUGVlcnMuICBUaGUgIG9mZi1u ZXQgIFBQMlAgIFBlZXJzICANCj4oaWUgIGVuZHVzZXJzKSAgd2lsbCAgYmUgIGFibGUgIHRvICBn ZXQgIGNodW5rcyAgZnJvbSAgdGhlICBpbi1uZXR3b3JrICANCj5DRE4gIG5vZGVzICAodXNpbmcg IFBQMlAgIHByb3RvY29scyAgd2l0aCAgdGhlICBDRE4gIG5vZGVzKS4NCj4gKiAgYSAgZ2l2ZW4g IG5ldHdvcmsgIHN1cHBvcnRzICBERUNBREUgIGluLW5ldHdvcmsgIGNhY2hpbmcsICANCj5hbmQg IChzb21lICBvZikgIGl0cyAgQ0ROICBub2RlcyAgcGFydGljaXBhdGUgIGFzICBQUFNQICBQZWVy cyAgZm9yICBhICANCj5naXZlbiAgInN0cmVhbSIgIChlLmcuICBzYXkgIGJlY2F1c2UgIGFuICBh cnJhbmdlbWVudCAgaGFzICBiZWVuICBwdXQgIA0KPmluICBwbGFjZSAgYmV0d2VlbiAgdGhlICBD b250ZW50ICBQcm92aWRlciAgYW5kICB0aGUgIGNvbnNpZGVyZWQgIA0KPm5ldHdvcmsgIHByb3Zp ZGVyKS4gIEluICB0aGF0ICBjYXNlLCAgdGhlICBDRE4gIG5vZGVzICB3aWxsICANCj5wYXJ0aWNp cGF0ZSAgYXMgIGluLW5ldHdvcmsgIFBQU1AgIFBlZXJzLiAgVGhlICBvZmYtbmV0ICBQUDJQICBQ ZWVycyAgDQo+KGllICBlbmR1c2VycykgIHdpbGwgIGJlICBhYmxlICB0byAgZ2V0ICBjaHVua3Mg IGZyb20gIHRoZSAgaW4tbmV0d29yayAgDQo+Q0ROICBub2RlcyAgKHVzaW5nICBQUDJQICBwcm90 b2NvbHMgIHdpdGggIHRoZSAgQ0ROICBub2RlcykgICAgX2FzICB3ZWxsICANCj5hc18gICAgYmUg IGFibGUgIHRvICBnZXQgIGNodW5rcyAgZnJvbSAgREVDQURFICBpbi1uZXR3b3JrICBDYWNoaW5n ICANCj5wb3B1bGF0ZWQgICh1c2luZyAgREVDQURFICBwcm90b2NvbHMpICBieSAgUFBTUCAgUGVl cnMgIChib3RoICBvZmYtbmV0ICANCj5lbmQtdXNlcnMgIGFuZCAgaW4tbmV0d29yayAgQ0ROICBO b2RlcykuDQo+DQo+KEZvciAgc2ltcGxpY2l0eSAgSSAgZGlzY3Vzc2VkICB0aGUgIHVzZSAgb2Yg IERFQ0FERSAgYW5kICBQUFNQICBQZWVyaW5nICANCj5pbiAgdGhlICBzYW1lICBzaW5nbGUgIG5l dHdvcmssICBidXQgIHRob3NlICBjb3VsZCAgaGFwcGVuICBpbiAgDQo+ZGlmZmVyZW50ICBuZXR3 b3JrcyAgYW5kICBzYW1lICB3b3VsZCAgYXBwbHkpLg0KPg0KPigqKSAgYSAgcGFydGljdWxhciAg Y2FzZSAgb2YgIHRoYXQgIGlzICB3aGVuICB0aGUgIENvbnRlbnQgIFB1Ymxpc2hlciAgDQo+YmVo YXZlcyAgYXMgIGEgIFBlZXIgIGFuZCAgdXNlcyAgREVDQURFICB0byAgcG9wdWxhdGUgIGluLW5l dHdvcmsgIA0KPmNvbnRlbnQgIGFzICBkaXNjdXNzZWQgIGluICBzZWN0aW9uICA1LjIgIG9mICBE RUNBREUgIHByb2JsZW0gIHN0YXRlbWVudC4NCj4NCg0KVGhhbmsgIHlvdSAgZm9yICBnb29kICBl eGFtcGxlczogICkgIA0KDQoNCj5JcyAgdGhpcyAgaG93ICB5b3UgIGFsc28gIHNlZSAgREVDQURF ICBhbmQgIFBQU1AgIHJlbGF0ZT8gIGNhbiAgdGhpcyAgYmUgIA0KPmV4cGxpY2l0bHkgIGRpc2N1 c3NlZD8NCj4NCg0KV2UgIGNhbiAgcmVnYXJkICBQUFNQICBhcyAgYSAgc3BlY2lmaWMgIHByb3Rv Y29sICBvZiAgYSAgc3RyZWFtaW5nICBhcHBsaWNhdGlvbiwgIHdoaWNoDQpjb3VsZCAgdXNlICBE RUNBREUgIGp1c3QgIGxpa2UgIG90aGVyICBwMnAgIGFwcGxpY2F0aW9ucy4NCg0KDQo+KiAgc2Vj dGlvbiAgNC4yOg0KPndvdWxkICBiZSAgd29ydGggIGNsYXJpZnlpbmcgIHdobyAgY29udHJvbHMg IHRoZSAgYXV0aG9yaXphdGlvbi4gIEF0ICANCj5sZWFzdCwgIG9uZSAgY2FzZSAgaXMgIHRoYXQg IGF1dGhvcml6YXRpb24gIGlzICBjb250cm9sbGVkICBieSAgdGhlICANCj5ERUNBREUgIHVzZXIg IHRoYXQgIHBsYWNlcyAgdGhlICBjb250ZW50ICBpbiAgdGhlICBjYWNoZS4NCj4NCg0KWWVzLiAg VGhlICB1c2VyICBjYW4gIGF1dGhvcml6ZSAgb3RoZXJzICB0byAgYWNjZXNzICAiaXRzIiAgaW4t bmV0d29yayAgc3RvcmFnZS4NCg0KPg0KPiogIEZpZ3VyZXMgIDIsICAzLCAgNCAgYW5kICA1Og0K PkkgIHN1Z2dlc3QgIHlvdSAgYWxzbyAgaWxsdXN0cmF0ZSAgdGhlICBhY3R1YWwgIHRyYW5zZmVy ICBvZiAgZGF0YSAgKGluICANCj5hZGRpdGlvbiAgdG8gIHRoZSAgREVDQURFICByZXF1ZXN0cyku ICBJdCAgaXMgIGRvbmUgIGluICBGaWcgIDUgIGJ1dCAgbm90ICANCj5pbiAgcHJldmlvdXMgIG9u ZXMuICBhbHNvICBJICB0aGluayAgaXQgIHdpbGwgIG1ha2UgIHNlcXVlbnRpYWxpdHkgIGNsZWFy ZXIuDQo+Rm9yICBleGFtcGxlICBpbiAgRmlnICAyLCAgdGhlICBkYXRhICB0cmFuc2ZlciAgZnJv bSAgU2IgIHRvICBCICB3b3VsZCAgbm90ICANCj5oYXBwZW4gIHJpZ2h0ICBhZnRlciAgc3RlcCAg MyAgKCIzICBJQVAgIGdldCIpOyAgaXQgIHdvdWxkICBoYXBwZW4gIGFmdGVyICANCj5hICBkYXRh ICB0cmFuc2ZlciAgZnJvbSAgU2EgIHRvICBTYiAgLCAgd2hpY2ggIHdvdWxkICBoYXBwZW4gIGFm dGVyICAiNCAgDQo+SUFQICBnZXQiICBmcm9tICBTYiAgdG8gIFNhLg0KPg0KDQpXZSAgd2lsbCAg YWRkICBsaW5lcyAgdG8gIGlsbHVzdHJhdGUgIHRoZSAgZGF0YSAgdHJhbnNmZXI6ICApDQoNCj4q ICBGaWd1cmUgIDQ6DQo+SXQgIG1heSAgYmUgIG1vcmUgIGludHVpdGl2ZSAgdG8gIHN3YXAgIHRo ZSAgb3JkZXIgIG9mICBzdGVwICAyICBhbmQgIDMgIChpZSAgDQo+c2hvdyAgQSAgc3RvcmluZyAg dGhlICBvYmplY3QgIGluICBTYiAgYmVmb3JlICBBICByZXNwb25kcyAgdG8gIEIpLg0KPg0KSXQn cyAgYSAgbGl0dGxlICB0cmlja3kgIGhlcmUgIGFuZCAgUDJQICBhcHBsaWNhdGlvbnMgIGNhbiAg dXNlICBkaWZmZXJlbnQgIHdheXMgIHRvICBkbw0KaXQuICBXaGVuICBBICBnZXRzICB0aGUgIHJl cXVlc3QgIHRvICBzdG9yZSAgb2JqZWN0ICB0byAgU2IsICBpdCAgY2FuICBzaW1wbHkgIHJlcGx5 ICB3aXRoDQoiT2theSIsICBhbmQgIHRoZW4gIGRvICB0aGUgIHN0b3JlICBvcGVyYXRpb24uICBB bHNvICBpdCAgY2FuICBzdGFydCAgdG8gIHN0b3JlICB0aGUNCm9iamVjdCAgdG8gIFNiICBhbmQg IHRoZW4gIHJlcGx5ICB0byAgQiAgd2l0aCAgYSAgbWVzc2FnZSAgIiAgSSAgaGF2ZSAgc3RhcnRl ZCAgdG8NCnRyYW5zZmVyLi4uIi4gICAgDQoNCg0KVGhhbmtzLA0KSGFpYmluDQoNCg0KPg0KPkhv cGUgIHRoYXQgIGhlbHBzLg0KPg0KPkZyYW5jb2lzDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5kZWNhZGUgIG1haWxpbmcgIGxpc3QNCj5kZWNh ZGVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RlY2Fk ZQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZGVjYWRlICBtYWlsaW5nICBsaXN0DQpkZWNhZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlDQo= --=====003_Dragon078352785458_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OsvOzOU7DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpq dXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpWZXJkYW5hOw0KCWNvbG9yOndpbmRv d3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQt ZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCiBAcGFnZSBT ZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0Ow0KCWxheW91dC1ncmlkOjE1LjZwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQotLT4NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOyZu YnNwOyZuYnNwOyBJdCBzZWVtcyBncmVhdCANCnRoYXQgRnJhbmNvaXMmbmJzcDtoYXMgZ2l2ZW4m bmJzcDt1cyBhIGNsZWFyZXIgcGljdHVyZSBvbiB0aGUgdXNhZ2Ugb2YgUFBTUCBhbmQgDQpERUNB REUuVGhhbmtzIGEgbG90LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBJIHdvdWxkIGxpa2UgDQp0byZu YnNwO2NsYXJpZnkgdGhhdCBhbHRob3VnaCBib3RoIFBQU1AgYW5kIERFQ0FERSBoYXZlIGFuIGVk Z2UgY2FjaGVzIHVzYWdlcywgDQp0aGV5IGhhdmUgc2V2ZXJhbCBub3RpY2VhYmxlIGRpZmZlcmVu Y2VzOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCjEpTW90aXZhdGlvbjo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQUFNQLCAN Cm9wZXJhdG9yL0lTUCBvciBvdGhlciB2ZW5kb3JzIHRvIGxhdW5jaCBwMnAgc3RyZWFtaW5nIHNl cnZpY2U7IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAw ZmYgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IERFQ0FERSwgDQpvcGVyYXRvci9JU1AgdG8gZGVjcmVhc2UgdHJhZmZp YyBwcmVzc3VyZS5UaGUgc2VydmljZSBpcyBub3QgcnVuIGJ5IA0Kb3BlcnRvci9JU1AuPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDBmZiBzaXplPTI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDIpVGFzazogDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQUFNQLHVuaWZ5aW5nIA0KcGVlci90cmFja2Vy IHByb3RvY29scyBib3RoIGZvciBDRE4gYW5kIGNvbW1vbiBwZWVycy4gPC9GT05UPjxGT05UIGZh Y2U9VmVyZGFuYSANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkNETiBhcyA8Rk9OVCBjb2xvcj0jZmYw MDAwPnN1cGVycGVlcnMgPC9GT05UPmVxdWlwcGluZyBQUFNQIA0KcHJvdG9jb2xzLlBQU1AgcHJv dG9jb2xzIGFyZSZuYnNwOyZuYnNwOyBwMnAgcHJvdG9jb2xzLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7REVDQURFLGNyZWF0 aW5nIA0KcGVlci9ub24tcGVlciBjbGllbnQgdG8gQ0ROIGFjY2VzcyBwcm90b2NvbCwgd2hpY2gg aXMgbm90IGEgUDJQIHByb3RvY29sIGl0c2VsZi4gDQpQZWVyL2NsaWVudCBuZWVkcyB0byB1cGRh dGUgdG8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VwcG9ydCANCkRFQ0FE RSBwcm90b2NvbC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0j MDAwMGZmIHNpemU9Mj4mbmJzcDsmbmJzcDsgMylTY29wZTogUFBTUCwgcDJwIA0Kc3RyZWFtaW5n IHNlbmFyaW9zOyBERUNBREUsIHAycCBkYXRhLWludGVuc2l2ZSBzZW5hcmlvczs8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOzQpUHVycG9zZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBQUFNQOmVmZmljaWVudCBpbmZvcm1hdGlvbiANCmV4Y2hhbmdlIGJldHdl ZW4gcGVlcnM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAw MGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBE RUNBREU6cGVlci9jbGllbnQgYW5kIGNhY2hlIA0KY29tbWFuZCB0byBhc2sgY2FjaGVzIHRvJm5i c3A7cGVyZm9ybSBjb3JyZXNwb25kaW5nIGFjdGlvbnM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgSW4g YSB3b3JkLCBQUFNQIA0KYW5kIERFQ0FERSBtYXkgb2NjdXIgaW4gdGhlIHNhbWUgc2VuYXJpbyxw MnAgc3RyZWFtaW5nIHdoaWxlIHRoZWlyIA0KZnVuY3Rpb25hbGl0aWVzIGFyZSBxdWl0ZSBkaWZm ZXJlbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDBm ZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s b3I9IzAwMDBmZiBzaXplPTI+QlI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBjb2xvcj0jMDAwMGZmIHNpemU9Mj5ZdW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0Pg0K PERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8SFIgc3R5bGU9IldJ RFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIFNJWkU9Mj4NCjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9I2MwYzBjMD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPnpoYW5neXVuZmVpPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjIwMDktMTEtMjM8L0ZP TlQ+PC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0K PEhSPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0y PjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gU29uZyANCkhhaWJpbjwvRk9OVD48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG8 5KO6PC9TVFJPTkc+IA0KMjAwOS0xMS0yMyZuYnNwOzExOjE5OjMyPC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6 PC9TVFJPTkc+ICdGcmFuY29pcyBMZSANCkZhdWNoZXVyJzsgZGVjYWRlQGlldGYub3JnPC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RS T05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IFJlOiBbZGVjYWRl XSBDb21tZW50cyANCm9uIGRyYWZ0LXNvbmctZGVjYWRlLXByb2JsZW0tc3RhdGVtZW50PC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkhpICZuYnNw O0ZyYW5jb2lzLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+R29vZCAmbmJzcDtjb21t ZW50cy4gJm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZndDstLS0tLU9yaWdpbmFsICZuYnNwO01lc3NhZ2UtLS0tLTwvRElWPg0K PERJVj4mZ3Q7RnJvbTogJm5ic3A7ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgDQombmJzcDtbbWFp bHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O09uICZu YnNwO0JlaGFsZiAmbmJzcDtPZiAmbmJzcDtGcmFuY29pcyAmbmJzcDtMZSAmbmJzcDtGYXVjaGV1 cjwvRElWPg0KPERJVj4mZ3Q7U2VudDogJm5ic3A7RnJpZGF5LCAmbmJzcDtOb3ZlbWJlciAmbmJz cDsyMCwgJm5ic3A7MjAwOSAmbmJzcDsxMDoyOCANCiZuYnNwO1BNPC9ESVY+DQo8RElWPiZndDtU bzogJm5ic3A7ZGVjYWRlQGlldGYub3JnPC9ESVY+DQo8RElWPiZndDtTdWJqZWN0OiAmbmJzcDtb ZGVjYWRlXSAmbmJzcDtDb21tZW50cyAmbmJzcDtvbiANCiZuYnNwO2RyYWZ0LXNvbmctZGVjYWRl LXByb2JsZW0tc3RhdGVtZW50PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0O0hlbGxv LDwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtIZXJlICZuYnNwO2FyZSAmbmJzcDtz b21lICZuYnNwO2NvbW1lbnRzL3N1Z2dlc3Rpb25zICZuYnNwO3JlIA0KJm5ic3A7ZGVjYWRlLXBy b2JsZW0tc3RhdGVtZW50OjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsqICZuYnNw O3NlY3Rpb24gJm5ic3A7My4xOjwvRElWPg0KPERJVj4mZ3Q7IlJlY2VudGx5LCAmbmJzcDt0aGUg Jm5ic3A7SUVURiAmbmJzcDtBcHBsaWNhdGlvbiAmbmJzcDtMYXllciANCiZuYnNwO1RyYWZmaWMg Jm5ic3A7T3B0aW1pemF0aW9uICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7KEFMVE8pICZuYnNwO1dv cmtpbmcgJm5ic3A7R3JvdXAgJm5ic3A7aXMgJm5ic3A7Zm9ybWVkICZuYnNwO3RvIA0KJm5ic3A7 cHJvdmlkZSAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb25zICZuYnNwOzwvRElWPg0KPERJVj4m Z3Q7d2l0aCAmbmJzcDtuZXR3b3JrICZuYnNwO2luZm9ybWF0aW9uICZuYnNwO3NvICZuYnNwO3Ro YXQgJm5ic3A7dGhleSANCiZuYnNwO2NhbiAmbmJzcDtwZXJmb3JtICZuYnNwOzwvRElWPg0KPERJ Vj4mZ3Q7YmV0dGVyLXRoYW4tcmFuZG9tICZuYnNwO2luaXRpYWwgJm5ic3A7cGVlciAmbmJzcDtz ZWxlY3Rpb24gDQombmJzcDs8L0RJVj4NCjxESVY+Jmd0O1tJLUQuaWV0Zi1hbHRvLXByb2JsZW0t c3RhdGVtZW50XS4gJm5ic3A7IjwvRElWPg0KPERJVj4mZ3Q7SSAmbmJzcDtiZWxpZXZlICZuYnNw O0FMVE8gJm5ic3A7Y2FuICZuYnNwO2JlICZuYnNwO3VzZWQgJm5ic3A7Zm9yIA0KJm5ic3A7cGVl ciAmbmJzcDtzZWxlY3Rpb24gJm5ic3A7YXQgJm5ic3A7YW55ICZuYnNwO3RpbWUgJm5ic3A7KGll ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7bm90ICZuYnNwO2p1c3QgJm5ic3A7aW5pdGlhbGx5KS48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkl0ICZuYnNwO2lzICZuYnNwO2luICZuYnNw O3BhcmFncmFwaCAmbmJzcDs0ICZuYnNwO29mICZuYnNwOyJEZXNjcmlwdGlvbiANCiZuYnNwO29m ICZuYnNwO1dvcmtpbmcgJm5ic3A7R3JvdXAiICZuYnNwO2luICZuYnNwO0FMVE8gJm5ic3A7V0cg DQombmJzcDtjaGFydGVyLjwvRElWPg0KPERJVj5Zb3UgJm5ic3A7YXJlICZuYnNwO3JpZ2h0ICZu YnNwO3RoYXQgJm5ic3A7UDJQICZuYnNwO2FwcGxpY2F0aW9ucyAmbmJzcDtjYW4gDQombmJzcDtk byAmbmJzcDt0aGUgJm5ic3A7cGVlciAmbmJzcDtzZWxlY3Rpb24gJm5ic3A7d2l0aCAmbmJzcDt0 aGUgDQombmJzcDtoZWxwPC9ESVY+DQo8RElWPm9mICZuYnNwO0FMVE8gJm5ic3A7c2VydmVyICZu YnNwO2F0ICZuYnNwO2FueSAmbmJzcDt0aW1lLiAmbmJzcDtCdXQgJm5ic3A7IA0KJm5ic3A7SSAm bmJzcDt0aGluayAmbmJzcDtoZXJlICZuYnNwOyJpbml0aWFsICZuYnNwO3BlZXIgJm5ic3A7c2Vs ZWN0aW9uIiANCiZuYnNwO21lYW5zPC9ESVY+DQo8RElWPml0ICZuYnNwOyhBTFRPKSAmbmJzcDtp cyAmbmJzcDt0aGUgJm5ic3A7Zmlyc3QgJm5ic3A7c3RlcCAmbmJzcDtmb3IgDQombmJzcDtwZWVy ICZuYnNwO3NlbGVjdGlvbiwgJm5ic3A7YW5kICZuYnNwO2FmdGVyICZuYnNwO3RoYXQgJm5ic3A7 UDJQPC9ESVY+DQo8RElWPmFwcGxpY2F0aW9uICZuYnNwO3VzZXJzICZuYnNwO2NhbiAmbmJzcDtk byAmbmJzcDthbm90aGVyICZuYnNwO3JvdW5kIA0KJm5ic3A7b2YgJm5ic3A7cGVlciAmbmJzcDtz ZWxlY3Rpb24gJm5ic3A7YmFzZWQgJm5ic3A7b24gJm5ic3A7b3RoZXI8L0RJVj4NCjxESVY+dGhp bmdzLCAmbmJzcDtzdWNoICZuYnNwO2xpa2UgJm5ic3A7Y2h1bmsgJm5ic3A7YXZhaWxhYmlsaXR5 KGUuZy4gDQombmJzcDsicmFyZXN0ICZuYnNwO3BpZWNlICZuYnNwO2ZpcnN0IikgJm5ic3A7YW5k ICZuYnNwO3BlciAmbmJzcDtwYWlyPC9ESVY+DQo8RElWPmNvbm5lY3Rpb24gJm5ic3A7cXVhbGl0 eS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtUaGUgJm5ic3A7aW5mb3JtYXRp b24gJm5ic3A7cHJvdmlkZWQgJm5ic3A7YnkgJm5ic3A7QUxUTyAmbmJzcDtpcyANCiZuYnNwO25v dCAmbmJzcDtuZWNlc3NhcmlseSAmbmJzcDsibmV0d29yayAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0 O2luZm9ybWF0aW9uIiAmbmJzcDsoZS5nLiAmbmJzcDtjb3VsZCAmbmJzcDtiZSAmbmJzcDtqdXN0 ICZuYnNwO2EgDQombmJzcDtsaXN0ICZuYnNwO29mICZuYnNwO3NlbGVjdGVkICZuYnNwO3BlZXJz KS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoZSAmbmJzcDtwZWVyICZuYnNwO3Nl bGVjdGlvbiAmbmJzcDtpcyAmbmJzcDttYWlubHkgJm5ic3A7YmFzZWQgJm5ic3A7b24gDQombmJz cDtuZXR3b3JrICZuYnNwO2Nvc3QgJm5ic3A7aW5mb3JtYXRpb24uICZuYnNwO0J1dCAmbmJzcDt5 b3UgJm5ic3A7YXJlPC9ESVY+DQo8RElWPnJpZ2h0LCAmbmJzcDt3ZSAmbmJzcDtzaG91bGQgJm5i c3A7ZGVsZXRlICZuYnNwO3RoZSAmbmJzcDt3b3JkIA0KJm5ic3A7Im5ldHdvcmsiICZuYnNwO2hl cmUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7QWxzbywgJm5ic3A7c29tZSAm bmJzcDtQMlAgJm5ic3A7QXBwcyAmbmJzcDt1c2UgJm5ic3A7b3RoZXIgDQombmJzcDtjcml0ZXJp YSAmbmJzcDt0aGFuICZuYnNwO3B1cmUgJm5ic3A7cmFuZG9tLCAmbmJzcDtidXQgJm5ic3A7PC9E SVY+DQo8RElWPiZndDtzdGlsbCAmbmJzcDtub3QgJm5ic3A7bmVjZXNzYXJpbHkgJm5ic3A7b3B0 aW1hbC48L0RJVj4NCjxESVY+Jmd0O1NvICZuYnNwO2hvdyAmbmJzcDthYm91dCwgJm5ic3A7c29t ZXRoaW5nICZuYnNwO2xpa2U6PC9ESVY+DQo8RElWPiZndDsiVGhlICZuYnNwO0lFVEYgJm5ic3A7 QXBwbGljYXRpb24gJm5ic3A7TGF5ZXIgJm5ic3A7VHJhZmZpYyANCiZuYnNwO09wdGltaXphdGlv biAmbmJzcDsoQUxUTykgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtXb3JraW5nICZuYnNwO0dyb3Vw ICZuYnNwO3NwZWNpZmllcyAmbmJzcDttZWNoYW5pc21zICZuYnNwO3RoYXQgDQombmJzcDthbGxv dyAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb25zICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7dG8g Jm5ic3A7cGVyZm9ybSAmbmJzcDtzZWxlY3Rpb24gJm5ic3A7b2YgJm5ic3A7cGVlcnMgJm5ic3A7 dGhhdCANCiZuYnNwO2lzICZuYnNwO3N1cGVyaW9yICZuYnNwO3RvICZuYnNwO3JhbmRvbSAmbmJz cDs8L0RJVj4NCjxESVY+Jmd0O3NlbGVjdGlvbiAmbmJzcDtvciAmbmJzcDtzZWxlY3Rpb24gJm5i c3A7YmFzZWQgJm5ic3A7b24gDQombmJzcDtpbmZvcm1hdGlvbiAmbmJzcDtkZWR1Y3RlZCAmbmJz cDtmcm9tICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7cGFydGlhbCAmbmJzcDtvYnNlcnZhdGlvbiAm bmJzcDtbSS1ELmlldGYtYWx0by1wcm9ibGVtLXN0YXRlbWVudF0uIA0KJm5ic3A7IjwvRElWPg0K PERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JdCdzICZuYnNwO29rYXku ICZuYnNwO0kgJm5ic3A7cHJlZmVyICZuYnNwO3RvICZuYnNwO2p1c3QgJm5ic3A7ZGVsZXRlIA0K Jm5ic3A7dGhlICZuYnNwO3dvcmQgJm5ic3A7Im5ldHdvcmsiLCAmbmJzcDtqdXN0ICZuYnNwO2xp a2UgJm5ic3A7d2hhdCANCiZuYnNwO2lzPC9ESVY+DQo8RElWPnNhaWQgJm5ic3A7aW4gJm5ic3A7 dGhlICZuYnNwO0FMVE8gJm5ic3A7Y2hhcnRlci48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyogJm5ic3A7c2VjdGlvbiAmbmJzcDszLjE6PC9ESVY+ DQo8RElWPiZndDsiT24gJm5ic3A7dGhlICZuYnNwO290aGVyICZuYnNwO2hhbmQsICZuYnNwO2l0 ICZuYnNwO2lzICZuYnNwO3JlcG9ydGVkIA0KJm5ic3A7dGhhdCAmbmJzcDtQMlAgJm5ic3A7dHJh ZmZpYyAmbmJzcDtpcyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2JlY29taW5nICZuYnNwO3RoZSAm bmJzcDtkb21pbmF0aW5nICZuYnNwO3RyYWZmaWMgJm5ic3A7b24gJm5ic3A7dGhlIA0KJm5ic3A7 YWNjZXNzICZuYnNwO25ldHdvcmtzICZuYnNwO29mICZuYnNwO3NvbWUgJm5ic3A7PC9ESVY+DQo8 RElWPiZndDtuZXR3b3JrcywgJm5ic3A7cmVhY2hpbmcgJm5ic3A7YXMgJm5ic3A7aGlnaCAmbmJz cDthcyAmbmJzcDs1MC02MCUgDQombmJzcDthdCAmbmJzcDt0aGUgJm5ic3A7ZG93bi1saW5rcyAm bmJzcDthbmQgJm5ic3A7PC9ESVY+DQo8RElWPiZndDs2MC05MCUgJm5ic3A7YXQgJm5ic3A7dGhl ICZuYnNwO3VwbGlua3MgJm5ic3A7KFtEQ0lBXSwgJm5ic3A7W0lDTlBdLCANCiZuYnNwO1tpcG9x dWUuUDJQX3N1cnZleS5dLCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O1tQMlBfZmlsZV9zaGFyaW5n XSkuICZuYnNwOyAmbmJzcDtDb25zZXF1ZW50bHksICZuYnNwO2l0ICZuYnNwO2JlY29tZXMgDQom bmJzcDtpbmNyZWFzaW5nbHkgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtpbXBvcnRhbnQgJm5ic3A7 dG8gJm5ic3A7Y29tcGxlbWVudCAmbmJzcDt0aGUgJm5ic3A7QUxUTyAmbmJzcDtlZmZvcnQgDQom bmJzcDthbmQgJm5ic3A7cmVkdWNlICZuYnNwO3VwbG9hZCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0 O2FjY2VzcyAmbmJzcDt0cmFmZmljLCAmbmJzcDtpbiAmbmJzcDthZGRpdGlvbiAmbmJzcDt0byAN CiZuYnNwO2Nyb3NzLWRvbWFpbiAmbmJzcDthbmQgJm5ic3A7YmFja2JvbmUgJm5ic3A7dHJhZmZp Yy48L0RJVj4NCjxESVY+Jmd0OyI8L0RJVj4NCjxESVY+Jmd0O0kgJm5ic3A7dGhpbmsgJm5ic3A7 aXQgJm5ic3A7d291bGQgJm5ic3A7YmUgJm5ic3A7d29ydGggDQombmJzcDtkaXNjdXNzaW5nICZu YnNwO2hvdyAmbmJzcDtMRURCQVQgJm5ic3A7cmVsYXRlcyAmbmJzcDt0byAmbmJzcDt0aGUgDQom bmJzcDthYm92ZS48L0RJVj4NCjxESVY+Jmd0O1BlcmhhcHMgJm5ic3A7YWRkaW5nICZuYnNwO3Nv bWV0aGluZyAmbmJzcDthbG9uZyAmbmJzcDt0aGUgJm5ic3A7bGluZXMgDQombmJzcDtvZjo8L0RJ Vj4NCjxESVY+Jmd0OyIgJm5ic3A7VGhlICZuYnNwO0lFVEYgJm5ic3A7TG93ICZuYnNwO0V4dHJh ICZuYnNwO0RlbGF5IA0KJm5ic3A7QmFja2dyb3VuZCAmbmJzcDtUcmFuc3BvcnQgJm5ic3A7KExF REJBVCkgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtXb3JraW5nICZuYnNwO0dyb3VwICZuYnNwO2lz ICZuYnNwO2ZvY3VzaW5nICZuYnNwO29uICZuYnNwO2Jyb2FkbHkgDQombmJzcDthcHBsaWNhYmxl ICZuYnNwO3RlY2huaXF1ZXMgJm5ic3A7PC9ESVY+DQo8RElWPiZndDt0aGF0ICZuYnNwO2FsbG93 ICZuYnNwO2xhcmdlICZuYnNwO2Ftb3VudHMgJm5ic3A7b2YgJm5ic3A7ZGF0YSAmbmJzcDt0byAN CiZuYnNwO2JlICZuYnNwO2NvbnNpc3RlbnRseSAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3RyYW5z bWl0dGVkICZuYnNwO3dpdGhvdXQgJm5ic3A7c3Vic3RhbnRpYWxseSAmbmJzcDthZmZlY3Rpbmcg Jm5ic3A7dGhlIA0KJm5ic3A7ZGVsYXlzICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ZXhwZXJpZW5j ZWQgJm5ic3A7YnkgJm5ic3A7b3RoZXIgJm5ic3A7dXNlcnMgJm5ic3A7YW5kIA0KJm5ic3A7YXBw bGljYXRpb25zLiAmbmJzcDtJdCAmbmJzcDtpcyAmbmJzcDtleHBlY3RlZCAmbmJzcDs8L0RJVj4N CjxESVY+Jmd0O3RoYXQgJm5ic3A7c29tZSAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb25zICZu YnNwO3dvdWxkICZuYnNwO3N0YXJ0IA0KJm5ic3A7dXNpbmcgJm5ic3A7c3VjaCAmbmJzcDt0ZWNo bmlxdWVzLCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3RoZXJlYnkgJm5ic3A7c29tZXdoYXQgJm5i c3A7YWxsZXZpYXRpbmcgJm5ic3A7dGhlICZuYnNwO3BlcmNlaXZhYmxlIA0KJm5ic3A7aW1wYWN0 ICZuYnNwOyhhdCAmbmJzcDtsZWFzdCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O29uICZuYnNwO290 aGVyICZuYnNwO2FwcGxpY2F0aW9ucykgJm5ic3A7b2YgJm5ic3A7dGhlaXIgJm5ic3A7aGlnaCAN CiZuYnNwO3ZvbHVtZSAmbmJzcDt0cmFmZmljICZuYnNwOy4gJm5ic3A7SG93ZXZlciwgJm5ic3A7 PC9ESVY+DQo8RElWPiZndDtzdWNoICZuYnNwO3RlY2huaXF1ZXMgJm5ic3A7ZG8gJm5ic3A7bm90 ICZuYnNwO3JlbW92ZSAmbmJzcDthbGwgDQombmJzcDtpbmVmZmljaWVuY2llcywgJm5ic3A7c3Vj aCAmbmJzcDthcyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3Rob3NlICZuYnNwO2Fzc29jaWF0ZWQg Jm5ic3A7d2l0aCAmbmJzcDt0cmFmZmljICZuYnNwO2JlaW5nICZuYnNwO3NlbnQgDQombmJzcDt1 cHN0cmVhbSAmbmJzcDthcyAmbmJzcDttYW55ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7dGltZXMg Jm5ic3A7YXMgJm5ic3A7dGhlcmUgJm5ic3A7YXJlICZuYnNwO3JlbW90ZSAmbmJzcDtwZWVycyAN CiZuYnNwO2ludGVyZXN0ZWQgJm5ic3A7aW4gJm5ic3A7Z2V0dGluZyAmbmJzcDt0aGUgJm5ic3A7 PC9ESVY+DQo8RElWPiZndDtjb3JyZXNwb25kaW5nICZuYnNwO2luZm9ybWF0aW9uLiI8L0RJVj4N CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSAmbmJzcDthZ3JlZSAm bmJzcDt3aXRoICZuYnNwO3doYXQgJm5ic3A7eW91ICZuYnNwO3NhaWQgJm5ic3A7aGVyZS4gDQom bmJzcDtCdXQgJm5ic3A7TEVEQkFUICZuYnNwO2lzICZuYnNwO25vdCAmbmJzcDtzbyAmbmJzcDty ZWxldmFudCAmbmJzcDt0byANCiZuYnNwO0RFQ0FERSAmbmJzcDthczwvRElWPg0KPERJVj5BTFRP LiAmbmJzcDtBTFRPICZuYnNwO2NhbiAmbmJzcDtyZWR1Y2UgJm5ic3A7dGhlICZuYnNwO2JhY2ti b25lIA0KJm5ic3A7dHJhZmZpYyAmbmJzcDtvZiAmbmJzcDtJU1AncyAmbmJzcDtuZXR3b3JrICZu YnNwO2J5ICZuYnNwO2RvIA0KJm5ic3A7YmV0dGVyPC9ESVY+DQo8RElWPnBlZXIgJm5ic3A7c2Vs ZWN0aW9uLCAmbmJzcDt3aGlsZSAmbmJzcDtERUNBREUgJm5ic3A7Y2FuICZuYnNwO3NhdmUgDQom bmJzcDttdWNoICZuYnNwO29mICZuYnNwO3lvdXIgJm5ic3A7dXBsaW5rICZuYnNwO2JhbmR3aWR0 aCAmbmJzcDtieTwvRElWPg0KPERJVj5wdXR0aW5nICZuYnNwO3lvdXIgJm5ic3A7Y29udGVudHMg Jm5ic3A7aW50byAmbmJzcDtuZXR3b3JrICZuYnNwO2FuZCANCiZuYnNwO2FsbG93aW5nICZuYnNw O290aGVycyAmbmJzcDt0byAmbmJzcDtkb3dubG9hZCAmbmJzcDtmcm9tPC9ESVY+DQo8RElWPnRo ZXJlICZuYnNwOyhuZWVkICZuYnNwO3N0YW5kYXJkICZuYnNwO3Jlc291cmNlICZuYnNwO2NvbnRy b2wpLiAmbmJzcDtCeSANCiZuYnNwO3B1dHRpbmcgJm5ic3A7dGhlICZuYnNwO2NvbnRlbnRzICZu YnNwO2ludG88L0RJVj4NCjxESVY+bmV0d29yaywgJm5ic3A7UDJQICZuYnNwO2FwcGxpY2F0aW9u cyAmbmJzcDtjYW4gJm5ic3A7YWxzbyAmbmJzcDtpbXByb3ZlIA0KJm5ic3A7dGhlICZuYnNwO2F2 YWlsYWJpbGl0eSAmbmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7Y29udGVudC48L0RJVj4NCjxESVY+ TEVEQkFUICZuYnNwO2ZvY3VzZXMgJm5ic3A7b24gJm5ic3A7dGhlICZuYnNwO3RlY2huaXF1ZXMg Jm5ic3A7dGhhdCANCiZuYnNwO3dpbGwgJm5ic3A7YWxsZXZpYXRlICZuYnNwO3RoZSAmbmJzcDtp bXBhY3QgJm5ic3A7YW1vbmc8L0RJVj4NCjxESVY+dHJhbnNwb3J0ICZuYnNwO2ZvciAmbmJzcDtk aWZmZXJlbnQgJm5ic3A7YXBwbGljYXRpb25zLiAmbmJzcDtJdCAmbmJzcDtpcyANCiZuYnNwO2Eg Jm5ic3A7bGl0dGxlICZuYnNwO2RpZmZlcmVudC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyogJm5ic3A7c2VjdGlvbiAmbmJzcDszLjE6PC9ESVY+ DQo8RElWPiZndDtUaGUgJm5ic3A7Y3VycmVudCAmbmJzcDt0ZXh0ICZuYnNwO2Rpc2N1c3NlcyAm bmJzcDtpbmVmZmljaWVuY2llcyANCiZuYnNwO2luICZuYnNwO3Rlcm1zICZuYnNwO29mICZuYnNw O2FjY2VzcyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O25ldHdvcmsgJm5ic3A7YmFuZHdpZHRoICZu YnNwO2JlaW5nICZuYnNwO2VmZmVjdGl2ZWx5ICZuYnNwO3dhc3RlZCANCiZuYnNwO2Zyb20gJm5i c3A7dGhlICZuYnNwO3ZpZXdwb2ludCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O29mICZuYnNwO3Ro ZSAmbmJzcDtuZXR3b3JrICZuYnNwO29wZXJhdG9yLiAmbmJzcDtQZXJoYXBzICZuYnNwO2l0IA0K Jm5ic3A7d291bGQgJm5ic3A7YWxzbyAmbmJzcDtiZSAmbmJzcDt3b3J0aCAmbmJzcDttYWtpbmcg Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtleHBsaWNpdCAmbmJzcDt0aGUgJm5ic3A7Y29uc2VxdWVu Y2VzICZuYnNwO2Zyb20gJm5ic3A7dGhlICZuYnNwO1AyUCANCiZuYnNwO2FwcGxpY2F0aW9ucyAm bmJzcDt2aWV3cG9pbnQgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtpLmUuICZuYnNwO2xpa2VseSAm bmJzcDtsb25nZXIgJm5ic3A7dGltZSAmbmJzcDt0byAmbmJzcDtyZXRyaWV2ZSANCiZuYnNwO2Nv bXBsZXRlICZuYnNwO2NvbnRlbnQgJm5ic3A7YXMgJm5ic3A7d2VsbCAmbmJzcDs8L0RJVj4NCjxE SVY+Jmd0O2FzICZuYnNwO2xpa2VseSAmbmJzcDtoaWdoZXIgJm5ic3A7bGF0ZW5jeSAmbmJzcDtm b3IgJm5ic3A7c29tZSANCiZuYnNwO3JlYWwgJm5ic3A7dGltZSAmbmJzcDthcHBsaWNhdGlvbnMg Jm5ic3A7KGUuZy4gJm5ic3A7UFBTUCkuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPkdvb2QgJm5ic3A7cG9pbnQuICZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyogJm5ic3A7c2VjdGlvbiAmbmJzcDs0OjwvRElWPg0KPERJVj4m Z3Q7Ik5vdGUgJm5ic3A7dGhhdCAmbmJzcDtERUNBREUgJm5ic3A7aXMgJm5ic3A7aW5kZXBlbmRl bnQgJm5ic3A7b2YgDQombmJzcDtjdXJyZW50ICZuYnNwO0lFVEYgJm5ic3A7d29yayAmbmJzcDtv biAmbmJzcDtQMlAsICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ZS5nLiAmbmJzcDtQMlBTSVAsICZu YnNwO0FMVE8sICZuYnNwO1BQU1AuICZuYnNwOyAmbmJzcDtGb3IgDQombmJzcDtleGFtcGxlLCAm bmJzcDtwZWVycyAmbmJzcDtkaXNjb3ZlcmVkICZuYnNwO2J5ICZuYnNwOzwvRElWPg0KPERJVj4m Z3Q7ZWl0aGVyICZuYnNwO1JFTE9BRCAmbmJzcDtvciAmbmJzcDtBTFRPICZuYnNwO2NhbiAmbmJz cDthbGwgJm5ic3A7dXNlIA0KJm5ic3A7REVDQURFICZuYnNwO3RvICZuYnNwO3NoYXJlICZuYnNw O2RhdGEuICZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O0RFQ0FERSAmbmJzcDt3aWxsICZu YnNwO2ZvY3VzICZuYnNwO29uICZuYnNwO3RoZSAmbmJzcDsgJm5ic3A7cHJvYmxlbXMgDQombmJz cDtvZiAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb25zLCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0 O2FsdGhvdWdoICZuYnNwO3RoZSAmbmJzcDtzb2x1dGlvbiAmbmJzcDttaWdodCAmbmJzcDtiZSAm bmJzcDt1c2VkIA0KJm5ic3A7aW4gJm5ic3A7b3RoZXIgJm5ic3A7Y29udGV4dC4iPC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0O1RoZSAmbmJzcDtyZWxhdGlvbnNoaXAgJm5ic3A7YmV0 d2VlbiAmbmJzcDtERUNBREUgJm5ic3A7YW5kICZuYnNwO1BQU1AgDQombmJzcDtkZXNlcnZlcyAm bmJzcDs8L0RJVj4NCjxESVY+Jmd0O2NsYXJpZmljYXRpb24uICZuYnNwO0luICZuYnNwO3BhcnRp Y3VsYXIsICZuYnNwO2JlY2F1c2UgJm5ic3A7dGhlIA0KJm5ic3A7UFAyUCAmbmJzcDtwcm9ibGVt ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7c3RhdGVtZW50ICZuYnNwO2RvY3VtZW50IA0KJm5ic3A7 KGRyYWZ0LXpoYW5nLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDUpOjwvRElWPg0KPERJVj4mZ3Q7 ICogJm5ic3A7aW4gJm5ic3A7aXRzICZuYnNwO3NlY3Rpb24gJm5ic3A7NC4yICZuYnNwOzogJm5i c3A7ZGVzY3JpYmVzIA0KJm5ic3A7RWRnZSAmbmJzcDtDYWNoZXMgJm5ic3A7YXMgJm5ic3A7b25l ICZuYnNwO29mICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7dGhlICZuYnNwO21vdGl2YXRpb25zICZu YnNwO2ZvciAmbmJzcDtkZXZlbG9waW5nICZuYnNwO1BQU1AgDQombmJzcDtzdGFuZGFyZHMgJm5i c3A7cHJvdG9jb2xzPC9ESVY+DQo8RElWPiZndDsgKiAmbmJzcDtpbiAmbmJzcDtpdHMgJm5ic3A7 c2VjdGlvbiAmbmJzcDs3LjEgJm5ic3A7OiAmbmJzcDtkZXNjcmliZXMgDQombmJzcDthICZuYnNw O1BQU1AgJm5ic3A7dXNlICZuYnNwO2Nhc2UgJm5ic3A7d2l0aCAmbmJzcDs8L0RJVj4NCjxESVY+ Jmd0O2luLW5ldHdvcmsgJm5ic3A7Q0ROICZuYnNwO25vZGVzICZuYnNwO2ZvciAmbmJzcDtlbmhh bmNlZCAmbmJzcDtQMlAgDQombmJzcDtzdHJlYW1pbmcuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkRFQ0FERSAmbmJzcDtpcyAmbmJzcDtxdWl0ZSAmbmJz cDtkaWZmZXJlbnQgJm5ic3A7ZnJvbSAmbmJzcDtQUFNQIA0KJm5ic3A7d2hpbGUgJm5ic3A7dGhl biAmbmJzcDtjYW4gJm5ic3A7Y29sbGFib3JhdGUgJm5ic3A7aW4gJm5ic3A7YSANCiZuYnNwO3N5 c3RlbS48L0RJVj4NCjxESVY+UDJQICZuYnNwO3N0cmVhbWluZyAmbmJzcDthcHBsaWNhdGlvbnMg Jm5ic3A7KGUuZy4gJm5ic3A7dGhvc2UgJm5ic3A7d2hvIA0KJm5ic3A7dXNlICZuYnNwO1BQU1Ag Jm5ic3A7cHJvdG9jb2wpICZuYnNwO2NhbiAmbmJzcDt1c2UgJm5ic3A7REVDQURFPC9ESVY+DQo8 RElWPnRvICZuYnNwO2Rpc3RyaWJ1dGUgJm5ic3A7dGhlaXIgJm5ic3A7c2VydmljZXMuICZuYnNw O0RFQ0FERSAmbmJzcDtpcyANCiZuYnNwO21vcmUgJm5ic3A7Z2VuZXJpYywgJm5ic3A7YW5kICZu YnNwO2ZvY3VlcyAmbmJzcDtvbiAmbmJzcDt0aGU8L0RJVj4NCjxESVY+c3RhbmRhcmQgJm5ic3A7 aW50ZXJmYWNlICZuYnNwO2JldHdlZW4gJm5ic3A7UDJQICZuYnNwO2NsaWVudCAmbmJzcDthbmQg DQombmJzcDt0aGUgJm5ic3A7aW4tbmV0d29yayAmbmJzcDtzdG9yYWdlKGVzcC48L0RJVj4NCjxE SVY+cmVzb3VyY2UgJm5ic3A7Y29udHJvbCkuICZuYnNwO1RoZSAmbmJzcDtwdXJwb3NlICZuYnNw O29mICZuYnNwO2V4aXN0aW5nIA0KJm5ic3A7UDJQICZuYnNwO2NhY2hlcyAmbmJzcDthcmUgJm5i c3A7Z29vZCAmbmJzcDthbmQgJm5ic3A7dGhleSAmbmJzcDthcmU8L0RJVj4NCjxESVY+YmVuZWZp Y2lhbCAmbmJzcDt0byAmbmJzcDtib3RoICZuYnNwO0lTUHMgJm5ic3A7YW5kICZuYnNwO1AyUCAN CiZuYnNwO2FwcGxpY2F0aW9ucywgJm5ic3A7YnV0ICZuYnNwO3RoZXkgJm5ic3A7aGF2ZSAmbmJz cDt0byAmbmJzcDtzdXBwb3J0IA0KJm5ic3A7YSAmbmJzcDtsb3Q8L0RJVj4NCjxESVY+b2YgJm5i c3A7b24tZXZvbHZpbmcgJm5ic3A7UDJQICZuYnNwO2FwcGxpY2F0aW9uICZuYnNwO3Byb3RvY29s cy4gDQombmJzcDtERUNBREUgJm5ic3A7d2lsbCAmbmJzcDthbGxvdyAmbmJzcDtQMlAgJm5ic3A7 YXBwbGljYXRpb25zPC9ESVY+DQo8RElWPnVzZXJzICZuYnNwO3RvICZuYnNwO3VzZSAmbmJzcDt0 aGVpciAmbmJzcDtpbi1uZXR3b3JrICZuYnNwO3N0b3JhZ2UgDQombmJzcDthbmQgJm5ic3A7c2hh cmUgJm5ic3A7dGhlaXIgJm5ic3A7aW4tbmV0d29yayAmbmJzcDtyZXNvdXJjZXM8L0RJVj4NCjxE SVY+aW4gJm5ic3A7YSAmbmJzcDtzdGFuZGFyZCAmbmJzcDt3YXksICZuYnNwO3NvICZuYnNwO2Fz ICZuYnNwO3RvIA0KJm5ic3A7cmVkdWNlICZuYnNwO3RoZSAmbmJzcDtjb21wbGV4aXR5ICZuYnNw O29mICZuYnNwO2V4aXN0aW5nICZuYnNwO3AycCANCiZuYnNwO2NhY2hlICZuYnNwO2FuZDwvRElW Pg0KPERJVj5hbGxvdyAmbmJzcDtiZXR0ZXIgJm5ic3A7aW50ZWdyYXRpb24gJm5ic3A7b2YgJm5i c3A7cDJwIA0KJm5ic3A7cG9saWNpZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jmd0O0kgJm5ic3A7dGhpbmsgJm5ic3A7REVDQURFICZuYnNwO2Fu ZCAmbmJzcDtQUDJQICZuYnNwO21heSAmbmJzcDtib3RoIA0KJm5ic3A7Y29udHJpYnV0ZSAmbmJz cDtpbmRlcGVuZGVudGx5LCAmbmJzcDthbmQgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtwb3NzaWJs eSAmbmJzcDtzaW11bHRhbmVvdXNseSwgJm5ic3A7dG8gJm5ic3A7bWFraW5nICZuYnNwO2NvbnRl bnQgDQombmJzcDthdmFpbGFibGUgJm5ic3A7Y2xvc2VyICZuYnNwO3RvICZuYnNwOzwvRElWPg0K PERJVj4mZ3Q7cGVlcnMuICZuYnNwO0ZvciAmbmJzcDtleGFtcGxlLCAmbmJzcDtJICZuYnNwO2Nh biAmbmJzcDtwaWN0dXJlIA0KJm5ic3A7dGhlICZuYnNwO2ZvbGxvd2luZyAmbmJzcDtzaXR1YXRp b25zICZuYnNwO2ZvciAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O1BQU1AgJm5ic3A7YW5kICZuYnNw O0RFQ0FERSAmbmJzcDtjb2V4aXN0ZW5zZTo8L0RJVj4NCjxESVY+Jmd0OyAqICZuYnNwO2EgJm5i c3A7Z2l2ZW4gJm5ic3A7bmV0d29yayAmbmJzcDtzdXBwb3J0cyAmbmJzcDtERUNBREUgDQombmJz cDtpbi1uZXR3b3JrICZuYnNwO2NhY2hpbmcsICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7YW5kICZu YnNwO2l0cyAmbmJzcDtDRE4gJm5ic3A7bm9kZXMgJm5ic3A7ZG8gJm5ic3A7bm90IA0KJm5ic3A7 cGFydGljaXBhdGUgJm5ic3A7YXMgJm5ic3A7UFBTUCAmbmJzcDtQZWVycyAmbmJzcDtmb3IgJm5i c3A7YSAmbmJzcDtnaXZlbiANCiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7InN0cmVhbSIgJm5ic3A7 KGUuZy4gJm5ic3A7c2F5ICZuYnNwO2JlY2F1c2UgJm5ic3A7bm8gJm5ic3A7Q0ROIA0KJm5ic3A7 YXJyYW5nZW1lbnQgJm5ic3A7aGFzICZuYnNwO2JlZW4gJm5ic3A7cHV0ICZuYnNwO2luICZuYnNw OzwvRElWPg0KPERJVj4mZ3Q7cGxhY2UgJm5ic3A7YmV0d2VlbiAmbmJzcDt0aGUgJm5ic3A7Q29u dGVudCAmbmJzcDtQcm92aWRlciAmbmJzcDthbmQgDQombmJzcDt0aGUgJm5ic3A7Y29uc2lkZXJl ZCAmbmJzcDtuZXR3b3JrICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7cHJvdmlkZXIpLiAmbmJzcDtJ biAmbmJzcDt0aGF0ICZuYnNwO2Nhc2UsICZuYnNwO1BQU1AgJm5ic3A7UGVlcnMgDQombmJzcDt3 aWxsICZuYnNwO2FsbCAmbmJzcDtiZSAmbmJzcDsib2ZmLW5ldCIgJm5ic3A7YnV0ICZuYnNwOzwv RElWPg0KPERJVj4mZ3Q7d2lsbCAmbmJzcDtiZSAmbmJzcDthYmxlICZuYnNwO3RvICZuYnNwO3Vz ZSAmbmJzcDtERUNBREUgDQombmJzcDtpbi1uZXR3b3JrICZuYnNwO2NhY2hpbmcgJm5ic3A7dG8g Jm5ic3A7ZXhjaGFuZ2UgJm5ic3A7Y2h1bmtzLiANCiZuYnNwOygqKTwvRElWPg0KPERJVj4mZ3Q7 ICogJm5ic3A7YSAmbmJzcDtnaXZlbiAmbmJzcDtuZXR3b3JrICZuYnNwO2RvZXMgJm5ic3A7bm90 ICZuYnNwO3N1cHBvcnQgDQombmJzcDtERUNBREUgJm5ic3A7aW4tbmV0d29yayAmbmJzcDs8L0RJ Vj4NCjxESVY+Jmd0O2NhY2hpbmcsICZuYnNwO2FuZCAmbmJzcDsoc29tZSAmbmJzcDtvZikgJm5i c3A7aXRzICZuYnNwO0NETiANCiZuYnNwO25vZGVzICZuYnNwO3BhcnRpY2lwYXRlICZuYnNwO2Fz ICZuYnNwO1BQU1AgJm5ic3A7UGVlcnMgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtmb3IgJm5ic3A7 YSAmbmJzcDtnaXZlbiAmbmJzcDsic3RyZWFtIiAmbmJzcDsoZS5nLiAmbmJzcDtzYXkgDQombmJz cDtiZWNhdXNlICZuYnNwO2FuICZuYnNwO2FycmFuZ2VtZW50ICZuYnNwO2hhcyAmbmJzcDtiZWVu ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7cHV0ICZuYnNwO2luICZuYnNwO3BsYWNlICZuYnNwO2Jl dHdlZW4gJm5ic3A7dGhlICZuYnNwO0NvbnRlbnQgDQombmJzcDtQcm92aWRlciAmbmJzcDthbmQg Jm5ic3A7dGhlICZuYnNwO2NvbnNpZGVyZWQgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtuZXR3b3Jr ICZuYnNwO3Byb3ZpZGVyKS4gJm5ic3A7SW4gJm5ic3A7dGhhdCAmbmJzcDtjYXNlLCAmbmJzcDt0 aGUgDQombmJzcDtDRE4gJm5ic3A7bm9kZXMgJm5ic3A7d2lsbCAmbmJzcDs8L0RJVj4NCjxESVY+ Jmd0O3BhcnRpY2lwYXRlICZuYnNwO2FzICZuYnNwO2luLW5ldHdvcmsgJm5ic3A7UFBTUCAmbmJz cDtQZWVycy4gJm5ic3A7VGhlIA0KJm5ic3A7b2ZmLW5ldCAmbmJzcDtQUDJQICZuYnNwO1BlZXJz ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7KGllICZuYnNwO2VuZHVzZXJzKSAmbmJzcDt3aWxsICZu YnNwO2JlICZuYnNwO2FibGUgJm5ic3A7dG8gJm5ic3A7Z2V0IA0KJm5ic3A7Y2h1bmtzICZuYnNw O2Zyb20gJm5ic3A7dGhlICZuYnNwO2luLW5ldHdvcmsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtD RE4gJm5ic3A7bm9kZXMgJm5ic3A7KHVzaW5nICZuYnNwO1BQMlAgJm5ic3A7cHJvdG9jb2xzICZu YnNwO3dpdGggDQombmJzcDt0aGUgJm5ic3A7Q0ROICZuYnNwO25vZGVzKS48L0RJVj4NCjxESVY+ Jmd0OyAqICZuYnNwO2EgJm5ic3A7Z2l2ZW4gJm5ic3A7bmV0d29yayAmbmJzcDtzdXBwb3J0cyAm bmJzcDtERUNBREUgDQombmJzcDtpbi1uZXR3b3JrICZuYnNwO2NhY2hpbmcsICZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7YW5kICZuYnNwOyhzb21lICZuYnNwO29mKSAmbmJzcDtpdHMgJm5ic3A7Q0RO ICZuYnNwO25vZGVzIA0KJm5ic3A7cGFydGljaXBhdGUgJm5ic3A7YXMgJm5ic3A7UFBTUCAmbmJz cDtQZWVycyAmbmJzcDtmb3IgJm5ic3A7YSAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2dpdmVuICZu YnNwOyJzdHJlYW0iICZuYnNwOyhlLmcuICZuYnNwO3NheSAmbmJzcDtiZWNhdXNlICZuYnNwO2Fu IA0KJm5ic3A7YXJyYW5nZW1lbnQgJm5ic3A7aGFzICZuYnNwO2JlZW4gJm5ic3A7cHV0ICZuYnNw OzwvRElWPg0KPERJVj4mZ3Q7aW4gJm5ic3A7cGxhY2UgJm5ic3A7YmV0d2VlbiAmbmJzcDt0aGUg Jm5ic3A7Q29udGVudCAmbmJzcDtQcm92aWRlciANCiZuYnNwO2FuZCAmbmJzcDt0aGUgJm5ic3A7 Y29uc2lkZXJlZCAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O25ldHdvcmsgJm5ic3A7cHJvdmlkZXIp LiAmbmJzcDtJbiAmbmJzcDt0aGF0ICZuYnNwO2Nhc2UsICZuYnNwO3RoZSANCiZuYnNwO0NETiAm bmJzcDtub2RlcyAmbmJzcDt3aWxsICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7cGFydGljaXBhdGUg Jm5ic3A7YXMgJm5ic3A7aW4tbmV0d29yayAmbmJzcDtQUFNQICZuYnNwO1BlZXJzLiAmbmJzcDtU aGUgDQombmJzcDtvZmYtbmV0ICZuYnNwO1BQMlAgJm5ic3A7UGVlcnMgJm5ic3A7PC9ESVY+DQo8 RElWPiZndDsoaWUgJm5ic3A7ZW5kdXNlcnMpICZuYnNwO3dpbGwgJm5ic3A7YmUgJm5ic3A7YWJs ZSAmbmJzcDt0byAmbmJzcDtnZXQgDQombmJzcDtjaHVua3MgJm5ic3A7ZnJvbSAmbmJzcDt0aGUg Jm5ic3A7aW4tbmV0d29yayAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O0NETiAmbmJzcDtub2RlcyAm bmJzcDsodXNpbmcgJm5ic3A7UFAyUCAmbmJzcDtwcm90b2NvbHMgJm5ic3A7d2l0aCANCiZuYnNw O3RoZSAmbmJzcDtDRE4gJm5ic3A7bm9kZXMpICZuYnNwOyAmbmJzcDtfYXMgJm5ic3A7d2VsbCAm bmJzcDs8L0RJVj4NCjxESVY+Jmd0O2FzXyAmbmJzcDsgJm5ic3A7YmUgJm5ic3A7YWJsZSAmbmJz cDt0byAmbmJzcDtnZXQgJm5ic3A7Y2h1bmtzIA0KJm5ic3A7ZnJvbSAmbmJzcDtERUNBREUgJm5i c3A7aW4tbmV0d29yayAmbmJzcDtDYWNoaW5nICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7cG9wdWxh dGVkICZuYnNwOyh1c2luZyAmbmJzcDtERUNBREUgJm5ic3A7cHJvdG9jb2xzKSAmbmJzcDtieSAN CiZuYnNwO1BQU1AgJm5ic3A7UGVlcnMgJm5ic3A7KGJvdGggJm5ic3A7b2ZmLW5ldCAmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0O2VuZC11c2VycyAmbmJzcDthbmQgJm5ic3A7aW4tbmV0d29yayAmbmJz cDtDRE4gJm5ic3A7Tm9kZXMpLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsoRm9y ICZuYnNwO3NpbXBsaWNpdHkgJm5ic3A7SSAmbmJzcDtkaXNjdXNzZWQgJm5ic3A7dGhlICZuYnNw O3VzZSANCiZuYnNwO29mICZuYnNwO0RFQ0FERSAmbmJzcDthbmQgJm5ic3A7UFBTUCAmbmJzcDtQ ZWVyaW5nICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7aW4gJm5ic3A7dGhlICZuYnNwO3NhbWUgJm5i c3A7c2luZ2xlICZuYnNwO25ldHdvcmssICZuYnNwO2J1dCANCiZuYnNwO3Rob3NlICZuYnNwO2Nv dWxkICZuYnNwO2hhcHBlbiAmbmJzcDtpbiAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2RpZmZlcmVu dCAmbmJzcDtuZXR3b3JrcyAmbmJzcDthbmQgJm5ic3A7c2FtZSAmbmJzcDt3b3VsZCANCiZuYnNw O2FwcGx5KS48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7KCopICZuYnNwO2EgJm5i c3A7cGFydGljdWxhciAmbmJzcDtjYXNlICZuYnNwO29mICZuYnNwO3RoYXQgJm5ic3A7aXMgDQom bmJzcDt3aGVuICZuYnNwO3RoZSAmbmJzcDtDb250ZW50ICZuYnNwO1B1Ymxpc2hlciAmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0O2JlaGF2ZXMgJm5ic3A7YXMgJm5ic3A7YSAmbmJzcDtQZWVyICZuYnNw O2FuZCAmbmJzcDt1c2VzICZuYnNwO0RFQ0FERSANCiZuYnNwO3RvICZuYnNwO3BvcHVsYXRlICZu YnNwO2luLW5ldHdvcmsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtjb250ZW50ICZuYnNwO2FzICZu YnNwO2Rpc2N1c3NlZCAmbmJzcDtpbiAmbmJzcDtzZWN0aW9uICZuYnNwOzUuMiANCiZuYnNwO29m ICZuYnNwO0RFQ0FERSAmbmJzcDtwcm9ibGVtICZuYnNwO3N0YXRlbWVudC48L0RJVj4NCjxESVY+ Jmd0OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmsgJm5ic3A7eW91ICZuYnNw O2ZvciAmbmJzcDtnb29kICZuYnNwO2V4YW1wbGVzOiAmbmJzcDspICZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtJcyAmbmJzcDt0aGlz ICZuYnNwO2hvdyAmbmJzcDt5b3UgJm5ic3A7YWxzbyAmbmJzcDtzZWUgJm5ic3A7REVDQURFIA0K Jm5ic3A7YW5kICZuYnNwO1BQU1AgJm5ic3A7cmVsYXRlPyAmbmJzcDtjYW4gJm5ic3A7dGhpcyAm bmJzcDtiZSAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2V4cGxpY2l0bHkgJm5ic3A7ZGlzY3Vzc2Vk PzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5XZSAmbmJz cDtjYW4gJm5ic3A7cmVnYXJkICZuYnNwO1BQU1AgJm5ic3A7YXMgJm5ic3A7YSAmbmJzcDtzcGVj aWZpYyANCiZuYnNwO3Byb3RvY29sICZuYnNwO29mICZuYnNwO2EgJm5ic3A7c3RyZWFtaW5nICZu YnNwO2FwcGxpY2F0aW9uLCANCiZuYnNwO3doaWNoPC9ESVY+DQo8RElWPmNvdWxkICZuYnNwO3Vz ZSAmbmJzcDtERUNBREUgJm5ic3A7anVzdCAmbmJzcDtsaWtlICZuYnNwO290aGVyICZuYnNwO3Ay cCANCiZuYnNwO2FwcGxpY2F0aW9ucy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mZ3Q7KiAmbmJzcDtzZWN0aW9uICZuYnNwOzQuMjo8L0RJVj4NCjxE SVY+Jmd0O3dvdWxkICZuYnNwO2JlICZuYnNwO3dvcnRoICZuYnNwO2NsYXJpZnlpbmcgJm5ic3A7 d2hvICZuYnNwO2NvbnRyb2xzIA0KJm5ic3A7dGhlICZuYnNwO2F1dGhvcml6YXRpb24uICZuYnNw O0F0ICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7bGVhc3QsICZuYnNwO29uZSAmbmJzcDtjYXNlICZu YnNwO2lzICZuYnNwO3RoYXQgJm5ic3A7YXV0aG9yaXphdGlvbiANCiZuYnNwO2lzICZuYnNwO2Nv bnRyb2xsZWQgJm5ic3A7YnkgJm5ic3A7dGhlICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7REVDQURF ICZuYnNwO3VzZXIgJm5ic3A7dGhhdCAmbmJzcDtwbGFjZXMgJm5ic3A7dGhlICZuYnNwO2NvbnRl bnQgDQombmJzcDtpbiAmbmJzcDt0aGUgJm5ic3A7Y2FjaGUuPC9ESVY+DQo8RElWPiZndDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlllcy4gJm5ic3A7VGhlICZuYnNwO3VzZXIgJm5i c3A7Y2FuICZuYnNwO2F1dGhvcml6ZSAmbmJzcDtvdGhlcnMgJm5ic3A7dG8gDQombmJzcDthY2Nl c3MgJm5ic3A7Iml0cyIgJm5ic3A7aW4tbmV0d29yayAmbmJzcDtzdG9yYWdlLjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7KiAmbmJzcDtGaWd1cmVz ICZuYnNwOzIsICZuYnNwOzMsICZuYnNwOzQgJm5ic3A7YW5kICZuYnNwOzU6PC9ESVY+DQo8RElW PiZndDtJICZuYnNwO3N1Z2dlc3QgJm5ic3A7eW91ICZuYnNwO2Fsc28gJm5ic3A7aWxsdXN0cmF0 ZSAmbmJzcDt0aGUgDQombmJzcDthY3R1YWwgJm5ic3A7dHJhbnNmZXIgJm5ic3A7b2YgJm5ic3A7 ZGF0YSAmbmJzcDsoaW4gJm5ic3A7PC9ESVY+DQo8RElWPiZndDthZGRpdGlvbiAmbmJzcDt0byAm bmJzcDt0aGUgJm5ic3A7REVDQURFICZuYnNwO3JlcXVlc3RzKS4gJm5ic3A7SXQgDQombmJzcDtp cyAmbmJzcDtkb25lICZuYnNwO2luICZuYnNwO0ZpZyAmbmJzcDs1ICZuYnNwO2J1dCAmbmJzcDtu b3QgJm5ic3A7PC9ESVY+DQo8RElWPiZndDtpbiAmbmJzcDtwcmV2aW91cyAmbmJzcDtvbmVzLiAm bmJzcDthbHNvICZuYnNwO0kgJm5ic3A7dGhpbmsgJm5ic3A7aXQgDQombmJzcDt3aWxsICZuYnNw O21ha2UgJm5ic3A7c2VxdWVudGlhbGl0eSAmbmJzcDtjbGVhcmVyLjwvRElWPg0KPERJVj4mZ3Q7 Rm9yICZuYnNwO2V4YW1wbGUgJm5ic3A7aW4gJm5ic3A7RmlnICZuYnNwOzIsICZuYnNwO3RoZSAm bmJzcDtkYXRhIA0KJm5ic3A7dHJhbnNmZXIgJm5ic3A7ZnJvbSAmbmJzcDtTYiAmbmJzcDt0byAm bmJzcDtCICZuYnNwO3dvdWxkICZuYnNwO25vdCANCiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7aGFw cGVuICZuYnNwO3JpZ2h0ICZuYnNwO2FmdGVyICZuYnNwO3N0ZXAgJm5ic3A7MyAmbmJzcDsoIjMg Jm5ic3A7SUFQIA0KJm5ic3A7Z2V0Iik7ICZuYnNwO2l0ICZuYnNwO3dvdWxkICZuYnNwO2hhcHBl biAmbmJzcDthZnRlciAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2EgJm5ic3A7ZGF0YSAmbmJzcDt0 cmFuc2ZlciAmbmJzcDtmcm9tICZuYnNwO1NhICZuYnNwO3RvICZuYnNwO1NiIA0KJm5ic3A7LCAm bmJzcDt3aGljaCAmbmJzcDt3b3VsZCAmbmJzcDtoYXBwZW4gJm5ic3A7YWZ0ZXIgJm5ic3A7IjQg Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtJQVAgJm5ic3A7Z2V0IiAmbmJzcDtmcm9tICZuYnNwO1Ni ICZuYnNwO3RvICZuYnNwO1NhLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5XZSAmbmJzcDt3aWxsICZuYnNwO2FkZCAmbmJzcDtsaW5lcyAmbmJzcDt0byAm bmJzcDtpbGx1c3RyYXRlICZuYnNwO3RoZSANCiZuYnNwO2RhdGEgJm5ic3A7dHJhbnNmZXI6ICZu YnNwOyk8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsqICZuYnNwO0ZpZ3VyZSAm bmJzcDs0OjwvRElWPg0KPERJVj4mZ3Q7SXQgJm5ic3A7bWF5ICZuYnNwO2JlICZuYnNwO21vcmUg Jm5ic3A7aW50dWl0aXZlICZuYnNwO3RvICZuYnNwO3N3YXAgDQombmJzcDt0aGUgJm5ic3A7b3Jk ZXIgJm5ic3A7b2YgJm5ic3A7c3RlcCAmbmJzcDsyICZuYnNwO2FuZCAmbmJzcDszICZuYnNwOyhp ZSANCiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7c2hvdyAmbmJzcDtBICZuYnNwO3N0b3JpbmcgJm5i c3A7dGhlICZuYnNwO29iamVjdCAmbmJzcDtpbiAmbmJzcDtTYiANCiZuYnNwO2JlZm9yZSAmbmJz cDtBICZuYnNwO3Jlc3BvbmRzICZuYnNwO3RvICZuYnNwO0IpLjwvRElWPg0KPERJVj4mZ3Q7PC9E SVY+DQo8RElWPkl0J3MgJm5ic3A7YSAmbmJzcDtsaXR0bGUgJm5ic3A7dHJpY2t5ICZuYnNwO2hl cmUgJm5ic3A7YW5kICZuYnNwO1AyUCANCiZuYnNwO2FwcGxpY2F0aW9ucyAmbmJzcDtjYW4gJm5i c3A7dXNlICZuYnNwO2RpZmZlcmVudCAmbmJzcDt3YXlzICZuYnNwO3RvIA0KJm5ic3A7ZG88L0RJ Vj4NCjxESVY+aXQuICZuYnNwO1doZW4gJm5ic3A7QSAmbmJzcDtnZXRzICZuYnNwO3RoZSAmbmJz cDtyZXF1ZXN0ICZuYnNwO3RvIA0KJm5ic3A7c3RvcmUgJm5ic3A7b2JqZWN0ICZuYnNwO3RvICZu YnNwO1NiLCAmbmJzcDtpdCAmbmJzcDtjYW4gJm5ic3A7c2ltcGx5IA0KJm5ic3A7cmVwbHkgJm5i c3A7d2l0aDwvRElWPg0KPERJVj4iT2theSIsICZuYnNwO2FuZCAmbmJzcDt0aGVuICZuYnNwO2Rv ICZuYnNwO3RoZSAmbmJzcDtzdG9yZSANCiZuYnNwO29wZXJhdGlvbi4gJm5ic3A7QWxzbyAmbmJz cDtpdCAmbmJzcDtjYW4gJm5ic3A7c3RhcnQgJm5ic3A7dG8gJm5ic3A7c3RvcmUgDQombmJzcDt0 aGU8L0RJVj4NCjxESVY+b2JqZWN0ICZuYnNwO3RvICZuYnNwO1NiICZuYnNwO2FuZCAmbmJzcDt0 aGVuICZuYnNwO3JlcGx5ICZuYnNwO3RvICZuYnNwO0IgDQombmJzcDt3aXRoICZuYnNwO2EgJm5i c3A7bWVzc2FnZSAmbmJzcDsiICZuYnNwO0kgJm5ic3A7aGF2ZSAmbmJzcDtzdGFydGVkIA0KJm5i c3A7dG88L0RJVj4NCjxESVY+dHJhbnNmZXIuLi4iLiAmbmJzcDsgJm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzLDwvRElWPg0KPERJ Vj5IYWliaW48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtIb3BlICZuYnNwO3RoYXQgJm5ic3A7aGVscHMuPC9ESVY+ DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0O0ZyYW5jb2lzPC9ESVY+DQo8RElWPiZndDs8L0RJ Vj4NCjxESVY+Jmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9ESVY+DQo8RElWPiZndDtkZWNhZGUgJm5ic3A7bWFpbGluZyAmbmJzcDtsaXN0PC9ESVY+ DQo8RElWPiZndDtkZWNhZGVAaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0O2h0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9ESVY+DQo8RElWPmRlY2FkZSAmbmJzcDttYWlsaW5nICZuYnNwO2xpc3Q8 L0RJVj4NCjxESVY+ZGVjYWRlQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlPC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= --=====003_Dragon078352785458_=====-- From melodysong@huawei.com Sun Nov 22 23:29:10 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D07B3A68C5 for ; Sun, 22 Nov 2009 23:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, J_CHICKENPOX_73=0.6, MIME_CHARSET_FARAWAY=2.45] 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 QYsNt3gaE89d for ; Sun, 22 Nov 2009 23:29:08 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6977B3A68E6 for ; Sun, 22 Nov 2009 23:29:08 -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 <0KTJ0030VWNKCR@szxga03-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 15:26:08 +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 <0KTJ001SMWNFSV@szxga03-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 15:26:03 +0800 (CST) Received: from s64081 ([10.164.12.12]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ000QVWNEOT@szxml04-in.huawei.com> for decade@ietf.org; Mon, 23 Nov 2009 15:26:03 +0800 (CST) Date: Mon, 23 Nov 2009 15:26:02 +0800 From: Song Haibin In-reply-to: <200911231204374682705@chinamobile.com> To: 'zhangyunfei' , 'Francois Le Faucheur' , decade@ietf.org Message-id: <011f01ca6c0e$363b7a50$0c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acpr8hrWDMI0H9NSR2eSbGP9M7/lkAAGpCnw Subject: Re: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:29:10 -0000 Yunfei, Thanks for your reply. I agree with your analysis here. =20 > 1)Motivation: > PPSP, operator/ISP or other vendors to launch p2p streaming service;=20 > DECADE, operator/ISP to decrease traffic pressure.The = service is not run by opertor/ISP. Reducing traffic, especially the last mile uplink is one important motivation. I think here you use the word "service" to mean applications actually. =20 =20 Haibin=20 ________________________________ From: zhangyunfei [mailto:zhangyunfei@chinamobile.com]=20 Sent: Monday, November 23, 2009 12:05 PM To: Song Haibin; 'Francois Le Faucheur'; decade@ietf.org Subject: Re: Re: [decade] Comments on = draft-song-decade-problem-statement Hi, =20 It seems great that Francois has given us a clearer picture on the usage of PPSP and DECADE.Thanks a lot. I would like to clarify that although both PPSP and DECADE have an edge caches usages, they have several noticeable differences: 1)Motivation: PPSP, operator/ISP or other vendors to launch p2p streaming service;=20 DECADE, operator/ISP to decrease traffic pressure.The service is not run by opertor/ISP. =20 =20 2)Task:=20 PPSP,unifying peer/tracker protocols both for CDN and common peers. CDN as superpeers equipping PPSP protocols.PPSP protocols = are p2p protocols. DECADE,creating peer/non-peer client to CDN access protocol, which is not a P2P protocol itself. Peer/client needs to = update to support DECADE protocol. 3)Scope: PPSP, p2p streaming senarios; DECADE, p2p data-intensive senarios; 4)Purpose: PPSP:efficient information exchange between peers DECADE:peer/client and cache command to ask caches to perform corresponding actions In a word, PPSP and DECADE may occur in the same senario,p2p streaming while their functionalities are quite different. =20 BR Yunfei =20 ________________________________ zhangyunfei 2009-11-23 ________________________________ =B7=A2=BC=FE=C8=CB=A3=BA Song Haibin =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-11-23 11:19:32 =CA=D5=BC=FE=C8=CB=A3=BA 'Francois Le Faucheur'; decade@ietf.org =B3=AD=CB=CD=A3=BA=20 =D6=F7=CC=E2=A3=BA Re: [decade] Comments on = draft-song-decade-problem-statement =20 Hi Francois, =20 Good comments. =20 =20 =20 >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] =20 >On Behalf Of Francois Le Faucheur >Sent: Friday, November 20, 2009 10:28 PM >To: decade@ietf.org >Subject: [decade] Comments on draft-song-decade-problem-statement > >Hello, > >Here are some comments/suggestions re decade-problem-statement: > >* section 3.1: >"Recently, the IETF Application Layer Traffic Optimization =20 >(ALTO) Working Group is formed to provide P2P applications >with network information so that they can perform =20 >better-than-random initial peer selection =20 >[I-D.ietf-alto-problem-statement]. " >I believe ALTO can be used for peer selection at any time (ie =20 >not just initially). =20 It is in paragraph 4 of "Description of Working Group" in ALTO WG charter. You are right that P2P applications can do the peer selection with the help of ALTO server at any time. But I think here "initial peer selection" means it (ALTO) is the first step for peer selection, and after that P2P application users can do another round of peer selection based on other things, such like chunk availability(e.g. "rarest piece first") and per pair connection quality. =20 >The information provided by ALTO is not necessarily "network =20 >information" (e.g. could be just a list of selected peers). =20 The peer selection is mainly based on network cost information. But you are right, we should delete the word "network" here. =20 >Also, some P2P Apps use other criteria than pure random, but =20 >still not necessarily optimal. >So how about, something like: >"The IETF Application Layer Traffic Optimization (ALTO) =20 >Working Group specifies mechanisms that allow P2P applications =20 >to perform selection of peers that is superior to random =20 >selection or selection based on information deducted from =20 >partial observation [I-D.ietf-alto-problem-statement]. " > =20 It's okay. I prefer to just delete the word "network", just like what is said in the ALTO charter. =20 > >* section 3.1: >"On the other hand, it is reported that P2P traffic is =20 >becoming the dominating traffic on the access networks of some =20 >networks, reaching as high as 50-60% at the down-links and >60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], >[P2P_file_sharing]). Consequently, it becomes increasingly =20 >important to complement the ALTO effort and reduce upload =20 >access traffic, in addition to cross-domain and backbone traffic. >" >I think it would be worth discussing how LEDBAT relates to the above. >Perhaps adding something along the lines of: >" The IETF Low Extra Delay Background Transport (LEDBAT) =20 >Working Group is focusing on broadly applicable techniques =20 >that allow large amounts of data to be consistently =20 >transmitted without substantially affecting the delays =20 >experienced by other users and applications. It is expected >that some P2P applications would start using such techniques, =20 >thereby somewhat alleviating the perceivable impact (at least =20 >on other applications) of their high volume traffic . However, =20 >such techniques do not remove all inefficiencies, such as =20 >those associated with traffic being sent upstream as many =20 >times as there are remote peers interested in getting the >corresponding information." > =20 I agree with what you said here. But LEDBAT is not so relevant to DECADE as ALTO. ALTO can reduce the backbone traffic of ISP's network by do better peer selection, while DECADE can save much of your uplink bandwidth by putting your contents into network and allowing others to download from there (need standard resource control). By putting the contents into network, P2P applications can also improve the availability of the content. LEDBAT focuses on the techniques that will alleviate the impact among transport for different applications. It is a little different. =20 > >* section 3.1: >The current text discusses inefficiencies in terms of access =20 >network bandwidth being effectively wasted from the viewpoint =20 >of the network operator. Perhaps it would also be worth making =20 >explicit the consequences from the P2P applications viewpoint =20 >i.e. likely longer time to retrieve complete content as well =20 >as likely higher latency for some real time applications (e.g. PPSP). > =20 Good point. =20 =20 >* section 4: >"Note that DECADE is independent of current IETF work on P2P, =20 >e.g. P2PSIP, ALTO, PPSP. For example, peers discovered by >either RELOAD or ALTO can all use DECADE to share data. >DECADE will focus on the problems of P2P applications, =20 >although the solution might be used in other context." > >The relationship between DECADE and PPSP deserves =20 >clarification. In particular, because the PP2P problem =20 >statement document (draft-zhang-ppsp-problem-statement-05): > * in its section 4.2 : describes Edge Caches as one of >the motivations for developing PPSP standards protocols > * in its section 7.1 : describes a PPSP use case with =20 >in-network CDN nodes for enhanced P2P streaming. > =20 DECADE is quite different from PPSP while then can collaborate in a system. P2P streaming applications (e.g. those who use PPSP protocol) can use DECADE to distribute their services. DECADE is more generic, and focues on the standard interface between P2P client and the in-network storage(esp. resource control). The purpose of existing P2P caches are good and they are beneficial to both ISPs and P2P applications, but they have to support a lot of on-evolving P2P application protocols. DECADE will allow P2P applications users to use their in-network storage and share their in-network resources in a standard way, so as to reduce the complexity of existing p2p cache and allow better integration of p2p policies. =20 =20 >I think DECADE and PP2P may both contribute independently, and =20 >possibly simultaneously, to making content available closer to =20 >peers. For example, I can picture the following situations for =20 >PPSP and DECADE coexistense: > * a given network supports DECADE in-network caching, =20 >and its CDN nodes do not participate as PPSP Peers for a given =20 >"stream" (e.g. say because no CDN arrangement has been put in =20 >place between the Content Provider and the considered network =20 >provider). In that case, PPSP Peers will all be "off-net" but =20 >will be able to use DECADE in-network caching to exchange chunks. (*) > * a given network does not support DECADE in-network =20 >caching, and (some of) its CDN nodes participate as PPSP Peers =20 >for a given "stream" (e.g. say because an arrangement has been =20 >put in place between the Content Provider and the considered =20 >network provider). In that case, the CDN nodes will =20 >participate as in-network PPSP Peers. The off-net PP2P Peers =20 >(ie endusers) will be able to get chunks from the in-network =20 >CDN nodes (using PP2P protocols with the CDN nodes). > * a given network supports DECADE in-network caching, =20 >and (some of) its CDN nodes participate as PPSP Peers for a =20 >given "stream" (e.g. say because an arrangement has been put =20 >in place between the Content Provider and the considered =20 >network provider). In that case, the CDN nodes will =20 >participate as in-network PPSP Peers. The off-net PP2P Peers =20 >(ie endusers) will be able to get chunks from the in-network =20 >CDN nodes (using PP2P protocols with the CDN nodes) _as well =20 >as_ be able to get chunks from DECADE in-network Caching >populated (using DECADE protocols) by PPSP Peers (both off-net =20 >end-users and in-network CDN Nodes). > >(For simplicity I discussed the use of DECADE and PPSP Peering =20 >in the same single network, but those could happen in =20 >different networks and same would apply). > >(*) a particular case of that is when the Content Publisher =20 >behaves as a Peer and uses DECADE to populate in-network =20 >content as discussed in section 5.2 of DECADE problem statement. > =20 Thank you for good examples: ) =20 =20 =20 >Is this how you also see DECADE and PPSP relate? can this be =20 >explicitly discussed? > =20 We can regard PPSP as a specific protocol of a streaming application, which could use DECADE just like other p2p applications. =20 =20 >* section 4.2: >would be worth clarifying who controls the authorization. At =20 >least, one case is that authorization is controlled by the >DECADE user that places the content in the cache. > =20 Yes. The user can authorize others to access "its" in-network storage. =20 > >* Figures 2, 3, 4 and 5: >I suggest you also illustrate the actual transfer of data (in =20 >addition to the DECADE requests). It is done in Fig 5 but not =20 >in previous ones. also I think it will make sequentiality clearer. >For example in Fig 2, the data transfer from Sb to B would not =20 >happen right after step 3 ("3 IAP get"); it would happen after =20 >a data transfer from Sa to Sb , which would happen after "4 =20 >IAP get" from Sb to Sa. > =20 We will add lines to illustrate the data transfer: ) =20 >* Figure 4: >It may be more intuitive to swap the order of step 2 and 3 (ie =20 >show A storing the object in Sb before A responds to B). > It's a little tricky here and P2P applications can use different ways to do it. When A gets the request to store object to Sb, it can simply reply with "Okay", and then do the store operation. Also it can start to store the object to Sb and then reply to B with a message " I have started to transfer...". =20 =20 =20 Thanks, Haibin =20 =20 > >Hope that helps. > >Francois > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > =20 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade =09 From zhangyunfei@chinamobile.com Sun Nov 22 23:30:20 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F85C3A68C5 for ; Sun, 22 Nov 2009 23:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.814 X-Spam-Level: X-Spam-Status: No, score=-92.814 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_73=0.6, 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 6FNgQKnbC2lP for ; Sun, 22 Nov 2009 23:30:17 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id EB9783A6895 for ; Sun, 22 Nov 2009 23:30:16 -0800 (PST) Received: from LENOVO-917FFE55 ([10.1.4.16]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009112315372006-13215 ; Mon, 23 Nov 2009 15:37:20 +0800 Date: Mon, 23 Nov 2009 15:30:02 +0800 From: "zhangyunfei" To: "Song Haibin" , "'Francois Le Faucheur'" , "decade@ietf.org" References: <011f01ca6c0e$363b7a50$0c0ca40a@china.huawei.com> Message-ID: <200911231530018903566@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 2009-11-23 15:37:20, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-11-23 15:30:12 Content-Type: multipart/alternative; boundary="=====003_Dragon636646623785_=====" Subject: Re: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:30:21 -0000 --=====003_Dragon636646623785_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" U3VyZS4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KMjAwOS0xMS0yMw0KDQoN Cg0Kt6K8/sjLo7ogU29uZyBIYWliaW4NCreiy83Ksbzko7ogMjAwOS0xMS0yMyAxNTozMzoyMA0K ytW8/sjLo7ogJ3poYW5neXVuZmVpJzsgJ0ZyYW5jb2lzIExlIEZhdWNoZXVyJzsgZGVjYWRlQGll dGYub3JnDQqzrcvNo7ogDQrW98zio7ogUkU6IFJlOiBbZGVjYWRlXSBDb21tZW50cyBvbiBkcmFm dC1zb25nLWRlY2FkZS1wcm9ibGVtLXN0YXRlbWVudA0KDQpZdW5mZWksDQoNClRoYW5rcyAgZm9y ICB5b3VyICByZXBseS4gIEkgIGFncmVlICB3aXRoICB5b3VyICBhbmFseXNpcyAgaGVyZS4NCg0K PiAgICAgICAgMSlNb3RpdmF0aW9uOg0KPiAgICAgICAgICAgICAgICAgICAgICBQUFNQLCAgb3Bl cmF0b3IvSVNQICBvciAgb3RoZXIgIHZlbmRvcnMgIHRvICBsYXVuY2ggIHAycCAgc3RyZWFtaW5n DQpzZXJ2aWNlOyAgDQo+ICAgICAgICAgICAgICAgICAgICAgIERFQ0FERSwgIG9wZXJhdG9yL0lT UCAgdG8gIGRlY3JlYXNlICB0cmFmZmljICBwcmVzc3VyZS5UaGUgIHNlcnZpY2UgIGlzDQpub3Qg IHJ1biAgYnkgIG9wZXJ0b3IvSVNQLg0KDQpSZWR1Y2luZyAgdHJhZmZpYywgIGVzcGVjaWFsbHkg IHRoZSAgbGFzdCAgbWlsZSAgdXBsaW5rICBpcyAgb25lICBpbXBvcnRhbnQNCm1vdGl2YXRpb24u ICBJICB0aGluayAgaGVyZSAgeW91ICB1c2UgIHRoZSAgd29yZCAgInNlcnZpY2UiICB0byAgbWVh biAgYXBwbGljYXRpb25zDQphY3R1YWxseS4gICAgICAgICAgICAgIA0KDQpIYWliaW4gIA0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206ICB6aGFuZ3l1bmZlaSAg W21haWx0bzp6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb21dICANClNlbnQ6ICBNb25kYXksICBO b3ZlbWJlciAgMjMsICAyMDA5ICAxMjowNSAgUE0NClRvOiAgU29uZyAgSGFpYmluOyAgJ0ZyYW5j b2lzICBMZSAgRmF1Y2hldXInOyAgZGVjYWRlQGlldGYub3JnDQpTdWJqZWN0OiAgUmU6ICBSZTog IFtkZWNhZGVdICBDb21tZW50cyAgb24gIGRyYWZ0LXNvbmctZGVjYWRlLXByb2JsZW0tc3RhdGVt ZW50DQoNCg0KDQpIaSwNCg0KICAgICAgIEl0ICBzZWVtcyAgZ3JlYXQgIHRoYXQgIEZyYW5jb2lz ICBoYXMgIGdpdmVuICB1cyAgYSAgY2xlYXJlciAgcGljdHVyZSAgb24NCnRoZSAgdXNhZ2UgIG9m ICBQUFNQICBhbmQgIERFQ0FERS5UaGFua3MgIGEgIGxvdC4NCiAgICAgICBJICB3b3VsZCAgbGlr ZSAgdG8gIGNsYXJpZnkgIHRoYXQgIGFsdGhvdWdoICBib3RoICBQUFNQICBhbmQgIERFQ0FERSAg aGF2ZQ0KYW4gIGVkZ2UgIGNhY2hlcyAgdXNhZ2VzLCAgdGhleSAgaGF2ZSAgc2V2ZXJhbCAgbm90 aWNlYWJsZSAgZGlmZmVyZW5jZXM6DQogICAgICAgMSlNb3RpdmF0aW9uOg0KICAgICAgICAgICAg ICAgICAgICAgUFBTUCwgIG9wZXJhdG9yL0lTUCAgb3IgIG90aGVyICB2ZW5kb3JzICB0byAgbGF1 bmNoICBwMnANCnN0cmVhbWluZyAgc2VydmljZTsgIA0KICAgICAgICAgICAgICAgICAgICAgREVD QURFLCAgb3BlcmF0b3IvSVNQICB0byAgZGVjcmVhc2UgIHRyYWZmaWMgIHByZXNzdXJlLlRoZQ0K c2VydmljZSAgaXMgIG5vdCAgcnVuICBieSAgb3BlcnRvci9JU1AuDQogICAgICAgICAgICAgDQoN CiAyKVRhc2s6ICANCiAgICAgICAgICAgICAgICAgICBQUFNQLHVuaWZ5aW5nICBwZWVyL3RyYWNr ZXIgIHByb3RvY29scyAgYm90aCAgZm9yICBDRE4gIGFuZA0KY29tbW9uICBwZWVycy4gIENETiAg YXMgIHN1cGVycGVlcnMgIGVxdWlwcGluZyAgUFBTUCAgcHJvdG9jb2xzLlBQU1AgIHByb3RvY29s cyAgYXJlDQpwMnAgIHByb3RvY29scy4NCiAgICAgICAgICAgICAgICAgICBERUNBREUsY3JlYXRp bmcgIHBlZXIvbm9uLXBlZXIgIGNsaWVudCAgdG8gIENETiAgYWNjZXNzDQpwcm90b2NvbCwgIHdo aWNoICBpcyAgbm90ICBhICBQMlAgIHByb3RvY29sICBpdHNlbGYuICBQZWVyL2NsaWVudCAgbmVl ZHMgIHRvICB1cGRhdGUgIHRvDQpzdXBwb3J0ICBERUNBREUgIHByb3RvY29sLg0KICAgICAzKVNj b3BlOiAgUFBTUCwgIHAycCAgc3RyZWFtaW5nICBzZW5hcmlvczsgIERFQ0FERSwgIHAycCAgZGF0 YS1pbnRlbnNpdmUNCnNlbmFyaW9zOw0KICAgICA0KVB1cnBvc2U6DQogICAgICAgICAgICAgICBQ UFNQOmVmZmljaWVudCAgaW5mb3JtYXRpb24gIGV4Y2hhbmdlICBiZXR3ZWVuICBwZWVycw0KICAg ICAgICAgICAgICAgREVDQURFOnBlZXIvY2xpZW50ICBhbmQgIGNhY2hlICBjb21tYW5kICB0byAg YXNrICBjYWNoZXMgIHRvDQpwZXJmb3JtICBjb3JyZXNwb25kaW5nICBhY3Rpb25zDQogICAgICAg SW4gIGEgIHdvcmQsICBQUFNQICBhbmQgIERFQ0FERSAgbWF5ICBvY2N1ciAgaW4gIHRoZSAgc2Ft ZSAgc2VuYXJpbyxwMnANCnN0cmVhbWluZyAgd2hpbGUgIHRoZWlyICBmdW5jdGlvbmFsaXRpZXMg IGFyZSAgcXVpdGUgIGRpZmZlcmVudC4NCg0KQlINCll1bmZlaQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQp6aGFuZ3l1bmZlaQ0KMjAwOS0xMS0yMw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0Kt6K8/sjLo7ogIFNvbmcgIEhhaWJpbg0Kt6LLzcqxvOSj uiAgMjAwOS0xMS0yMyAgMTE6MTk6MzINCsrVvP7Iy6O6ICAnRnJhbmNvaXMgIExlICBGYXVjaGV1 cic7ICBkZWNhZGVAaWV0Zi5vcmcNCrOty82juiAgDQrW98zio7ogIFJlOiAgW2RlY2FkZV0gIENv bW1lbnRzICBvbiAgZHJhZnQtc29uZy1kZWNhZGUtcHJvYmxlbS1zdGF0ZW1lbnQNCg0KSGkgICAg RnJhbmNvaXMsDQoNCkdvb2QgICAgY29tbWVudHMuICAgIA0KICAgICANCg0KPi0tLS0tT3JpZ2lu YWwgICAgTWVzc2FnZS0tLS0tDQo+RnJvbTogICAgZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgICAg W21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gICAgDQo+T24gICAgQmVoYWxmICAgIE9m ICAgIEZyYW5jb2lzICAgIExlICAgIEZhdWNoZXVyDQo+U2VudDogICAgRnJpZGF5LCAgICBOb3Zl bWJlciAgICAyMCwgICAgMjAwOSAgICAxMDoyOCAgICBQTQ0KPlRvOiAgICBkZWNhZGVAaWV0Zi5v cmcNCj5TdWJqZWN0OiAgICBbZGVjYWRlXSAgICBDb21tZW50cyAgICBvbg0KZHJhZnQtc29uZy1k ZWNhZGUtcHJvYmxlbS1zdGF0ZW1lbnQNCj4NCj5IZWxsbywNCj4NCj5IZXJlICAgIGFyZSAgICBz b21lICAgIGNvbW1lbnRzL3N1Z2dlc3Rpb25zICAgIHJlDQpkZWNhZGUtcHJvYmxlbS1zdGF0ZW1l bnQ6DQo+DQo+KiAgICBzZWN0aW9uICAgIDMuMToNCj4iUmVjZW50bHksICAgIHRoZSAgICBJRVRG ICAgIEFwcGxpY2F0aW9uICAgIExheWVyICAgIFRyYWZmaWMgICAgT3B0aW1pemF0aW9uICAgIA0K PihBTFRPKSAgICBXb3JraW5nICAgIEdyb3VwICAgIGlzICAgIGZvcm1lZCAgICB0byAgICBwcm92 aWRlICAgIFAyUCAgICBhcHBsaWNhdGlvbnMNCg0KPndpdGggICAgbmV0d29yayAgICBpbmZvcm1h dGlvbiAgICBzbyAgICB0aGF0ICAgIHRoZXkgICAgY2FuICAgIHBlcmZvcm0gICAgDQo+YmV0dGVy LXRoYW4tcmFuZG9tICAgIGluaXRpYWwgICAgcGVlciAgICBzZWxlY3Rpb24gICAgDQo+W0ktRC5p ZXRmLWFsdG8tcHJvYmxlbS1zdGF0ZW1lbnRdLiAgICAiDQo+SSAgICBiZWxpZXZlICAgIEFMVE8g ICAgY2FuICAgIGJlICAgIHVzZWQgICAgZm9yICAgIHBlZXIgICAgc2VsZWN0aW9uICAgIGF0ICAg IGFueQ0KdGltZSAgICAoaWUgICAgDQo+bm90ICAgIGp1c3QgICAgaW5pdGlhbGx5KS4NCg0KSXQg ICAgaXMgICAgaW4gICAgcGFyYWdyYXBoICAgIDQgICAgb2YgICAgIkRlc2NyaXB0aW9uICAgIG9m ICAgIFdvcmtpbmcgICAgR3JvdXAiICAgIGluDQpBTFRPICAgIFdHICAgIGNoYXJ0ZXIuDQpZb3Ug ICAgYXJlICAgIHJpZ2h0ICAgIHRoYXQgICAgUDJQICAgIGFwcGxpY2F0aW9ucyAgICBjYW4gICAg ZG8gICAgdGhlICAgIHBlZXINCnNlbGVjdGlvbiAgICB3aXRoICAgIHRoZSAgICBoZWxwDQpvZiAg ICBBTFRPICAgIHNlcnZlciAgICBhdCAgICBhbnkgICAgdGltZS4gICAgQnV0ICAgICAgICBJICAg IHRoaW5rICAgIGhlcmUgICAgImluaXRpYWwNCnBlZXIgICAgc2VsZWN0aW9uIiAgICBtZWFucw0K aXQgICAgKEFMVE8pICAgIGlzICAgIHRoZSAgICBmaXJzdCAgICBzdGVwICAgIGZvciAgICBwZWVy ICAgIHNlbGVjdGlvbiwgICAgYW5kICAgIGFmdGVyDQp0aGF0ICAgIFAyUA0KYXBwbGljYXRpb24g ICAgdXNlcnMgICAgY2FuICAgIGRvICAgIGFub3RoZXIgICAgcm91bmQgICAgb2YgICAgcGVlciAg ICBzZWxlY3Rpb24NCmJhc2VkICAgIG9uICAgIG90aGVyDQp0aGluZ3MsICAgIHN1Y2ggICAgbGlr ZSAgICBjaHVuayAgICBhdmFpbGFiaWxpdHkoZS5nLiAgICAicmFyZXN0ICAgIHBpZWNlDQpmaXJz dCIpICAgIGFuZCAgICBwZXIgICAgcGFpcg0KY29ubmVjdGlvbiAgICBxdWFsaXR5Lg0KDQo+VGhl ICAgIGluZm9ybWF0aW9uICAgIHByb3ZpZGVkICAgIGJ5ICAgIEFMVE8gICAgaXMgICAgbm90ICAg IG5lY2Vzc2FyaWx5DQoibmV0d29yayAgICANCj5pbmZvcm1hdGlvbiIgICAgKGUuZy4gICAgY291 bGQgICAgYmUgICAganVzdCAgICBhICAgIGxpc3QgICAgb2YgICAgc2VsZWN0ZWQNCnBlZXJzKS4N Cg0KVGhlICAgIHBlZXIgICAgc2VsZWN0aW9uICAgIGlzICAgIG1haW5seSAgICBiYXNlZCAgICBv biAgICBuZXR3b3JrICAgIGNvc3QNCmluZm9ybWF0aW9uLiAgICBCdXQgICAgeW91ICAgIGFyZQ0K cmlnaHQsICAgIHdlICAgIHNob3VsZCAgICBkZWxldGUgICAgdGhlICAgIHdvcmQgICAgIm5ldHdv cmsiICAgIGhlcmUuDQoNCj5BbHNvLCAgICBzb21lICAgIFAyUCAgICBBcHBzICAgIHVzZSAgICBv dGhlciAgICBjcml0ZXJpYSAgICB0aGFuICAgIHB1cmUgICAgcmFuZG9tLA0KYnV0ICAgIA0KPnN0 aWxsICAgIG5vdCAgICBuZWNlc3NhcmlseSAgICBvcHRpbWFsLg0KPlNvICAgIGhvdyAgICBhYm91 dCwgICAgc29tZXRoaW5nICAgIGxpa2U6DQo+IlRoZSAgICBJRVRGICAgIEFwcGxpY2F0aW9uICAg IExheWVyICAgIFRyYWZmaWMgICAgT3B0aW1pemF0aW9uICAgIChBTFRPKSAgICANCj5Xb3JraW5n ICAgIEdyb3VwICAgIHNwZWNpZmllcyAgICBtZWNoYW5pc21zICAgIHRoYXQgICAgYWxsb3cgICAg UDJQDQphcHBsaWNhdGlvbnMgICAgDQo+dG8gICAgcGVyZm9ybSAgICBzZWxlY3Rpb24gICAgb2Yg ICAgcGVlcnMgICAgdGhhdCAgICBpcyAgICBzdXBlcmlvciAgICB0byAgICByYW5kb20gICAgDQo+ c2VsZWN0aW9uICAgIG9yICAgIHNlbGVjdGlvbiAgICBiYXNlZCAgICBvbiAgICBpbmZvcm1hdGlv biAgICBkZWR1Y3RlZCAgICBmcm9tICAgIA0KPnBhcnRpYWwgICAgb2JzZXJ2YXRpb24gICAgW0kt RC5pZXRmLWFsdG8tcHJvYmxlbS1zdGF0ZW1lbnRdLiAgICAiDQo+DQoNCkl0J3MgICAgb2theS4g ICAgSSAgICBwcmVmZXIgICAgdG8gICAganVzdCAgICBkZWxldGUgICAgdGhlICAgIHdvcmQgICAg Im5ldHdvcmsiLA0KanVzdCAgICBsaWtlICAgIHdoYXQgICAgaXMNCnNhaWQgICAgaW4gICAgdGhl ICAgIEFMVE8gICAgY2hhcnRlci4NCg0KPg0KPiogICAgc2VjdGlvbiAgICAzLjE6DQo+Ik9uICAg IHRoZSAgICBvdGhlciAgICBoYW5kLCAgICBpdCAgICBpcyAgICByZXBvcnRlZCAgICB0aGF0ICAg IFAyUCAgICB0cmFmZmljICAgIGlzICAgIA0KPmJlY29taW5nICAgIHRoZSAgICBkb21pbmF0aW5n ICAgIHRyYWZmaWMgICAgb24gICAgdGhlICAgIGFjY2VzcyAgICBuZXR3b3JrcyAgICBvZg0Kc29t ZSAgICANCj5uZXR3b3JrcywgICAgcmVhY2hpbmcgICAgYXMgICAgaGlnaCAgICBhcyAgICA1MC02 MCUgICAgYXQgICAgdGhlICAgIGRvd24tbGlua3MgICAgYW5kDQoNCj42MC05MCUgICAgYXQgICAg dGhlICAgIHVwbGlua3MgICAgKFtEQ0lBXSwgICAgW0lDTlBdLCAgICBbaXBvcXVlLlAyUF9zdXJ2 ZXkuXSwNCg0KPltQMlBfZmlsZV9zaGFyaW5nXSkuICAgICAgICBDb25zZXF1ZW50bHksICAgIGl0 ICAgIGJlY29tZXMgICAgaW5jcmVhc2luZ2x5ICAgIA0KPmltcG9ydGFudCAgICB0byAgICBjb21w bGVtZW50ICAgIHRoZSAgICBBTFRPICAgIGVmZm9ydCAgICBhbmQgICAgcmVkdWNlICAgIHVwbG9h ZCAgICANCj5hY2Nlc3MgICAgdHJhZmZpYywgICAgaW4gICAgYWRkaXRpb24gICAgdG8gICAgY3Jv c3MtZG9tYWluICAgIGFuZCAgICBiYWNrYm9uZQ0KdHJhZmZpYy4NCj4iDQo+SSAgICB0aGluayAg ICBpdCAgICB3b3VsZCAgICBiZSAgICB3b3J0aCAgICBkaXNjdXNzaW5nICAgIGhvdyAgICBMRURC QVQgICAgcmVsYXRlcw0KdG8gICAgdGhlICAgIGFib3ZlLg0KPlBlcmhhcHMgICAgYWRkaW5nICAg IHNvbWV0aGluZyAgICBhbG9uZyAgICB0aGUgICAgbGluZXMgICAgb2Y6DQo+IiAgICBUaGUgICAg SUVURiAgICBMb3cgICAgRXh0cmEgICAgRGVsYXkgICAgQmFja2dyb3VuZCAgICBUcmFuc3BvcnQg ICAgKExFREJBVCkgICAgDQo+V29ya2luZyAgICBHcm91cCAgICBpcyAgICBmb2N1c2luZyAgICBv biAgICBicm9hZGx5ICAgIGFwcGxpY2FibGUgICAgdGVjaG5pcXVlcyAgICANCj50aGF0ICAgIGFs bG93ICAgIGxhcmdlICAgIGFtb3VudHMgICAgb2YgICAgZGF0YSAgICB0byAgICBiZSAgICBjb25z aXN0ZW50bHkgICAgDQo+dHJhbnNtaXR0ZWQgICAgd2l0aG91dCAgICBzdWJzdGFudGlhbGx5ICAg IGFmZmVjdGluZyAgICB0aGUgICAgZGVsYXlzICAgIA0KPmV4cGVyaWVuY2VkICAgIGJ5ICAgIG90 aGVyICAgIHVzZXJzICAgIGFuZCAgICBhcHBsaWNhdGlvbnMuICAgIEl0ICAgIGlzICAgIGV4cGVj dGVkDQoNCj50aGF0ICAgIHNvbWUgICAgUDJQICAgIGFwcGxpY2F0aW9ucyAgICB3b3VsZCAgICBz dGFydCAgICB1c2luZyAgICBzdWNoDQp0ZWNobmlxdWVzLCAgICANCj50aGVyZWJ5ICAgIHNvbWV3 aGF0ICAgIGFsbGV2aWF0aW5nICAgIHRoZSAgICBwZXJjZWl2YWJsZSAgICBpbXBhY3QgICAgKGF0 DQpsZWFzdCAgICANCj5vbiAgICBvdGhlciAgICBhcHBsaWNhdGlvbnMpICAgIG9mICAgIHRoZWly ICAgIGhpZ2ggICAgdm9sdW1lICAgIHRyYWZmaWMgICAgLg0KSG93ZXZlciwgICAgDQo+c3VjaCAg ICB0ZWNobmlxdWVzICAgIGRvICAgIG5vdCAgICByZW1vdmUgICAgYWxsICAgIGluZWZmaWNpZW5j aWVzLCAgICBzdWNoICAgIGFzICAgIA0KPnRob3NlICAgIGFzc29jaWF0ZWQgICAgd2l0aCAgICB0 cmFmZmljICAgIGJlaW5nICAgIHNlbnQgICAgdXBzdHJlYW0gICAgYXMgICAgbWFueSAgICANCj50 aW1lcyAgICBhcyAgICB0aGVyZSAgICBhcmUgICAgcmVtb3RlICAgIHBlZXJzICAgIGludGVyZXN0 ZWQgICAgaW4gICAgZ2V0dGluZyAgICB0aGUNCg0KPmNvcnJlc3BvbmRpbmcgICAgaW5mb3JtYXRp b24uIg0KPg0KDQpJICAgIGFncmVlICAgIHdpdGggICAgd2hhdCAgICB5b3UgICAgc2FpZCAgICBo ZXJlLiAgICBCdXQgICAgTEVEQkFUICAgIGlzICAgIG5vdCAgICBzbw0KcmVsZXZhbnQgICAgdG8g ICAgREVDQURFICAgIGFzDQpBTFRPLiAgICBBTFRPICAgIGNhbiAgICByZWR1Y2UgICAgdGhlICAg IGJhY2tib25lICAgIHRyYWZmaWMgICAgb2YgICAgSVNQJ3MgICAgbmV0d29yaw0KYnkgICAgZG8g ICAgYmV0dGVyDQpwZWVyICAgIHNlbGVjdGlvbiwgICAgd2hpbGUgICAgREVDQURFICAgIGNhbiAg ICBzYXZlICAgIG11Y2ggICAgb2YgICAgeW91ciAgICB1cGxpbmsNCmJhbmR3aWR0aCAgICBieQ0K cHV0dGluZyAgICB5b3VyICAgIGNvbnRlbnRzICAgIGludG8gICAgbmV0d29yayAgICBhbmQgICAg YWxsb3dpbmcgICAgb3RoZXJzICAgIHRvDQpkb3dubG9hZCAgICBmcm9tDQp0aGVyZSAgICAobmVl ZCAgICBzdGFuZGFyZCAgICByZXNvdXJjZSAgICBjb250cm9sKS4gICAgQnkgICAgcHV0dGluZyAg ICB0aGUNCmNvbnRlbnRzICAgIGludG8NCm5ldHdvcmssICAgIFAyUCAgICBhcHBsaWNhdGlvbnMg ICAgY2FuICAgIGFsc28gICAgaW1wcm92ZSAgICB0aGUgICAgYXZhaWxhYmlsaXR5DQpvZiAgICB0 aGUgICAgY29udGVudC4NCkxFREJBVCAgICBmb2N1c2VzICAgIG9uICAgIHRoZSAgICB0ZWNobmlx dWVzICAgIHRoYXQgICAgd2lsbCAgICBhbGxldmlhdGUgICAgdGhlDQppbXBhY3QgICAgYW1vbmcN CnRyYW5zcG9ydCAgICBmb3IgICAgZGlmZmVyZW50ICAgIGFwcGxpY2F0aW9ucy4gICAgSXQgICAg aXMgICAgYSAgICBsaXR0bGUNCmRpZmZlcmVudC4NCg0KPg0KPiogICAgc2VjdGlvbiAgICAzLjE6 DQo+VGhlICAgIGN1cnJlbnQgICAgdGV4dCAgICBkaXNjdXNzZXMgICAgaW5lZmZpY2llbmNpZXMg ICAgaW4gICAgdGVybXMgICAgb2YNCmFjY2VzcyAgICANCj5uZXR3b3JrICAgIGJhbmR3aWR0aCAg ICBiZWluZyAgICBlZmZlY3RpdmVseSAgICB3YXN0ZWQgICAgZnJvbSAgICB0aGUNCnZpZXdwb2lu dCAgICANCj5vZiAgICB0aGUgICAgbmV0d29yayAgICBvcGVyYXRvci4gICAgUGVyaGFwcyAgICBp dCAgICB3b3VsZCAgICBhbHNvICAgIGJlICAgIHdvcnRoDQptYWtpbmcgICAgDQo+ZXhwbGljaXQg ICAgdGhlICAgIGNvbnNlcXVlbmNlcyAgICBmcm9tICAgIHRoZSAgICBQMlAgICAgYXBwbGljYXRp b25zDQp2aWV3cG9pbnQgICAgDQo+aS5lLiAgICBsaWtlbHkgICAgbG9uZ2VyICAgIHRpbWUgICAg dG8gICAgcmV0cmlldmUgICAgY29tcGxldGUgICAgY29udGVudCAgICBhcw0Kd2VsbCAgICANCj5h cyAgICBsaWtlbHkgICAgaGlnaGVyICAgIGxhdGVuY3kgICAgZm9yICAgIHNvbWUgICAgcmVhbCAg ICB0aW1lICAgIGFwcGxpY2F0aW9ucw0KKGUuZy4gICAgUFBTUCkuDQo+DQoNCkdvb2QgICAgcG9p bnQuICAgIA0KDQo+KiAgICBzZWN0aW9uICAgIDQ6DQo+Ik5vdGUgICAgdGhhdCAgICBERUNBREUg ICAgaXMgICAgaW5kZXBlbmRlbnQgICAgb2YgICAgY3VycmVudCAgICBJRVRGICAgIHdvcmsgICAg b24NClAyUCwgICAgDQo+ZS5nLiAgICBQMlBTSVAsICAgIEFMVE8sICAgIFBQU1AuICAgICAgICBG b3IgICAgZXhhbXBsZSwgICAgcGVlcnMgICAgZGlzY292ZXJlZCAgICBieQ0KDQo+ZWl0aGVyICAg IFJFTE9BRCAgICBvciAgICBBTFRPICAgIGNhbiAgICBhbGwgICAgdXNlICAgIERFQ0FERSAgICB0 byAgICBzaGFyZSAgICBkYXRhLg0KDQo+REVDQURFICAgIHdpbGwgICAgZm9jdXMgICAgb24gICAg dGhlICAgICAgICBwcm9ibGVtcyAgICBvZiAgICBQMlAgICAgYXBwbGljYXRpb25zLCAgICANCj5h bHRob3VnaCAgICB0aGUgICAgc29sdXRpb24gICAgbWlnaHQgICAgYmUgICAgdXNlZCAgICBpbiAg ICBvdGhlciAgICBjb250ZXh0LiINCj4NCj5UaGUgICAgcmVsYXRpb25zaGlwICAgIGJldHdlZW4g ICAgREVDQURFICAgIGFuZCAgICBQUFNQICAgIGRlc2VydmVzICAgIA0KPmNsYXJpZmljYXRpb24u ICAgIEluICAgIHBhcnRpY3VsYXIsICAgIGJlY2F1c2UgICAgdGhlICAgIFBQMlAgICAgcHJvYmxl bSAgICANCj5zdGF0ZW1lbnQgICAgZG9jdW1lbnQgICAgKGRyYWZ0LXpoYW5nLXBwc3AtcHJvYmxl bS1zdGF0ZW1lbnQtMDUpOg0KPiAgKiAgICBpbiAgICBpdHMgICAgc2VjdGlvbiAgICA0LjIgICAg OiAgICBkZXNjcmliZXMgICAgRWRnZSAgICBDYWNoZXMgICAgYXMgICAgb25lICAgIG9mDQoNCj50 aGUgICAgbW90aXZhdGlvbnMgICAgZm9yICAgIGRldmVsb3BpbmcgICAgUFBTUCAgICBzdGFuZGFy ZHMgICAgcHJvdG9jb2xzDQo+ICAqICAgIGluICAgIGl0cyAgICBzZWN0aW9uICAgIDcuMSAgICA6 ICAgIGRlc2NyaWJlcyAgICBhICAgIFBQU1AgICAgdXNlICAgIGNhc2UgICAgd2l0aCAgICANCj5p bi1uZXR3b3JrICAgIENETiAgICBub2RlcyAgICBmb3IgICAgZW5oYW5jZWQgICAgUDJQICAgIHN0 cmVhbWluZy4NCj4NCg0KREVDQURFICAgIGlzICAgIHF1aXRlICAgIGRpZmZlcmVudCAgICBmcm9t ICAgIFBQU1AgICAgd2hpbGUgICAgdGhlbiAgICBjYW4NCmNvbGxhYm9yYXRlICAgIGluICAgIGEg ICAgc3lzdGVtLg0KUDJQICAgIHN0cmVhbWluZyAgICBhcHBsaWNhdGlvbnMgICAgKGUuZy4gICAg dGhvc2UgICAgd2hvICAgIHVzZSAgICBQUFNQDQpwcm90b2NvbCkgICAgY2FuICAgIHVzZSAgICBE RUNBREUNCnRvICAgIGRpc3RyaWJ1dGUgICAgdGhlaXIgICAgc2VydmljZXMuICAgIERFQ0FERSAg ICBpcyAgICBtb3JlICAgIGdlbmVyaWMsICAgIGFuZA0KZm9jdWVzICAgIG9uICAgIHRoZQ0Kc3Rh bmRhcmQgICAgaW50ZXJmYWNlICAgIGJldHdlZW4gICAgUDJQICAgIGNsaWVudCAgICBhbmQgICAg dGhlICAgIGluLW5ldHdvcmsNCnN0b3JhZ2UoZXNwLg0KcmVzb3VyY2UgICAgY29udHJvbCkuICAg IFRoZSAgICBwdXJwb3NlICAgIG9mICAgIGV4aXN0aW5nICAgIFAyUCAgICBjYWNoZXMgICAgYXJl DQpnb29kICAgIGFuZCAgICB0aGV5ICAgIGFyZQ0KYmVuZWZpY2lhbCAgICB0byAgICBib3RoICAg IElTUHMgICAgYW5kICAgIFAyUCAgICBhcHBsaWNhdGlvbnMsICAgIGJ1dCAgICB0aGV5ICAgIGhh dmUNCnRvICAgIHN1cHBvcnQgICAgYSAgICBsb3QNCm9mICAgIG9uLWV2b2x2aW5nICAgIFAyUCAg ICBhcHBsaWNhdGlvbiAgICBwcm90b2NvbHMuICAgIERFQ0FERSAgICB3aWxsICAgIGFsbG93DQpQ MlAgICAgYXBwbGljYXRpb25zDQp1c2VycyAgICB0byAgICB1c2UgICAgdGhlaXIgICAgaW4tbmV0 d29yayAgICBzdG9yYWdlICAgIGFuZCAgICBzaGFyZSAgICB0aGVpcg0KaW4tbmV0d29yayAgICBy ZXNvdXJjZXMNCmluICAgIGEgICAgc3RhbmRhcmQgICAgd2F5LCAgICBzbyAgICBhcyAgICB0byAg ICByZWR1Y2UgICAgdGhlICAgIGNvbXBsZXhpdHkgICAgb2YNCmV4aXN0aW5nICAgIHAycCAgICBj YWNoZSAgICBhbmQNCmFsbG93ICAgIGJldHRlciAgICBpbnRlZ3JhdGlvbiAgICBvZiAgICBwMnAg ICAgcG9saWNpZXMuDQoNCg0KPkkgICAgdGhpbmsgICAgREVDQURFICAgIGFuZCAgICBQUDJQICAg IG1heSAgICBib3RoICAgIGNvbnRyaWJ1dGUgICAgaW5kZXBlbmRlbnRseSwNCmFuZCAgICANCj5w b3NzaWJseSAgICBzaW11bHRhbmVvdXNseSwgICAgdG8gICAgbWFraW5nICAgIGNvbnRlbnQgICAg YXZhaWxhYmxlICAgIGNsb3Nlcg0KdG8gICAgDQo+cGVlcnMuICAgIEZvciAgICBleGFtcGxlLCAg ICBJICAgIGNhbiAgICBwaWN0dXJlICAgIHRoZSAgICBmb2xsb3dpbmcgICAgc2l0dWF0aW9ucw0K Zm9yICAgIA0KPlBQU1AgICAgYW5kICAgIERFQ0FERSAgICBjb2V4aXN0ZW5zZToNCj4gICogICAg YSAgICBnaXZlbiAgICBuZXR3b3JrICAgIHN1cHBvcnRzICAgIERFQ0FERSAgICBpbi1uZXR3b3Jr ICAgIGNhY2hpbmcsICAgIA0KPmFuZCAgICBpdHMgICAgQ0ROICAgIG5vZGVzICAgIGRvICAgIG5v dCAgICBwYXJ0aWNpcGF0ZSAgICBhcyAgICBQUFNQICAgIFBlZXJzICAgIGZvciAgICBhDQpnaXZl biAgICANCj4ic3RyZWFtIiAgICAoZS5nLiAgICBzYXkgICAgYmVjYXVzZSAgICBubyAgICBDRE4g ICAgYXJyYW5nZW1lbnQgICAgaGFzICAgIGJlZW4gICAgcHV0DQppbiAgICANCj5wbGFjZSAgICBi ZXR3ZWVuICAgIHRoZSAgICBDb250ZW50ICAgIFByb3ZpZGVyICAgIGFuZCAgICB0aGUgICAgY29u c2lkZXJlZA0KbmV0d29yayAgICANCj5wcm92aWRlcikuICAgIEluICAgIHRoYXQgICAgY2FzZSwg ICAgUFBTUCAgICBQZWVycyAgICB3aWxsICAgIGFsbCAgICBiZSAgICAib2ZmLW5ldCINCmJ1dCAg ICANCj53aWxsICAgIGJlICAgIGFibGUgICAgdG8gICAgdXNlICAgIERFQ0FERSAgICBpbi1uZXR3 b3JrICAgIGNhY2hpbmcgICAgdG8gICAgZXhjaGFuZ2UNCmNodW5rcy4gICAgKCopDQo+ICAqICAg IGEgICAgZ2l2ZW4gICAgbmV0d29yayAgICBkb2VzICAgIG5vdCAgICBzdXBwb3J0ICAgIERFQ0FE RSAgICBpbi1uZXR3b3JrICAgIA0KPmNhY2hpbmcsICAgIGFuZCAgICAoc29tZSAgICBvZikgICAg aXRzICAgIENETiAgICBub2RlcyAgICBwYXJ0aWNpcGF0ZSAgICBhcyAgICBQUFNQDQpQZWVycyAg ICANCj5mb3IgICAgYSAgICBnaXZlbiAgICAic3RyZWFtIiAgICAoZS5nLiAgICBzYXkgICAgYmVj YXVzZSAgICBhbiAgICBhcnJhbmdlbWVudCAgICBoYXMNCmJlZW4gICAgDQo+cHV0ICAgIGluICAg IHBsYWNlICAgIGJldHdlZW4gICAgdGhlICAgIENvbnRlbnQgICAgUHJvdmlkZXIgICAgYW5kICAg IHRoZQ0KY29uc2lkZXJlZCAgICANCj5uZXR3b3JrICAgIHByb3ZpZGVyKS4gICAgSW4gICAgdGhh dCAgICBjYXNlLCAgICB0aGUgICAgQ0ROICAgIG5vZGVzICAgIHdpbGwgICAgDQo+cGFydGljaXBh dGUgICAgYXMgICAgaW4tbmV0d29yayAgICBQUFNQICAgIFBlZXJzLiAgICBUaGUgICAgb2ZmLW5l dCAgICBQUDJQDQpQZWVycyAgICANCj4oaWUgICAgZW5kdXNlcnMpICAgIHdpbGwgICAgYmUgICAg YWJsZSAgICB0byAgICBnZXQgICAgY2h1bmtzICAgIGZyb20gICAgdGhlDQppbi1uZXR3b3JrICAg IA0KPkNETiAgICBub2RlcyAgICAodXNpbmcgICAgUFAyUCAgICBwcm90b2NvbHMgICAgd2l0aCAg ICB0aGUgICAgQ0ROICAgIG5vZGVzKS4NCj4gICogICAgYSAgICBnaXZlbiAgICBuZXR3b3JrICAg IHN1cHBvcnRzICAgIERFQ0FERSAgICBpbi1uZXR3b3JrICAgIGNhY2hpbmcsICAgIA0KPmFuZCAg ICAoc29tZSAgICBvZikgICAgaXRzICAgIENETiAgICBub2RlcyAgICBwYXJ0aWNpcGF0ZSAgICBh cyAgICBQUFNQICAgIFBlZXJzICAgIGZvcg0KYSAgICANCj5naXZlbiAgICAic3RyZWFtIiAgICAo ZS5nLiAgICBzYXkgICAgYmVjYXVzZSAgICBhbiAgICBhcnJhbmdlbWVudCAgICBoYXMgICAgYmVl bg0KcHV0ICAgIA0KPmluICAgIHBsYWNlICAgIGJldHdlZW4gICAgdGhlICAgIENvbnRlbnQgICAg UHJvdmlkZXIgICAgYW5kICAgIHRoZSAgICBjb25zaWRlcmVkICAgIA0KPm5ldHdvcmsgICAgcHJv dmlkZXIpLiAgICBJbiAgICB0aGF0ICAgIGNhc2UsICAgIHRoZSAgICBDRE4gICAgbm9kZXMgICAg d2lsbCAgICANCj5wYXJ0aWNpcGF0ZSAgICBhcyAgICBpbi1uZXR3b3JrICAgIFBQU1AgICAgUGVl cnMuICAgIFRoZSAgICBvZmYtbmV0ICAgIFBQMlANClBlZXJzICAgIA0KPihpZSAgICBlbmR1c2Vy cykgICAgd2lsbCAgICBiZSAgICBhYmxlICAgIHRvICAgIGdldCAgICBjaHVua3MgICAgZnJvbSAg ICB0aGUNCmluLW5ldHdvcmsgICAgDQo+Q0ROICAgIG5vZGVzICAgICh1c2luZyAgICBQUDJQICAg IHByb3RvY29scyAgICB3aXRoICAgIHRoZSAgICBDRE4gICAgbm9kZXMpICAgICAgICBfYXMNCndl bGwgICAgDQo+YXNfICAgICAgICBiZSAgICBhYmxlICAgIHRvICAgIGdldCAgICBjaHVua3MgICAg ZnJvbSAgICBERUNBREUgICAgaW4tbmV0d29yayAgICBDYWNoaW5nDQoNCj5wb3B1bGF0ZWQgICAg KHVzaW5nICAgIERFQ0FERSAgICBwcm90b2NvbHMpICAgIGJ5ICAgIFBQU1AgICAgUGVlcnMgICAg KGJvdGgNCm9mZi1uZXQgICAgDQo+ZW5kLXVzZXJzICAgIGFuZCAgICBpbi1uZXR3b3JrICAgIENE TiAgICBOb2RlcykuDQo+DQo+KEZvciAgICBzaW1wbGljaXR5ICAgIEkgICAgZGlzY3Vzc2VkICAg IHRoZSAgICB1c2UgICAgb2YgICAgREVDQURFICAgIGFuZCAgICBQUFNQDQpQZWVyaW5nICAgIA0K PmluICAgIHRoZSAgICBzYW1lICAgIHNpbmdsZSAgICBuZXR3b3JrLCAgICBidXQgICAgdGhvc2Ug ICAgY291bGQgICAgaGFwcGVuICAgIGluICAgIA0KPmRpZmZlcmVudCAgICBuZXR3b3JrcyAgICBh bmQgICAgc2FtZSAgICB3b3VsZCAgICBhcHBseSkuDQo+DQo+KCopICAgIGEgICAgcGFydGljdWxh ciAgICBjYXNlICAgIG9mICAgIHRoYXQgICAgaXMgICAgd2hlbiAgICB0aGUgICAgQ29udGVudA0K UHVibGlzaGVyICAgIA0KPmJlaGF2ZXMgICAgYXMgICAgYSAgICBQZWVyICAgIGFuZCAgICB1c2Vz ICAgIERFQ0FERSAgICB0byAgICBwb3B1bGF0ZSAgICBpbi1uZXR3b3JrICAgIA0KPmNvbnRlbnQg ICAgYXMgICAgZGlzY3Vzc2VkICAgIGluICAgIHNlY3Rpb24gICAgNS4yICAgIG9mICAgIERFQ0FE RSAgICBwcm9ibGVtDQpzdGF0ZW1lbnQuDQo+DQoNClRoYW5rICAgIHlvdSAgICBmb3IgICAgZ29v ZCAgICBleGFtcGxlczogICAgKSAgICANCg0KDQo+SXMgICAgdGhpcyAgICBob3cgICAgeW91ICAg IGFsc28gICAgc2VlICAgIERFQ0FERSAgICBhbmQgICAgUFBTUCAgICByZWxhdGU/ICAgIGNhbg0K dGhpcyAgICBiZSAgICANCj5leHBsaWNpdGx5ICAgIGRpc2N1c3NlZD8NCj4NCg0KV2UgICAgY2Fu ICAgIHJlZ2FyZCAgICBQUFNQICAgIGFzICAgIGEgICAgc3BlY2lmaWMgICAgcHJvdG9jb2wgICAg b2YgICAgYSAgICBzdHJlYW1pbmcNCmFwcGxpY2F0aW9uLCAgICB3aGljaA0KY291bGQgICAgdXNl ICAgIERFQ0FERSAgICBqdXN0ICAgIGxpa2UgICAgb3RoZXIgICAgcDJwICAgIGFwcGxpY2F0aW9u cy4NCg0KDQo+KiAgICBzZWN0aW9uICAgIDQuMjoNCj53b3VsZCAgICBiZSAgICB3b3J0aCAgICBj bGFyaWZ5aW5nICAgIHdobyAgICBjb250cm9scyAgICB0aGUgICAgYXV0aG9yaXphdGlvbi4NCkF0 ICAgIA0KPmxlYXN0LCAgICBvbmUgICAgY2FzZSAgICBpcyAgICB0aGF0ICAgIGF1dGhvcml6YXRp b24gICAgaXMgICAgY29udHJvbGxlZCAgICBieSAgICB0aGUNCg0KPkRFQ0FERSAgICB1c2VyICAg IHRoYXQgICAgcGxhY2VzICAgIHRoZSAgICBjb250ZW50ICAgIGluICAgIHRoZSAgICBjYWNoZS4N Cj4NCg0KWWVzLiAgICBUaGUgICAgdXNlciAgICBjYW4gICAgYXV0aG9yaXplICAgIG90aGVycyAg ICB0byAgICBhY2Nlc3MgICAgIml0cyINCmluLW5ldHdvcmsgICAgc3RvcmFnZS4NCg0KPg0KPiog ICAgRmlndXJlcyAgICAyLCAgICAzLCAgICA0ICAgIGFuZCAgICA1Og0KPkkgICAgc3VnZ2VzdCAg ICB5b3UgICAgYWxzbyAgICBpbGx1c3RyYXRlICAgIHRoZSAgICBhY3R1YWwgICAgdHJhbnNmZXIg ICAgb2YgICAgZGF0YQ0KKGluICAgIA0KPmFkZGl0aW9uICAgIHRvICAgIHRoZSAgICBERUNBREUg ICAgcmVxdWVzdHMpLiAgICBJdCAgICBpcyAgICBkb25lICAgIGluICAgIEZpZyAgICA1DQpidXQg ICAgbm90ICAgIA0KPmluICAgIHByZXZpb3VzICAgIG9uZXMuICAgIGFsc28gICAgSSAgICB0aGlu ayAgICBpdCAgICB3aWxsICAgIG1ha2UgICAgc2VxdWVudGlhbGl0eQ0KY2xlYXJlci4NCj5Gb3Ig ICAgZXhhbXBsZSAgICBpbiAgICBGaWcgICAgMiwgICAgdGhlICAgIGRhdGEgICAgdHJhbnNmZXIg ICAgZnJvbSAgICBTYiAgICB0byAgICBCDQp3b3VsZCAgICBub3QgICAgDQo+aGFwcGVuICAgIHJp Z2h0ICAgIGFmdGVyICAgIHN0ZXAgICAgMyAgICAoIjMgICAgSUFQICAgIGdldCIpOyAgICBpdCAg ICB3b3VsZCAgICBoYXBwZW4NCmFmdGVyICAgIA0KPmEgICAgZGF0YSAgICB0cmFuc2ZlciAgICBm cm9tICAgIFNhICAgIHRvICAgIFNiICAgICwgICAgd2hpY2ggICAgd291bGQgICAgaGFwcGVuICAg IGFmdGVyDQoiNCAgICANCj5JQVAgICAgZ2V0IiAgICBmcm9tICAgIFNiICAgIHRvICAgIFNhLg0K Pg0KDQpXZSAgICB3aWxsICAgIGFkZCAgICBsaW5lcyAgICB0byAgICBpbGx1c3RyYXRlICAgIHRo ZSAgICBkYXRhICAgIHRyYW5zZmVyOiAgICApDQoNCj4qICAgIEZpZ3VyZSAgICA0Og0KPkl0ICAg IG1heSAgICBiZSAgICBtb3JlICAgIGludHVpdGl2ZSAgICB0byAgICBzd2FwICAgIHRoZSAgICBv cmRlciAgICBvZiAgICBzdGVwICAgIDINCmFuZCAgICAzICAgIChpZSAgICANCj5zaG93ICAgIEEg ICAgc3RvcmluZyAgICB0aGUgICAgb2JqZWN0ICAgIGluICAgIFNiICAgIGJlZm9yZSAgICBBICAg IHJlc3BvbmRzICAgIHRvICAgIEIpLg0KPg0KSXQncyAgICBhICAgIGxpdHRsZSAgICB0cmlja3kg ICAgaGVyZSAgICBhbmQgICAgUDJQICAgIGFwcGxpY2F0aW9ucyAgICBjYW4gICAgdXNlDQpkaWZm ZXJlbnQgICAgd2F5cyAgICB0byAgICBkbw0KaXQuICAgIFdoZW4gICAgQSAgICBnZXRzICAgIHRo ZSAgICByZXF1ZXN0ICAgIHRvICAgIHN0b3JlICAgIG9iamVjdCAgICB0byAgICBTYiwgICAgaXQN CmNhbiAgICBzaW1wbHkgICAgcmVwbHkgICAgd2l0aA0KIk9rYXkiLCAgICBhbmQgICAgdGhlbiAg ICBkbyAgICB0aGUgICAgc3RvcmUgICAgb3BlcmF0aW9uLiAgICBBbHNvICAgIGl0ICAgIGNhbiAg ICBzdGFydA0KdG8gICAgc3RvcmUgICAgdGhlDQpvYmplY3QgICAgdG8gICAgU2IgICAgYW5kICAg IHRoZW4gICAgcmVwbHkgICAgdG8gICAgQiAgICB3aXRoICAgIGEgICAgbWVzc2FnZSAgICAiICAg IEkNCmhhdmUgICAgc3RhcnRlZCAgICB0bw0KdHJhbnNmZXIuLi4iLiAgICAgICAgDQoNCg0KVGhh bmtzLA0KSGFpYmluDQoNCg0KPg0KPkhvcGUgICAgdGhhdCAgICBoZWxwcy4NCj4NCj5GcmFuY29p cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ZGVjYWRlICAgIG1haWxpbmcgICAgbGlzdA0KPmRlY2FkZUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlDQo+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkZWNhZGUgICAgbWFpbGluZyAgICBsaXN0 DQpkZWNhZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGVjYWRlDQo= --=====003_Dragon636646623785_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Sure.
 
BR
Yunfei
 
zhangyunfei=
2009-11-23
=B7=A2=BC=FE=C8=CB=A3=BA Song=20 Haibin
=B7=A2=CB=CD=CA=B1=BC=E4= =A3=BA=20 2009-11-23 15:33:20
=CA=D5=BC=FE=C8=CB=A3=BA 'zhangyunfei';=20 'Francois Le Faucheur'; decade@ietf.org
=B3=AD=CB=CD=A3=BA
=D6=F7=CC=E2=A3=BA RE: Re: [decade]=20 Comments on draft-song-decade-problem-statement
 
Yunfei,
 
Thanks  for  your  reply.  I  agree  wit= h=20  your  analysis  here.
 
>        1)Motivation:
>                   &n= bsp;=20  PPSP,  operator/ISP  or  other  vendors  to =  launch  p2p  streaming
service;  
>                   &n= bsp;=20  DECADE,  operator/ISP  to  decrease  traffic=20  pressure.The  service  is
not  run  by  opertor/ISP.
 
Reducing  traffic,  especially  the  last  mi= le=20  uplink  is  one  important
motivation.  I  think  here  you  use  t= he=20  word  "service"  to  mean  applications
actually.              
 
Haibin  
 
 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
 
From:  zhangyunfei  [mailto:zhangyunfei@chinamobile.com]=20  
Sent:  Monday,  November  23,  2009  12:05=20  PM
To:  Song  Haibin;  'Francois  Le  Faucheur';= =20  decade@ietf.org
Subject:  Re:  Re:  [decade]  Comments  on=20  draft-song-decade-problem-statement
 
 
 
Hi,
 
       It  seems  great  that=20  Francois  has  given  us  a  clearer=20  picture  on
the  usage  of  PPSP  and  DECADE.Thanks &nbs= p;a=20  lot.
       I  would  like  to  cla= rify=20  that  although  both  PPSP  and  DECADE=20  have
an  edge  caches  usages,  they  have=20  several  noticeable  differences:
       1)Motivation:
                    =  PPSP,  operator/ISP  or  other  vendors  to =  launch  p2p
streaming  service;  
                    =  DECADE,  operator/ISP  to  decrease  traffic=20  pressure.The
service  is  not  run  by  opertor/ISP.
             
 
 2)Task:  
                 =20  PPSP,unifying  peer/tracker  protocols  both  for= =20  CDN  and
common  peers.  CDN  as  superpeers  equippin= g=20  PPSP  protocols.PPSP  protocols  are
p2p  protocols.
                 =20  DECADE,creating  peer/non-peer  client  to  CDN=20  access
protocol,  which  is  not  a  P2P  proto= col=20  itself.  Peer/client  needs  to  update  to<= /DIV>
support  DECADE  protocol.
     3)Scope:  PPSP,  p2p  streaming=20  senarios;  DECADE,  p2p  data-intensive
senarios;
     4)Purpose:
               PPSP:efficient =  information  exchange  between  peers
               DECADE:peer/cli= ent=20  and  cache  command  to  ask  caches=20  to
perform  corresponding  actions
       In  a  word,  PPSP  and= =20  DECADE  may  occur  in  the  same=20  senario,p2p
streaming  while  their  functionalities  are=20  quite  different.
 
BR
Yunfei
 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
 
zhangyunfei
2009-11-23
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
 
=B7=A2=BC=FE=C8=CB=A3=BA  Song  Haibin
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA  2009-11-23  11:19:32
=CA=D5=BC=FE=C8=CB=A3=BA  'Francois  Le  Faucheur'; &nb= sp;decade@ietf.org
=B3=AD=CB=CD=A3=BA  
=D6=F7=CC=E2=A3=BA  Re:  [decade]  Comments  on=20  draft-song-decade-problem-statement
 
Hi    Francois,
 
Good    comments.    
     
 
>-----Original    Message-----
>From:    decade-bounces@ietf.org  =20  [mailto:decade-bounces@ietf.org]    
>On    Behalf    Of    Francois  = ;=20  Le    Faucheur
>Sent:    Friday,    November    20, =    2009    10:28    PM
>To:    decade@ietf.org
>Subject:    [decade]    Comments  =20  on
draft-song-decade-problem-statement
>
>Hello,
>
>Here    are    some  =20  comments/suggestions    re
decade-problem-statement:
>
>*    section    3.1:
>"Recently,    the    IETF    Applica= tion=20    Layer    Traffic    Optimization  =20  
>(ALTO)    Working    Group    is &nb= sp;=20  formed    to    provide    P2P  =20  applications
 
>with    network    information    so= =20    that    they    can    perform &= nbsp;=20  
>better-than-random    initial    peer  =20  selection    
>[I-D.ietf-alto-problem-statement].    "
>I    believe    ALTO    can  =20  be    used    for    peer  =20  selection    at    any
time    (ie    
>not    just    initially).
 
It    is    in    paragraph    = ;4=20    of    "Description    of    Work= ing=20    Group"    in
ALTO    WG    charter.
You    are    right    that    = ;P2P=20    applications    can    do    the= =20    peer
selection    with    the    help
of    ALTO    server    at    = any=20    time.    But        I  =20  think    here    "initial
peer    selection"    means
it    (ALTO)    is    the    f= irst=20    step    for    peer    selection= ,=20    and    after
that    P2P
application    users    can    do  = =20  another    round    of    peer  =20  selection
based    on    other
things,    such    like    chunk   =  availability(e.g.    "rarest    piece
first")    and    per    pair
connection    quality.
 
>The    information    provided    by= =20    ALTO    is    not  =20  necessarily
"network    
>information"    (e.g.    could    be= =20    just    a    list    of  =20  selected
peers).
 
The    peer    selection    is  =20  mainly    based    on    network  = =20  cost
information.    But    you    are
right,    we    should    delete   =  the    word    "network"    here.
 
>Also,    some    P2P    Apps   =  use    other    criteria    than  = =20  pure    random,
but    
>still    not    necessarily  =20  optimal.
>So    how    about,    something &nb= sp;=20  like:
>"The    IETF    Application    Layer= =20    Traffic    Optimization    (ALTO)  =20  
>Working    Group    specifies  =20  mechanisms    that    allow    P2P
applications    
>to    perform    selection    of &nb= sp;=20  peers    that    is    superior   =  to    random    
>selection    or    selection    base= d=20    on    information    deducted    = ;from=20    
>partial    observation  =20  [I-D.ietf-alto-problem-statement].    "
>
 
It's    okay.    I    prefer   &nbs= p;to=20    just    delete    the    word &n= bsp;=20  "network",
just    like    what    is
said    in    the    ALTO  =20  charter.
 
>
>*    section    3.1:
>"On    the    other    hand,   =  it    is    reported    that  =20  P2P    traffic    is    
>becoming    the    dominating    tra= ffic=20    on    the    access    networks =    of
some    
>networks,    reaching    as    high =    as    50-60%    at    the  = =20  down-links    and
 
>60-90%    at    the    uplinks  = ;=20  ([DCIA],    [ICNP],    [ipoque.P2P=5Fsurvey.],
 
>[P2P=5Ffile=5Fsharing]).        Consequently, =  =20  it    becomes    increasingly    
>important    to    complement    the= =20    ALTO    effort    and    reduce =    upload    
>access    traffic,    in    addition= =20    to    cross-domain    and  =20  backbone
traffic.
>"
>I    think    it    would   &nb= sp;be=20    worth    discussing    how    LE= DBAT=20    relates
to    the    above.
>Perhaps    adding    something    al= ong=20    the    lines    of:
>"    The    IETF    Low  =20  Extra    Delay    Background    Transpo= rt=20    (LEDBAT)    
>Working    Group    is    focusing &= nbsp;=20  on    broadly    applicable    techniqu= es=20    
>that    allow    large    amounts &n= bsp;=20  of    data    to    be  =20  consistently    
>transmitted    without    substantially  = =20  affecting    the    delays    
>experienced    by    other    users =    and    applications.    It    is= =20    expected
 
>that    some    P2P    applications =    would    start    using    such<= /DIV>
techniques,    
>thereby    somewhat    alleviating   &nbs= p;the=20    perceivable    impact    (at
least    
>on    other    applications)    of &= nbsp;=20  their    high    volume    traffic &nbs= p;=20  .
However,    
>such    techniques    do    not &nbs= p;=20  remove    all    inefficiencies,    suc= h=20    as    
>those    associated    with    traff= ic=20    being    sent    upstream    as =    many    
>times    as    there    are  =20  remote    peers    interested    in &nb= sp;=20  getting    the
 
>corresponding    information."
>
 
I    agree    with    what    = you=20    said    here.    But    LEDBAT &= nbsp;=20  is    not    so
relevant    to    DECADE    as
ALTO.    ALTO    can    reduce  =20  the    backbone    traffic    of  = =20  ISP's    network
by    do    better
peer    selection,    while    DECADE &n= bsp;=20  can    save    much    of    = your=20    uplink
bandwidth    by
putting    your    contents    into &nbs= p;=20  network    and    allowing    others &n= bsp;=20  to
download    from
there    (need    standard    resource &= nbsp;=20  control).    By    putting    the
contents    into
network,    P2P    applications    can &= nbsp;=20  also    improve    the    availability<= /DIV>
of    the    content.
LEDBAT    focuses    on    the  =20  techniques    that    will    alleviate= =20    the
impact    among
transport    for    different  =20  applications.    It    is    a  =20  little
different.
 
>
>*    section    3.1:
>The    current    text    discusses =    inefficiencies    in    terms  =20  of
access    
>network    bandwidth    being  =20  effectively    wasted    from    the
viewpoint    
>of    the    network    operator. &n= bsp;=20  Perhaps    it    would    also  =20  be    worth
making    
>explicit    the    consequences    f= rom=20    the    P2P    applications
viewpoint    
>i.e.    likely    longer    time &nb= sp;=20  to    retrieve    complete    content &= nbsp;=20  as
well    
>as    likely    higher    latency &n= bsp;=20  for    some    real    time  =20  applications
(e.g.    PPSP).
>
 
Good    point.    
 
>*    section    4:
>"Note    that    DECADE    is  = =20  independent    of    current    IETF &n= bsp;=20  work    on
P2P,    
>e.g.    P2PSIP,    ALTO,    PPSP. &n= bsp;=20      For    example,    peers  =20  discovered    by
 
>either    RELOAD    or    ALTO  = ;=20  can    all    use    DECADE   &nbs= p;to=20    share    data.
 
>DECADE    will    focus    on  = =20  the        problems    of    = P2P=20    applications,    
>although    the    solution    might= =20    be    used    in    other  = =20  context."
>
>The    relationship    between    DE= CADE=20    and    PPSP    deserves    
>clarification.    In    particular,  =20  because    the    PP2P    problem  = ;=20  
>statement    document  =20  (draft-zhang-ppsp-problem-statement-05):
>  *    in    its    section &nb= sp;=20  4.2    :    describes    Edge  =20  Caches    as    one    of
 
>the    motivations    for    develop= ing=20    PPSP    standards    protocols
>  *    in    its    section &nb= sp;=20  7.1    :    describes    a    = ;PPSP=20    use    case    with    
>in-network    CDN    nodes    for &n= bsp;=20  enhanced    P2P    streaming.
>
 
DECADE    is    quite    different  = ;=20  from    PPSP    while    then  =20  can
collaborate    in    a    system.
P2P    streaming    applications    (e.g= .=20    those    who    use    PPSP
protocol)    can    use    DECADE
to    distribute    their    services. &= nbsp;=20  DECADE    is    more    generic,  = =20  and
focues    on    the
standard    interface    between    P2P =    client    and    the  =20  in-network
storage(esp.
resource    control).    The    purpose =    of    existing    P2P    caches =    are
good    and    they    are
beneficial    to    both    ISPs   =  and    P2P    applications,    but &nbs= p;=20  they    have
to    support    a    lot
of    on-evolving    P2P    application =    protocols.    DECADE    will  =20  allow
P2P    applications
users    to    use    their  =20  in-network    storage    and    share &= nbsp;=20  their
in-network    resources
in    a    standard    way,    = ;so=20    as    to    reduce    the  = =20  complexity    of
existing    p2p    cache    and
allow    better    integration    of &nb= sp;=20  p2p    policies.
 
 
>I    think    DECADE    and  =20  PP2P    may    both    contribute  = ;=20  independently,
and    
>possibly    simultaneously,    to  =20  making    content    available  =20  closer
to    
>peers.    For    example,    I  = ;=20  can    picture    the    following &nbs= p;=20  situations
for    
>PPSP    and    DECADE  =20  coexistense:
>  *    a    given    network &n= bsp;=20  supports    DECADE    in-network    cac= hing,=20    
>and    its    CDN    nodes  =20  do    not    participate    as  =20  PPSP    Peers    for    a
given    
>"stream"    (e.g.    say    because =    no    CDN    arrangement    has =    been    put
in    
>place    between    the    Content &= nbsp;=20  Provider    and    the    considered
network    
>provider).    In    that    case, &n= bsp;=20  PPSP    Peers    will    all   &nb= sp;be=20    "off-net"
but    
>will    be    able    to   &nbs= p;use=20    DECADE    in-network    caching   &nb= sp;to=20    exchange
chunks.    (*)
>  *    a    given    network &n= bsp;=20  does    not    support    DECADE  = =20  in-network    
>caching,    and    (some    of) &nbs= p;=20  its    CDN    nodes    participate &nbs= p;=20  as    PPSP
Peers    
>for    a    given    "stream"  = =20  (e.g.    say    because    an  =20  arrangement    has
been    
>put    in    place    between  = =20  the    Content    Provider    and  = ;=20  the
considered    
>network    provider).    In    that =    case,    the    CDN    nodes &nb= sp;=20  will    
>participate    as    in-network    P= PSP=20    Peers.    The    off-net  =20  PP2P
Peers    
>(ie    endusers)    will    be  = ;=20  able    to    get    chunks  =20  from    the
in-network    
>CDN    nodes    (using    PP2P  = ;=20  protocols    with    the    CDN   =  nodes).
>  *    a    given    network &n= bsp;=20  supports    DECADE    in-network    cac= hing,=20    
>and    (some    of)    its  =20  CDN    nodes    participate    as  = ;=20  PPSP    Peers    for
a    
>given    "stream"    (e.g.    say &n= bsp;=20  because    an    arrangement    has &nb= sp;=20  been
put    
>in    place    between    the  = =20  Content    Provider    and    the  = ;=20  considered    
>network    provider).    In    that =    case,    the    CDN    nodes &nb= sp;=20  will    
>participate    as    in-network    P= PSP=20    Peers.    The    off-net  =20  PP2P
Peers    
>(ie    endusers)    will    be  = ;=20  able    to    get    chunks  =20  from    the
in-network    
>CDN    nodes    (using    PP2P  = ;=20  protocols    with    the    CDN   =  nodes)        =5Fas
well    
>as=5F        be    able    = ;to=20    get    chunks    from    DECADE =    in-network    Caching
 
>populated    (using    DECADE  =20  protocols)    by    PPSP    Peers  = ;=20  (both
off-net    
>end-users    and    in-network    CD= N=20    Nodes).
>
>(For    simplicity    I    discussed= =20    the    use    of    DECADE  = ;=20  and    PPSP
Peering    
>in    the    same    single  =20  network,    but    those    could  = ;=20  happen    in    
>different    networks    and    same= =20    would    apply).
>
>(*)    a    particular    case  = ;=20  of    that    is    when    t= he=20    Content
Publisher    
>behaves    as    a    Peer  =20  and    uses    DECADE    to  =20  populate    in-network    
>content    as    discussed    in &nb= sp;=20  section    5.2    of    DECADE  =20  problem
statement.
>
 
Thank    you    for    good  =20  examples:    )    
 
 
>Is    this    how    you  =20  also    see    DECADE    and  =20  PPSP    relate?    can
this    be    
>explicitly    discussed?
>
 
We    can    regard    PPSP    = ;as=20    a    specific    protocol    of =    a    streaming
application,    which
could    use    DECADE    just  =20  like    other    p2p    applications.
 
 
>*    section    4.2:
>would    be    worth    clarifying &= nbsp;=20  who    controls    the  =20  authorization.
At    
>least,    one    case    is  =20  that    authorization    is    controll= ed=20    by    the
 
>DECADE    user    that    places &nb= sp;=20  the    content    in    the  =20  cache.
>
 
Yes.    The    user    can  =20  authorize    others    to    access &nb= sp;=20  "its"
in-network    storage.
 
>
>*    Figures    2,    3,   &nbs= p;4=20    and    5:
>I    suggest    you    also  =20  illustrate    the    actual    transfer= =20    of    data
(in    
>addition    to    the    DECADE &nbs= p;=20  requests).    It    is    done  =20  in    Fig    5
but    not    
>in    previous    ones.    also &nbs= p;=20  I    think    it    will    m= ake=20    sequentiality
clearer.
>For    example    in    Fig  =20  2,    the    data    transfer  =20  from    Sb    to    B
would    not    
>happen    right    after    step &nb= sp;=20  3    ("3    IAP    get");    = it=20    would    happen
after    
>a    data    transfer    from  = =20  Sa    to    Sb    ,    which =    would    happen    after
"4    
>IAP    get"    from    Sb   &nb= sp;to=20    Sa.
>
 
We    will    add    lines    = to=20    illustrate    the    data  =20  transfer:    )
 
>*    Figure    4:
>It    may    be    more  =20  intuitive    to    swap    the  =20  order    of    step    2
and    3    (ie    
>show    A    storing    the  =20  object    in    Sb    before   &nb= sp;A=20    responds    to    B).
>
It's    a    little    tricky  =20  here    and    P2P    applications &nbs= p;=20  can    use
different    ways    to    do
it.    When    A    gets    th= e=20    request    to    store    object= =20    to    Sb,    it
can    simply    reply    with
"Okay",    and    then    do   &nbs= p;the=20    store    operation.    Also    i= t=20    can    start
to    store    the
object    to    Sb    and    t= hen=20    reply    to    B    with   =  a    message    "    I
have    started    to
transfer...".        
 
 
Thanks,
Haibin
 
 
>
>Hope    that    helps.
>
>Francois
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
>decade    mailing    list
>decade@ietf.org
>https://www.ietf.org/mailman/listinfo/decade
>
 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
decade    mailing    list
decade@ietf.org
https://www.ietf.org/mailman/listinfo/decade
--=====003_Dragon636646623785_=====-- From flefauch@cisco.com Tue Nov 24 02:02:16 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8833A68A8 for ; Tue, 24 Nov 2009 02:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] 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 AmcXfFV3i7BU for ; Tue, 24 Nov 2009 02:02:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 36C103A68F2 for ; Tue, 24 Nov 2009 02:02:13 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,277,1257120000"; d="scan'208,217";a="55075102" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2009 10:02:08 +0000 Received: from ams-flefauch-87110.cisco.com (ams-flefauch-87110.cisco.com [10.55.161.203]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAOA25DB006638; Tue, 24 Nov 2009 10:02:05 GMT References: <010801ca6bea$b6e969b0$0c0ca40a@china.huawei.com> In-Reply-To: <010801ca6bea$b6e969b0$0c0ca40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-10--570633534 Message-Id: <095DA7DA-0BA9-4EE4-9069-CB113953F1E8@cisco.com> From: Francois Le Faucheur Date: Tue, 24 Nov 2009 11:02:04 +0100 To: Song Haibin X-Mailer: Apple Mail (2.1077) Cc: decade@ietf.org Subject: Re: [decade] Comments on draft-song-decade-problem-statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 10:02:16 -0000 --Apple-Mail-10--570633534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Haibin, On 23 Nov 2009, at 04:11, Song Haibin wrote: > Hi Francois, >=20 > Good comments.=20 >=20 >=20 >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 >> On Behalf Of Francois Le Faucheur >> Sent: Friday, November 20, 2009 10:28 PM >> To: decade@ietf.org >> Subject: [decade] Comments on draft-song-decade-problem-statement >>=20 >> Hello, >>=20 >> Here are some comments/suggestions re decade-problem-statement: >>=20 >> * section 3.1: >> "Recently, the IETF Application Layer Traffic Optimization=20 >> (ALTO) Working Group is formed to provide P2P applications=20 >> with network information so that they can perform=20 >> better-than-random initial peer selection=20 >> [I-D.ietf-alto-problem-statement]. " >> I believe ALTO can be used for peer selection at any time (ie=20 >> not just initially). >=20 > It is in paragraph 4 of "Description of Working Group" in ALTO WG = charter. > You are right that P2P applications can do the peer selection with the = help > of ALTO server at any time. But I think here "initial peer selection" = means > it (ALTO) is the first step for peer selection, I see. With such a meaning of "first step" then "initial" is fine. > and after that P2P > application users can do another round of peer selection based on = other > things, such like chunk availability(e.g. "rarest piece first") and = per pair > connection quality. >=20 >> The information provided by ALTO is not necessarily "network=20 >> information" (e.g. could be just a list of selected peers). >=20 > The peer selection is mainly based on network cost information. But = you are > right, we should delete the word "network" here. >=20 >> Also, some P2P Apps use other criteria than pure random, but=20 >> still not necessarily optimal. >> So how about, something like: >> "The IETF Application Layer Traffic Optimization (ALTO)=20 >> Working Group specifies mechanisms that allow P2P applications=20 >> to perform selection of peers that is superior to random=20 >> selection or selection based on information deducted from=20 >> partial observation [I-D.ietf-alto-problem-statement]. " >>=20 >=20 > It's okay. I prefer to just delete the word "network", just like what = is > said in the ALTO charter. >=20 >>=20 >> * section 3.1: >> "On the other hand, it is reported that P2P traffic is=20 >> becoming the dominating traffic on the access networks of some=20 >> networks, reaching as high as 50-60% at the down-links and=20 >> 60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.],=20 >> [P2P_file_sharing]). Consequently, it becomes increasingly=20 >> important to complement the ALTO effort and reduce upload=20 >> access traffic, in addition to cross-domain and backbone traffic. >> " >> I think it would be worth discussing how LEDBAT relates to the above. >> Perhaps adding something along the lines of: >> " The IETF Low Extra Delay Background Transport (LEDBAT)=20 >> Working Group is focusing on broadly applicable techniques=20 >> that allow large amounts of data to be consistently=20 >> transmitted without substantially affecting the delays=20 >> experienced by other users and applications. It is expected=20 >> that some P2P applications would start using such techniques,=20 >> thereby somewhat alleviating the perceivable impact (at least=20 >> on other applications) of their high volume traffic . However,=20 >> such techniques do not remove all inefficiencies, such as=20 >> those associated with traffic being sent upstream as many=20 >> times as there are remote peers interested in getting the=20 >> corresponding information." >>=20 >=20 > I agree with what you said here. But LEDBAT is not so relevant to = DECADE as > ALTO. Right. But LEDBAT is relevant to the problem statement of DECADE. To put = it simply, inefficiencies/bandwidth-wastage is an important part of the = DECADE problem statement. And it can be argued that LEDBAT alleviates = the consequences of inefficiencies/bandwidth-wastage (certainly on other = applications). So I am saying the problem statement would benefit from = discussing LEDBAT and clarifying that the problem is still worth solving = in the presence of LEDBAT. In other words, you want to avoid someone reading the problem statement = and thinking ... well, if DECADE is all about the fact that P2P is = "reaching 50-60% at the down-links and 60-90% at the uplinks" and LEDBAT = is all about making sure that P2P operates fine when using up all = bottleneck bandwidth while other Apps operate "almost" as if P2P load = was not there, then do I really need DECADE? So I'm suggesting that you explicitly answer that question in the = problem statement. > ALTO can reduce the backbone traffic of ISP's network by do better > peer selection, while DECADE can save much of your uplink bandwidth by > putting your contents into network and allowing others to download = from > there (need standard resource control). By putting the contents into > network, P2P applications can also improve the availability of the = content. > LEDBAT focuses on the techniques that will alleviate the impact among > transport for different applications. It is a little different. >=20 >>=20 >> * section 3.1: >> The current text discusses inefficiencies in terms of access=20 >> network bandwidth being effectively wasted from the viewpoint=20 >> of the network operator. Perhaps it would also be worth making=20 >> explicit the consequences from the P2P applications viewpoint=20 >> i.e. likely longer time to retrieve complete content as well=20 >> as likely higher latency for some real time applications (e.g. PPSP). >>=20 >=20 > Good point.=20 >=20 >> * section 4: >> "Note that DECADE is independent of current IETF work on P2P,=20 >> e.g. P2PSIP, ALTO, PPSP. For example, peers discovered by=20 >> either RELOAD or ALTO can all use DECADE to share data. =20 >> DECADE will focus on the problems of P2P applications,=20 >> although the solution might be used in other context." >>=20 >> The relationship between DECADE and PPSP deserves=20 >> clarification. In particular, because the PP2P problem=20 >> statement document (draft-zhang-ppsp-problem-statement-05): >> * in its section 4.2 : describes Edge Caches as one of=20 >> the motivations for developing PPSP standards protocols >> * in its section 7.1 : describes a PPSP use case with=20 >> in-network CDN nodes for enhanced P2P streaming. >>=20 >=20 > DECADE is quite different from PPSP while then can collaborate in a = system. > P2P streaming applications (e.g. those who use PPSP protocol) can use = DECADE > to distribute their services. DECADE is more generic, and focues on = the > standard interface between P2P client and the in-network storage(esp. > resource control). The purpose of existing P2P caches are good and = they are > beneficial to both ISPs and P2P applications, but they have to support = a lot > of on-evolving P2P application protocols. However PPSP is precisely proposing to facilitate this by allowing P2P = Caching using a single standard protocol (PPSP). But that is somewhat besides the point. My point here is that we = simultaneously have two problem statements (DECADE & PP2P) that propose = to standardize solution for effectively storing content in-network and = serving it to endusers (notably P2P clients). So I am suggesting that = the DECADE problem statement should acknowledge that situation, and = articulate why both flavors make sense. The input from Yunfei could also = be useful for that purpose. > DECADE will allow P2P applications > users to use their in-network storage and share their in-network = resources > in a standard way, so as to reduce the complexity of existing p2p = cache and > allow better integration of p2p policies. >=20 >=20 >> I think DECADE and PP2P may both contribute independently, and=20 >> possibly simultaneously, to making content available closer to=20 >> peers. For example, I can picture the following situations for=20 >> PPSP and DECADE coexistense: >> * a given network supports DECADE in-network caching,=20 >> and its CDN nodes do not participate as PPSP Peers for a given=20 >> "stream" (e.g. say because no CDN arrangement has been put in=20 >> place between the Content Provider and the considered network=20 >> provider). In that case, PPSP Peers will all be "off-net" but=20 >> will be able to use DECADE in-network caching to exchange chunks. (*) >> * a given network does not support DECADE in-network=20 >> caching, and (some of) its CDN nodes participate as PPSP Peers=20 >> for a given "stream" (e.g. say because an arrangement has been=20 >> put in place between the Content Provider and the considered=20 >> network provider). In that case, the CDN nodes will=20 >> participate as in-network PPSP Peers. The off-net PP2P Peers=20 >> (ie endusers) will be able to get chunks from the in-network=20 >> CDN nodes (using PP2P protocols with the CDN nodes). >> * a given network supports DECADE in-network caching,=20 >> and (some of) its CDN nodes participate as PPSP Peers for a=20 >> given "stream" (e.g. say because an arrangement has been put=20 >> in place between the Content Provider and the considered=20 >> network provider). In that case, the CDN nodes will=20 >> participate as in-network PPSP Peers. The off-net PP2P Peers=20 >> (ie endusers) will be able to get chunks from the in-network=20 >> CDN nodes (using PP2P protocols with the CDN nodes) _as well=20 >> as_ be able to get chunks from DECADE in-network Caching=20 >> populated (using DECADE protocols) by PPSP Peers (both off-net=20 >> end-users and in-network CDN Nodes). >>=20 >> (For simplicity I discussed the use of DECADE and PPSP Peering=20 >> in the same single network, but those could happen in=20 >> different networks and same would apply). >>=20 >> (*) a particular case of that is when the Content Publisher=20 >> behaves as a Peer and uses DECADE to populate in-network=20 >> content as discussed in section 5.2 of DECADE problem statement. >>=20 >=20 > Thank you for good examples: )=20 >=20 >=20 >> Is this how you also see DECADE and PPSP relate? can this be=20 >> explicitly discussed? >>=20 >=20 > We can regard PPSP as a specific protocol of a streaming application, = which > could use DECADE just like other p2p applications. agreed. >=20 >=20 >> * section 4.2: >> would be worth clarifying who controls the authorization. At=20 >> least, one case is that authorization is controlled by the=20 >> DECADE user that places the content in the cache. >>=20 >=20 > Yes. The user can authorize others to access "its" in-network storage. >=20 >>=20 >> * Figures 2, 3, 4 and 5: >> I suggest you also illustrate the actual transfer of data (in=20 >> addition to the DECADE requests). It is done in Fig 5 but not=20 >> in previous ones. also I think it will make sequentiality clearer. >> For example in Fig 2, the data transfer from Sb to B would not=20 >> happen right after step 3 ("3 IAP get"); it would happen after=20 >> a data transfer from Sa to Sb , which would happen after "4=20 >> IAP get" from Sb to Sa. >>=20 >=20 > We will add lines to illustrate the data transfer: ) >=20 >> * Figure 4: >> It may be more intuitive to swap the order of step 2 and 3 (ie=20 >> show A storing the object in Sb before A responds to B). >>=20 > It's a little tricky here and P2P applications can use different ways = to do > it. When A gets the request to store object to Sb, it can simply reply = with > "Okay", and then do the store operation. Also it can start to store = the > object to Sb and then reply to B with a message " I have started to > transfer...". =20 Yes, it could be done several ways. But the key steps will be clear = anyways when you illustrate actual data transfers. Cheers Francois >=20 >=20 > Thanks, > Haibin >=20 >=20 >>=20 >> Hope that helps. >>=20 >> Francois >>=20 >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >>=20 >=20 --Apple-Mail-10--570633534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Haibin,

On 23 Nov 2009, at 04:11, Song Haibin = wrote:

Hi Francois,

Good comments. =


-----Original = Message-----
From: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org]
On Behalf Of Francois Le = Faucheur
Sent: Friday, = November 20, 2009 10:28 PM
To: = decade@ietf.org
Subject: [decade] Comments on = draft-song-decade-problem-statement

Hello,

Here are some = comments/suggestions re = decade-problem-statement:

* section = 3.1:
"Recently, the IETF = Application Layer Traffic Optimization
(ALTO) Working Group is formed to provide P2P applications =
with network information so = that they can perform
better-than-random initial peer selection =
[I-D.ietf-alto-problem-statement]. = "
I believe ALTO can be used = for peer selection at any time (ie
not just initially).

It is in = paragraph 4 of "Description of Working Group" in ALTO WG charter.
You = are right that P2P applications can do the peer selection with the = help
of ALTO server at any time. But  I think here "initial peer = selection" means
it (ALTO) is the first step for peer selection, =

I see. With such a meaning of = "first step" then "initial" is fine.

and after that P2P
application users can do = another round of peer selection based on other
things, such like = chunk availability(e.g. "rarest piece first") and per pair
connection = quality.

The information provided by = ALTO is not necessarily "network
information" (e.g. could be just a list of selected = peers).

The peer selection is mainly based on = network cost information. But you are
right, we should delete the = word "network" here.

Also, some P2P = Apps use other criteria than pure random, but =
still not necessarily = optimal.
So how about, = something like:
"The IETF = Application Layer Traffic Optimization (ALTO) =
Working Group specifies = mechanisms that allow P2P applications
to perform selection of peers that is superior to random =
selection or selection based = on information deducted from
partial observation [I-D.ietf-alto-problem-statement]. = "


It's = okay. I prefer to just delete the word "network", just like what = is
said in the ALTO charter.


* section = 3.1:
"On the other hand, it is = reported that P2P traffic is
becoming the dominating traffic on the access networks of = some
networks, reaching as = high as 50-60% at the down-links and
60-90% at the uplinks ([DCIA], [ICNP], = [ipoque.P2P_survey.],
[P2P_file_sharing]).  Consequently, it becomes = increasingly
important to = complement the ALTO effort and reduce upload =
access traffic, in addition = to cross-domain and backbone traffic.
"
I think it = would be worth discussing how LEDBAT relates to the = above.
Perhaps adding = something along the lines of:
" = The IETF Low Extra Delay Background Transport (LEDBAT) =
Working Group is focusing on = broadly applicable techniques
that allow large amounts of data to be consistently =
transmitted without = substantially affecting the delays
experienced by other users and applications. It is = expected
that some P2P = applications would start using such techniques, =
thereby somewhat alleviating = the perceivable impact (at least
on other applications) of their high volume traffic . = However,
such techniques do = not remove all inefficiencies, such as
those associated with traffic being sent upstream as many =
times as there are remote = peers interested in getting the
corresponding information."


I agree with what you said here. But = LEDBAT is not so relevant to DECADE as
ALTO. =

Right. But LEDBAT is relevant to = the problem statement of DECADE. To put it = simply, inefficiencies/bandwidth-wastage is an important part of = the DECADE problem statement. And it can be argued that LEDBAT = alleviates the consequences of inefficiencies/bandwidth-wastage = (certainly on other applications). So I am saying the problem statement = would benefit from discussing LEDBAT and clarifying that the problem is = still worth solving in the presence of = LEDBAT.

In other words, you want to avoid = someone reading the problem statement and thinking ... well, if DECADE = is all about the fact that P2P is "reaching 50-60% at the = down-links and 60-90% at the uplinks" and LEDBAT is all about = making sure that P2P operates fine when using up all bottleneck = bandwidth while other Apps operate "almost" as if P2P load was not = there, then do I really need DECADE?
So I'm suggesting that = you explicitly answer that question in the problem = statement.

ALTO can reduce the = backbone traffic of ISP's network by do better
peer selection, while = DECADE can save much of your uplink bandwidth by
putting your = contents into network and allowing others to download from
there = (need standard resource control). By putting the contents = into
network, P2P applications can also improve the availability of = the content.
LEDBAT focuses on the techniques that will alleviate the = impact among
transport for different applications. It is a little = different.


* section = 3.1:
The current text = discusses inefficiencies in terms of access
network bandwidth being effectively wasted from the = viewpoint
of the network = operator. Perhaps it would also be worth making =
explicit the consequences = from the P2P applications viewpoint
i.e. likely longer time to retrieve complete content as = well
as likely higher latency = for some real time applications (e.g. PPSP).


Good point.

* section 4:
"Note= that DECADE is independent of current IETF work on P2P, =
e.g. P2PSIP, ALTO, PPSP. =  For example, peers discovered by
either RELOAD or ALTO can all use DECADE to share data. =  
DECADE will focus on = the  problems of P2P applications,
although the solution might be used in other = context."

The = relationship between DECADE and PPSP deserves =
clarification. In particular, = because the PP2P problem
statement document = (draft-zhang-ppsp-problem-statement-05):
= * in its section 4.2 : describes Edge Caches as one of =
the motivations for = developing PPSP standards protocols
= * in its section 7.1 : describes a PPSP use case with =
in-network CDN nodes for = enhanced P2P streaming.


DECADE is quite different from PPSP = while then can collaborate in a system.
P2P streaming applications = (e.g. those who use PPSP protocol) can use DECADE
to distribute their = services. DECADE is more generic, and focues on the
standard = interface between P2P client and the in-network storage(esp.
resource = control). The purpose of existing P2P caches are good and they = are
beneficial to both ISPs and P2P applications, but they have to = support a lot
of on-evolving P2P application protocols. =

However PPSP is precisely = proposing to facilitate this by allowing P2P Caching using a single = standard protocol (PPSP).

But that is somewhat = besides the point. My point here is that we simultaneously have two = problem statements (DECADE & PP2P) that propose to standardize = solution for effectively storing content in-network and serving it to = endusers (notably P2P clients). So I am suggesting that the DECADE = problem statement should acknowledge that situation, and articulate why = both flavors make sense. The input from Yunfei could also be useful for = that purpose.


DECADE will allow P2P applications
users to use = their in-network storage and share their in-network resources
in a = standard way, so as to reduce the complexity of existing p2p cache = and
allow better integration of p2p policies.


I think DECADE and PP2P may both contribute independently, = and
possibly simultaneously, = to making content available closer to
peers. For example, I can picture the following situations = for
PPSP and DECADE = coexistense:
* a given = network supports DECADE in-network caching,
and its CDN nodes do not participate as PPSP Peers for a = given
"stream" (e.g. say = because no CDN arrangement has been put in
place between the Content Provider and the considered = network
provider). In that = case, PPSP Peers will all be "off-net" but
will be able to use DECADE in-network caching to exchange = chunks. (*)
* a given = network does not support DECADE in-network
caching, and (some of) its CDN nodes participate as PPSP = Peers
for a given "stream" = (e.g. say because an arrangement has been
put in place between the Content Provider and the = considered
network provider). = In that case, the CDN nodes will
participate as in-network PPSP Peers. The off-net PP2P = Peers
(ie endusers) will be = able to get chunks from the in-network
CDN nodes (using PP2P protocols with the CDN = nodes).
* a given = network supports DECADE in-network caching,
and (some of) its CDN nodes participate as PPSP Peers for = a
given "stream" (e.g. say = because an arrangement has been put
in place between the Content Provider and the considered =
network provider). In that = case, the CDN nodes will
participate as in-network PPSP Peers. The off-net PP2P = Peers
(ie endusers) will be = able to get chunks from the in-network
CDN nodes (using PP2P protocols with the CDN nodes) =  _as well
as_  be = able to get chunks from DECADE in-network Caching =
populated (using DECADE = protocols) by PPSP Peers (both off-net
end-users and in-network CDN = Nodes).

(For simplicity = I discussed the use of DECADE and PPSP Peering =
in the same single network, = but those could happen in
different networks and same would = apply).

(*) a = particular case of that is when the Content Publisher =
behaves as a Peer and uses = DECADE to populate in-network
content as discussed in section 5.2 of DECADE problem = statement.


Thank you for good examples: ) =


Is this how you also see DECADE = and PPSP relate? can this be
explicitly discussed?


We can regard PPSP as a specific = protocol of a streaming application, which
could use DECADE just like = other p2p = applications.

agreed.

<= blockquote type=3D"cite">


* = section 4.2:
would be worth = clarifying who controls the authorization. At =
least, one case is that = authorization is controlled by the
DECADE user that places the content in the = cache.


Yes.= The user can authorize others to access "its" in-network = storage.


* Figures 2, 3, 4 and 5:
I suggest you also illustrate the actual transfer of data = (in
addition to the DECADE = requests). It is done in Fig 5 but not
in previous ones. also I think it will make sequentiality = clearer.
For example in Fig 2, = the data transfer from Sb to B would not
happen right after step 3 ("3 IAP get"); it would happen = after
a data transfer from Sa = to Sb , which would happen after "4
IAP get" from Sb to Sa.


We will add lines to illustrate the = data transfer: )

* Figure = 4:
It may be more intuitive to = swap the order of step 2 and 3 (ie
show A storing the object in Sb before A responds to = B).

It's a = little tricky here and P2P applications can use different ways to = do
it. When A gets the request to store object to Sb, it can simply = reply with
"Okay", and then do the store operation. Also it can start = to store the
object to Sb and then reply to B with a message " I have = started to
transfer...". =  

Yes, it could be done = several ways. But the key steps will be clear anyways when you = illustrate actual data = transfers.

Cheers

Franco= is



Thanks,
Haibin



Hope that = helps.

Francois

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



= --Apple-Mail-10--570633534-- From richard_woundy@cable.comcast.com Mon Nov 30 19:32:38 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4080228C166 for ; Mon, 30 Nov 2009 19:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 GnWtxGi+4OIu for ; Mon, 30 Nov 2009 19:32:37 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 434243A681D for ; Mon, 30 Nov 2009 19:32:37 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73739873; Mon, 30 Nov 2009 22:31:49 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 22:31:50 -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_01CA7236.D0F08E18" Date: Mon, 30 Nov 2009 22:31:47 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB6ECFAB@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <000901ca6a31$0645a610$520c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE minute notes Thread-Index: AcpqMQQOxzXZaK95SK6Ri9UIxdNs/gIBYqMw References: <000901ca6a31$0645a610$520c7c0a@china.huawei.com> From: "Woundy, Richard" To: X-OriginalArrivalTime: 01 Dec 2009 03:31:50.0405 (UTC) FILETIME=[D19DA350:01CA7236] Subject: Re: [decade] DECADE minute notes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:32:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7236.D0F08E18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Decade folks, =20 I made significant revisions to the Decade BOF Minutes and posted them to the IETF website: http://www.ietf.org/proceedings/09nov/minutes/decade.txt. Thanks to Lucy Yong for the original meeting notes. =20 Please send any updates or corrections to the mailing list. Thanks. =20 -- Rich =20 From: Yong Lucy [mailto:lucyyong@huawei.com]=20 Sent: Friday, November 20, 2009 5:30 PM To: decade@ietf.org Cc: 'Song Haibin'; Woundy, Richard Subject: DECADE minute notes =20 Here are minute notes from the meeting. Welcome to add on or correct it. Lucy ------_=_NextPart_001_01CA7236.D0F08E18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Decade folks,

 

I made significant revisions to the Decade BOF Minutes = and posted them to the IETF website: http://= www.ietf.org/proceedings/09nov/minutes/decade.txt. Thanks to Lucy Yong for the original meeting = notes.

 

Please send any updates or corrections to the mailing = list. Thanks.

 

-- Rich

 

From:= Yong Lucy [mailto:lucyyong@huawei.com]
Sent: Friday, November 20, 2009 5:30 PM
To: decade@ietf.org
Cc: 'Song Haibin'; Woundy, Richard
Subject: DECADE minute notes

 

Here are minute notes from the meeting. Welcome to add on or correct = it.

Lucy

------_=_NextPart_001_01CA7236.D0F08E18--