From guyingjie@huawei.com Mon Aug 3 00:31: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 BCF9928C0F0 for ; Mon, 3 Aug 2009 00:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[AWL=0.095, 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 WZcRYSvJlQfE for ; Mon, 3 Aug 2009 00:31:39 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F254D28C0EE for ; Mon, 3 Aug 2009 00:31:38 -0700 (PDT) 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 <0KNS002YKI3BQ1@szxga04-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 15:28:23 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNS0098EI3BKC@szxga04-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 15:28:23 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNS00951I3A2Z@szxml06-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 15:28:23 +0800 (CST) Date: Mon, 03 Aug 2009 15:28:22 +0800 From: "Y.J. Gu" In-reply-to: <81E94869FA91394CB0D6408786148E9B10483731@TK5EX14MBXC112.redmond.corp.microsoft.com> To: decade@ietf.org Message-id: <003701ca140b$fb80f9d0$400ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSA= Subject: [decade] Comment for motivations and goals of 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: Mon, 03 Aug 2009 07:31:39 -0000 I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. IMHO, "band-saving" might not be a good reason to convince IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as ALTO. I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question. "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy Yong. I agree with them, it will make things too complicated. Look back the meeting minutes, and you will find that 7 out of 15 questions in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. To decouple signaling and data transmission is the very incentive that we need. Up to now, there is no WG in IETF ever intends to address the updating pressure to existing caches system. Absorbing people's attention on this aspect might help us clarify the necessary of DECADE more convincibly. And we can regard "band-saving" as a subordinate advantage, instead of as an incentive. Regards Yingjie Gu From alan@peerapp.com Mon Aug 3 01:01:04 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 22DFF3A6B30 for ; Mon, 3 Aug 2009 01:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 mOHxCLgnsa8n for ; Mon, 3 Aug 2009 01:01:03 -0700 (PDT) Received: from mx1.peerapp.com (ded758-win-170-58.netsonic.net [66.180.170.58]) by core3.amsl.com (Postfix) with ESMTP id 38D0B3A6833 for ; Mon, 3 Aug 2009 01:01:02 -0700 (PDT) Received: from exchange.PEERAPP.com ([212.150.66.66]) by mx1.peerapp.com (8.14.1/8.14.1/SuSE Linux 0.8) with ESMTP id n7383usA011795; Mon, 3 Aug 2009 03:03:59 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 11:00:22 +0300 Message-ID: In-Reply-To: <003701ca140b$fb80f9d0$400ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Comment for motivations and goals of DECADE thread-index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0A== References: <81E94869FA91394CB0D6408786148E9B10483731@TK5EX14MBXC112.redmond.corp.microsoft.com> <003701ca140b$fb80f9d0$400ca40a@china.huawei.com> From: "Alan Arolovitch" Importance: normal Priority: normal To: "Y.J. Gu" , Subject: Re: [decade] Comment for motivations and goals of 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: Mon, 03 Aug 2009 08:01:04 -0000 0.02$ from P2P caching vendor perspective I agree that bandwidth savings as a scope is too narrow and not exclusive enough. P2P caching systems can accommodate a variety of value propositions, including bandwidth savings, SLA assurance and service delivery. Based on discussions spurred by ALTO, it seems that there's a perceived and=20 understood challenge in scaling multi-protocol support of P2P applications Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. Just as HTTP1.1 RFC 2616 doesn't spell out particular caching architecture, but=20 rather standardizes solid protocol-level caching support, that allows to build=20 transparent and non-transparent caching systems based on it. Lastly, on the legal side, I don't think DECADE should focus exclusively on DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content) There is plenty of deployment scenarios that do not fall into this bucket, even though it would be nice if DECADE wasn't in a clear violation of the procedures set by DMCA=20 and other very similar legal acts adopted globally. --alan=20 =20 -------------------------------------------------------------------------= - This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 -------------------------------------------------------------------------= - -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu Sent: Monday, August 03, 2009 10:28 AM To: decade@ietf.org Subject: [decade] Comment for motivations and goals of DECADE I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. IMHO, "band-saving" might not be a good reason to convince IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as ALTO. I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question.=20 "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy Yong. I agree with them, it will make things too complicated. Look back the meeting minutes, and you will find that 7 out of 15 questions in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. To decouple signaling and data transmission is the very incentive that we need. Up to now, there is no WG in IETF ever intends to address the updating pressure to existing caches system. Absorbing people's attention on this aspect might help us clarify the necessary of DECADE more convincibly. And we can regard "band-saving" as a subordinate advantage, instead of as an incentive. Regards Yingjie Gu _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade ************************************************************************ ********************* From guyingjie@huawei.com Mon Aug 3 02:30:33 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 5665B3A6AFC for ; Mon, 3 Aug 2009 02:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=2.033, 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 bVQATbnsX8ql for ; Mon, 3 Aug 2009 02:30:26 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 194E63A6D77 for ; Mon, 3 Aug 2009 02:30:18 -0700 (PDT) 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 <0KNS00L66NQJR2@szxga02-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 17:30:19 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNS00GYYNQI7H@szxga02-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 17:30:18 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNS00KD0NQIWD@szxml06-in.huawei.com> for decade@ietf.org; Mon, 03 Aug 2009 17:30:18 +0800 (CST) Date: Mon, 03 Aug 2009 17:30:18 +0800 From: "Y.J. Gu" In-reply-to: To: 'Alan Arolovitch' , decade@ietf.org Message-id: <003d01ca141d$03e1b090$400ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchA Subject: Re: [decade] Comment for motivations and goals of 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: Mon, 03 Aug 2009 09:30:33 -0000 " Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. " Support, a universal protocol should be the final target of DECADE. But, IMHO, at beginning, we should base our discussion on a particular caching form, to avoid abstract discussion. This caching form should be scalable, open architecture and protocol, and, of course, P2P friendly. This could be either an existing caching form or a new one. Regards Yingjie Gu -----Original Message----- From: Alan Arolovitch [mailto:alan@peerapp.com] Sent: Monday, August 03, 2009 4:00 PM To: Y.J. Gu; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE 0.02$ from P2P caching vendor perspective I agree that bandwidth savings as a scope is too narrow and not exclusive enough. P2P caching systems can accommodate a variety of value propositions, including bandwidth savings, SLA assurance and service delivery. Based on discussions spurred by ALTO, it seems that there's a perceived and understood challenge in scaling multi-protocol support of P2P applications Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. Just as HTTP1.1 RFC 2616 doesn't spell out particular caching architecture, but rather standardizes solid protocol-level caching support, that allows to build transparent and non-transparent caching systems based on it. Lastly, on the legal side, I don't think DECADE should focus exclusively on DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content) There is plenty of deployment scenarios that do not fall into this bucket, even though it would be nice if DECADE wasn't in a clear violation of the procedures set by DMCA and other very similar legal acts adopted globally. --alan -------------------------------------------------------------------------- This e-mail Contains PeerApp Proprietary and Confidential information. -------------------------------------------------------------------------- -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu Sent: Monday, August 03, 2009 10:28 AM To: decade@ietf.org Subject: [decade] Comment for motivations and goals of DECADE I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. IMHO, "band-saving" might not be a good reason to convince IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as ALTO. I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question. "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy Yong. I agree with them, it will make things too complicated. Look back the meeting minutes, and you will find that 7 out of 15 questions in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. To decouple signaling and data transmission is the very incentive that we need. Up to now, there is no WG in IETF ever intends to address the updating pressure to existing caches system. Absorbing people's attention on this aspect might help us clarify the necessary of DECADE more convincibly. And we can regard "band-saving" as a subordinate advantage, instead of as an incentive. Regards Yingjie Gu _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade ************************************************************************ ********************* From zhangyunfei@chinamobile.com Mon Aug 3 20:56:44 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 B62D83A6F24 for ; Mon, 3 Aug 2009 20:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.211 X-Spam-Level: X-Spam-Status: No, score=-96.211 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 fScqwwzNtYWj for ; Mon, 3 Aug 2009 20:56:43 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 702F83A677E for ; Mon, 3 Aug 2009 20:56:43 -0700 (PDT) Received: from LENOVO-917FFE55 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009080411563401-6116 ; Tue, 4 Aug 2009 11:56:34 +0800 Date: Tue, 4 Aug 2009 11:56:31 +0800 From: "zhangyunfei" To: "Y.J. Gu" , "decade@ietf.org" References: <003701ca140b$fb80f9d0$400ca40a@china.huawei.com> Message-ID: <200908041156286251743@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-08-04 11:56:38, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-08-04 11:56:47, Serialize complete at 2009-08-04 11:56:47 Content-Type: multipart/alternative; boundary="=====003_Dragon252681262022_=====" Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 03:56:44 -0000 This is a multi-part message in MIME format. --=====003_Dragon252681262022_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" UGxlYXNlIHNlZSBpbmxpbmUgZm9yIHRoZSBjb21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAg ICAgQlINCiAgICAgICAgICAgICAgICAgICAgICAgWXVuZmVpDQoNCg0KDQoNCiBCZXN0IHJlZ2Fy ZHMhDQogIFNpbmNlcmVseSB5b3VycywNCiAgICAgIFl1bmZlaSANCiAgICAgICAyMDA5LTA4LTA0 DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQpZdW5mZWkgWmhhbmcsIFBoLkQuDQoNClImRCwgQ0hJTkEgTU9CSUxFIENPTU1VTklDQVRJT05T IENPUlBPUkFUSU9ODQoNClRlbDogKzg2IDEwIDE1ODAxNjk2NjY4OCBleHQuIDMyNDcNCg0KRmF4 OiArODYgMTAgNjM2MDEwODcNCg0KTU9CSUxFOiAxMzYwLTEwMzItMTE5DQoNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KDQoNCreivP7I y6O6IFkuSi4gR3UNCreiy83Ksbzko7ogMjAwOS0wOC0wMyAxNTozMTo1OA0KytW8/sjLo7ogZGVj YWRlQGlldGYub3JnDQqzrcvNo7ogDQrW98zio7ogW2RlY2FkZV0gQ29tbWVudCBmb3IgbW90aXZh dGlvbnMgYW5kIGdvYWxzIG9mIERFQ0FERQ0KDQpJICBkaWQgIG5vdCAgYXR0ZW5kICBERUNBREUg IGJhciAgQk9GLCAganVzdCAgZm9sbG93ICB0aGUgIHByb2dyZXNzICBieSAgYW5hbHl6aW5nDQpt ZWV0aW5nICBtaW51dGVzLiAgU28sICBmb3JnaXZlICBtZSAgaWYgIHRoZXJlICBtaWdodCAgYmUg IGFueSAgbWlzdW5kZXJzdGFuZGluZy4gICAgXl9eDQoNCkkgIG5vdGljZSAgdGhhdCAgYm90aCAg dGhlICAiUHJvYmxlbSAgc3RhdGVtZW50IiAgYW5kICAiQnJhbmNoQ2FjaGUgIHByZXNlbnRhdGlv biINCnRha2UgICJiYW5kLXNhdmluZyIgIGFzICBhICBwcmltYXJ5ICBtb3RpdmF0aW9uL2luY2Vu dGl2ZSAgZm9yICBERUNBREUuDQoNCklNSE8sICAiYmFuZC1zYXZpbmciICBtaWdodCAgbm90ICBi ZSAgYSAgZ29vZCAgcmVhc29uICB0byAgY29udmluY2UgIElFVEYgIHRvICB3b3JrICBvbg0KREVD QURFICBhbmQgIG1pZ2h0ICBwdXQgIERFQ0FERSAgaW50byAgbXVjaCAgbW9yZSAgZGViYXRlLiAg VGhlcmUgIGFyZSAgYWxyZWFkeSAgdmFyaW91cw0KY2FjaGluZyAgb3IgIG5vbi1jYWNoaW5nICBz b2x1dGlvbnMgIGltcGxlbWVudGVkICB0byAgcmVkdWNlICB1cGxpbmsvZG93bmxpbmsNCmJhbmR3 aWR0aCwgIGZvciAgYm90aCAgQy9TICBhbmQgIFAyUCAgYXBwbGljYXRpb25zLCAgZS5nLiAgQ0RO LCAgUDJQICBjYWNoaW5nICBhbmQgIERQSS4NClNvbWUgIG90aGVycyAgYXJlICB1bmRlciAgZGlz Y3Vzc2lvbiAgaW4gIG1haWxpbmcgIGxpc3QsICBzdWNoICBhcyAgQUxUTy4NCg0KSSAga25vdyAg REVDQURFICBpcyAgZGlmZmVyZW50LCAgYnV0ICB3aHkgIElFVEYgIG5lZWQgIGFub3RoZXIgICJi YW5kLXNhdmluZyINCnNvbHV0aW9uPyAgVGhhdCdzICBhICBoYXJkICBxdWVzdGlvbi4gIA0KInNh dmluZyAgdXBsaW5rICBpcyAgdG9vICBicm9hZCAgc2NvcGUiLCAgYXMgIFJpY2ggIHNhaWQuDQoi c2F2aW5nICB0aGUgIHVwbGluayAgaXMgIG5vdCAgdGhlICBtYWluICBkcnZpbmcgIGZvcmNlIiwg IHNhaWQgIEx1Y3kgIFlvbmcuDQpJICBhZ3JlZSAgd2l0aCAgdGhlbSwgIGl0ICB3aWxsICBtYWtl ICB0aGluZ3MgIHRvbyAgY29tcGxpY2F0ZWQuICBMb29rICBiYWNrICB0aGUNCm1lZXRpbmcgIG1p bnV0ZXMsICBhbmQgIHlvdSAgd2lsbCAgZmluZCAgdGhhdCAgNyAgb3V0ICBvZiAgMTUgIHF1ZXN0 aW9ucyAgaW4gICJQcm9ibGVtDQpzdGF0ZW1lbnQiICBRJkEgIGFyZSAgYWJvdXQgIGJhbmR3aWR0 aC4gIFdlICBkbyAgbm90ICBuZWVkICBtdWx0aS1tb3RpdmF0aW9ucyAgdG8NCmluZGljYXRlICB0 aGUgIGltcG9ydGFuY2UgIG9mICBERUNBREUsICB3ZSAganVzdCAgbmVlZCAgYW4gIG92ZXJ3aGVs bWluZyAgb25lLg0KDQpUbyAgZGVjb3VwbGUgIHNpZ25hbGluZyAgYW5kICBkYXRhICB0cmFuc21p c3Npb24gIGlzICB0aGUgIHZlcnkgIGluY2VudGl2ZSAgdGhhdCAgd2UNCm5lZWQuICBVcCAgdG8g IG5vdywgIHRoZXJlICBpcyAgbm8gIFdHICBpbiAgSUVURiAgZXZlciAgaW50ZW5kcyAgdG8gIGFk ZHJlc3MgIHRoZSAgdXBkYXRpbmcNCnByZXNzdXJlICB0byAgZXhpc3RpbmcgIGNhY2hlcyAgc3lz dGVtLiAgICBBYnNvcmJpbmcgIHBlb3BsZSdzICBhdHRlbnRpb24gIG9uICB0aGlzDQphc3BlY3Qg IG1pZ2h0ICBoZWxwICB1cyAgY2xhcmlmeSAgdGhlICBuZWNlc3NhcnkgIG9mICBERUNBREUgIG1v cmUgIGNvbnZpbmNpYmx5Lg0KTWFueSBpbml0aWF0aXZlcyBoYXZlIHNpbWlsYXIgaW5jZW50aXZl LGUuZy4sIFBQU1AgZGVjb3VwbGVzIHNpZ25hbGluZyBhbmQgZGF0YSB0cmFuc21pc3Npb24gYXMg d2VsbCwgd2hpY2ggY2FuIGFsc28gaW5jbHVkZSBleGlzaXRpbmcgY2FjaGUgc3lzdGVtIGFzIHRo ZSBwZWVycy5TbyBJIHRoaW5rIGl0J3MgbW9yZSBjb252aW5jaW5nIHRvIGZvY3VzIHRoZSBpbmNl bnRpdmUgYW5kIHNjb3BlIG9mIERFQ0FERSBhcyAic2F2aW5nIHVwbGluayB1c2FnZSJhbmQgImRl dmVsb3Bpbmcgc2lnbmFsaW5nIHByb3RvY29sIGJldHdlZW4gY2xpZW50IGFuZCBjYWNoZSBub2Rl cyIuDQoNCkFuZCAgd2UgIGNhbiAgcmVnYXJkICAiYmFuZC1zYXZpbmciICBhcyAgYSAgc3Vib3Jk aW5hdGUgIGFkdmFudGFnZSwgIGluc3RlYWQgIG9mICBhcyAgYW4NCmluY2VudGl2ZS4NCg0KUmVn YXJkcw0KDQpZaW5namllICBHdQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KZGVjYWRlICBtYWlsaW5nICBsaXN0DQpkZWNhZGVAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlDQo= --=====003_Dragon252681262022_===== 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 ZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlBsZWFzZSBzZWUgaW5saW5lIGZvciB0 aGUgDQpjb21tZW50cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xv cj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkJSPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpZdW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VmVyZGFu YSBzaXplPTI+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwMDBmZj4NCjxIUiBzdHls ZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJ ViBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPSMwMDAwZmY+Jm5ic3A7QmVzdCByZWdhcmRzITxCUj4m bmJzcDsgU2luY2VyZWx5IA0KeW91cnMsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBZdW5mZWkgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMjAw OS0wOC0wNDxCUj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwMDBmZj5ZdW5mZWkgWmhh bmcsIFBoLkQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jMDAwMGZmPlImYW1wO0Qs IENISU5BIE1PQklMRSBDT01NVU5JQ0FUSU9OUyANCkNPUlBPUkFUSU9OPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249 bGVmdD48Rk9OVCBjb2xvcj0jMDAwMGZmPlRlbDogKzg2IDEwIDE1ODAxNjk2NjY4OCBleHQuIA0K MzI0NzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwMDBmZj5GYXg6ICs4NiAxMCA2 MzYwMTA4NzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwMDBmZj5NT0JJTEU6IDEz NjAtMTAzMi0xMTk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIA0KY29sb3I9IzAwMDBmZj4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxCUj48L0ZP TlQ+PC9ESVY+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0K PEhSPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0y PjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gWS5KLiANCkd1PC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPreiy83Ksbzko7o8 L1NUUk9ORz4gDQoyMDA5LTA4LTAzJm5ic3A7MTU6MzE6NTg8L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+ytW8/sjLo7o8L1NU Uk9ORz4gDQpkZWNhZGVAaWV0Zi5vcmc8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9O Rz7W98zio7o8L1NUUk9ORz4gW2RlY2FkZV0gQ29tbWVudCBmb3IgDQptb3RpdmF0aW9ucyBhbmQg Z29hbHMgb2YgREVDQURFPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+DQo8RElWPkkgJm5ic3A7ZGlkICZuYnNwO25vdCAmbmJzcDthdHRlbmQgJm5ic3A7REVD QURFICZuYnNwO2JhciAmbmJzcDtCT0YsIA0KJm5ic3A7anVzdCAmbmJzcDtmb2xsb3cgJm5ic3A7 dGhlICZuYnNwO3Byb2dyZXNzICZuYnNwO2J5ICZuYnNwO2FuYWx5emluZzwvRElWPg0KPERJVj5t ZWV0aW5nICZuYnNwO21pbnV0ZXMuICZuYnNwO1NvLCAmbmJzcDtmb3JnaXZlICZuYnNwO21lICZu YnNwO2lmIA0KJm5ic3A7dGhlcmUgJm5ic3A7bWlnaHQgJm5ic3A7YmUgJm5ic3A7YW55ICZuYnNw O21pc3VuZGVyc3RhbmRpbmcuICZuYnNwOyANCiZuYnNwO15fXjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+SSAmbmJzcDtub3RpY2UgJm5ic3A7dGhhdCAmbmJzcDtib3RoICZuYnNwO3Ro ZSAmbmJzcDsiUHJvYmxlbSANCiZuYnNwO3N0YXRlbWVudCIgJm5ic3A7YW5kICZuYnNwOyJCcmFu Y2hDYWNoZSAmbmJzcDtwcmVzZW50YXRpb24iPC9ESVY+DQo8RElWPnRha2UgJm5ic3A7ImJhbmQt c2F2aW5nIiAmbmJzcDthcyAmbmJzcDthICZuYnNwO3ByaW1hcnkgDQombmJzcDttb3RpdmF0aW9u L2luY2VudGl2ZSAmbmJzcDtmb3IgJm5ic3A7REVDQURFLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+SU1ITywgJm5ic3A7ImJhbmQtc2F2aW5nIiAmbmJzcDttaWdodCAmbmJzcDtub3Qg Jm5ic3A7YmUgJm5ic3A7YSAmbmJzcDtnb29kIA0KJm5ic3A7cmVhc29uICZuYnNwO3RvICZuYnNw O2NvbnZpbmNlICZuYnNwO0lFVEYgJm5ic3A7dG8gJm5ic3A7d29yayANCiZuYnNwO29uPC9ESVY+ DQo8RElWPkRFQ0FERSAmbmJzcDthbmQgJm5ic3A7bWlnaHQgJm5ic3A7cHV0ICZuYnNwO0RFQ0FE RSAmbmJzcDtpbnRvICZuYnNwO211Y2ggDQombmJzcDttb3JlICZuYnNwO2RlYmF0ZS4gJm5ic3A7 VGhlcmUgJm5ic3A7YXJlICZuYnNwO2FscmVhZHkgJm5ic3A7dmFyaW91czwvRElWPg0KPERJVj5j YWNoaW5nICZuYnNwO29yICZuYnNwO25vbi1jYWNoaW5nICZuYnNwO3NvbHV0aW9ucyAmbmJzcDtp bXBsZW1lbnRlZCANCiZuYnNwO3RvICZuYnNwO3JlZHVjZSAmbmJzcDt1cGxpbmsvZG93bmxpbms8 L0RJVj4NCjxESVY+YmFuZHdpZHRoLCAmbmJzcDtmb3IgJm5ic3A7Ym90aCAmbmJzcDtDL1MgJm5i c3A7YW5kICZuYnNwO1AyUCANCiZuYnNwO2FwcGxpY2F0aW9ucywgJm5ic3A7ZS5nLiAmbmJzcDtD RE4sICZuYnNwO1AyUCAmbmJzcDtjYWNoaW5nICZuYnNwO2FuZCANCiZuYnNwO0RQSS48L0RJVj4N CjxESVY+U29tZSAmbmJzcDtvdGhlcnMgJm5ic3A7YXJlICZuYnNwO3VuZGVyICZuYnNwO2Rpc2N1 c3Npb24gJm5ic3A7aW4gDQombmJzcDttYWlsaW5nICZuYnNwO2xpc3QsICZuYnNwO3N1Y2ggJm5i c3A7YXMgJm5ic3A7QUxUTy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgJm5ic3A7 a25vdyAmbmJzcDtERUNBREUgJm5ic3A7aXMgJm5ic3A7ZGlmZmVyZW50LCAmbmJzcDtidXQgJm5i c3A7d2h5IA0KJm5ic3A7SUVURiAmbmJzcDtuZWVkICZuYnNwO2Fub3RoZXIgJm5ic3A7ImJhbmQt c2F2aW5nIjwvRElWPg0KPERJVj5zb2x1dGlvbj8gJm5ic3A7VGhhdCdzICZuYnNwO2EgJm5ic3A7 aGFyZCAmbmJzcDtxdWVzdGlvbi4gJm5ic3A7PC9ESVY+DQo8RElWPiJzYXZpbmcgJm5ic3A7dXBs aW5rICZuYnNwO2lzICZuYnNwO3RvbyAmbmJzcDticm9hZCAmbmJzcDtzY29wZSIsICZuYnNwO2Fz IA0KJm5ic3A7UmljaCAmbmJzcDtzYWlkLjwvRElWPg0KPERJVj4ic2F2aW5nICZuYnNwO3RoZSAm bmJzcDt1cGxpbmsgJm5ic3A7aXMgJm5ic3A7bm90ICZuYnNwO3RoZSAmbmJzcDttYWluIA0KJm5i c3A7ZHJ2aW5nICZuYnNwO2ZvcmNlIiwgJm5ic3A7c2FpZCAmbmJzcDtMdWN5ICZuYnNwO1lvbmcu PC9ESVY+DQo8RElWPkkgJm5ic3A7YWdyZWUgJm5ic3A7d2l0aCAmbmJzcDt0aGVtLCAmbmJzcDtp dCAmbmJzcDt3aWxsICZuYnNwO21ha2UgDQombmJzcDt0aGluZ3MgJm5ic3A7dG9vICZuYnNwO2Nv bXBsaWNhdGVkLiAmbmJzcDtMb29rICZuYnNwO2JhY2sgJm5ic3A7dGhlPC9ESVY+DQo8RElWPm1l ZXRpbmcgJm5ic3A7bWludXRlcywgJm5ic3A7YW5kICZuYnNwO3lvdSAmbmJzcDt3aWxsICZuYnNw O2ZpbmQgJm5ic3A7dGhhdCANCiZuYnNwOzcgJm5ic3A7b3V0ICZuYnNwO29mICZuYnNwOzE1ICZu YnNwO3F1ZXN0aW9ucyAmbmJzcDtpbiANCiZuYnNwOyJQcm9ibGVtPC9ESVY+DQo8RElWPnN0YXRl bWVudCIgJm5ic3A7USZhbXA7QSAmbmJzcDthcmUgJm5ic3A7YWJvdXQgJm5ic3A7YmFuZHdpZHRo LiAmbmJzcDtXZSANCiZuYnNwO2RvICZuYnNwO25vdCAmbmJzcDtuZWVkICZuYnNwO211bHRpLW1v dGl2YXRpb25zICZuYnNwO3RvPC9ESVY+DQo8RElWPmluZGljYXRlICZuYnNwO3RoZSAmbmJzcDtp bXBvcnRhbmNlICZuYnNwO29mICZuYnNwO0RFQ0FERSwgJm5ic3A7d2UgDQombmJzcDtqdXN0ICZu YnNwO25lZWQgJm5ic3A7YW4gJm5ic3A7b3ZlcndoZWxtaW5nICZuYnNwO29uZS48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRvICZuYnNwO2RlY291cGxlICZuYnNwO3NpZ25hbGluZyAm bmJzcDthbmQgJm5ic3A7ZGF0YSAmbmJzcDt0cmFuc21pc3Npb24gDQombmJzcDtpcyAmbmJzcDt0 aGUgJm5ic3A7dmVyeSAmbmJzcDtpbmNlbnRpdmUgJm5ic3A7dGhhdCAmbmJzcDt3ZTwvRElWPg0K PERJVj5uZWVkLiAmbmJzcDtVcCAmbmJzcDt0byAmbmJzcDtub3csICZuYnNwO3RoZXJlICZuYnNw O2lzICZuYnNwO25vICZuYnNwO1dHIA0KJm5ic3A7aW4gJm5ic3A7SUVURiAmbmJzcDtldmVyICZu YnNwO2ludGVuZHMgJm5ic3A7dG8gJm5ic3A7YWRkcmVzcyAmbmJzcDt0aGUgDQombmJzcDt1cGRh dGluZzwvRElWPg0KPERJVj5wcmVzc3VyZSAmbmJzcDt0byAmbmJzcDtleGlzdGluZyAmbmJzcDtj YWNoZXMgJm5ic3A7c3lzdGVtLiAmbmJzcDsgDQombmJzcDtBYnNvcmJpbmcgJm5ic3A7cGVvcGxl J3MgJm5ic3A7YXR0ZW50aW9uICZuYnNwO29uICZuYnNwO3RoaXM8L0RJVj4NCjxESVY+YXNwZWN0 ICZuYnNwO21pZ2h0ICZuYnNwO2hlbHAgJm5ic3A7dXMgJm5ic3A7Y2xhcmlmeSAmbmJzcDt0aGUg DQombmJzcDtuZWNlc3NhcnkgJm5ic3A7b2YgJm5ic3A7REVDQURFICZuYnNwO21vcmUgJm5ic3A7 Y29udmluY2libHkuPC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmY+TWFueSBpbml0aWF0 aXZlcyBoYXZlIHNpbWlsYXIgaW5jZW50aXZlLGUuZy4sIFBQU1AgDQpkZWNvdXBsZXMgc2lnbmFs aW5nIGFuZCBkYXRhIHRyYW5zbWlzc2lvbiBhcyB3ZWxsLCB3aGljaCBjYW4gYWxzbyBpbmNsdWRl IA0KZXhpc2l0aW5nIGNhY2hlIHN5c3RlbSBhcyB0aGUgcGVlcnMuU28gSSB0aGluayBpdCdzIG1v cmUgY29udmluY2luZyB0byBmb2N1cyB0aGUgDQppbmNlbnRpdmUgYW5kIHNjb3BlIG9mIERFQ0FE RSBhcyAic2F2aW5nIHVwbGluayB1c2FnZSJhbmQgImRldmVsb3Bpbmcgc2lnbmFsaW5nIA0KcHJv dG9jb2wgYmV0d2VlbiBjbGllbnQgYW5kIGNhY2hlIG5vZGVzIi48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5BbmQgJm5ic3A7 d2UgJm5ic3A7Y2FuICZuYnNwO3JlZ2FyZCAmbmJzcDsiYmFuZC1zYXZpbmciICZuYnNwO2FzICZu YnNwO2EgDQombmJzcDtzdWJvcmRpbmF0ZSAmbmJzcDthZHZhbnRhZ2UsICZuYnNwO2luc3RlYWQg Jm5ic3A7b2YgJm5ic3A7YXMgDQombmJzcDthbjwvRElWPg0KPERJVj5pbmNlbnRpdmUuPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5SZWdhcmRzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5ZaW5namllICZuYnNwO0d1PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElWPg0KPERJ Vj5kZWNhZGUgJm5ic3A7bWFpbGluZyAmbmJzcDtsaXN0PC9ESVY+DQo8RElWPmRlY2FkZUBpZXRm Lm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rl Y2FkZTwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon252681262022_=====-- From guyingjie@huawei.com Mon Aug 3 23:31:51 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 E0D923A6F4C for ; Mon, 3 Aug 2009 23:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_CHARSET_FARAWAY=2.45, 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 I-lDi5SElYN1 for ; Mon, 3 Aug 2009 23:31:50 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C8BE33A6F0A for ; Mon, 3 Aug 2009 23:31:48 -0700 (PDT) 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 <0KNU00K0BA2TM4@szxga04-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 14:30:29 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNU00D30A2T6D@szxga04-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 14:30:29 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNU00H7ZA2SF3@szxml06-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 14:30:29 +0800 (CST) Date: Tue, 04 Aug 2009 14:30:28 +0800 From: "Y.J. Gu" In-reply-to: <200908041156286251743@chinamobile.com> To: 'zhangyunfei' , decade@ietf.org Message-id: <000c01ca14cd$0f5b8df0$400ca40a@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/alternative; boundary="Boundary_(ID_yV2OmGIVP034SSi/nr9NBw)" Thread-index: AcoUt7avnOAV4/H2SOCNd6Y4kHL1mAAD4FYA Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 06:31:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yV2OmGIVP034SSi/nr9NBw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hello Yunfei, thank you for your comments. First of all, I need to explain that when I said "decouple signaling = and data transmission", I actually mean that cache will act as a content storage without understanding various proprietary protocol. =20 As much as I know, PPSP is going to establish a standard architecture = and protocol for P2P streaming. I guess what you mean by "PPSP decouples signaling and data transmission " is PPSP provides a universal = signaling, regardless who store the data and how it is transmitted to terminal. = That means, in PPSP, an object who performing signalling could also be the = one who store and transmit the data. So, I think we are talking about different issues. Besides, PPSP focus on streaming and DECADE has no such limitation. PPSP is also an very interesting topic. I'm still looking forward to the meeting minutes of PPSP. =20 Could you list other initiatives that is incentived by "decouple = signaling and data transmission on cache " , so we can make a deep and wide comparison. That will be really helpful. =20 Regards Yingjie Gu =20 _____ =20 From: zhangyunfei [mailto:zhangyunfei@chinamobile.com]=20 Sent: Tuesday, August 04, 2009 11:57 AM To: Y.J. Gu; decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE Please see inline for the comments. =20 BR Yunfei =20 _____ =20 Best regards! Sincerely yours, Yunfei=20 2009-08-04 ***************************************************** =20 Yunfei Zhang, Ph.D. =20 R&D, CHINA MOBILE COMMUNICATIONS CORPORATION =20 Tel: +86 10 158016966688 ext. 3247 =20 Fax: +86 10 63601087 =20 MOBILE: 1360-1032-119 =20 ***************************************************** _____ =20 =B7=A2=BC=FE=C8=CB=A3=BA Y.J. Gu =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-08-03 15:31:58 =CA=D5=BC=FE=C8=CB=A3=BA decade@ietf.org =B3=AD=CB=CD=A3=BA=20 =D6=F7=CC=E2=A3=BA [decade] Comment for motivations and goals of DECADE =20 I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ =20 I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. =20 IMHO, "band-saving" might not be a good reason to convince = IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as = ALTO. =20 I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question. =20 "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy = Yong. I agree with them, it will make things too complicated. Look = back the meeting minutes, and you will find that 7 out of 15 questions = in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. =20 To decouple signaling and data transmission is the very = incentive that we need. Up to now, there is no WG in IETF ever intends to = address the updating pressure to existing caches system. Absorbing people's = attention on this aspect might help us clarify the necessary of DECADE more convincibly. Many initiatives have similar incentive,e.g., PPSP decouples signaling = and data transmission as well, which can also include exisiting cache system = as the peers.So I think it's more convincing to focus the incentive and = scope of DECADE as "saving uplink usage"and "developing signaling protocol = between client and cache nodes". =20 And we can regard "band-saving" as a subordinate advantage, = instead of as an incentive. =20 Regards =20 Yingjie Gu =20 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade --Boundary_(ID_yV2OmGIVP034SSi/nr9NBw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hello Yunfei, thank = you for your=20 comments.
First of all, I need = to explain that=20 when I said "decouple  signaling  and =  data=20  transmission", I actually mean that cache will act as a = content=20 storage without understanding various proprietary protocol. =20  
As much as I know, = PPSP is going to=20 establish a standard architecture and protocol for P2P streaming. I = guess what=20 you mean by  "PPSP decouples signaling and = data=20 transmission " is PPSP provides a universal signaling,=20 regardless who store the data and how it = is transmitted to=20 terminal.  That means, in PPSP, an object who performing=20 signalling could also be the one who store and transmit the=20 data.
So, I think we are = talking about=20 different issues.
Besides,  PPSP = focus on=20 streaming and DECADE has no such limitation.
PPSP is also an very = interesting=20 topic. I'm still looking forward to the meeting minutes of=20 PPSP.
 
Could you list other = initiatives=20 that is incentived by "decouple  signaling =  and=20  data  transmission on cache " , so we=20 can make a deep and wide comparison. That will be really=20 helpful.
 

Regards

Yingjie Gu

 

From: zhangyunfei=20 [mailto:zhangyunfei@chinamobile.com]
Sent: Tuesday, August = 04, 2009=20 11:57 AM
To: Y.J. Gu; decade@ietf.org
Subject: Re: = [decade]=20 Comment for motivations and goals of DECADE

Please see inline for = the=20 comments.
 
          &nbs= p;         =20 BR
          &nbs= p;           =20 Yunfei
 
 Best regards!
  = Sincerely=20 yours,
      Yunfei=20
      =20 2009-08-04
*****************************************************
 
Yunfei Zhang, Ph.D.
 
R&D, CHINA MOBILE = COMMUNICATIONS=20 CORPORATION
 
Tel: +86 10 158016966688 ext.=20 3247
 
Fax: +86 10 = 63601087
 
MOBILE: = 1360-1032-119
 
*****************************************************
=
=B7=A2=BC=FE=C8=CB=A3=BA Y.J.=20 Gu
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA=20 2009-08-03 15:31:58
=CA=D5=BC=FE=C8=CB=A3=BA=20 decade@ietf.org
=B3=AD=CB=CD=A3=BA
=D6=F7=CC=E2=A3=BA [decade] Comment for=20 motivations and goals of DECADE
 
I  did  not  attend  DECADE  bar =  BOF,=20  just  follow  the  progress  by =  analyzing
meeting  minutes.  So,  forgive  me  if=20  there  might  be  any  misunderstanding. =  =20  ^_^
 
I  notice  that  both  the  "Problem=20  statement"  and  "BranchCache  presentation"
take  "band-saving"  as  a  primary=20  motivation/incentive  for  DECADE.
 
IMHO,  "band-saving"  might  not  be  a =  good=20  reason  to  convince  IETF  to  work=20  on
DECADE  and  might  put  DECADE  into =  much=20  more  debate.  There  are  already =  various
caching  or  non-caching  solutions =  implemented=20  to  reduce  uplink/downlink
bandwidth,  for  both  C/S  and  P2P=20  applications,  e.g.  CDN,  P2P  caching =  and=20  DPI.
Some  others  are  under  discussion  in=20  mailing  list,  such  as  ALTO.
 
I  know  DECADE  is  different,  but =  why=20  IETF  need  another  "band-saving"
solution?  That's  a  hard  question. =  
"saving  uplink  is  too  broad  scope", =  as=20  Rich  said.
"saving  the  uplink  is  not  the =  main=20  drving  force",  said  Lucy  Yong.
I  agree  with  them,  it  will  make =  things  too  complicated.  Look  back =  the
meeting  minutes,  and  you  will  find =  that=20  7  out  of  15  questions  in=20  "Problem
statement"  Q&A  are  about  bandwidth. =  We=20  do  not  need  multi-motivations  to
indicate  the  importance  of  DECADE,  we =  just  need  an  overwhelming  one.
 
To  decouple  signaling  and  data =  transmission=20  is  the  very  incentive  that  we
need.  Up  to  now,  there  is  no =  WG=20  in  IETF  ever  intends  to  address =  the=20  updating
pressure  to  existing  caches  system.  =20  Absorbing  people's  attention  on  this
aspect  might  help  us  clarify  the=20  necessary  of  DECADE  more =  convincibly.
Many initiatives have similar incentive,e.g., = PPSP=20 decouples signaling and data transmission as well, which can also = include=20 exisiting cache system as the peers.So I think it's more convincing to = focus the=20 incentive and scope of DECADE as "saving uplink usage"and "developing = signaling=20 protocol between client and cache nodes".
 
And  we  can  regard  "band-saving"  as =  a=20  subordinate  advantage,  instead  of  as=20  an
incentive.
 
Regards
 
Yingjie  Gu
 
_______________________________________________
decade  mailing  list
decade@ietf.org
https://www.ietf.org/mailman/listinfo/decade
--Boundary_(ID_yV2OmGIVP034SSi/nr9NBw)-- From spis@intracom.com Tue Aug 4 00:14:35 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 87C7B3A6CE9 for ; Tue, 4 Aug 2009 00:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAy3leQkn2n7 for ; Tue, 4 Aug 2009 00:14:34 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.GR [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id 0D50628C2E4 for ; Tue, 4 Aug 2009 00:14:11 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n747E7OI006910 for ; Tue, 4 Aug 2009 10:14:08 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n747E6Hv006883 for ; Tue, 4 Aug 2009 10:14:06 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n747E5u9006875; Tue, 4 Aug 2009 10:14:06 +0300 (EEST) Received: from [146.124.44.139] ([146.124.44.139] verified) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29938142; Tue, 04 Aug 2009 10:14:05 +0300 Message-ID: <4A77DE7B.4000702@intracom.com> Date: Tue, 04 Aug 2009 10:08:43 +0300 From: Spiros Spirou Organization: Intracom Telecom User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Y.J. Gu" References: <000c01ca14cd$0f5b8df0$400ca40a@china.huawei.com> In-Reply-To: <000c01ca14cd$0f5b8df0$400ca40a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: spis@intracom.com 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, 04 Aug 2009 07:14:35 -0000 Hi Yingjie, Y.J. Gu wrote: > First of all, I need to explain that when I said "decouple signaling > and data transmission", I actually mean that cache will act as a > content storage without understanding various proprietary protocol. Would you please explain this a bit further? Thanks, Spiros From zhangyunfei@chinamobile.com Tue Aug 4 00:42:17 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 AAFDF28C2CA for ; Tue, 4 Aug 2009 00:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.14 X-Spam-Level: X-Spam-Status: No, score=-96.14 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 VpfxJbxfcuec for ; Tue, 4 Aug 2009 00:42:16 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id DE7743A6A45 for ; Tue, 4 Aug 2009 00:42:15 -0700 (PDT) Received: from LENOVO-917FFE55 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009080415415817-10387 ; Tue, 4 Aug 2009 15:41:58 +0800 Date: Tue, 4 Aug 2009 15:41:52 +0800 From: "zhangyunfei" To: "Y.J. Gu" , "decade@ietf.org" References: <000c01ca14cd$0f5b8df0$400ca40a@china.huawei.com> Message-ID: <200908041541484219346@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-08-04 15:42:05, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-08-04 15:42:19, Serialize complete at 2009-08-04 15:42:19 Content-Type: multipart/alternative; boundary="=====003_Dragon114316400677_=====" Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 07:42:17 -0000 This is a multi-part message in MIME format. --=====003_Dragon114316400677_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgWWluZ2ppZSwNCiAgICBQbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhlIHJlcGx5LlRoYW5rcyEN CiAgICAgICAgICAgICAgICAgICAgIEJSDQogICAgICAgICAgICAgICAgICAgICAgWXVuZmVpDQoN Cg0KDQoNCnpoYW5neXVuZmVpDQoyMDA5LTA4LTA0DQoNCg0KDQq3orz+yMujuiBZLkouIEd1DQq3 osvNyrG85KO6IDIwMDktMDgtMDQgMTU6Mjk6NDUNCsrVvP7Iy6O6ICd6aGFuZ3l1bmZlaSc7IGRl Y2FkZUBpZXRmLm9yZw0Ks63LzaO6IA0K1vfM4qO6IFJFOiBbZGVjYWRlXSBDb21tZW50IGZvciBt b3RpdmF0aW9ucyBhbmQgZ29hbHMgb2YgREVDQURFDQoNCkhlbGxvIFl1bmZlaSwgdGhhbmsgeW91 IGZvciB5b3VyIGNvbW1lbnRzLg0KRmlyc3Qgb2YgYWxsLCBJIG5lZWQgdG8gZXhwbGFpbiB0aGF0 IHdoZW4gSSBzYWlkICJkZWNvdXBsZSAgc2lnbmFsaW5nICBhbmQgIGRhdGEgIHRyYW5zbWlzc2lv biIsIEkgYWN0dWFsbHkgbWVhbiB0aGF0IGNhY2hlIHdpbGwgYWN0IGFzIGEgY29udGVudCBzdG9y YWdlIHdpdGhvdXQgdW5kZXJzdGFuZGluZyB2YXJpb3VzIHByb3ByaWV0YXJ5IHByb3RvY29sLiAg IA0KDQpBcyBtdWNoIGFzIEkga25vdywgUFBTUCBpcyBnb2luZyB0byBlc3RhYmxpc2ggYSBzdGFu ZGFyZCBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29sIGZvciBQMlAgc3RyZWFtaW5nLiBJIGd1ZXNz IHdoYXQgeW91IG1lYW4gYnkgICJQUFNQIGRlY291cGxlcyBzaWduYWxpbmcgYW5kIGRhdGEgdHJh bnNtaXNzaW9uICIgaXMgUFBTUCBwcm92aWRlcyBhIHVuaXZlcnNhbCBzaWduYWxpbmcsIHJlZ2Fy ZGxlc3Mgd2hvIHN0b3JlIHRoZSBkYXRhIGFuZCBob3cgaXQgaXMgdHJhbnNtaXR0ZWQgdG8gdGVy bWluYWwuICBUaGF0IG1lYW5zLCBpbiBQUFNQLCBhbiBvYmplY3Qgd2hvIHBlcmZvcm1pbmcgc2ln bmFsbGluZyBjb3VsZCBhbHNvIGJlIHRoZSBvbmUgd2hvIHN0b3JlIGFuZCB0cmFuc21pdCB0aGUg ZGF0YS4NClNvLCBJIHRoaW5rIHdlIGFyZSB0YWxraW5nIGFib3V0IGRpZmZlcmVudCBpc3N1ZXMu DQpCZXNpZGVzLCAgUFBTUCBmb2N1cyBvbiBzdHJlYW1pbmcgYW5kIERFQ0FERSBoYXMgbm8gc3Vj aCBsaW1pdGF0aW9uLg0KLS0tLS1ZdW5mZWk6DQpJbiB0aGUgbGFzdCB3ZWVrIFBQU1AgYmFyIGJv ZiwgYWN1dGFsbHkgdGhlcmUgYXJlIHN1Z2dlc3Rpb25zIHRvIGV4cGxvcmUgbW9yZSBzZXJ2aWNl cyBwb3NzaWJsaXR5LCBlLmcuLCBmaWxlIHNoYXJpbmcuU28gd2VsY29tZSB0byBkaXNjdXNzIHRo ZSBzY29wZSBpbiBQUFNQIG1haWxpbmcgbGlzdC4NClBQU1AgaXMgYWxzbyBhbiB2ZXJ5IGludGVy ZXN0aW5nIHRvcGljLiBJJ20gc3RpbGwgbG9va2luZyBmb3J3YXJkIHRvIHRoZSBtZWV0aW5nIG1p bnV0ZXMgb2YgUFBTUC4NCll1bmZlaS0tLQ0KVGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgaW50ZXJl c3QgaW4gUFBTUC5UaGUgbWVldGluZyBtaW51dGVzIGlzIHRvIGJlIHB1Ymxpc2hlZCBzb29uLlZp Y3RvciB3aWxsIHBvc3QgaXQgaW4gdGhlIG1haWxpbmcgbGlzdC4NCkNvdWxkIHlvdSBsaXN0IG90 aGVyIGluaXRpYXRpdmVzIHRoYXQgaXMgaW5jZW50aXZlZCBieSAiZGVjb3VwbGUgIHNpZ25hbGlu ZyAgYW5kICBkYXRhICB0cmFuc21pc3Npb24gb24gY2FjaGUgIiAsIHNvIHdlIGNhbiBtYWtlIGEg ZGVlcCBhbmQgd2lkZSBjb21wYXJpc29uLiBUaGF0IHdpbGwgYmUgcmVhbGx5IGhlbHBmdWwuDQpZ dW5mZWktLS0NCkh1bS4uSSB0aGluayB0aGUgbW9zdCBhdHRhY3RpbmcgcG9pbnQgaXMgdG8gcmVk dWNlIHRoZSB1cGxpbmsgcHJlc3N1cmUuDQoNClJlZ2FyZHMNCllpbmdqaWUgR3UNCg0KDQoNCg0K DQpGcm9tOiB6aGFuZ3l1bmZlaSBbbWFpbHRvOnpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDQsIDIwMDkgMTE6NTcgQU0NClRvOiBZLkouIEd1OyBk ZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVjYWRlXSBDb21tZW50IGZvciBtb3RpdmF0 aW9ucyBhbmQgZ29hbHMgb2YgREVDQURFDQoNCg0KUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHRoZSBj b21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgQlINCiAgICAgICAgICAgICAgICAgICAg ICAgWXVuZmVpDQoNCg0KDQoNCiBCZXN0IHJlZ2FyZHMhDQogIFNpbmNlcmVseSB5b3VycywNCiAg ICAgIFl1bmZlaSANCiAgICAgICAyMDA5LTA4LTA0DQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpZdW5mZWkgWmhhbmcsIFBoLkQuDQoNClIm RCwgQ0hJTkEgTU9CSUxFIENPTU1VTklDQVRJT05TIENPUlBPUkFUSU9ODQoNClRlbDogKzg2IDEw IDE1ODAxNjk2NjY4OCBleHQuIDMyNDcNCg0KRmF4OiArODYgMTAgNjM2MDEwODcNCg0KTU9CSUxF OiAxMzYwLTEwMzItMTE5DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQoNCg0KDQoNCreivP7Iy6O6IFkuSi4gR3UNCreiy83Ksbzko7ogMjAw OS0wOC0wMyAxNTozMTo1OA0KytW8/sjLo7ogZGVjYWRlQGlldGYub3JnDQqzrcvNo7ogDQrW98zi o7ogW2RlY2FkZV0gQ29tbWVudCBmb3IgbW90aXZhdGlvbnMgYW5kIGdvYWxzIG9mIERFQ0FERQ0K DQpJICBkaWQgIG5vdCAgYXR0ZW5kICBERUNBREUgIGJhciAgQk9GLCAganVzdCAgZm9sbG93ICB0 aGUgIHByb2dyZXNzICBieSAgYW5hbHl6aW5nDQptZWV0aW5nICBtaW51dGVzLiAgU28sICBmb3Jn aXZlICBtZSAgaWYgIHRoZXJlICBtaWdodCAgYmUgIGFueSAgbWlzdW5kZXJzdGFuZGluZy4gICAg Xl9eDQoNCkkgIG5vdGljZSAgdGhhdCAgYm90aCAgdGhlICAiUHJvYmxlbSAgc3RhdGVtZW50IiAg YW5kICAiQnJhbmNoQ2FjaGUgIHByZXNlbnRhdGlvbiINCnRha2UgICJiYW5kLXNhdmluZyIgIGFz ICBhICBwcmltYXJ5ICBtb3RpdmF0aW9uL2luY2VudGl2ZSAgZm9yICBERUNBREUuDQoNCklNSE8s ICAiYmFuZC1zYXZpbmciICBtaWdodCAgbm90ICBiZSAgYSAgZ29vZCAgcmVhc29uICB0byAgY29u dmluY2UgIElFVEYgIHRvICB3b3JrICBvbg0KREVDQURFICBhbmQgIG1pZ2h0ICBwdXQgIERFQ0FE RSAgaW50byAgbXVjaCAgbW9yZSAgZGViYXRlLiAgVGhlcmUgIGFyZSAgYWxyZWFkeSAgdmFyaW91 cw0KY2FjaGluZyAgb3IgIG5vbi1jYWNoaW5nICBzb2x1dGlvbnMgIGltcGxlbWVudGVkICB0byAg cmVkdWNlICB1cGxpbmsvZG93bmxpbmsNCmJhbmR3aWR0aCwgIGZvciAgYm90aCAgQy9TICBhbmQg IFAyUCAgYXBwbGljYXRpb25zLCAgZS5nLiAgQ0ROLCAgUDJQICBjYWNoaW5nICBhbmQgIERQSS4N ClNvbWUgIG90aGVycyAgYXJlICB1bmRlciAgZGlzY3Vzc2lvbiAgaW4gIG1haWxpbmcgIGxpc3Qs ICBzdWNoICBhcyAgQUxUTy4NCg0KSSAga25vdyAgREVDQURFICBpcyAgZGlmZmVyZW50LCAgYnV0 ICB3aHkgIElFVEYgIG5lZWQgIGFub3RoZXIgICJiYW5kLXNhdmluZyINCnNvbHV0aW9uPyAgVGhh dCdzICBhICBoYXJkICBxdWVzdGlvbi4gIA0KInNhdmluZyAgdXBsaW5rICBpcyAgdG9vICBicm9h ZCAgc2NvcGUiLCAgYXMgIFJpY2ggIHNhaWQuDQoic2F2aW5nICB0aGUgIHVwbGluayAgaXMgIG5v dCAgdGhlICBtYWluICBkcnZpbmcgIGZvcmNlIiwgIHNhaWQgIEx1Y3kgIFlvbmcuDQpJICBhZ3Jl ZSAgd2l0aCAgdGhlbSwgIGl0ICB3aWxsICBtYWtlICB0aGluZ3MgIHRvbyAgY29tcGxpY2F0ZWQu ICBMb29rICBiYWNrICB0aGUNCm1lZXRpbmcgIG1pbnV0ZXMsICBhbmQgIHlvdSAgd2lsbCAgZmlu ZCAgdGhhdCAgNyAgb3V0ICBvZiAgMTUgIHF1ZXN0aW9ucyAgaW4gICJQcm9ibGVtDQpzdGF0ZW1l bnQiICBRJkEgIGFyZSAgYWJvdXQgIGJhbmR3aWR0aC4gIFdlICBkbyAgbm90ICBuZWVkICBtdWx0 aS1tb3RpdmF0aW9ucyAgdG8NCmluZGljYXRlICB0aGUgIGltcG9ydGFuY2UgIG9mICBERUNBREUs ICB3ZSAganVzdCAgbmVlZCAgYW4gIG92ZXJ3aGVsbWluZyAgb25lLg0KDQpUbyAgZGVjb3VwbGUg IHNpZ25hbGluZyAgYW5kICBkYXRhICB0cmFuc21pc3Npb24gIGlzICB0aGUgIHZlcnkgIGluY2Vu dGl2ZSAgdGhhdCAgd2UNCm5lZWQuICBVcCAgdG8gIG5vdywgIHRoZXJlICBpcyAgbm8gIFdHICBp biAgSUVURiAgZXZlciAgaW50ZW5kcyAgdG8gIGFkZHJlc3MgIHRoZSAgdXBkYXRpbmcNCnByZXNz dXJlICB0byAgZXhpc3RpbmcgIGNhY2hlcyAgc3lzdGVtLiAgICBBYnNvcmJpbmcgIHBlb3BsZSdz ICBhdHRlbnRpb24gIG9uICB0aGlzDQphc3BlY3QgIG1pZ2h0ICBoZWxwICB1cyAgY2xhcmlmeSAg dGhlICBuZWNlc3NhcnkgIG9mICBERUNBREUgIG1vcmUgIGNvbnZpbmNpYmx5Lg0KTWFueSBpbml0 aWF0aXZlcyBoYXZlIHNpbWlsYXIgaW5jZW50aXZlLGUuZy4sIFBQU1AgZGVjb3VwbGVzIHNpZ25h bGluZyBhbmQgZGF0YSB0cmFuc21pc3Npb24gYXMgd2VsbCwgd2hpY2ggY2FuIGFsc28gaW5jbHVk ZSBleGlzaXRpbmcgY2FjaGUgc3lzdGVtIGFzIHRoZSBwZWVycy5TbyBJIHRoaW5rIGl0J3MgbW9y ZSBjb252aW5jaW5nIHRvIGZvY3VzIHRoZSBpbmNlbnRpdmUgYW5kIHNjb3BlIG9mIERFQ0FERSBh cyAic2F2aW5nIHVwbGluayB1c2FnZSJhbmQgImRldmVsb3Bpbmcgc2lnbmFsaW5nIHByb3RvY29s IGJldHdlZW4gY2xpZW50IGFuZCBjYWNoZSBub2RlcyIuDQoNCkFuZCAgd2UgIGNhbiAgcmVnYXJk ICAiYmFuZC1zYXZpbmciICBhcyAgYSAgc3Vib3JkaW5hdGUgIGFkdmFudGFnZSwgIGluc3RlYWQg IG9mICBhcyAgYW4NCmluY2VudGl2ZS4NCg0KUmVnYXJkcw0KDQpZaW5namllICBHdQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGVjYWRlICBtYWls aW5nICBsaXN0DQpkZWNhZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGVjYWRlDQo= --=====003_Dragon114316400677_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkw MC4zNDkyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRp b25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5kb3d0ZXh0 Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2UgU2VjdGlv bjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2Vj dGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IaSBZaW5namllLDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyBQbGVhc2Ugc2VlIA0KaW5saW5lIGZvciB0aGUgcmVwbHkuVGhhbmtzITwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KQlI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCll1bmZlaTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+ DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxIUiBzdHlsZT0i V0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+emhhbmd5dW5mZWk8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+MjAwOS0wOC0wNDwv Rk9OVD48L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ DQo8SFI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXpl PTI+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBZLkouIA0KR3U8L0ZPTlQ+PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSj ujwvU1RST05HPiANCjIwMDktMDgtMDQmbmJzcDsxNToyOTo0NTwvRk9OVD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz7K1bz+yMujujwv U1RST05HPiAnemhhbmd5dW5mZWknOyANCmRlY2FkZUBpZXRmLm9yZzwvRk9OVD48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz6zrcvNo7o8 L1NUUk9ORz4gPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxG T05UIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05HPiBSRTogW2RlY2FkZV0gQ29tbWVudCAN CmZvciBtb3RpdmF0aW9ucyBhbmQgZ29hbHMgb2YgREVDQURFPC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz01MTM0MDQ4MDUtMDQwODIwMDk+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IGNvbG9yPSMwMDAwZmYgc2l6ZT01PkhlbGxvIFl1bmZlaSwgdGhhbmsgeW91IGZvciB5b3VyIA0K Y29tbWVudHMuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTUxMzQwNDgwNS0wNDA4MjAwOT48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21h biIgY29sb3I9IzAwMDBmZiBzaXplPTU+Rmlyc3Qgb2YgYWxsLCBJIG5lZWQgdG8gZXhwbGFpbiB0 aGF0IA0Kd2hlbiBJIHNhaWQgIjxGT05UIGNvbG9yPSMwMDAwMDA+ZGVjb3VwbGUgJm5ic3A7c2ln bmFsaW5nICZuYnNwO2FuZCAmbmJzcDtkYXRhIA0KJm5ic3A7dHJhbnNtaXNzaW9uPC9GT05UPiIs IEkgYWN0dWFsbHkgbWVhbiB0aGF0IGNhY2hlIHdpbGwgYWN0IGFzIGEgY29udGVudCANCnN0b3Jh Z2Ugd2l0aG91dCB1bmRlcnN0YW5kaW5nIHZhcmlvdXMgcHJvcHJpZXRhcnkgDQpwcm90b2NvbC4m bmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9NTEzNDA0ODA1LTA0MDgyMDA5PjxGT05UIA0KZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBjb2xvcj0jZmYwMDAwIHNpemU9NT48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTEzNDA0ODA1LTA0MDgyMDA5 PjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMGZmIHNpemU9NT5BcyBt dWNoIGFzIEkga25vdywgUFBTUCBpcyBnb2luZyB0byANCmVzdGFibGlzaCBhIHN0YW5kYXJkIGFy Y2hpdGVjdHVyZSBhbmQgcHJvdG9jb2wgZm9yIFAyUCBzdHJlYW1pbmcuIEkgZ3Vlc3Mgd2hhdCAN CnlvdSBtZWFuIGJ5ICZuYnNwOyI8Rk9OVCBjb2xvcj0jMDAwMDAwPlBQU1AgZGVjb3VwbGVzIHNp Z25hbGluZyBhbmQgZGF0YSANCnRyYW5zbWlzc2lvbjwvRk9OVD4gIiBpcyBQUFNQIHByb3ZpZGVz IGEgdW5pdmVyc2FsIHNpZ25hbGluZywgDQpyZWdhcmRsZXNzJm5ic3A7d2hvJm5ic3A7c3RvcmUm bmJzcDt0aGUgZGF0YSBhbmQgaG93IGl0IGlzJm5ic3A7dHJhbnNtaXR0ZWQgdG8gDQp0ZXJtaW5h bC4mbmJzcDsgVGhhdCBtZWFucywgaW4gUFBTUCwmbmJzcDthbiBvYmplY3Qgd2hvJm5ic3A7cGVy Zm9ybWluZyANCnNpZ25hbGxpbmcmbmJzcDtjb3VsZCBhbHNvIGJlIHRoZSBvbmUgd2hvIHN0b3Jl IGFuZCB0cmFuc21pdCB0aGUgDQpkYXRhLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01MTM0MDQ4MDUtMDQwODIwMDk+PEZPTlQgDQpmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwZmYgc2l6ZT01PlNvLCBJIHRoaW5rIHdlIGFy ZSB0YWxraW5nIGFib3V0IA0KZGlmZmVyZW50IGlzc3Vlcy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0K PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTEzNDA0ODA1LTA0MDgyMDA5PjxG T05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMGZmIHNpemU9NT5CZXNpZGVz LCZuYnNwOyBQUFNQIGZvY3VzIG9uIA0Kc3RyZWFtaW5nIGFuZCBERUNBREUgaGFzIG5vIHN1Y2gg bGltaXRhdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NTEzNDA0ODA1LTA0MDgyMDA5PjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBjb2xvcj0jZmYwMDAwIHNpemU9NT4tLS0tLVl1bmZlaTo8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTEzNDA0ODA1LTA0MDgyMDA5 PjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jZmYwMDAwIHNpemU9NT5JbiB0 aGUgbGFzdCB3ZWVrIFBQU1AgYmFyIGJvZiwgDQphY3V0YWxseSB0aGVyZSBhcmUgc3VnZ2VzdGlv bnMgdG8gZXhwbG9yZSBtb3JlIHNlcnZpY2VzIHBvc3NpYmxpdHksIGUuZy4sIGZpbGUgDQpzaGFy aW5nLlNvIHdlbGNvbWUgdG8gZGlzY3VzcyB0aGUgc2NvcGUgaW4gUFBTUCBtYWlsaW5nIA0KbGlz dC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9NTEzNDA0ODA1LTA0MDgyMDA5PjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xv cj0jMDAwMGZmIHNpemU9NT5QUFNQIGlzIGFsc28gYW4gdmVyeSBpbnRlcmVzdGluZyANCnRvcGlj LiBJJ20gc3RpbGwgbG9va2luZyBmb3J3YXJkIHRvIHRoZSBtZWV0aW5nIG1pbnV0ZXMgb2YgDQpQ UFNQLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz01MTM0MDQ4MDUtMDQwODIwMDk+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNv bG9yPSNmZjAwMDAgc2l6ZT01Pll1bmZlaS0tLTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01MTM0MDQ4MDUtMDQwODIwMDk+PEZPTlQgDQpm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSNmZjAwMDAgc2l6ZT01PlRoYW5rcyBzbyBtdWNo IGZvciB5b3VyIGludGVyZXN0IGluIA0KUFBTUC5UaGUgbWVldGluZyBtaW51dGVzIGlzIHRvIGJl IHB1Ymxpc2hlZCBzb29uLlZpY3RvciB3aWxsIHBvc3QgaXQgaW4gdGhlIA0KbWFpbGluZyBsaXN0 LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz01MTM0MDQ4MDUtMDQwODIwMDk+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9y PSMwMDAwZmYgc2l6ZT01PkNvdWxkIHlvdSBsaXN0IG90aGVyIGluaXRpYXRpdmVzIA0KdGhhdCBp cyBpbmNlbnRpdmVkIGJ5ICI8Rk9OVCBjb2xvcj0jMDAwMDAwPmRlY291cGxlICZuYnNwO3NpZ25h bGluZyAmbmJzcDthbmQgDQombmJzcDtkYXRhICZuYnNwO3RyYW5zbWlzc2lvbiBvbiBjYWNoZTwv Rk9OVD48Rk9OVCBjb2xvcj0jMDAwMGZmPiZuYnNwOyIgLCBzbyB3ZSANCmNhbiBtYWtlIGEgZGVl cCBhbmQgd2lkZSBjb21wYXJpc29uLiBUaGF0IHdpbGwgYmUgcmVhbGx5IA0KaGVscGZ1bC48L0ZP TlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTUxMzQwNDgwNS0wNDA4MjAwOT48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29s b3I9I2ZmMDAwMCBzaXplPTU+WXVuZmVpLS0tPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTUxMzQwNDgwNS0wNDA4MjAwOT48Rk9OVCANCmZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9I2ZmMDAwMCBzaXplPTU+SHVtLi5JIHRoaW5rIHRo ZSBtb3N0IGF0dGFjdGluZyANCnBvaW50IGlzIHRvIHJlZHVjZSB0aGUgdXBsaW5rIHByZXNzdXJl LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0 PjxGT05UIHNpemU9Mj4NCjxQIGNsYXNzPU1zb1NhbHV0YXRpb24gc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiIGFsaWduPWxlZnQ+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6IMvOzOU7IG1z by1hc2NpaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWwi PjwvU1BBTj48U1BBTiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBhbGlnbj1sZWZ0PjxTUEFO IA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogMTUwJTsgRk9OVC1GQU1JTFk6 IMvOzOU7IG1zby1hc2NpaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1oYW5zaS1mb250LWZhbWls eTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYmlkaS1mb250LWZhbWls eTogQXJpYWwiPjxGT05UIA0Kc2l6ZT00PlJlZ2FyZHM8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiAxNTAlOyBGT05U LUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCnNpemU9 ND5ZaW5namllIEd1PC9GT05UPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjxC Uj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz16aC1jbiBkaXI9bHRyIGFs aWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+ RnJvbTo8L0I+IHpoYW5neXVuZmVpIA0KW21haWx0bzp6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5j b21dIDxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwgQXVndXN0IDA0LCAyMDA5IA0KMTE6NTcgQU08 QlI+PEI+VG86PC9CPiBZLkouIEd1OyBkZWNhZGVAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+ IFJlOiBbZGVjYWRlXSANCkNvbW1lbnQgZm9yIG1vdGl2YXRpb25zIGFuZCBnb2FscyBvZiBERUNB REU8QlI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj5QbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhlIA0KY29t bWVudHMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDBm ZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s b3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpCUjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K WXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y Pg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPSMwMDAwZmY+DQo8SFIgc3R5bGU9IldJRFRI OiAxMjJweDsgSEVJR0hUOiAycHgiIFNJWkU9Mj4NCjwvRk9OVD48L0RJVj4NCjxESVYgYWxpZ249 bGVmdD48Rk9OVCBjb2xvcj0jMDAwMGZmPiZuYnNwO0Jlc3QgcmVnYXJkcyE8QlI+Jm5ic3A7IFNp bmNlcmVseSANCnlvdXJzLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWXVuZmVp IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjIwMDktMDgtMDQ8 QlI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPSMwMDAwZmY+WXVuZmVpIFpoYW5nLCBQaC5E LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwMDBmZj5SJmFtcDtELCBDSElOQSBN T0JJTEUgQ09NTVVOSUNBVElPTlMgDQpDT1JQT1JBVElPTjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+PEZP TlQgY29sb3I9IzAwMDBmZj5UZWw6ICs4NiAxMCAxNTgwMTY5NjY2ODggZXh0LiANCjMyNDc8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJViBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPSMwMDAwZmY+RmF4OiArODYgMTAgNjM2MDEwODc8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPSMwMDAwZmY+TU9CSUxFOiAxMzYwLTEwMzIt MTE5PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCANCmNvbG9yPSMwMDAwZmY+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+PC9GT05UPjwvRElW PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxIUj4NCjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05H PreivP7Iy6O6PC9TVFJPTkc+IFkuSi4gDQpHdTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+ IA0KMjAwOS0wOC0wMyZuYnNwOzE1OjMxOjU4PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IA0K ZGVjYWRlQGlldGYub3JnPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hPjxGT05UIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6 PC9TVFJPTkc+IFtkZWNhZGVdIENvbW1lbnQgZm9yIA0KbW90aXZhdGlvbnMgYW5kIGdvYWxzIG9m IERFQ0FERTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0K PERJVj5JICZuYnNwO2RpZCAmbmJzcDtub3QgJm5ic3A7YXR0ZW5kICZuYnNwO0RFQ0FERSAmbmJz cDtiYXIgJm5ic3A7Qk9GLCANCiZuYnNwO2p1c3QgJm5ic3A7Zm9sbG93ICZuYnNwO3RoZSAmbmJz cDtwcm9ncmVzcyAmbmJzcDtieSAmbmJzcDthbmFseXppbmc8L0RJVj4NCjxESVY+bWVldGluZyAm bmJzcDttaW51dGVzLiAmbmJzcDtTbywgJm5ic3A7Zm9yZ2l2ZSAmbmJzcDttZSAmbmJzcDtpZiAN CiZuYnNwO3RoZXJlICZuYnNwO21pZ2h0ICZuYnNwO2JlICZuYnNwO2FueSAmbmJzcDttaXN1bmRl cnN0YW5kaW5nLiAmbmJzcDsgDQombmJzcDteX148L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPkkgJm5ic3A7bm90aWNlICZuYnNwO3RoYXQgJm5ic3A7Ym90aCAmbmJzcDt0aGUgJm5ic3A7 IlByb2JsZW0gDQombmJzcDtzdGF0ZW1lbnQiICZuYnNwO2FuZCAmbmJzcDsiQnJhbmNoQ2FjaGUg Jm5ic3A7cHJlc2VudGF0aW9uIjwvRElWPg0KPERJVj50YWtlICZuYnNwOyJiYW5kLXNhdmluZyIg Jm5ic3A7YXMgJm5ic3A7YSAmbmJzcDtwcmltYXJ5IA0KJm5ic3A7bW90aXZhdGlvbi9pbmNlbnRp dmUgJm5ic3A7Zm9yICZuYnNwO0RFQ0FERS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PklNSE8sICZuYnNwOyJiYW5kLXNhdmluZyIgJm5ic3A7bWlnaHQgJm5ic3A7bm90ICZuYnNwO2Jl ICZuYnNwO2EgJm5ic3A7Z29vZCANCiZuYnNwO3JlYXNvbiAmbmJzcDt0byAmbmJzcDtjb252aW5j ZSAmbmJzcDtJRVRGICZuYnNwO3RvICZuYnNwO3dvcmsgDQombmJzcDtvbjwvRElWPg0KPERJVj5E RUNBREUgJm5ic3A7YW5kICZuYnNwO21pZ2h0ICZuYnNwO3B1dCAmbmJzcDtERUNBREUgJm5ic3A7 aW50byAmbmJzcDttdWNoIA0KJm5ic3A7bW9yZSAmbmJzcDtkZWJhdGUuICZuYnNwO1RoZXJlICZu YnNwO2FyZSAmbmJzcDthbHJlYWR5ICZuYnNwO3ZhcmlvdXM8L0RJVj4NCjxESVY+Y2FjaGluZyAm bmJzcDtvciAmbmJzcDtub24tY2FjaGluZyAmbmJzcDtzb2x1dGlvbnMgJm5ic3A7aW1wbGVtZW50 ZWQgDQombmJzcDt0byAmbmJzcDtyZWR1Y2UgJm5ic3A7dXBsaW5rL2Rvd25saW5rPC9ESVY+DQo8 RElWPmJhbmR3aWR0aCwgJm5ic3A7Zm9yICZuYnNwO2JvdGggJm5ic3A7Qy9TICZuYnNwO2FuZCAm bmJzcDtQMlAgDQombmJzcDthcHBsaWNhdGlvbnMsICZuYnNwO2UuZy4gJm5ic3A7Q0ROLCAmbmJz cDtQMlAgJm5ic3A7Y2FjaGluZyAmbmJzcDthbmQgDQombmJzcDtEUEkuPC9ESVY+DQo8RElWPlNv bWUgJm5ic3A7b3RoZXJzICZuYnNwO2FyZSAmbmJzcDt1bmRlciAmbmJzcDtkaXNjdXNzaW9uICZu YnNwO2luIA0KJm5ic3A7bWFpbGluZyAmbmJzcDtsaXN0LCAmbmJzcDtzdWNoICZuYnNwO2FzICZu YnNwO0FMVE8uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JICZuYnNwO2tub3cgJm5i c3A7REVDQURFICZuYnNwO2lzICZuYnNwO2RpZmZlcmVudCwgJm5ic3A7YnV0ICZuYnNwO3doeSAN CiZuYnNwO0lFVEYgJm5ic3A7bmVlZCAmbmJzcDthbm90aGVyICZuYnNwOyJiYW5kLXNhdmluZyI8 L0RJVj4NCjxESVY+c29sdXRpb24/ICZuYnNwO1RoYXQncyAmbmJzcDthICZuYnNwO2hhcmQgJm5i c3A7cXVlc3Rpb24uICZuYnNwOzwvRElWPg0KPERJVj4ic2F2aW5nICZuYnNwO3VwbGluayAmbmJz cDtpcyAmbmJzcDt0b28gJm5ic3A7YnJvYWQgJm5ic3A7c2NvcGUiLCAmbmJzcDthcyANCiZuYnNw O1JpY2ggJm5ic3A7c2FpZC48L0RJVj4NCjxESVY+InNhdmluZyAmbmJzcDt0aGUgJm5ic3A7dXBs aW5rICZuYnNwO2lzICZuYnNwO25vdCAmbmJzcDt0aGUgJm5ic3A7bWFpbiANCiZuYnNwO2Rydmlu ZyAmbmJzcDtmb3JjZSIsICZuYnNwO3NhaWQgJm5ic3A7THVjeSAmbmJzcDtZb25nLjwvRElWPg0K PERJVj5JICZuYnNwO2FncmVlICZuYnNwO3dpdGggJm5ic3A7dGhlbSwgJm5ic3A7aXQgJm5ic3A7 d2lsbCAmbmJzcDttYWtlIA0KJm5ic3A7dGhpbmdzICZuYnNwO3RvbyAmbmJzcDtjb21wbGljYXRl ZC4gJm5ic3A7TG9vayAmbmJzcDtiYWNrICZuYnNwO3RoZTwvRElWPg0KPERJVj5tZWV0aW5nICZu YnNwO21pbnV0ZXMsICZuYnNwO2FuZCAmbmJzcDt5b3UgJm5ic3A7d2lsbCAmbmJzcDtmaW5kICZu YnNwO3RoYXQgDQombmJzcDs3ICZuYnNwO291dCAmbmJzcDtvZiAmbmJzcDsxNSAmbmJzcDtxdWVz dGlvbnMgJm5ic3A7aW4gDQombmJzcDsiUHJvYmxlbTwvRElWPg0KPERJVj5zdGF0ZW1lbnQiICZu YnNwO1EmYW1wO0EgJm5ic3A7YXJlICZuYnNwO2Fib3V0ICZuYnNwO2JhbmR3aWR0aC4gJm5ic3A7 V2UgDQombmJzcDtkbyAmbmJzcDtub3QgJm5ic3A7bmVlZCAmbmJzcDttdWx0aS1tb3RpdmF0aW9u cyAmbmJzcDt0bzwvRElWPg0KPERJVj5pbmRpY2F0ZSAmbmJzcDt0aGUgJm5ic3A7aW1wb3J0YW5j ZSAmbmJzcDtvZiAmbmJzcDtERUNBREUsICZuYnNwO3dlIA0KJm5ic3A7anVzdCAmbmJzcDtuZWVk ICZuYnNwO2FuICZuYnNwO292ZXJ3aGVsbWluZyAmbmJzcDtvbmUuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5UbyAmbmJzcDtkZWNvdXBsZSAmbmJzcDtzaWduYWxpbmcgJm5ic3A7YW5k ICZuYnNwO2RhdGEgJm5ic3A7dHJhbnNtaXNzaW9uIA0KJm5ic3A7aXMgJm5ic3A7dGhlICZuYnNw O3ZlcnkgJm5ic3A7aW5jZW50aXZlICZuYnNwO3RoYXQgJm5ic3A7d2U8L0RJVj4NCjxESVY+bmVl ZC4gJm5ic3A7VXAgJm5ic3A7dG8gJm5ic3A7bm93LCAmbmJzcDt0aGVyZSAmbmJzcDtpcyAmbmJz cDtubyAmbmJzcDtXRyANCiZuYnNwO2luICZuYnNwO0lFVEYgJm5ic3A7ZXZlciAmbmJzcDtpbnRl bmRzICZuYnNwO3RvICZuYnNwO2FkZHJlc3MgJm5ic3A7dGhlIA0KJm5ic3A7dXBkYXRpbmc8L0RJ Vj4NCjxESVY+cHJlc3N1cmUgJm5ic3A7dG8gJm5ic3A7ZXhpc3RpbmcgJm5ic3A7Y2FjaGVzICZu YnNwO3N5c3RlbS4gJm5ic3A7IA0KJm5ic3A7QWJzb3JiaW5nICZuYnNwO3Blb3BsZSdzICZuYnNw O2F0dGVudGlvbiAmbmJzcDtvbiAmbmJzcDt0aGlzPC9ESVY+DQo8RElWPmFzcGVjdCAmbmJzcDtt aWdodCAmbmJzcDtoZWxwICZuYnNwO3VzICZuYnNwO2NsYXJpZnkgJm5ic3A7dGhlIA0KJm5ic3A7 bmVjZXNzYXJ5ICZuYnNwO29mICZuYnNwO0RFQ0FERSAmbmJzcDttb3JlICZuYnNwO2NvbnZpbmNp Ymx5LjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmPk1hbnkgaW5pdGlhdGl2ZXMgaGF2 ZSBzaW1pbGFyIGluY2VudGl2ZSxlLmcuLCBQUFNQIA0KZGVjb3VwbGVzIHNpZ25hbGluZyBhbmQg ZGF0YSB0cmFuc21pc3Npb24gYXMgd2VsbCwgd2hpY2ggY2FuIGFsc28gaW5jbHVkZSANCmV4aXNp dGluZyBjYWNoZSBzeXN0ZW0gYXMgdGhlIHBlZXJzLlNvIEkgdGhpbmsgaXQncyBtb3JlIGNvbnZp bmNpbmcgdG8gZm9jdXMgdGhlIA0KaW5jZW50aXZlIGFuZCBzY29wZSBvZiBERUNBREUgYXMgInNh dmluZyB1cGxpbmsgdXNhZ2UiYW5kICJkZXZlbG9waW5nIHNpZ25hbGluZyANCnByb3RvY29sIGJl dHdlZW4gY2xpZW50IGFuZCBjYWNoZSBub2RlcyIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMGZmPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+QW5kICZuYnNwO3dlICZuYnNw O2NhbiAmbmJzcDtyZWdhcmQgJm5ic3A7ImJhbmQtc2F2aW5nIiAmbmJzcDthcyAmbmJzcDthIA0K Jm5ic3A7c3Vib3JkaW5hdGUgJm5ic3A7YWR2YW50YWdlLCAmbmJzcDtpbnN0ZWFkICZuYnNwO29m ICZuYnNwO2FzIA0KJm5ic3A7YW48L0RJVj4NCjxESVY+aW5jZW50aXZlLjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ WWluZ2ppZSAmbmJzcDtHdTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+ZGVjYWRl ICZuYnNwO21haWxpbmcgJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kZWNhZGVAaWV0Zi5vcmc8L0RJ Vj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGU8L0RJ Vj48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon114316400677_=====-- From osh93@etri.re.kr Tue Aug 4 01:59:35 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 B01103A6ED6 for ; Tue, 4 Aug 2009 01:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.651 X-Spam-Level: X-Spam-Status: No, score=-97.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_INFO=1.448, MIME_8BIT_HEADER=0.3, 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 ELJIkG4c4RKQ for ; Tue, 4 Aug 2009 01:59:35 -0700 (PDT) Received: from email2.etri.info (email2.etri.re.kr [129.254.16.132]) by core3.amsl.com (Postfix) with ESMTP id 4D8543A6FC8 for ; Tue, 4 Aug 2009 01:58:40 -0700 (PDT) Received: from SeungHunOhPC ([129.254.232.74]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Aug 2009 17:58:42 +0900 From: =?ks_c_5601-1987?B?v8C9wsjG?= To: , "'Y.J. Gu'" References: <000c01ca14cd$0f5b8df0$400ca40a@china.huawei.com> <4A77DE7B.4000702@intracom.com> In-Reply-To: <4A77DE7B.4000702@intracom.com> Date: Tue, 4 Aug 2009 17:58:29 +0900 Organization: ETRI Message-ID: <007f01ca14e1$bca72c30$35f58490$@re.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoU0zyMIDePoeTTRGWOJ8q5spibYAADhgJg Content-Language: ko X-OriginalArrivalTime: 04 Aug 2009 08:58:42.0256 (UTC) FILETIME=[C4085D00:01CA14E1] Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: osh93@etri.re.kr 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, 04 Aug 2009 08:59:35 -0000 Hello Yingjie, I also have difficult to understand how "cache will act as a content storage w/o understanding various proprietary protocol" is related with " decouple signaling > and data transmission" Please explain more. Thanks in advance, Seung-Hun Oh -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Spiros Spirou Sent: Tuesday, August 04, 2009 4:09 PM To: Y.J. Gu Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE Hi Yingjie, Y.J. Gu wrote: > First of all, I need to explain that when I said "decouple signaling > and data transmission", I actually mean that cache will act as a > content storage without understanding various proprietary protocol. Would you please explain this a bit further? Thanks, Spiros _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From guyingjie@huawei.com Tue Aug 4 02:07: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 233B028C30F for ; Tue, 4 Aug 2009 02:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=0.569, 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 lmHAb5Sx9hVm for ; Tue, 4 Aug 2009 02:07:06 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4575328C312 for ; Tue, 4 Aug 2009 02:07:06 -0700 (PDT) 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 <0KNU00K8YH4AM3@szxga04-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 17:02:34 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNU00GODH4AJ2@szxga04-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 17:02:34 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNU00LYBH49SC@szxml06-in.huawei.com> for decade@ietf.org; Tue, 04 Aug 2009 17:02:34 +0800 (CST) Date: Tue, 04 Aug 2009 17:02:33 +0800 From: "Y.J. Gu" In-reply-to: <4A77DE7B.4000702@intracom.com> To: spis@intracom.com Message-id: <002101ca14e2$4e0427a0$400ca40a@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: AcoU1PM9gBz4URr/RB+jaUM25iGMpwADEUcw Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 09:07:07 -0000 Hi Spiros, I would like to explain this issue from my perspective. Caches are widely deployed in network and serve both C/S and P2P applictions, especially those with large amounts of data. For each application it supports, the existing caches have to understand the corresponding protocol(e.g. BT, Emule) in order to perform singalling and transmit data to the end client. So it's necessary to update caches if a new application needs to be supported. +------------+ | caches | +------------+ 0 & * 0 & * 0 & * +------+ +--------+ +-------+ | BT | |Emule | | CDN | | user | | user | | user | +------+ +---------+ +-------+ 0 is BT protocol & is Emule protocol * is some other protocol Fig 1 existing caching system If we perform signalling among peers or C&S, and let caches store data, things will change. E.g peers negotiate with each other using proprietary protocol and download data from caches using a same protocol. See in Fig2. +------------+ | caches | +------------+ $ $ $ $ $ $ $ $ $ +------+ +--------+ +--------+ | BT | |Emule| | CDN | | user | | user | | user | +-------+ +--------+ +--------+ 0 & * 0 & * 0 & * +-----+ +-------+ +--------+ | BT | |Emule| | CDN | | user| | user | | server| +------+ +--------+ +---------+ 0 is BT protocol & is Emule protocol * is some other protocol $ is a new protocol we need to design in DECADE Fig 2 decouple application and data Does this explaination make sense to you, Spiros? Regards Yingjie Gu -----Original Message----- From: Spiros Spirou [mailto:spis@intracom.com] Sent: Tuesday, August 04, 2009 3:09 PM To: Y.J. Gu Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE Hi Yingjie, Y.J. Gu wrote: > First of all, I need to explain that when I said "decouple signaling > and data transmission", I actually mean that cache will act as a > content storage without understanding various proprietary protocol. Would you please explain this a bit further? Thanks, Spiros From alan@peerapp.com Tue Aug 4 02:27:41 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 0586428C202 for ; Tue, 4 Aug 2009 02:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 OKQcVRdU14Lm for ; Tue, 4 Aug 2009 02:27:40 -0700 (PDT) Received: from mx1.peerapp.com (ded758-win-170-58.netsonic.net [66.180.170.58]) by core3.amsl.com (Postfix) with ESMTP id 0CA793A6FF5 for ; Tue, 4 Aug 2009 02:27:39 -0700 (PDT) Received: from exchange.PEERAPP.com ([212.150.66.66]) by mx1.peerapp.com (8.14.1/8.14.1/SuSE Linux 0.8) with ESMTP id n749UuIO020510; Tue, 4 Aug 2009 04:30:59 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 12:27:26 +0300 Message-ID: In-Reply-To: <003d01ca141d$03e1b090$400ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Comment for motivations and goals of DECADE thread-index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVA= References: <003d01ca141d$03e1b090$400ca40a@china.huawei.com> From: "Alan Arolovitch" Importance: normal Priority: normal To: "Y.J. Gu" , Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 09:27:41 -0000 Yingjie, I agree with the practical test, need to have a caching framework in mind to make the discussion practical I am familiar with two main caching architectures when applied to P2P: - in-line caching=20 cache intermediates transactions between peers, similarly to conventional Web caching -"super-peer" caching=20 peer discovers cache and contacts it separately and in addition to=20 regular peer discovery and swarming Each form of caching has its own advantages, depending on the objectives of application and/or network operator. It seems to me that it is possible to come up with a solution that would accommodate more than one form of caching --alan =20 -------------------------------------------------------------------------= - This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 -------------------------------------------------------------------------= - -----Original Message----- From: Y.J. Gu [mailto:guyingjie@huawei.com]=20 Sent: Monday, August 03, 2009 12:30 PM To: Alan Arolovitch; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE " Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. " Support, a universal protocol should be the final target of DECADE. But, IMHO, at beginning, we should base our discussion on a particular caching form, to avoid abstract discussion. This caching form should be scalable, open architecture and protocol, and, of course, P2P friendly. This could be either an existing caching form or a new one.=20 =20 Regards Yingjie Gu -----Original Message----- From: Alan Arolovitch [mailto:alan@peerapp.com]=20 Sent: Monday, August 03, 2009 4:00 PM To: Y.J. Gu; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE 0.02$ from P2P caching vendor perspective I agree that bandwidth savings as a scope is too narrow and not exclusive enough. P2P caching systems can accommodate a variety of value propositions, including bandwidth savings, SLA assurance and service delivery. Based on discussions spurred by ALTO, it seems that there's a perceived and understood challenge in scaling multi-protocol support of P2P applications Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. Just as HTTP1.1 RFC 2616 doesn't spell out particular caching architecture, but rather standardizes solid protocol-level caching support, that allows to build transparent and non-transparent caching systems based on it. Lastly, on the legal side, I don't think DECADE should focus exclusively on DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content) There is plenty of deployment scenarios that do not fall into this bucket, even though it would be nice if DECADE wasn't in a clear violation of the procedures set by DMCA and other very similar legal acts adopted globally. --alan=20 =20 ------------------------------------------------------------------------ -- This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 ------------------------------------------------------------------------ -- -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu Sent: Monday, August 03, 2009 10:28 AM To: decade@ietf.org Subject: [decade] Comment for motivations and goals of DECADE I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. IMHO, "band-saving" might not be a good reason to convince IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as ALTO. I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question.=20 "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy Yong. I agree with them, it will make things too complicated. Look back the meeting minutes, and you will find that 7 out of 15 questions in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. To decouple signaling and data transmission is the very incentive that we need. Up to now, there is no WG in IETF ever intends to address the updating pressure to existing caches system. Absorbing people's attention on this aspect might help us clarify the necessary of DECADE more convincibly. And we can regard "band-saving" as a subordinate advantage, instead of as an incentive. Regards Yingjie Gu _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade ************************************************************************ ********************* ************************************************************************ ********************* From osh93@etri.re.kr Tue Aug 4 03:24: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 765D13A7009 for ; Tue, 4 Aug 2009 03:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.651 X-Spam-Level: X-Spam-Status: No, score=-97.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_INFO=1.448, MIME_8BIT_HEADER=0.3, 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 UohbF8kCMyiD for ; Tue, 4 Aug 2009 03:24:36 -0700 (PDT) Received: from email2.etri.info (email2.etri.re.kr [129.254.16.132]) by core3.amsl.com (Postfix) with ESMTP id 3481628C32F for ; Tue, 4 Aug 2009 03:23:49 -0700 (PDT) Received: from SeungHunOhPC ([129.254.232.74]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Aug 2009 19:23:52 +0900 From: =?ks_c_5601-1987?B?v8C9wsjG?= To: "'Y.J. Gu'" , References: <4A77DE7B.4000702@intracom.com> <002101ca14e2$4e0427a0$400ca40a@china.huawei.com> In-Reply-To: <002101ca14e2$4e0427a0$400ca40a@china.huawei.com> Date: Tue, 4 Aug 2009 19:23:39 +0900 Organization: ETRI Message-ID: <008001ca14ed$a2872150$e79563f0$@re.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoU1PM9gBz4URr/RB+jaUM25iGMpwADEUcwAAK/7fA= Content-Language: ko X-OriginalArrivalTime: 04 Aug 2009 10:23:52.0493 (UTC) FILETIME=[A9F8A5D0:01CA14ED] Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: osh93@etri.re.kr 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, 04 Aug 2009 10:24:37 -0000 Hello Yingjie Gu, I appreciate for your in-depth explanation. According to your description, "SIGNALING" takes place among the peers and is the proprietary protocol. "DATA TRANSMISSION" takes place between caches and peers of different types and is something (protocol) that DECADE is going to make. In that sense, are 'signaling' and 'data transmission' decoupled? Do I understand correctly? Regards, Seung-Hun Oh -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu Sent: Tuesday, August 04, 2009 6:03 PM To: spis@intracom.com Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE Hi Spiros, I would like to explain this issue from my perspective. Caches are widely deployed in network and serve both C/S and P2P applictions, especially those with large amounts of data. For each application it supports, the existing caches have to understand the corresponding protocol(e.g. BT, Emule) in order to perform singalling and transmit data to the end client. So it's necessary to update caches if a new application needs to be supported. +------------+ | caches | +------------+ 0 & * 0 & * 0 & * +------+ +--------+ +-------+ | BT | |Emule | | CDN | | user | | user | | user | +------+ +---------+ +-------+ 0 is BT protocol & is Emule protocol * is some other protocol Fig 1 existing caching system If we perform signalling among peers or C&S, and let caches store data, things will change. E.g peers negotiate with each other using proprietary protocol and download data from caches using a same protocol. See in Fig2. +------------+ | caches | +------------+ $ $ $ $ $ $ $ $ $ +------+ +--------+ +--------+ | BT | |Emule| | CDN | | user | | user | | user | +-------+ +--------+ +--------+ 0 & * 0 & * 0 & * +-----+ +-------+ +--------+ | BT | |Emule| | CDN | | user| | user | | server| +------+ +--------+ +---------+ 0 is BT protocol & is Emule protocol * is some other protocol $ is a new protocol we need to design in DECADE Fig 2 decouple application and data Does this explaination make sense to you, Spiros? Regards Yingjie Gu -----Original Message----- From: Spiros Spirou [mailto:spis@intracom.com] Sent: Tuesday, August 04, 2009 3:09 PM To: Y.J. Gu Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE Hi Yingjie, Y.J. Gu wrote: > First of all, I need to explain that when I said "decouple signaling > and data transmission", I actually mean that cache will act as a > content storage without understanding various proprietary protocol. Would you please explain this a bit further? Thanks, Spiros _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From alexey.melnikov@isode.com Tue Aug 4 15:08:32 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 08E393A6EB9 for ; Tue, 4 Aug 2009 15:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 LbUMc54tJcuj for ; Tue, 4 Aug 2009 15:08:31 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AB1B23A69ED for ; Tue, 4 Aug 2009 15:08:30 -0700 (PDT) Received: from [92.40.96.132] (92.40.96.132.sub.mbb.three.co.uk [92.40.96.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Aug 2009 23:08:24 +0100 Message-ID: <4A78B137.3020400@isode.com> Date: Tue, 04 Aug 2009 23:07:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Yu-Shun Wang References: <81E94869FA91394CB0D6408786148E9B10471264@TK5EX14MBXC112.redmond.corp.microsoft.com> In-Reply-To: <81E94869FA91394CB0D6408786148E9B10471264@TK5EX14MBXC112.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "decade@ietf.org" Subject: Re: [decade] DECADE Bar BOF follow up 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, 04 Aug 2009 22:08:32 -0000 Yu-Shun Wang wrote: >Hi Everyone, > >First of all, thanks for coming and for a productive discussion. >I think it's fair to say that there are problems in this space >that IETF can and should consider, and also that there are >interests among the participants to work on the problems. >But there are also issues that we definitely should address in >order to move toward a working group. Just to list some high >level points here: > > - in depth investigation on prior work (also justification > on new work) > - applicability > - benefit > - incentives > - some statement on layer 8 issues, esp. on potential > deployment hurdles > - ... > This is a good summary of issues raised during the bar BOF. >Some logistics. > >- Slide decks: > >Alexey mentioned last night after the BoF for us to send the >slides to him, and (presumably) Alexey will find some place >to post the materials, maybe a page on the wiki? > > I've uploaded 4 presentations to the wiki: (Note, these slides are not going to be a part of official IETF 75 proceedings, as this was not an official BOF.) >And yes, the slide deck, at least the BranchCache one, is >pretty big (6MB) due to the animations and diagrams. I'll >try to condense it a bit before posting it. > I couldn't upload this one, as the wiki limits presentations to 1Mb. >- Minutes: > >Haibing and I will combine the minutes and send it to the list. >The chairs would also like to thank Linda and Roni for >volunteering as note takers. > >Next steps: > >Let's continue the discussion on list. Or send a note to >Haibing and I if you are interested on certain aspects >of the problems. We would very much like to shoot for an >official BoF for the next IETF. (And get out of early/late >Bar BoFs!) > >Thanks, >Haiging and Yushun > Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From richard_woundy@cable.comcast.com Tue Aug 4 16:07:04 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 1567A3A70D8 for ; Tue, 4 Aug 2009 16:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.863 X-Spam-Level: X-Spam-Status: No, score=-6.863 tagged_above=-999 required=5 tests=[AWL=1.600, 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 DjQuCOZ2Kf2S for ; Tue, 4 Aug 2009 16:07:03 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id DD40E3A708E for ; Tue, 4 Aug 2009 16:07:02 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.48448515; Tue, 04 Aug 2009 19:06:41 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 19:06:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 19:06:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Comment for motivations and goals of DECADE Thread-Index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IACkdNQ References: <81E94869FA91394CB0D6408786148E9B10483731@TK5EX14MBXC112.redmond.corp.microsoft.com><003701ca140b$fb80f9d0$400ca40a@china.huawei.com> From: "Woundy, Richard" To: "Alan Arolovitch" , "Y.J. Gu" X-OriginalArrivalTime: 04 Aug 2009 23:06:42.0812 (UTC) FILETIME=[3B3513C0:01CA1558] Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 04 Aug 2009 23:07:04 -0000 Yingjie Gu said: >"saving uplink is too broad scope", as Rich said. Alan Arolovitch replied: >I agree that bandwidth savings as a scope is too narrow and not exclusive enough. P2P caching systems can accommodate a variety of value propositions, including bandwidth savings, SLA assurance and service delivery. I agree with Alan that there are different motivations by different members of the overall community for caching. End users may be more interested in faster downloads, while ISPs may be more interested in saving bandwidth. But I had some other tradeoffs in mind when I made my original comment. Some broadband access providers are more constrained on uplink bandwidth, and others are more constrained on downlink bandwidth, depending on their network topologies, eg the relative uplink/downlink bandwidths available across the bottleneck shared links. In addition, some ISPs are more affected (economically) by inbound traffic on backbone interconnects than other ISPs, e.g. see the "bandwidth cost" bullet on slide 8 of http://www.ietf.org/proceedings/75/slides/P2PRG-8.pdf. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Alan Arolovitch Sent: Monday, August 03, 2009 4:00 AM To: Y.J. Gu; decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE 0.02$ from P2P caching vendor perspective I agree that bandwidth savings as a scope is too narrow and not exclusive enough. P2P caching systems can accommodate a variety of value propositions, including bandwidth savings, SLA assurance and service delivery. Based on discussions spurred by ALTO, it seems that there's a perceived and=20 understood challenge in scaling multi-protocol support of P2P applications Maybe DECADE should focus on this narrow protocol problem, and not preclude any particular form of caching systems architectures and/or P2P applications types. Just as HTTP1.1 RFC 2616 doesn't spell out particular caching architecture, but=20 rather standardizes solid protocol-level caching support, that allows to build=20 transparent and non-transparent caching systems based on it. Lastly, on the legal side, I don't think DECADE should focus exclusively on DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content) There is plenty of deployment scenarios that do not fall into this bucket, even though it would be nice if DECADE wasn't in a clear violation of the procedures set by DMCA=20 and other very similar legal acts adopted globally. --alan=20 =20 ------------------------------------------------------------------------ -- This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 ------------------------------------------------------------------------ -- -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu Sent: Monday, August 03, 2009 10:28 AM To: decade@ietf.org Subject: [decade] Comment for motivations and goals of DECADE I did not attend DECADE bar BOF, just follow the progress by analyzing meeting minutes. So, forgive me if there might be any misunderstanding. ^_^ I notice that both the "Problem statement" and "BranchCache presentation" take "band-saving" as a primary motivation/incentive for DECADE. IMHO, "band-saving" might not be a good reason to convince IETF to work on DECADE and might put DECADE into much more debate. There are already various caching or non-caching solutions implemented to reduce uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI. Some others are under discussion in mailing list, such as ALTO. I know DECADE is different, but why IETF need another "band-saving" solution? That's a hard question.=20 "saving uplink is too broad scope", as Rich said. "saving the uplink is not the main drving force", said Lucy Yong. I agree with them, it will make things too complicated. Look back the meeting minutes, and you will find that 7 out of 15 questions in "Problem statement" Q&A are about bandwidth. We do not need multi-motivations to indicate the importance of DECADE, we just need an overwhelming one. To decouple signaling and data transmission is the very incentive that we need. Up to now, there is no WG in IETF ever intends to address the updating pressure to existing caches system. Absorbing people's attention on this aspect might help us clarify the necessary of DECADE more convincibly. And we can regard "band-saving" as a subordinate advantage, instead of as an incentive. Regards Yingjie Gu _______________________________________________ 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 guyingjie@huawei.com Tue Aug 4 18:34: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 CB12F3A7133 for ; Tue, 4 Aug 2009 18:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_05=-1.11, 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 Hs5+QRbyihgo for ; Tue, 4 Aug 2009 18:34:39 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1DBC53A70FB for ; Tue, 4 Aug 2009 18:34:21 -0700 (PDT) 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 <0KNV007UVR11ME@szxga02-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 09:34:13 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNV00CAPR115X@szxga02-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 09:34:13 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNV00CXRR104C@szxml06-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 09:34:13 +0800 (CST) Date: Wed, 05 Aug 2009 09:34:13 +0800 From: "Y.J. Gu" In-reply-to: <008001ca14ed$a2872150$e79563f0$@re.kr> To: osh93@etri.re.kr, spis@intracom.com Message-id: <001201ca156c$d6b9ea00$400ca40a@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: AcoU1PM9gBz4URr/RB+jaUM25iGMpwADEUcwAAK/7fAAH57q0A== Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 01:34:39 -0000 To Seung-Hun: Yes, that's what I mean. To Alan: It depends on the concept of DECADE. When the mailing list make out what DECADE is going to do, then folks can figure out what kind of form is acceptable to most people. Regards Yingjie Gu From melodysong@huawei.com Wed Aug 5 00:39:48 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 EC2CA28C50D for ; Wed, 5 Aug 2009 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=2.213, 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 PKAEr2Fs6OOd for ; Wed, 5 Aug 2009 00:39:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4867E28C2D8 for ; Wed, 5 Aug 2009 00:39:46 -0700 (PDT) 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 <0KNW00C7H7TIFL@szxga04-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 15:36:55 +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 <0KNW0020S7TI5B@szxga04-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 15:36:54 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW008NL7TG04@szxml04-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 15:36:54 +0800 (CST) Date: Wed, 05 Aug 2009 15:36:52 +0800 From: Song Haibin In-reply-to: To: 'Alan Arolovitch' , "'Y.J. Gu'" , decade@ietf.org Message-id: <00b601ca159f$80561930$0f0ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUA== Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 07:39:49 -0000 Hi Alan, >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Alan Arolovitch >Sent: Tuesday, August 04, 2009 5:27 PM >To: Y.J. Gu; decade@ietf.org >Subject: Re: [decade] Comment for motivations and goals of DECADE > >Yingjie, > >I agree with the practical test, need to have a caching >framework in mind to make the discussion practical I am >familiar with two main caching architectures when applied to P2P: > >- in-line caching > cache intermediates transactions between peers, similarly to > conventional Web caching >-"super-peer" caching > peer discovers cache and contacts it separately and in >addition to > regular peer discovery and swarming > >Each form of caching has its own advantages, depending on the >objectives of application and/or network operator. >It seems to me that it is possible to come up with a solution >that would accommodate more than one form of caching > I would like to find another term instead of "cache". Because the existing P2P "cache" system is either transparent or non-transparent, which are all application protocol aware. What we want to develop is an application protocol agnostic framework, esp. the standard protocol(s) (control and data transport) spoken between the peers and the in-network storage, in order to minimize the complexity of supporting various and continuous changing p2p application protocols on existing cache systems, and also save bandwidth for ISPs. The final solution could be used by both p2p and c/s applications. The access control and resource control on the sharing model are important. BR, Haibin >--alan > > > >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Y.J. Gu [mailto:guyingjie@huawei.com] >Sent: Monday, August 03, 2009 12:30 PM >To: Alan Arolovitch; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >" Maybe DECADE should focus on this narrow protocol problem, >and not preclude any particular form of caching systems >architectures and/or P2P applications types. " > >Support, a universal protocol should be the final target of DECADE. >But, IMHO, at beginning, we should base our discussion on a >particular caching form, to avoid abstract discussion. >This caching form should be scalable, open architecture and >protocol, and, of course, P2P friendly. >This could be either an existing caching form or a new one. > > > > >Regards > >Yingjie Gu > > >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com] >Sent: Monday, August 03, 2009 4:00 PM >To: Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >0.02$ from P2P caching vendor perspective > >I agree that bandwidth savings as a scope is too narrow and >not exclusive enough. >P2P caching systems can accommodate a variety of value >propositions, including bandwidth savings, SLA assurance and >service delivery. >Based on discussions spurred by ALTO, it seems that there's a >perceived and understood challenge in scaling multi-protocol >support of P2P applications Maybe DECADE should focus on this >narrow protocol problem, and not preclude any particular form >of caching systems architectures and/or P2P applications types. >Just as HTTP1.1 RFC 2616 doesn't spell out particular caching >architecture, but rather standardizes solid protocol-level >caching support, that allows to build transparent and >non-transparent caching systems based on it. > >Lastly, on the legal side, I don't think DECADE should focus >exclusively on DMCA agenda (i.e. >caching-of-potentially-copyright-infringing-content) >There is plenty of deployment scenarios that do not fall into >this bucket, even though it would be nice if DECADE wasn't in >a clear violation of the procedures set by DMCA and other very >similar legal acts adopted globally. > >--alan > > > >--------------------------------------------------------------- >--------- >-- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >--------- >-- >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Y.J. Gu >Sent: Monday, August 03, 2009 10:28 AM >To: decade@ietf.org >Subject: [decade] Comment for motivations and goals of DECADE > >I did not attend DECADE bar BOF, just follow the progress by >analyzing meeting minutes. So, forgive me if there might be >any misunderstanding. >^_^ > >I notice that both the "Problem statement" and "BranchCache >presentation" >take "band-saving" as a primary motivation/incentive for DECADE. > >IMHO, "band-saving" might not be a good reason to convince >IETF to work on DECADE and might put DECADE into much more >debate. There are already various caching or non-caching >solutions implemented to reduce uplink/downlink bandwidth, for >both C/S and P2P applications, e.g. CDN, P2P caching and DPI. >Some others are under discussion in mailing list, such as ALTO. > >I know DECADE is different, but why IETF need another "band-saving" >solution? That's a hard question. >"saving uplink is too broad scope", as Rich said. >"saving the uplink is not the main drving force", said Lucy Yong. >I agree with them, it will make things too complicated. Look >back the meeting minutes, and you will find that 7 out of 15 >questions in "Problem statement" Q&A are about bandwidth. We >do not need multi-motivations to indicate the importance of >DECADE, we just need an overwhelming one. > >To decouple signaling and data transmission is the very >incentive that we need. Up to now, there is no WG in IETF ever >intends to address the updating pressure to existing caches >system. Absorbing people's attention on this aspect might >help us clarify the necessary of DECADE more convincibly. > >And we can regard "band-saving" as a subordinate advantage, >instead of as an incentive. > >Regards > >Yingjie Gu > >_______________________________________________ >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 alan@peerapp.com Wed Aug 5 01:10:26 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 307883A7175 for ; Wed, 5 Aug 2009 01:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 haFlZ5b0q1Ns for ; Wed, 5 Aug 2009 01:10:25 -0700 (PDT) Received: from mx1.peerapp.com (ded758-win-170-58.netsonic.net [66.180.170.58]) by core3.amsl.com (Postfix) with ESMTP id 84B543A6F0A for ; Wed, 5 Aug 2009 01:10:24 -0700 (PDT) Received: from exchange.PEERAPP.com ([212.150.66.66]) by mx1.peerapp.com (8.14.1/8.14.1/SuSE Linux 0.8) with ESMTP id n758DMgN026615; Wed, 5 Aug 2009 03:13:24 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 11:09:37 +0300 Message-ID: In-Reply-To: <00b601ca159f$80561930$0f0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Comment for motivations and goals of DECADE thread-index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUIAACwRg References: <00b601ca159f$80561930$0f0ca40a@china.huawei.com> From: "Alan Arolovitch" Importance: normal To: "Song Haibin" , "Y.J. Gu" , Priority: normal Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 08:10:26 -0000 Haibin, I think we're in agreement on these high-level objectives When we talk about the standardized communications between peers and=20 in-network storage, it is common to think of content retrieval. The acquisition of content by in-network storage from P2P applications=20 is as important, and in fact may be more difficult to make=20 application/protocol agnostic. Also, is it the intention to use RELOAD work for in-network storage discovery? --alan =20 -------------------------------------------------------------------------= - This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 -------------------------------------------------------------------------= - -----Original Message----- From: Song Haibin [mailto:melodysong@huawei.com]=20 Sent: Wednesday, August 05, 2009 10:37 AM To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE Hi Alan, >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 >On Behalf Of Alan Arolovitch >Sent: Tuesday, August 04, 2009 5:27 PM >To: Y.J. Gu; decade@ietf.org >Subject: Re: [decade] Comment for motivations and goals of DECADE > >Yingjie, > >I agree with the practical test, need to have a caching=20 >framework in mind to make the discussion practical I am=20 >familiar with two main caching architectures when applied to P2P: > >- in-line caching=20 > cache intermediates transactions between peers, similarly to > conventional Web caching >-"super-peer" caching=20 > peer discovers cache and contacts it separately and in=20 >addition to=20 > regular peer discovery and swarming > >Each form of caching has its own advantages, depending on the=20 >objectives of application and/or network operator. >It seems to me that it is possible to come up with a solution=20 >that would accommodate more than one form of caching > I would like to find another term instead of "cache". Because the existing P2P "cache" system is either transparent or non-transparent, which are all application protocol aware. What we want to develop is an application protocol agnostic framework, esp. the standard protocol(s) (control and data transport) spoken between the peers and the in-network storage, in order to minimize the complexity of supporting various and continuous changing p2p application protocols on existing cache systems, and also save bandwidth for ISPs. The final solution could be used by both p2p and c/s applications. The access control and resource control on the sharing model are important. BR, Haibin >--alan > > >=20 >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. >=20 >=20 >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Y.J. Gu [mailto:guyingjie@huawei.com] >Sent: Monday, August 03, 2009 12:30 PM >To: Alan Arolovitch; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >" Maybe DECADE should focus on this narrow protocol problem,=20 >and not preclude any particular form of caching systems=20 >architectures and/or P2P applications types. " > >Support, a universal protocol should be the final target of DECADE. >But, IMHO, at beginning, we should base our discussion on a=20 >particular caching form, to avoid abstract discussion. >This caching form should be scalable, open architecture and=20 >protocol, and, of course, P2P friendly. >This could be either an existing caching form or a new one.=20 > >=20 > > >Regards > >Yingjie Gu > > >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com] >Sent: Monday, August 03, 2009 4:00 PM >To: Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >0.02$ from P2P caching vendor perspective > >I agree that bandwidth savings as a scope is too narrow and=20 >not exclusive enough. >P2P caching systems can accommodate a variety of value=20 >propositions, including bandwidth savings, SLA assurance and=20 >service delivery. >Based on discussions spurred by ALTO, it seems that there's a=20 >perceived and understood challenge in scaling multi-protocol=20 >support of P2P applications Maybe DECADE should focus on this=20 >narrow protocol problem, and not preclude any particular form=20 >of caching systems architectures and/or P2P applications types. >Just as HTTP1.1 RFC 2616 doesn't spell out particular caching=20 >architecture, but rather standardizes solid protocol-level=20 >caching support, that allows to build transparent and=20 >non-transparent caching systems based on it. > >Lastly, on the legal side, I don't think DECADE should focus=20 >exclusively on DMCA agenda (i.e.=20 >caching-of-potentially-copyright-infringing-content) >There is plenty of deployment scenarios that do not fall into=20 >this bucket, even though it would be nice if DECADE wasn't in=20 >a clear violation of the procedures set by DMCA and other very=20 >similar legal acts adopted globally. > >--alan=20 > > >=20 >--------------------------------------------------------------- >--------- >-- >This e-mail Contains PeerApp Proprietary and Confidential information. >=20 >=20 >--------------------------------------------------------------- >--------- >-- >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 >On Behalf Of Y.J. Gu >Sent: Monday, August 03, 2009 10:28 AM >To: decade@ietf.org >Subject: [decade] Comment for motivations and goals of DECADE > >I did not attend DECADE bar BOF, just follow the progress by=20 >analyzing meeting minutes. So, forgive me if there might be=20 >any misunderstanding. >^_^ > >I notice that both the "Problem statement" and "BranchCache=20 >presentation" >take "band-saving" as a primary motivation/incentive for DECADE. > >IMHO, "band-saving" might not be a good reason to convince=20 >IETF to work on DECADE and might put DECADE into much more=20 >debate. There are already various caching or non-caching=20 >solutions implemented to reduce uplink/downlink bandwidth, for=20 >both C/S and P2P applications, e.g. CDN, P2P caching and DPI. >Some others are under discussion in mailing list, such as ALTO. > >I know DECADE is different, but why IETF need another "band-saving" >solution? That's a hard question.=20 >"saving uplink is too broad scope", as Rich said. >"saving the uplink is not the main drving force", said Lucy Yong. >I agree with them, it will make things too complicated. Look=20 >back the meeting minutes, and you will find that 7 out of 15=20 >questions in "Problem statement" Q&A are about bandwidth. We=20 >do not need multi-motivations to indicate the importance of=20 >DECADE, we just need an overwhelming one. > >To decouple signaling and data transmission is the very=20 >incentive that we need. Up to now, there is no WG in IETF ever=20 >intends to address the updating pressure to existing caches=20 >system. Absorbing people's attention on this aspect might=20 >help us clarify the necessary of DECADE more convincibly. > >And we can regard "band-saving" as a subordinate advantage,=20 >instead of as an incentive. > >Regards > >Yingjie Gu > >_______________________________________________ >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 melodysong@huawei.com Wed Aug 5 01:13:12 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 82A933A718D for ; Wed, 5 Aug 2009 01:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.845, 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 CBXO-FT9M236 for ; Wed, 5 Aug 2009 01:13:11 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1A5193A6F0A for ; Wed, 5 Aug 2009 01:13:11 -0700 (PDT) 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 <0KNW00HE69GMYW@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:12:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW00D089GMGE@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:12:22 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW007OO9GMZY@szxml04-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:12:22 +0800 (CST) Date: Wed, 05 Aug 2009 16:12:22 +0800 From: Song Haibin In-reply-to: To: "'Woundy, Richard'" , 'Alan Arolovitch' , "'Y.J. Gu'" Message-id: <00be01ca15a4$75ae2f90$0f0ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IACkdNQgACRmTA= Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 08:13:12 -0000 Hi Rich, >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Woundy, Richard >Sent: Wednesday, August 05, 2009 7:06 AM >To: Alan Arolovitch; Y.J. Gu >Cc: decade@ietf.org >Subject: Re: [decade] Comment for motivations and goals of DECADE > >Yingjie Gu said: > >>"saving uplink is too broad scope", as Rich said. > >Alan Arolovitch replied: > >>I agree that bandwidth savings as a scope is too narrow and not >exclusive enough. P2P caching systems can accommodate a >variety of value propositions, including bandwidth savings, >SLA assurance and service delivery. > >I agree with Alan that there are different motivations by >different members of the overall community for caching. End >users may be more interested in faster downloads, while ISPs >may be more interested in saving bandwidth. > Agree. Besides that, the cache system providers may be more interested in their maintenance cost. >But I had some other tradeoffs in mind when I made my original comment. >Some broadband access providers are more constrained on uplink >bandwidth, and others are more constrained on downlink >bandwidth, depending on their network topologies, eg the >relative uplink/downlink bandwidths available across the >bottleneck shared links. > >In addition, some ISPs are more affected (economically) by >inbound traffic on backbone interconnects than other ISPs, >e.g. see the "bandwidth cost" bullet on slide 8 of >http://www.ietf.org/proceedings/75/slides/P2PRG-8.pdf. Thanks. I think ISPs would like to save both uplink and downlink bandwidths whenever possible. It will depend on the deployment to save downlink or inbound backbone bandwidths sometimes. BR, Haibin > >-- Rich > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Alan Arolovitch >Sent: Monday, August 03, 2009 4:00 AM >To: Y.J. Gu; decade@ietf.org >Subject: Re: [decade] Comment for motivations and goals of DECADE > >0.02$ from P2P caching vendor perspective > >I agree that bandwidth savings as a scope is too narrow and >not exclusive enough. >P2P caching systems can accommodate a variety of value >propositions, including bandwidth savings, SLA assurance and >service delivery. >Based on discussions spurred by ALTO, it seems that there's a >perceived and understood challenge in scaling multi-protocol >support of P2P applications Maybe DECADE should focus on this >narrow protocol problem, and not preclude any particular form >of caching systems architectures and/or P2P applications types. >Just as HTTP1.1 RFC 2616 doesn't spell out particular caching >architecture, but rather standardizes solid protocol-level >caching support, that allows to build transparent and >non-transparent caching systems based on it. > >Lastly, on the legal side, I don't think DECADE should focus >exclusively on DMCA agenda (i.e. >caching-of-potentially-copyright-infringing-content) >There is plenty of deployment scenarios that do not fall into >this bucket, even though it would be nice if DECADE wasn't in >a clear violation of the procedures set by DMCA and other very >similar legal acts adopted globally. > >--alan > > > >--------------------------------------------------------------- >--------- >-- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >--------- >-- >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Y.J. Gu >Sent: Monday, August 03, 2009 10:28 AM >To: decade@ietf.org >Subject: [decade] Comment for motivations and goals of DECADE > >I did not attend DECADE bar BOF, just follow the progress by >analyzing meeting minutes. So, forgive me if there might be >any misunderstanding. >^_^ > >I notice that both the "Problem statement" and "BranchCache >presentation" >take "band-saving" as a primary motivation/incentive for DECADE. > >IMHO, "band-saving" might not be a good reason to convince >IETF to work on DECADE and might put DECADE into much more >debate. There are already various caching or non-caching >solutions implemented to reduce uplink/downlink bandwidth, for >both C/S and P2P applications, e.g. CDN, P2P caching and DPI. >Some others are under discussion in mailing list, such as ALTO. > >I know DECADE is different, but why IETF need another "band-saving" >solution? That's a hard question. >"saving uplink is too broad scope", as Rich said. >"saving the uplink is not the main drving force", said Lucy Yong. >I agree with them, it will make things too complicated. Look >back the meeting minutes, and you will find that 7 out of 15 >questions in "Problem statement" Q&A are about bandwidth. We >do not need multi-motivations to indicate the importance of >DECADE, we just need an overwhelming one. > >To decouple signaling and data transmission is the very >incentive that we need. Up to now, there is no WG in IETF ever >intends to address the updating pressure to existing caches >system. Absorbing people's attention on this aspect might >help us clarify the necessary of DECADE more convincibly. > >And we can regard "band-saving" as a subordinate advantage, >instead of as an incentive. > >Regards > >Yingjie Gu > >_______________________________________________ >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 >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From melodysong@huawei.com Wed Aug 5 01:36:17 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 E1AFC3A7187 for ; Wed, 5 Aug 2009 01:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=0.739, 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 E29wiD3Dr4xi for ; Wed, 5 Aug 2009 01:36:16 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 57E5C3A6F0A for ; Wed, 5 Aug 2009 01:36:16 -0700 (PDT) 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 <0KNW00HQ7AHEYW@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:34:26 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW009FHAHE6K@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:34:26 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW00028AHDWE@szxml06-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:34:26 +0800 (CST) Date: Wed, 05 Aug 2009 16:34:25 +0800 From: Song Haibin In-reply-to: To: 'Alan Arolovitch' , "'Y.J. Gu'" , decade@ietf.org Message-id: <00bf01ca15a7$8a6d2190$0f0ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUIAACwRggAAJ77A= Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 08:36:18 -0000 Hi Alan, >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com] >Sent: Wednesday, August 05, 2009 4:10 PM >To: Song Haibin; Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Haibin, > >I think we're in agreement on these high-level objectives When >we talk about the standardized communications between peers >and in-network storage, it is common to think of content retrieval. >The acquisition of content by in-network storage from P2P >applications is as important, and in fact may be more >difficult to make application/protocol agnostic. > It's not content retrieval. It's content store/retrieval. P2P applications users also use the standard protocol (control/data transport) to store content to the in-network storage and share it to other peers. It will be application protocol agnostic. >Also, is it the intention to use RELOAD work for in-network >storage discovery? > We need the discovery for the in-network storage entity for contents, although we don't want to touch the content format itself. The discovery will be based on either application protocols or some other existing mechanisms. BR, Haibin >--alan > > > >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Song Haibin [mailto:melodysong@huawei.com] >Sent: Wednesday, August 05, 2009 10:37 AM >To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Hi Alan, > >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>Behalf Of Alan Arolovitch >>Sent: Tuesday, August 04, 2009 5:27 PM >>To: Y.J. Gu; decade@ietf.org >>Subject: Re: [decade] Comment for motivations and goals of DECADE >> >>Yingjie, >> >>I agree with the practical test, need to have a caching framework in >>mind to make the discussion practical I am familiar with two main >>caching architectures when applied to P2P: >> >>- in-line caching >> cache intermediates transactions between peers, similarly to >> conventional Web caching >>-"super-peer" caching >> peer discovers cache and contacts it separately and in >addition to >> regular peer discovery and swarming >> >>Each form of caching has its own advantages, depending on the >>objectives of application and/or network operator. >>It seems to me that it is possible to come up with a solution that >>would accommodate more than one form of caching >> > >I would like to find another term instead of "cache". Because >the existing P2P "cache" system is either transparent or >non-transparent, which are all application protocol aware. >What we want to develop is an application protocol agnostic >framework, esp. the standard protocol(s) (control and data >transport) spoken between the peers and the in-network >storage, in order to minimize the complexity of supporting >various and continuous changing p2p application protocols on >existing cache systems, and also save bandwidth for ISPs. The >final solution could be used by both p2p and c/s applications. >The >access control and resource control on the sharing model are important. > >BR, >Haibin > > > >>--alan >> >> >> >>--------------------------------------------------------------- >>----------- >>This e-mail Contains PeerApp Proprietary and Confidential information. >> >> >>--------------------------------------------------------------- >>----------- >>-----Original Message----- >>From: Y.J. Gu [mailto:guyingjie@huawei.com] >>Sent: Monday, August 03, 2009 12:30 PM >>To: Alan Arolovitch; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>" Maybe DECADE should focus on this narrow protocol problem, and not >>preclude any particular form of caching systems architectures and/or >>P2P applications types. " >> >>Support, a universal protocol should be the final target of DECADE. >>But, IMHO, at beginning, we should base our discussion on a >particular >>caching form, to avoid abstract discussion. >>This caching form should be scalable, open architecture and protocol, >>and, of course, P2P friendly. >>This could be either an existing caching form or a new one. >> >> >> >> >>Regards >> >>Yingjie Gu >> >> >>-----Original Message----- >>From: Alan Arolovitch [mailto:alan@peerapp.com] >>Sent: Monday, August 03, 2009 4:00 PM >>To: Y.J. Gu; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>0.02$ from P2P caching vendor perspective >> >>I agree that bandwidth savings as a scope is too narrow and not >>exclusive enough. >>P2P caching systems can accommodate a variety of value propositions, >>including bandwidth savings, SLA assurance and service delivery. >>Based on discussions spurred by ALTO, it seems that there's a >perceived >>and understood challenge in scaling multi-protocol support of P2P >>applications Maybe DECADE should focus on this narrow >protocol problem, >>and not preclude any particular form of caching systems architectures >>and/or P2P applications types. >>Just as HTTP1.1 RFC 2616 doesn't spell out particular caching >>architecture, but rather standardizes solid protocol-level caching >>support, that allows to build transparent and non-transparent caching >>systems based on it. >> >>Lastly, on the legal side, I don't think DECADE should focus >>exclusively on DMCA agenda (i.e. >>caching-of-potentially-copyright-infringing-content) >>There is plenty of deployment scenarios that do not fall into this >>bucket, even though it would be nice if DECADE wasn't in a clear >>violation of the procedures set by DMCA and other very similar legal >>acts adopted globally. >> >>--alan >> >> >> >>--------------------------------------------------------------- >>--------- >>-- >>This e-mail Contains PeerApp Proprietary and Confidential information. >> >> >>--------------------------------------------------------------- >>--------- >>-- >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>Behalf Of Y.J. Gu >>Sent: Monday, August 03, 2009 10:28 AM >>To: decade@ietf.org >>Subject: [decade] Comment for motivations and goals of DECADE >> >>I did not attend DECADE bar BOF, just follow the progress by >analyzing >>meeting minutes. So, forgive me if there might be any >misunderstanding. >>^_^ >> >>I notice that both the "Problem statement" and "BranchCache >>presentation" >>take "band-saving" as a primary motivation/incentive for DECADE. >> >>IMHO, "band-saving" might not be a good reason to convince >IETF to work >>on DECADE and might put DECADE into much more debate. There >are already >>various caching or non-caching solutions implemented to reduce >>uplink/downlink bandwidth, for both C/S and P2P applications, >e.g. CDN, >>P2P caching and DPI. >>Some others are under discussion in mailing list, such as ALTO. >> >>I know DECADE is different, but why IETF need another "band-saving" >>solution? That's a hard question. >>"saving uplink is too broad scope", as Rich said. >>"saving the uplink is not the main drving force", said Lucy Yong. >>I agree with them, it will make things too complicated. Look back the >>meeting minutes, and you will find that 7 out of 15 questions in >>"Problem statement" Q&A are about bandwidth. We do not need >>multi-motivations to indicate the importance of DECADE, we >just need an >>overwhelming one. >> >>To decouple signaling and data transmission is the very >incentive that >>we need. Up to now, there is no WG in IETF ever intends to >address the >>updating pressure to existing caches system. Absorbing people's >>attention on this aspect might help us clarify the necessary >of DECADE >>more convincibly. >> >>And we can regard "band-saving" as a subordinate advantage, >instead of >>as an incentive. >> >>Regards >> >>Yingjie Gu >> >>_______________________________________________ >>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 guyingjie@huawei.com Wed Aug 5 01:42:32 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 BFD543A718C for ; Wed, 5 Aug 2009 01:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=0.520, 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 MKgBrpfvtELQ for ; Wed, 5 Aug 2009 01:42:30 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 69C103A7189 for ; Wed, 5 Aug 2009 01:42:30 -0700 (PDT) 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 <0KNW00A7FARL3O@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:40:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW00DY4ARKGE@szxga03-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:40:32 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW000VIARKW8@szxml06-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 16:40:32 +0800 (CST) Date: Wed, 05 Aug 2009 16:40:32 +0800 From: "Y.J. Gu" In-reply-to: To: 'Alan Arolovitch' , 'Song Haibin' , decade@ietf.org Message-id: <001901ca15a8$650313f0$400ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUIAACwRggAAN3RA= Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 08:42:32 -0000 "The acquisition of content by in-network storage from P2P applications is as important, and in fact may be more difficult to make application/protocol agnostic." Good comment. Seems that DECADE wants to design a new access protocol to establish a relationship between peer and in-network storage. Then peer can upload content to in-network storage by RTP, FTP, HTTP,..., the in-network storage need not know what the application protocol is. Regards Yingjie Gu -----Original Message----- From: Alan Arolovitch [mailto:alan@peerapp.com] Sent: Wednesday, August 05, 2009 4:10 PM To: Song Haibin; Y.J. Gu; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE Haibin, I think we're in agreement on these high-level objectives When we talk about the standardized communications between peers and in-network storage, it is common to think of content retrieval. The acquisition of content by in-network storage from P2P applications is as important, and in fact may be more difficult to make application/protocol agnostic. Also, is it the intention to use RELOAD work for in-network storage discovery? --alan -------------------------------------------------------------------------- This e-mail Contains PeerApp Proprietary and Confidential information. -------------------------------------------------------------------------- -----Original Message----- From: Song Haibin [mailto:melodysong@huawei.com] Sent: Wednesday, August 05, 2009 10:37 AM To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE Hi Alan, >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >Behalf Of Alan Arolovitch >Sent: Tuesday, August 04, 2009 5:27 PM >To: Y.J. Gu; decade@ietf.org >Subject: Re: [decade] Comment for motivations and goals of DECADE > >Yingjie, > >I agree with the practical test, need to have a caching framework in >mind to make the discussion practical I am familiar with two main >caching architectures when applied to P2P: > >- in-line caching > cache intermediates transactions between peers, similarly to > conventional Web caching >-"super-peer" caching > peer discovers cache and contacts it separately and in addition to > regular peer discovery and swarming > >Each form of caching has its own advantages, depending on the >objectives of application and/or network operator. >It seems to me that it is possible to come up with a solution that >would accommodate more than one form of caching > I would like to find another term instead of "cache". Because the existing P2P "cache" system is either transparent or non-transparent, which are all application protocol aware. What we want to develop is an application protocol agnostic framework, esp. the standard protocol(s) (control and data transport) spoken between the peers and the in-network storage, in order to minimize the complexity of supporting various and continuous changing p2p application protocols on existing cache systems, and also save bandwidth for ISPs. The final solution could be used by both p2p and c/s applications. The access control and resource control on the sharing model are important. BR, Haibin >--alan > > > >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Y.J. Gu [mailto:guyingjie@huawei.com] >Sent: Monday, August 03, 2009 12:30 PM >To: Alan Arolovitch; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >" Maybe DECADE should focus on this narrow protocol problem, and not >preclude any particular form of caching systems architectures and/or >P2P applications types. " > >Support, a universal protocol should be the final target of DECADE. >But, IMHO, at beginning, we should base our discussion on a particular >caching form, to avoid abstract discussion. >This caching form should be scalable, open architecture and protocol, >and, of course, P2P friendly. >This could be either an existing caching form or a new one. > > > > >Regards > >Yingjie Gu > > >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com] >Sent: Monday, August 03, 2009 4:00 PM >To: Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >0.02$ from P2P caching vendor perspective > >I agree that bandwidth savings as a scope is too narrow and not >exclusive enough. >P2P caching systems can accommodate a variety of value propositions, >including bandwidth savings, SLA assurance and service delivery. >Based on discussions spurred by ALTO, it seems that there's a perceived >and understood challenge in scaling multi-protocol support of P2P >applications Maybe DECADE should focus on this narrow protocol problem, >and not preclude any particular form of caching systems architectures >and/or P2P applications types. >Just as HTTP1.1 RFC 2616 doesn't spell out particular caching >architecture, but rather standardizes solid protocol-level caching >support, that allows to build transparent and non-transparent caching >systems based on it. > >Lastly, on the legal side, I don't think DECADE should focus >exclusively on DMCA agenda (i.e. >caching-of-potentially-copyright-infringing-content) >There is plenty of deployment scenarios that do not fall into this >bucket, even though it would be nice if DECADE wasn't in a clear >violation of the procedures set by DMCA and other very similar legal >acts adopted globally. > >--alan > > > >--------------------------------------------------------------- >--------- >-- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >--------- >-- >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >Behalf Of Y.J. Gu >Sent: Monday, August 03, 2009 10:28 AM >To: decade@ietf.org >Subject: [decade] Comment for motivations and goals of DECADE > >I did not attend DECADE bar BOF, just follow the progress by analyzing >meeting minutes. So, forgive me if there might be any misunderstanding. >^_^ > >I notice that both the "Problem statement" and "BranchCache >presentation" >take "band-saving" as a primary motivation/incentive for DECADE. > >IMHO, "band-saving" might not be a good reason to convince IETF to work >on DECADE and might put DECADE into much more debate. There are already >various caching or non-caching solutions implemented to reduce >uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, >P2P caching and DPI. >Some others are under discussion in mailing list, such as ALTO. > >I know DECADE is different, but why IETF need another "band-saving" >solution? That's a hard question. >"saving uplink is too broad scope", as Rich said. >"saving the uplink is not the main drving force", said Lucy Yong. >I agree with them, it will make things too complicated. Look back the >meeting minutes, and you will find that 7 out of 15 questions in >"Problem statement" Q&A are about bandwidth. We do not need >multi-motivations to indicate the importance of DECADE, we just need an >overwhelming one. > >To decouple signaling and data transmission is the very incentive that >we need. Up to now, there is no WG in IETF ever intends to address the >updating pressure to existing caches system. Absorbing people's >attention on this aspect might help us clarify the necessary of DECADE >more convincibly. > >And we can regard "band-saving" as a subordinate advantage, instead of >as an incentive. > >Regards > >Yingjie Gu > >_______________________________________________ >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 alan@peerapp.com Wed Aug 5 02:03:00 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 20C1A3A711B for ; Wed, 5 Aug 2009 02:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 tSWaQagow-fY for ; Wed, 5 Aug 2009 02:02:59 -0700 (PDT) Received: from mx1.peerapp.com (ded758-win-170-58.netsonic.net [66.180.170.58]) by core3.amsl.com (Postfix) with ESMTP id DB14B28C4ED for ; Wed, 5 Aug 2009 02:02:57 -0700 (PDT) Received: from exchange.PEERAPP.com ([212.150.66.66]) by mx1.peerapp.com (8.14.1/8.14.1/SuSE Linux 0.8) with ESMTP id n7595wff026905; Wed, 5 Aug 2009 04:06:01 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 12:02:19 +0300 Message-ID: In-Reply-To: <00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Comment for motivations and goals of DECADE thread-index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUIAACwRggAAJ77CAAAhmsA== References: <00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> From: "Alan Arolovitch" Importance: normal To: "Song Haibin" , "Y.J. Gu" , Priority: normal Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 09:03:00 -0000 Song, Yingjie, If I follow you correctly, you limit the function of in-network storage=20 to content origination, when all addressable content is always available in the storage. In this case indeed there's a simple flow of sharing content into the storage ("upload") and retrieving it back. You can think of this scenario as P2P-based YouTube service. There are other feasible and interesting scenarios where the in-network storage acts as a cache, when only some of addressable content is available in the storage. It could be because the content is not locally available, to support differentiated=20 service levels or to gain some scalability benefits In this case the in-network storage system would have to acquire content from P2P overlay and/or other forms of networked storage, on its own. --alan =20 -------------------------------------------------------------------------= - This e-mail Contains PeerApp Proprietary and Confidential information. =20 =20 -------------------------------------------------------------------------= - -----Original Message----- From: Song Haibin [mailto:melodysong@huawei.com]=20 Sent: Wednesday, August 05, 2009 11:34 AM To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org Subject: RE: [decade] Comment for motivations and goals of DECADE Hi Alan, =20 >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com]=20 >Sent: Wednesday, August 05, 2009 4:10 PM >To: Song Haibin; Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Haibin, > >I think we're in agreement on these high-level objectives When=20 >we talk about the standardized communications between peers=20 >and in-network storage, it is common to think of content retrieval. >The acquisition of content by in-network storage from P2P=20 >applications is as important, and in fact may be more=20 >difficult to make application/protocol agnostic. > It's not content retrieval. It's content store/retrieval. P2P applications users also use the standard protocol (control/data transport) to store content to the in-network storage and share it to other peers. It will be application protocol agnostic. >Also, is it the intention to use RELOAD work for in-network=20 >storage discovery? > We need the discovery for the in-network storage entity for contents, although we don't want to touch the content format itself. The discovery will be based on either application protocols or some other existing mechanisms. BR, Haibin >--alan > > >=20 >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. >=20 >=20 >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Song Haibin [mailto:melodysong@huawei.com] >Sent: Wednesday, August 05, 2009 10:37 AM >To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Hi Alan, > >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On=20 >>Behalf Of Alan Arolovitch >>Sent: Tuesday, August 04, 2009 5:27 PM >>To: Y.J. Gu; decade@ietf.org >>Subject: Re: [decade] Comment for motivations and goals of DECADE >> >>Yingjie, >> >>I agree with the practical test, need to have a caching framework in=20 >>mind to make the discussion practical I am familiar with two main=20 >>caching architectures when applied to P2P: >> >>- in-line caching=20 >> cache intermediates transactions between peers, similarly to >> conventional Web caching >>-"super-peer" caching=20 >> peer discovers cache and contacts it separately and in=20 >addition to >> regular peer discovery and swarming >> >>Each form of caching has its own advantages, depending on the=20 >>objectives of application and/or network operator. >>It seems to me that it is possible to come up with a solution that=20 >>would accommodate more than one form of caching >> > >I would like to find another term instead of "cache". Because=20 >the existing P2P "cache" system is either transparent or=20 >non-transparent, which are all application protocol aware.=20 >What we want to develop is an application protocol agnostic=20 >framework, esp. the standard protocol(s) (control and data >transport) spoken between the peers and the in-network=20 >storage, in order to minimize the complexity of supporting=20 >various and continuous changing p2p application protocols on=20 >existing cache systems, and also save bandwidth for ISPs. The=20 >final solution could be used by both p2p and c/s applications. >The >access control and resource control on the sharing model are important. > >BR, >Haibin > > > >>--alan >> >> >>=20 >>--------------------------------------------------------------- >>----------- >>This e-mail Contains PeerApp Proprietary and Confidential information. >>=20 >>=20 >>--------------------------------------------------------------- >>----------- >>-----Original Message----- >>From: Y.J. Gu [mailto:guyingjie@huawei.com] >>Sent: Monday, August 03, 2009 12:30 PM >>To: Alan Arolovitch; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>" Maybe DECADE should focus on this narrow protocol problem, and not=20 >>preclude any particular form of caching systems architectures and/or=20 >>P2P applications types. " >> >>Support, a universal protocol should be the final target of DECADE. >>But, IMHO, at beginning, we should base our discussion on a=20 >particular=20 >>caching form, to avoid abstract discussion. >>This caching form should be scalable, open architecture and protocol,=20 >>and, of course, P2P friendly. >>This could be either an existing caching form or a new one.=20 >> >>=20 >> >> >>Regards >> >>Yingjie Gu >> >> >>-----Original Message----- >>From: Alan Arolovitch [mailto:alan@peerapp.com] >>Sent: Monday, August 03, 2009 4:00 PM >>To: Y.J. Gu; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>0.02$ from P2P caching vendor perspective >> >>I agree that bandwidth savings as a scope is too narrow and not=20 >>exclusive enough. >>P2P caching systems can accommodate a variety of value propositions,=20 >>including bandwidth savings, SLA assurance and service delivery. >>Based on discussions spurred by ALTO, it seems that there's a=20 >perceived=20 >>and understood challenge in scaling multi-protocol support of P2P=20 >>applications Maybe DECADE should focus on this narrow=20 >protocol problem,=20 >>and not preclude any particular form of caching systems architectures=20 >>and/or P2P applications types. >>Just as HTTP1.1 RFC 2616 doesn't spell out particular caching=20 >>architecture, but rather standardizes solid protocol-level caching=20 >>support, that allows to build transparent and non-transparent caching=20 >>systems based on it. >> >>Lastly, on the legal side, I don't think DECADE should focus=20 >>exclusively on DMCA agenda (i.e. >>caching-of-potentially-copyright-infringing-content) >>There is plenty of deployment scenarios that do not fall into this=20 >>bucket, even though it would be nice if DECADE wasn't in a clear=20 >>violation of the procedures set by DMCA and other very similar legal=20 >>acts adopted globally. >> >>--alan >> >> >>=20 >>--------------------------------------------------------------- >>--------- >>-- >>This e-mail Contains PeerApp Proprietary and Confidential information. >>=20 >>=20 >>--------------------------------------------------------------- >>--------- >>-- >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On=20 >>Behalf Of Y.J. Gu >>Sent: Monday, August 03, 2009 10:28 AM >>To: decade@ietf.org >>Subject: [decade] Comment for motivations and goals of DECADE >> >>I did not attend DECADE bar BOF, just follow the progress by=20 >analyzing=20 >>meeting minutes. So, forgive me if there might be any=20 >misunderstanding. >>^_^ >> >>I notice that both the "Problem statement" and "BranchCache=20 >>presentation" >>take "band-saving" as a primary motivation/incentive for DECADE. >> >>IMHO, "band-saving" might not be a good reason to convince=20 >IETF to work=20 >>on DECADE and might put DECADE into much more debate. There=20 >are already=20 >>various caching or non-caching solutions implemented to reduce=20 >>uplink/downlink bandwidth, for both C/S and P2P applications,=20 >e.g. CDN,=20 >>P2P caching and DPI. >>Some others are under discussion in mailing list, such as ALTO. >> >>I know DECADE is different, but why IETF need another "band-saving" >>solution? That's a hard question.=20 >>"saving uplink is too broad scope", as Rich said. >>"saving the uplink is not the main drving force", said Lucy Yong. >>I agree with them, it will make things too complicated. Look back the=20 >>meeting minutes, and you will find that 7 out of 15 questions in=20 >>"Problem statement" Q&A are about bandwidth. We do not need=20 >>multi-motivations to indicate the importance of DECADE, we=20 >just need an=20 >>overwhelming one. >> >>To decouple signaling and data transmission is the very=20 >incentive that=20 >>we need. Up to now, there is no WG in IETF ever intends to=20 >address the=20 >>updating pressure to existing caches system. Absorbing people's=20 >>attention on this aspect might help us clarify the necessary=20 >of DECADE=20 >>more convincibly. >> >>And we can regard "band-saving" as a subordinate advantage,=20 >instead of=20 >>as an incentive. >> >>Regards >> >>Yingjie Gu >> >>_______________________________________________ >>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 spis@intracom.com Wed Aug 5 02:30:13 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 B962C28C553 for ; Wed, 5 Aug 2009 02:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 wC4xMR2zsayx for ; Wed, 5 Aug 2009 02:30:12 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.gr [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id 7525628C4B9 for ; Wed, 5 Aug 2009 02:30:12 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n759SgZB028858 for ; Wed, 5 Aug 2009 12:28:42 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n759Sg7s001424 for ; Wed, 5 Aug 2009 12:28:42 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n759Sfdw001419; Wed, 5 Aug 2009 12:28:41 +0300 (EEST) Received: from [146.124.139.213] (HELO [192.168.17.53]) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29953571; Wed, 05 Aug 2009 12:28:40 +0300 Message-Id: From: Spiros Spirou To: "Y.J. Gu" In-Reply-To: <002101ca14e2$4e0427a0$400ca40a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 12:28:39 +0300 References: <002101ca14e2$4e0427a0$400ca40a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 09:30:13 -0000 Hi Yingjie, Many thanks for the elaborate explanation. It's clear that the concept of Fig. 2 provides a protocol target for =20 DECADE. That's the protocol that applications (P2P or C/S) would use =20 to retrieve content from caches (in-network storage). However, I think we need to consider the effects that such a protocol =20= would have on stakeholders (cache vendors, cache owners, app =20 developers, app users, etc.). With the concept of Fig. 1 a cache =20 vendor would have to do more work to support another app, but at the =20 same time she's able to minimize the investment risk both for herself =20= and the cache owner. Everything is under the control of the cache =20 vendor/owner; the cache is ready to work out-of-the-box without =20 dependencies to external factors (e.g., app modifications). On the other hand, the concept of Fig. 2 simplifies the job of the =20 cache vendor/owner, because no extra work is necessary to support a =20 new app. However, unless app developers modify their apps and app =20 users install those apps, the cache will not be effective. In fact, =20 dependence on such many factors under different authorities can make =20 cache success ambiguous. I'm not saying that we should resolve the socio-economic issues of a =20 common app-cache protocol here. (Besides, the existence of such a =20 protocol could handle those issues naturally in the long run). I'm =20 only suggesting that we should discuss the protocol's possibly adverse =20= effects and emphasize stakeholder incentives to mitigate them. Thanks, Spiros On 04 =CE=91=CF=85=CE=B3 2009, at 12:02 =CE=9C=CE=9C, Y.J. Gu wrote: > Caches are widely deployed in network and serve both C/S and P2P > applictions, especially those with large amounts of data. For each > application it supports, the existing caches have to understand the > corresponding protocol(e.g. BT, Emule) in order to perform =20 > singalling and > transmit data to the end client. So it's necessary to update caches =20= > if a new > application needs to be supported. > > +------------+ > | caches | > +------------+ > 0 & * > 0 & * > 0 & * > +------+ +--------+ +-------+ > | BT | |Emule | | CDN | > | user | | user | | user | > +------+ +---------+ +-------+ > 0 is BT protocol > & is Emule protocol > * is some other protocol > Fig 1 existing caching system > > If we perform signalling among peers or C&S, and let caches store =20 > data, > things will change. E.g peers negotiate with each other using =20 > proprietary > protocol and download data from caches using a same protocol. See in =20= > Fig2. > > +------------+ > | caches | > +------------+ > $ $ $ > $ $ $ > $ $ $ > +------+ +--------+ +--------+ > | BT | |Emule| | CDN | > | user | | user | | user | > +-------+ +--------+ +--------+ > 0 & * > 0 & * > 0 & * > +-----+ +-------+ +--------+ > | BT | |Emule| | CDN | > | user| | user | | server| > +------+ +--------+ +---------+ > > 0 is BT protocol > & is Emule protocol > * is some other protocol > $ is a new protocol we need to design in DECADE > Fig 2 decouple application and data > > Does this explaination make sense to you, Spiros? > > > Regards > > Yingjie Gu > From melodysong@huawei.com Wed Aug 5 02:49:52 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 21BBB3A6B19 for ; Wed, 5 Aug 2009 02:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.591, 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 wOFCeysiI0i2 for ; Wed, 5 Aug 2009 02:49:50 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 224963A6AD3 for ; Wed, 5 Aug 2009 02:48:47 -0700 (PDT) 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 <0KNW00FNEDX3FC@szxga01-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 17:48:39 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW007PCDX3HA@szxga01-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 17:48:39 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNW00KU4DX2B5@szxml06-in.huawei.com> for decade@ietf.org; Wed, 05 Aug 2009 17:48:38 +0800 (CST) Date: Wed, 05 Aug 2009 17:48:38 +0800 From: Song Haibin In-reply-to: To: 'Alan Arolovitch' , "'Y.J. Gu'" , decade@ietf.org Message-id: <00c701ca15b1$e883d8f0$0f0ca40a@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: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFggASLvSCAABce0IAAGchAgAGSeVCAAW2NUIAACwRggAAJ77CAAAhmsIAAD2YA Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 09:49:52 -0000 >-----Original Message----- >From: Alan Arolovitch [mailto:alan@peerapp.com] >Sent: Wednesday, August 05, 2009 5:02 PM >To: Song Haibin; Y.J. Gu; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Song, Yingjie, > >If I follow you correctly, you limit the function of >in-network storage to content origination, when all >addressable content is always available > >in the storage. >In this case indeed there's a simple flow of sharing content >into the storage ("upload") and retrieving it back. >You can think of this scenario as P2P-based YouTube service. > >There are other feasible and interesting scenarios where the >in-network storage acts as a cache, when only some of >addressable content is available in the storage. >It could be because the content is not locally available, to >support differentiated service levels or to gain some >scalability benefits In this case the in-network storage >system would have to acquire content from P2P overlay and/or >other forms of networked storage, on its own. > That depends on which party determines what to be stored in in-network storage and whether the standard protocol we want to develop here is supported among that p2p application users. Haibin >--alan > > > >--------------------------------------------------------------- >----------- >This e-mail Contains PeerApp Proprietary and Confidential information. > > >--------------------------------------------------------------- >----------- >-----Original Message----- >From: Song Haibin [mailto:melodysong@huawei.com] >Sent: Wednesday, August 05, 2009 11:34 AM >To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org >Subject: RE: [decade] Comment for motivations and goals of DECADE > >Hi Alan, > > >>-----Original Message----- >>From: Alan Arolovitch [mailto:alan@peerapp.com] >>Sent: Wednesday, August 05, 2009 4:10 PM >>To: Song Haibin; Y.J. Gu; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>Haibin, >> >>I think we're in agreement on these high-level objectives >When we talk >>about the standardized communications between peers and in-network >>storage, it is common to think of content retrieval. >>The acquisition of content by in-network storage from P2P >applications >>is as important, and in fact may be more difficult to make >>application/protocol agnostic. >> > >It's not content retrieval. It's content store/retrieval. P2P >applications users also use the standard protocol >(control/data transport) to store content to the in-network >storage and share it to other peers. It will be application >protocol agnostic. > >>Also, is it the intention to use RELOAD work for in-network storage >>discovery? >> > >We need the discovery for the in-network storage entity for >contents, although we don't want to touch the content format >itself. The discovery will be based on either application >protocols or some other existing mechanisms. > > >BR, >Haibin > > >>--alan >> >> >> >>--------------------------------------------------------------- >>----------- >>This e-mail Contains PeerApp Proprietary and Confidential information. >> >> >>--------------------------------------------------------------- >>----------- >>-----Original Message----- >>From: Song Haibin [mailto:melodysong@huawei.com] >>Sent: Wednesday, August 05, 2009 10:37 AM >>To: Alan Arolovitch; 'Y.J. Gu'; decade@ietf.org >>Subject: RE: [decade] Comment for motivations and goals of DECADE >> >>Hi Alan, >> >>>-----Original Message----- >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>Behalf Of Alan Arolovitch >>>Sent: Tuesday, August 04, 2009 5:27 PM >>>To: Y.J. Gu; decade@ietf.org >>>Subject: Re: [decade] Comment for motivations and goals of DECADE >>> >>>Yingjie, >>> >>>I agree with the practical test, need to have a caching framework in >>>mind to make the discussion practical I am familiar with two main >>>caching architectures when applied to P2P: >>> >>>- in-line caching >>> cache intermediates transactions between peers, similarly to >>> conventional Web caching >>>-"super-peer" caching >>> peer discovers cache and contacts it separately and in >>addition to >>> regular peer discovery and swarming >>> >>>Each form of caching has its own advantages, depending on the >>>objectives of application and/or network operator. >>>It seems to me that it is possible to come up with a solution that >>>would accommodate more than one form of caching >>> >> >>I would like to find another term instead of "cache". Because the >>existing P2P "cache" system is either transparent or non-transparent, >>which are all application protocol aware. >>What we want to develop is an application protocol agnostic >framework, >>esp. the standard protocol(s) (control and data >>transport) spoken between the peers and the in-network storage, in >>order to minimize the complexity of supporting various and continuous >>changing p2p application protocols on existing cache systems, >and also >>save bandwidth for ISPs. The final solution could be used by both p2p >>and c/s applications. >>The >>access control and resource control on the sharing model are >important. >> >>BR, >>Haibin >> >> >> >>>--alan >>> >>> >>> >>>--------------------------------------------------------------- >>>----------- >>>This e-mail Contains PeerApp Proprietary and Confidential >information. >>> >>> >>>--------------------------------------------------------------- >>>----------- >>>-----Original Message----- >>>From: Y.J. Gu [mailto:guyingjie@huawei.com] >>>Sent: Monday, August 03, 2009 12:30 PM >>>To: Alan Arolovitch; decade@ietf.org >>>Subject: RE: [decade] Comment for motivations and goals of DECADE >>> >>>" Maybe DECADE should focus on this narrow protocol problem, and not >>>preclude any particular form of caching systems architectures and/or >>>P2P applications types. " >>> >>>Support, a universal protocol should be the final target of DECADE. >>>But, IMHO, at beginning, we should base our discussion on a >>particular >>>caching form, to avoid abstract discussion. >>>This caching form should be scalable, open architecture and >protocol, >>>and, of course, P2P friendly. >>>This could be either an existing caching form or a new one. >>> >>> >>> >>> >>>Regards >>> >>>Yingjie Gu >>> >>> >>>-----Original Message----- >>>From: Alan Arolovitch [mailto:alan@peerapp.com] >>>Sent: Monday, August 03, 2009 4:00 PM >>>To: Y.J. Gu; decade@ietf.org >>>Subject: RE: [decade] Comment for motivations and goals of DECADE >>> >>>0.02$ from P2P caching vendor perspective >>> >>>I agree that bandwidth savings as a scope is too narrow and not >>>exclusive enough. >>>P2P caching systems can accommodate a variety of value propositions, >>>including bandwidth savings, SLA assurance and service delivery. >>>Based on discussions spurred by ALTO, it seems that there's a >>perceived >>>and understood challenge in scaling multi-protocol support of P2P >>>applications Maybe DECADE should focus on this narrow >>protocol problem, >>>and not preclude any particular form of caching systems >architectures >>>and/or P2P applications types. >>>Just as HTTP1.1 RFC 2616 doesn't spell out particular caching >>>architecture, but rather standardizes solid protocol-level caching >>>support, that allows to build transparent and >non-transparent caching >>>systems based on it. >>> >>>Lastly, on the legal side, I don't think DECADE should focus >>>exclusively on DMCA agenda (i.e. >>>caching-of-potentially-copyright-infringing-content) >>>There is plenty of deployment scenarios that do not fall into this >>>bucket, even though it would be nice if DECADE wasn't in a clear >>>violation of the procedures set by DMCA and other very similar legal >>>acts adopted globally. >>> >>>--alan >>> >>> >>> >>>--------------------------------------------------------------- >>>--------- >>>-- >>>This e-mail Contains PeerApp Proprietary and Confidential >information. >>> >>> >>>--------------------------------------------------------------- >>>--------- >>>-- >>>-----Original Message----- >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>Behalf Of Y.J. Gu >>>Sent: Monday, August 03, 2009 10:28 AM >>>To: decade@ietf.org >>>Subject: [decade] Comment for motivations and goals of DECADE >>> >>>I did not attend DECADE bar BOF, just follow the progress by >>analyzing >>>meeting minutes. So, forgive me if there might be any >>misunderstanding. >>>^_^ >>> >>>I notice that both the "Problem statement" and "BranchCache >>>presentation" >>>take "band-saving" as a primary motivation/incentive for DECADE. >>> >>>IMHO, "band-saving" might not be a good reason to convince >>IETF to work >>>on DECADE and might put DECADE into much more debate. There >>are already >>>various caching or non-caching solutions implemented to reduce >>>uplink/downlink bandwidth, for both C/S and P2P applications, >>e.g. CDN, >>>P2P caching and DPI. >>>Some others are under discussion in mailing list, such as ALTO. >>> >>>I know DECADE is different, but why IETF need another "band-saving" >>>solution? That's a hard question. >>>"saving uplink is too broad scope", as Rich said. >>>"saving the uplink is not the main drving force", said Lucy Yong. >>>I agree with them, it will make things too complicated. Look >back the >>>meeting minutes, and you will find that 7 out of 15 questions in >>>"Problem statement" Q&A are about bandwidth. We do not need >>>multi-motivations to indicate the importance of DECADE, we >>just need an >>>overwhelming one. >>> >>>To decouple signaling and data transmission is the very >>incentive that >>>we need. Up to now, there is no WG in IETF ever intends to >>address the >>>updating pressure to existing caches system. Absorbing people's >>>attention on this aspect might help us clarify the necessary >>of DECADE >>>more convincibly. >>> >>>And we can regard "band-saving" as a subordinate advantage, >>instead of >>>as an incentive. >>> >>>Regards >>> >>>Yingjie Gu >>> >>>_______________________________________________ >>>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 spis@intracom.com Wed Aug 5 02:53: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 DD5CE3A6B19 for ; Wed, 5 Aug 2009 02:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P07UMZocZdEu for ; Wed, 5 Aug 2009 02:53:16 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.gr [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id C08483A6B2D for ; Wed, 5 Aug 2009 02:53:15 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n759rGAt003514 for ; Wed, 5 Aug 2009 12:53:16 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n759rF2g009456 for ; Wed, 5 Aug 2009 12:53:16 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n759rFSE009445; Wed, 5 Aug 2009 12:53:15 +0300 (EEST) Received: from [146.124.139.213] (HELO [192.168.17.53]) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29954004; Wed, 05 Aug 2009 12:53:15 +0300 Message-Id: From: Spiros Spirou To: Song Haibin In-Reply-To: <00be01ca15a4$75ae2f90$0f0ca40a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 12:53:13 +0300 References: <00be01ca15a4$75ae2f90$0f0ca40a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 09:53:16 -0000 Hi all, On 05 =CE=91=CF=85=CE=B3 2009, at 11:12 =CE=A0=CE=9C, Song Haibin wrote: >> In addition, some ISPs are more affected (economically) by >> inbound traffic on backbone interconnects than other ISPs, >> e.g. see the "bandwidth cost" bullet on slide 8 of >> http://www.ietf.org/proceedings/75/slides/P2PRG-8.pdf. > > Thanks. I think ISPs would like to save both uplink and downlink =20 > bandwidths > whenever possible. It will depend on the deployment to save downlink =20= > or > inbound backbone bandwidths sometimes. I'm aware of 3 transit traffic charging models so far: 1) download only 2) abs(download - upload) 3) max{download, upload} IMO, these have been created with download's dominance in mind. It =20 seems that tier-3 ISPs are controlling upload through asymmetric =20 access connections. Of course these could change with FTTH. If anyone is aware of alt charging models/trends or the popularity of =20= those above please share. Info like this can show us what requirements =20= for DECADE are important. Thanks, Spiros=20= From spis@intracom.com Wed Aug 5 03:11: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 948AF3A7190 for ; Wed, 5 Aug 2009 03:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 VtnnVw7YH5xA for ; Wed, 5 Aug 2009 03:11:23 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.gr [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id 68EBC3A711B for ; Wed, 5 Aug 2009 03:11:23 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n75ABJXV007195 for ; Wed, 5 Aug 2009 13:11:19 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n75ABIuD015721 for ; Wed, 5 Aug 2009 13:11:19 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n75ABHSc015708; Wed, 5 Aug 2009 13:11:18 +0300 (EEST) Received: from [146.124.139.213] (HELO [192.168.17.53]) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29954333; Wed, 05 Aug 2009 13:11:17 +0300 Message-Id: <8A367ECE-FAB4-4248-89BF-A7A61C5BD97A@intracom.com> From: Spiros Spirou To: "Alan Arolovitch" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 13:11:16 +0300 References: <00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 10:11:24 -0000 Hi all, On 05 =CE=91=CF=85=CE=B3 2009, at 12:02 =CE=9C=CE=9C, Alan Arolovitch = wrote: > If I follow you correctly, you limit the function of in-network =20 > storage > to content origination, when all addressable content is always =20 > available > > in the storage. > In this case indeed there's a simple flow of sharing content into > the storage ("upload") and retrieving it back. > You can think of this scenario as P2P-based YouTube service. > > There are other feasible and interesting scenarios where the in-=20 > network > storage > acts as a cache, when only some of addressable content is available in > the storage. > It could be because the content is not locally available, to support > differentiated > service levels or to gain some scalability benefits > In this case the in-network storage system would have to acquire =20 > content > from P2P overlay and/or other forms of networked storage, on its own. I fully agree with Alan. If I understood correctly, it seems there are =20= 2 separate concepts here: 1) Delegation of uploading. Instead of uploading themselves, app nodes =20= delegate that task to the in-network storage (cache). 2) In-network storage content provisioning. The in-network storage =20 needs to know what content to store and how to get it from the app. IMO, (2) needs a protocol between the in-network storage and the app =20 resource directory (e.g. trackers in BitTorrent). The in-network =20 storage would use such a protocol to query the resource directory for =20= e.g. the most popular content in it's domain. However, there's no =20 clear incentive for a resource directory to offer such a protocol. Thanks, Spiros= From richard.alimi@yale.edu Wed Aug 5 06:26:56 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 BA48C28C577 for ; Wed, 5 Aug 2009 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dleS71w7q+iV for ; Wed, 5 Aug 2009 06:26:56 -0700 (PDT) Received: from pantheon-po42.its.yale.edu (pantheon-po42.its.yale.edu [130.132.50.101]) by core3.amsl.com (Postfix) with ESMTP id D980F28C573 for ; Wed, 5 Aug 2009 06:26:55 -0700 (PDT) Received: from poweredge.velvetsea.net (adsl-69-183-228-95.dsl.wlfrct.sbcglobal.net [69.183.228.95]) (authenticated bits=0) by pantheon-po42.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n75DQY83025466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Aug 2009 09:26:34 -0400 Received: from laptop.localnet (adsl-69-183-228-95.dsl.wlfrct.sbcglobal.net [69.183.228.95]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id D7EB6424001; Wed, 5 Aug 2009 09:26:33 -0400 (EDT) From: Richard Alimi To: decade@ietf.org Date: Wed, 5 Aug 2009 09:26:24 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; x86_64; ; ) References: <001901ca15a8$650313f0$400ca40a@china.huawei.com> In-Reply-To: <001901ca15a8$650313f0$400ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200908050926.29812.richard.alimi@yale.edu> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 13:26:56 -0000 Hi Yingjie, On Wednesday 05 August 2009 4:40:32 am Y.J. Gu wrote: > "The acquisition of content by in-network storage from P2P applications is > as important, and in fact may be more difficult to make > application/protocol agnostic." > > Good comment. > Seems that DECADE wants to design a new access protocol to establish a > relationship between peer and in-network storage. Then peer can upload > content to in-network storage by RTP, FTP, HTTP,..., the in-network storage > need not know what the application protocol is. In terms of populating the in-network storage, this is indeed the model we had in mind. We had not originally considered the possibility of the in-network storage discovering content itself since, as has been pointed out, that can complicate matters by making in-network storage not application/protocol agnostic. In the Sailor presentation, we showed a single operation called 'slr-store' (it was actually implemented as an HTTP PUT) that was used to put an object into the user's data locker. Of course, this is just one possibility... -- Richard Alimi Department of Computer Science Yale University From yry@cs.yale.edu Wed Aug 5 09:46:41 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 32D3F3A6C2B for ; Wed, 5 Aug 2009 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLDEwbEAuxeo for ; Wed, 5 Aug 2009 09:46:36 -0700 (PDT) Received: from pantheon-po43.its.yale.edu (pantheon-po43.its.yale.edu [130.132.50.104]) by core3.amsl.com (Postfix) with ESMTP id E86C73A6C39 for ; Wed, 5 Aug 2009 09:46:32 -0700 (PDT) Received: from [128.36.169.209] (dhcp128036169209.med.yale.edu [128.36.169.209]) (authenticated bits=0) by pantheon-po43.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n75GkVYv014131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Aug 2009 12:46:31 -0400 Message-ID: <4A79B766.9080300@cs.yale.edu> Date: Wed, 05 Aug 2009 12:46:30 -0400 From: "Y. R. Yang" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Spiros Spirou References: <00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> <8A367ECE-FAB4-4248-89BF-A7A61C5BD97A@intracom.com> In-Reply-To: <8A367ECE-FAB4-4248-89BF-A7A61C5BD97A@intracom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of 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: Wed, 05 Aug 2009 16:46:41 -0000 Hi Spiros and Alan, Good comments. Please see below. Spiros Spirou wrote: > Hi all, > > On 05 Αυγ 2009, at 12:02 ΜΜ, Alan Arolovitch wrote: > >> If I follow you correctly, you limit the function of in-network storage >> to content origination, when all addressable content is always available >> >> in the storage. >> In this case indeed there's a simple flow of sharing content into >> the storage ("upload") and retrieving it back. >> You can think of this scenario as P2P-based YouTube service. >> >> There are other feasible and interesting scenarios where the in-network >> storage >> acts as a cache, when only some of addressable content is available in >> the storage. >> It could be because the content is not locally available, to support >> differentiated >> service levels or to gain some scalability benefits >> In this case the in-network storage system would have to acquire content >> from P2P overlay and/or other forms of networked storage, on its own. > > I fully agree with Alan. If I understood correctly, it seems there are > 2 separate concepts here: > This classification is good. > 1) Delegation of uploading. Instead of uploading themselves, app nodes > delegate that task to the in-network storage (cache). > 2) In-network storage content provisioning. The in-network storage > needs to know what content to store and how to get it from the app. > > IMO, (2) needs a protocol between the in-network storage and the app > resource directory (e.g. trackers in BitTorrent). The in-network > storage would use such a protocol to query the resource directory for > e.g. the most popular content in it's domain. However, there's no > clear incentive for a resource directory to offer such a protocol. > Provisioning and access control are coupled. There are two provisioning methods to get content into the storage: P1: Application entity stores content into the storage (e.g., peer A or content publisher C; it may be in a format that A stores a content block itself, or A asks the storage to fetch a content block from a location); P2: The storage fetches content by itself (not on behalf of any particular entity). The access problem is who does gatekeeping and distributes access token to the content in the storage. This is related with who does the provisioning. (Note that this is a logical model; there are under-the-hood optimization to avoid duplicating upload to the storage). In the current Sailor design, we felt that P1 is a cleaner design, and there is an access-control mechanism that is simple to state and allows easy accountability: only who puts the content in can grant access to that content to others (modular some storage usage policies imposed by an ISP storage provider such as no uploading to those outside the ISP). To support P2, you are right that we then need a notification mechanism (for content provider or P2P app to notify the storage about content availability) and/or query mechanism (e.g., the storage queries tracker or a content registry, as once mentioned by Nick Weaver). There is also a need for solving the access control policy problem for the the content obtained by P2. Yet another problem is the notification/query problem of telling applications what content the storage has (as it maybe the case that no application entity knows that the storage has fetched some particular content). Let me add that even if a system allows only P1, there is an alternative design for access: peer A puts some content into the storage; if there is a querying mechanism to the storage to know what is available in the storage, peer B, who has no connection to peer A, can query and then download. We considered this possibility in the P2P context but did not pursue due to complexity. Overall, I have no strong objection to allowing P2 (I feel that it may help existing P2P caches for content acquisition). But it appears to be a separate protocol of the main protocols that we will consider. Richard > Thanks, > > Spiros > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From zhangyunfei@chinamobile.com Wed Aug 5 19:01:28 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 9F0173A68FA for ; Wed, 5 Aug 2009 19:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.33 X-Spam-Level: X-Spam-Status: No, score=-95.33 tagged_above=-999 required=5 tests=[AWL=-1.447, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 fVHFrwT3FodJ for ; Wed, 5 Aug 2009 19:01:27 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 1FF2D3A68C3 for ; Wed, 5 Aug 2009 19:01:27 -0700 (PDT) Received: from LENOVO-917FFE55 ([10.1.4.230]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009080610011439-3256 ; Thu, 6 Aug 2009 10:01:14 +0800 From: "zhangyunfei" To: "Spiros Spirou" , "Alan Arolovitch" References: < 00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> <8A367ECE-FAB4-4248-89BF-A7A61C5BD97A@intracom.com> Message-ID: <200808091001123756397@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-08-06 10:01:14, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-08-06 10:01:30, Serialize complete at 2009-08-06 10:01:30 Content-Type: multipart/alternative; boundary="=====003_Dragon636714043850_=====" Cc: "decade@ietf.org" Subject: Re: [decade] Comment for motivations and goals of 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: , Date: Thu, 06 Aug 2009 02:01:28 -0000 X-Original-Date: Sat, 9 Aug 2008 10:01:12 +0800 X-List-Received-Date: Thu, 06 Aug 2009 02:01:28 -0000 This is a multi-part message in MIME format. --=====003_Dragon636714043850_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgYWxsLA0KICAgSSBhZ3JlZSB3aXRoIFNwaXJvcydzIG9waW5pb24uIEFzIHBvaW50ZWQgZWFy bGllciwgSSBkb24ndCB0aGluayB0aGUgSW4tbmV0d29yayAgc3RvcmFnZSAgY29udGVudCAgcHJv dmlzaW9uaW5nIHByb3RvY29sIGJldHdlZW4gdGhlIGNhY2hlcyBvciBiZXR3ZWVuIGNhY2hlcyBh bmQgYXBwcyBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiBERUNBREUuVGhlcmUgYXJlIHR3byBvcHRp b25zIGFib3V0IHRoaXMgcHJvdG9jb2w6IDEpIFJldXNlIGV4aXNpdGluZyBwcm9wcmlldGFyeSBw cm90b2NvbHM7IENhY2hlIGlzIGp1c3QgbGlrZSBhIGNvbW1vbiBwZWVyIHdoZW4gZG9pbmcgdGhp cztCdXQgaXQgbmVlZCByZWd1bGFyIHVwZGF0ZSBvZiB0aGUgY2FjaGUgc3lzdGVtcy4yKSBUaGVy ZSBhcmUgYWxyZWFkeSBhdHRlbXB0cyBsaWtlIFBQU1AgZG9pbmcgc3VjaCBzdGFuZGFyZCBwcm90 b2NvbHMuDQpUaGUgcmVhbCB2YWx1ZSBvZiBERUNBREUgaXMgcG9pbnQxLERlbGVnYXRpb24gIG9m ICB1cGxvYWRpbmcsIGZyb20gYW4gb3BlcnRvcidzIHBvaW50IG9mIHZpZXcuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBCUg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCjIwMDgtMDgtMDkNCg0KDQoNCreivP7Iy6O6 IFNwaXJvcyBTcGlyb3UNCreiy83Ksbzko7ogMjAwOS0wOC0wNSAxODoxMTozMQ0KytW8/sjLo7og QWxhbiBBcm9sb3ZpdGNoDQqzrcvNo7ogZGVjYWRlQGlldGYub3JnDQrW98zio7ogUmU6IFtkZWNh ZGVdIENvbW1lbnQgZm9yIG1vdGl2YXRpb25zIGFuZCBnb2FscyBvZiBERUNBREUNCg0KSGkgIGFs bCwNCg0KT24gIDA1ICCmoabUpsMgIDIwMDksICBhdCAgMTI6MDIgIKaspqwsICBBbGFuICBBcm9s b3ZpdGNoICB3cm90ZToNCg0KPiAgSWYgIEkgIGZvbGxvdyAgeW91ICBjb3JyZWN0bHksICB5b3Ug IGxpbWl0ICB0aGUgIGZ1bmN0aW9uICBvZiAgaW4tbmV0d29yayAgICANCj4gIHN0b3JhZ2UNCj4g IHRvICBjb250ZW50ICBvcmlnaW5hdGlvbiwgIHdoZW4gIGFsbCAgYWRkcmVzc2FibGUgIGNvbnRl bnQgIGlzICBhbHdheXMgICAgDQo+ICBhdmFpbGFibGUNCj4NCj4gIGluICB0aGUgIHN0b3JhZ2Uu DQo+ICBJbiAgdGhpcyAgY2FzZSAgaW5kZWVkICB0aGVyZSdzICBhICBzaW1wbGUgIGZsb3cgIG9m ICBzaGFyaW5nICBjb250ZW50ICBpbnRvDQo+ICB0aGUgIHN0b3JhZ2UgICgidXBsb2FkIikgIGFu ZCAgcmV0cmlldmluZyAgaXQgIGJhY2suDQo+ICBZb3UgIGNhbiAgdGhpbmsgIG9mICB0aGlzICBz Y2VuYXJpbyAgYXMgIFAyUC1iYXNlZCAgWW91VHViZSAgc2VydmljZS4NCj4NCj4gIFRoZXJlICBh cmUgIG90aGVyICBmZWFzaWJsZSAgYW5kICBpbnRlcmVzdGluZyAgc2NlbmFyaW9zICB3aGVyZSAg dGhlICBpbi0gIA0KPiAgbmV0d29yaw0KPiAgc3RvcmFnZQ0KPiAgYWN0cyAgYXMgIGEgIGNhY2hl LCAgd2hlbiAgb25seSAgc29tZSAgb2YgIGFkZHJlc3NhYmxlICBjb250ZW50ICBpcyAgYXZhaWxh YmxlICBpbg0KPiAgdGhlICBzdG9yYWdlLg0KPiAgSXQgIGNvdWxkICBiZSAgYmVjYXVzZSAgdGhl ICBjb250ZW50ICBpcyAgbm90ICBsb2NhbGx5ICBhdmFpbGFibGUsICB0byAgc3VwcG9ydA0KPiAg ZGlmZmVyZW50aWF0ZWQNCj4gIHNlcnZpY2UgIGxldmVscyAgb3IgIHRvICBnYWluICBzb21lICBz Y2FsYWJpbGl0eSAgYmVuZWZpdHMNCj4gIEluICB0aGlzICBjYXNlICB0aGUgIGluLW5ldHdvcmsg IHN0b3JhZ2UgIHN5c3RlbSAgd291bGQgIGhhdmUgIHRvICBhY3F1aXJlICAgIA0KPiAgY29udGVu dA0KPiAgZnJvbSAgUDJQICBvdmVybGF5ICBhbmQvb3IgIG90aGVyICBmb3JtcyAgb2YgIG5ldHdv cmtlZCAgc3RvcmFnZSwgIG9uICBpdHMgIG93bi4NCg0KSSAgZnVsbHkgIGFncmVlICB3aXRoICBB bGFuLiAgSWYgIEkgIHVuZGVyc3Rvb2QgIGNvcnJlY3RseSwgIGl0ICBzZWVtcyAgdGhlcmUgIGFy ZSAgICANCjIgIHNlcGFyYXRlICBjb25jZXB0cyAgaGVyZToNCg0KMSkgIERlbGVnYXRpb24gIG9m ICB1cGxvYWRpbmcuICBJbnN0ZWFkICBvZiAgdXBsb2FkaW5nICB0aGVtc2VsdmVzLCAgYXBwICBu b2RlcyAgICANCmRlbGVnYXRlICB0aGF0ICB0YXNrICB0byAgdGhlICBpbi1uZXR3b3JrICBzdG9y YWdlICAoY2FjaGUpLg0KMikgIEluLW5ldHdvcmsgIHN0b3JhZ2UgIGNvbnRlbnQgIHByb3Zpc2lv bmluZy4gIFRoZSAgaW4tbmV0d29yayAgc3RvcmFnZSAgICANCm5lZWRzICB0byAga25vdyAgd2hh dCAgY29udGVudCAgdG8gIHN0b3JlICBhbmQgIGhvdyAgdG8gIGdldCAgaXQgIGZyb20gIHRoZSAg YXBwLg0KDQpJTU8sICAoMikgIG5lZWRzICBhICBwcm90b2NvbCAgYmV0d2VlbiAgdGhlICBpbi1u ZXR3b3JrICBzdG9yYWdlICBhbmQgIHRoZSAgYXBwICAgIA0KcmVzb3VyY2UgIGRpcmVjdG9yeSAg KGUuZy4gIHRyYWNrZXJzICBpbiAgQml0VG9ycmVudCkuICBUaGUgIGluLW5ldHdvcmsgICAgDQpz dG9yYWdlICB3b3VsZCAgdXNlICBzdWNoICBhICBwcm90b2NvbCAgdG8gIHF1ZXJ5ICB0aGUgIHJl c291cmNlICBkaXJlY3RvcnkgIGZvciAgICANCmUuZy4gIHRoZSAgbW9zdCAgcG9wdWxhciAgY29u dGVudCAgaW4gIGl0J3MgIGRvbWFpbi4gIEhvd2V2ZXIsICB0aGVyZSdzICBubyAgICANCmNsZWFy ICBpbmNlbnRpdmUgIGZvciAgYSAgcmVzb3VyY2UgIGRpcmVjdG9yeSAgdG8gIG9mZmVyICBzdWNo ICBhICBwcm90b2NvbC4NCg0KVGhhbmtzLA0KDQpTcGlyb3MNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkZWNhZGUgIG1haWxpbmcgIGxpc3QNCmRlY2Fk ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUN Cg== --=====003_Dragon636714043850_===== 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 ZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDsmbmJzcDsg SSBhZ3JlZSB3aXRoIFNwaXJvcydzIA0Kb3Bpbmlvbi4gQXMgcG9pbnRlZCBlYXJsaWVyLCBJIGRv bid0IHRoaW5rIHRoZSA8Rk9OVCBjb2xvcj0jMDAwMGZmPkluLW5ldHdvcmsgDQombmJzcDtzdG9y YWdlICZuYnNwO2NvbnRlbnQgJm5ic3A7cHJvdmlzaW9uaW5nIHByb3RvY29sIGJldHdlZW4gdGhl IGNhY2hlcyBvciANCmJldHdlZW4gY2FjaGVzIGFuZCBhcHBzIGFyZSB3aXRoaW4gdGhlIHNjb3Bl IG9mIERFQ0FERS5UaGVyZSBhcmUgdHdvIG9wdGlvbnMgDQphYm91dCB0aGlzIHByb3RvY29sOiAx KSBSZXVzZSBleGlzaXRpbmcgcHJvcHJpZXRhcnkgcHJvdG9jb2xzOyBDYWNoZSBpcyBqdXN0IA0K bGlrZSBhIGNvbW1vbiBwZWVyIHdoZW4gZG9pbmcgdGhpcztCdXQgaXQgbmVlZCByZWd1bGFyIHVw ZGF0ZSBvZiB0aGUgY2FjaGUgDQpzeXN0ZW1zLjIpIFRoZXJlIGFyZSBhbHJlYWR5Jm5ic3A7YXR0 ZW1wdHMgbGlrZSBQUFNQIGRvaW5nIHN1Y2ggc3RhbmRhcmQgDQpwcm90b2NvbHMuPC9GT05UPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxGT05UIGNvbG9yPSMwMDAwZmY+VGhlIHJlYWwgdmFsdWUgDQpvZiBERUNBREUgaXMgcG9pbnQx LDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMGZmPkRlbGVnYXRpb24gJm5ic3A7b2YgDQombmJzcDt1 cGxvYWRpbmcsIGZyb20gYW4gb3BlcnRvcidzIHBvaW50IG9mIHZpZXcuPC9GT05UPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgDQpz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KQlI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCll1bmZlaTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBm YWNlPVZlcmRhbmEgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4 IiBTSVpFPTI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj56aGFuZ3l1bmZlaTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj4yMDA4LTA4LTA5PC9GT05UPjwvRk9OVD48L0RJVj48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxIUj4NCjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJP Tkc+IFNwaXJvcyANClNwaXJvdTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IA0KMjAwOS0w OC0wNSZuYnNwOzE4OjExOjMxPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IEFsYW4gDQpBcm9s b3ZpdGNoPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05U IHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiANCmRlY2FkZUBpZXRmLm9yZzwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9O Rz7W98zio7o8L1NUUk9ORz4gUmU6IFtkZWNhZGVdIENvbW1lbnQgDQpmb3IgbW90aXZhdGlvbnMg YW5kIGdvYWxzIG9mIERFQ0FERTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRh bmEgc2l6ZT0yPg0KPERJVj5IaSAmbmJzcDthbGwsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5PbiAmbmJzcDswNSAmbmJzcDumoabUpsMgJm5ic3A7MjAwOSwgJm5ic3A7YXQgJm5ic3A7 MTI6MDIgJm5ic3A7pqymrCwgJm5ic3A7QWxhbiANCiZuYnNwO0Fyb2xvdml0Y2ggJm5ic3A7d3Jv dGU6PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO0lmICZuYnNwO0kg Jm5ic3A7Zm9sbG93ICZuYnNwO3lvdSAmbmJzcDtjb3JyZWN0bHksICZuYnNwO3lvdSANCiZuYnNw O2xpbWl0ICZuYnNwO3RoZSAmbmJzcDtmdW5jdGlvbiAmbmJzcDtvZiAmbmJzcDtpbi1uZXR3b3Jr ICZuYnNwOyANCiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO3N0b3JhZ2U8L0RJVj4NCjxE SVY+Jmd0OyAmbmJzcDt0byAmbmJzcDtjb250ZW50ICZuYnNwO29yaWdpbmF0aW9uLCAmbmJzcDt3 aGVuICZuYnNwO2FsbCANCiZuYnNwO2FkZHJlc3NhYmxlICZuYnNwO2NvbnRlbnQgJm5ic3A7aXMg Jm5ic3A7YWx3YXlzICZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDthdmFpbGFi bGU8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO2luICZuYnNwO3RoZSAm bmJzcDtzdG9yYWdlLjwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO0luICZuYnNwO3RoaXMgJm5ic3A7 Y2FzZSAmbmJzcDtpbmRlZWQgJm5ic3A7dGhlcmUncyAmbmJzcDthIA0KJm5ic3A7c2ltcGxlICZu YnNwO2Zsb3cgJm5ic3A7b2YgJm5ic3A7c2hhcmluZyAmbmJzcDtjb250ZW50ICZuYnNwO2ludG88 L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDt0aGUgJm5ic3A7c3RvcmFnZSAmbmJzcDsoInVwbG9hZCIp ICZuYnNwO2FuZCAmbmJzcDtyZXRyaWV2aW5nIA0KJm5ic3A7aXQgJm5ic3A7YmFjay48L0RJVj4N CjxESVY+Jmd0OyAmbmJzcDtZb3UgJm5ic3A7Y2FuICZuYnNwO3RoaW5rICZuYnNwO29mICZuYnNw O3RoaXMgJm5ic3A7c2NlbmFyaW8gDQombmJzcDthcyAmbmJzcDtQMlAtYmFzZWQgJm5ic3A7WW91 VHViZSAmbmJzcDtzZXJ2aWNlLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsgJm5i c3A7VGhlcmUgJm5ic3A7YXJlICZuYnNwO290aGVyICZuYnNwO2ZlYXNpYmxlICZuYnNwO2FuZCAN CiZuYnNwO2ludGVyZXN0aW5nICZuYnNwO3NjZW5hcmlvcyAmbmJzcDt3aGVyZSAmbmJzcDt0aGUg Jm5ic3A7aW4tICZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO25ldHdvcms8L0RJVj4NCjxE SVY+Jmd0OyAmbmJzcDtzdG9yYWdlPC9ESVY+DQo8RElWPiZndDsgJm5ic3A7YWN0cyAmbmJzcDth cyAmbmJzcDthICZuYnNwO2NhY2hlLCAmbmJzcDt3aGVuICZuYnNwO29ubHkgDQombmJzcDtzb21l ICZuYnNwO29mICZuYnNwO2FkZHJlc3NhYmxlICZuYnNwO2NvbnRlbnQgJm5ic3A7aXMgJm5ic3A7 YXZhaWxhYmxlIA0KJm5ic3A7aW48L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDt0aGUgJm5ic3A7c3Rv cmFnZS48L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtJdCAmbmJzcDtjb3VsZCAmbmJzcDtiZSAmbmJz cDtiZWNhdXNlICZuYnNwO3RoZSAmbmJzcDtjb250ZW50IA0KJm5ic3A7aXMgJm5ic3A7bm90ICZu YnNwO2xvY2FsbHkgJm5ic3A7YXZhaWxhYmxlLCAmbmJzcDt0byAmbmJzcDtzdXBwb3J0PC9ESVY+ DQo8RElWPiZndDsgJm5ic3A7ZGlmZmVyZW50aWF0ZWQ8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtz ZXJ2aWNlICZuYnNwO2xldmVscyAmbmJzcDtvciAmbmJzcDt0byAmbmJzcDtnYWluICZuYnNwO3Nv bWUgDQombmJzcDtzY2FsYWJpbGl0eSAmbmJzcDtiZW5lZml0czwvRElWPg0KPERJVj4mZ3Q7ICZu YnNwO0luICZuYnNwO3RoaXMgJm5ic3A7Y2FzZSAmbmJzcDt0aGUgJm5ic3A7aW4tbmV0d29yayAN CiZuYnNwO3N0b3JhZ2UgJm5ic3A7c3lzdGVtICZuYnNwO3dvdWxkICZuYnNwO2hhdmUgJm5ic3A7 dG8gJm5ic3A7YWNxdWlyZSAmbmJzcDsgDQombmJzcDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtj b250ZW50PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7ZnJvbSAmbmJzcDtQMlAgJm5ic3A7b3Zlcmxh eSAmbmJzcDthbmQvb3IgJm5ic3A7b3RoZXIgDQombmJzcDtmb3JtcyAmbmJzcDtvZiAmbmJzcDtu ZXR3b3JrZWQgJm5ic3A7c3RvcmFnZSwgJm5ic3A7b24gJm5ic3A7aXRzIA0KJm5ic3A7b3duLjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSAmbmJzcDtmdWxseSAmbmJzcDthZ3JlZSAm bmJzcDt3aXRoICZuYnNwO0FsYW4uICZuYnNwO0lmICZuYnNwO0kgDQombmJzcDt1bmRlcnN0b29k ICZuYnNwO2NvcnJlY3RseSwgJm5ic3A7aXQgJm5ic3A7c2VlbXMgJm5ic3A7dGhlcmUgJm5ic3A7 YXJlIA0KJm5ic3A7ICZuYnNwOzwvRElWPg0KPERJVj4yICZuYnNwO3NlcGFyYXRlICZuYnNwO2Nv bmNlcHRzICZuYnNwO2hlcmU6PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4xKSAmbmJz cDtEZWxlZ2F0aW9uICZuYnNwO29mICZuYnNwO3VwbG9hZGluZy4gJm5ic3A7SW5zdGVhZCAmbmJz cDtvZiANCiZuYnNwO3VwbG9hZGluZyAmbmJzcDt0aGVtc2VsdmVzLCAmbmJzcDthcHAgJm5ic3A7 bm9kZXMgJm5ic3A7ICZuYnNwOzwvRElWPg0KPERJVj5kZWxlZ2F0ZSAmbmJzcDt0aGF0ICZuYnNw O3Rhc2sgJm5ic3A7dG8gJm5ic3A7dGhlICZuYnNwO2luLW5ldHdvcmsgDQombmJzcDtzdG9yYWdl ICZuYnNwOyhjYWNoZSkuPC9ESVY+DQo8RElWPjIpICZuYnNwO0luLW5ldHdvcmsgJm5ic3A7c3Rv cmFnZSAmbmJzcDtjb250ZW50ICZuYnNwO3Byb3Zpc2lvbmluZy4gDQombmJzcDtUaGUgJm5ic3A7 aW4tbmV0d29yayAmbmJzcDtzdG9yYWdlICZuYnNwOyAmbmJzcDs8L0RJVj4NCjxESVY+bmVlZHMg Jm5ic3A7dG8gJm5ic3A7a25vdyAmbmJzcDt3aGF0ICZuYnNwO2NvbnRlbnQgJm5ic3A7dG8gJm5i c3A7c3RvcmUgDQombmJzcDthbmQgJm5ic3A7aG93ICZuYnNwO3RvICZuYnNwO2dldCAmbmJzcDtp dCAmbmJzcDtmcm9tICZuYnNwO3RoZSANCiZuYnNwO2FwcC48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPklNTywgJm5ic3A7KDIpICZuYnNwO25lZWRzICZuYnNwO2EgJm5ic3A7cHJvdG9j b2wgJm5ic3A7YmV0d2VlbiAmbmJzcDt0aGUgDQombmJzcDtpbi1uZXR3b3JrICZuYnNwO3N0b3Jh Z2UgJm5ic3A7YW5kICZuYnNwO3RoZSAmbmJzcDthcHAgJm5ic3A7ICZuYnNwOzwvRElWPg0KPERJ Vj5yZXNvdXJjZSAmbmJzcDtkaXJlY3RvcnkgJm5ic3A7KGUuZy4gJm5ic3A7dHJhY2tlcnMgJm5i c3A7aW4gDQombmJzcDtCaXRUb3JyZW50KS4gJm5ic3A7VGhlICZuYnNwO2luLW5ldHdvcmsgJm5i c3A7ICZuYnNwOzwvRElWPg0KPERJVj5zdG9yYWdlICZuYnNwO3dvdWxkICZuYnNwO3VzZSAmbmJz cDtzdWNoICZuYnNwO2EgJm5ic3A7cHJvdG9jb2wgJm5ic3A7dG8gDQombmJzcDtxdWVyeSAmbmJz cDt0aGUgJm5ic3A7cmVzb3VyY2UgJm5ic3A7ZGlyZWN0b3J5ICZuYnNwO2ZvciAmbmJzcDsgDQom bmJzcDs8L0RJVj4NCjxESVY+ZS5nLiAmbmJzcDt0aGUgJm5ic3A7bW9zdCAmbmJzcDtwb3B1bGFy ICZuYnNwO2NvbnRlbnQgJm5ic3A7aW4gJm5ic3A7aXQncyANCiZuYnNwO2RvbWFpbi4gJm5ic3A7 SG93ZXZlciwgJm5ic3A7dGhlcmUncyAmbmJzcDtubyAmbmJzcDsgJm5ic3A7PC9ESVY+DQo8RElW PmNsZWFyICZuYnNwO2luY2VudGl2ZSAmbmJzcDtmb3IgJm5ic3A7YSAmbmJzcDtyZXNvdXJjZSAm bmJzcDtkaXJlY3RvcnkgDQombmJzcDt0byAmbmJzcDtvZmZlciAmbmJzcDtzdWNoICZuYnNwO2Eg Jm5ic3A7cHJvdG9jb2wuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGFua3MsPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TcGlyb3M8L0RJVj4NCjxESVY+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+ZGVjYWRl ICZuYnNwO21haWxpbmcgJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kZWNhZGVAaWV0Zi5vcmc8L0RJ Vj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGU8L0RJ Vj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon636714043850_=====-- From lucyyong@huawei.com Tue Aug 11 14:32:09 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 4ACF53A6E34 for ; Tue, 11 Aug 2009 14:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=-2.128, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 p2Wy6xXPeQZl for ; Tue, 11 Aug 2009 14:32:08 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E446E3A68C2 for ; Tue, 11 Aug 2009 14:32:07 -0700 (PDT) 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 <0KO800ELPED84R@usaga04-in.huawei.com> for decade@ietf.org; Tue, 11 Aug 2009 16:29:33 -0500 (CDT) Received: from y736742 ([10.124.12.61]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO8001PFED2ED@usaga04-in.huawei.com> for decade@ietf.org; Tue, 11 Aug 2009 16:29:32 -0500 (CDT) Date: Tue, 11 Aug 2009 16:29:26 -0500 From: Yong Lucy In-reply-to: <200808091001123756397@chinamobile.com> To: decade@ietf.org Message-id: <006c01ca1aca$cdf964f0$3d0c7c0a@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/alternative; boundary="Boundary_(ID_YoUvmw8e6dVT6d2DfLW1Ng)" Thread-index: AcoWOdg4o8NmLRVrTQGEL+zoKKkDYwEi+vhg References: <00bf01ca15a7$8a6d2190$0f0ca40a@china.huawei.com> <8A367ECE-FAB4-4248-89BF-A7A61C5BD97A@intracom.com> <200808091001123756397@chinamobile.com> Subject: Re: [decade] Comment for motivations and goals of 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: Tue, 11 Aug 2009 21:32:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YoUvmw8e6dVT6d2DfLW1Ng) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi All, =20 I am pleased to jump this discussion and hope not too late. It is very = clear to me the need for a standard protocol for in-network storage access. However, it seems a necessary to revise DECADE problem statement. As I stated in bar BOF meeting, the main driver for this work is not for = saving the uplink BW. Here are motivations I see: 1) Support a standard in-network storage access that is application agnostic 2) Allow the contents at in-network storage sharing with single or multiple users who may run different applications =20 3) Enable more advanced caching at in-network storages (no need = depend on applications) 4) Bring network operator opportunity to offer in-network storage service along with network service 5) In-network storage is the trend of industry moving, a standard protocol will help in-network storage venders as well =20 Cheers, Lucy =20 =20 _____ =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of zhangyunfei Sent: Friday, August 08, 2008 9:01 PM To: Spiros Spirou; Alan Arolovitch Cc: decade@ietf.org Subject: Re: [decade] Comment for motivations and goals of DECADE =20 Hi all, I agree with Spiros's opinion. As pointed earlier, I don't think the In-network storage content provisioning protocol between the caches = or between caches and apps are within the scope of DECADE.There are two = options about this protocol: 1) Reuse exisiting proprietary protocols; Cache is = just like a common peer when doing this;But it need regular update of the = cache systems.2) There are already attempts like PPSP doing such standard protocols. The real value of DECADE is point1,Delegation of uploading, from an opertor's point of view. =20 BR Yunfei =20 _____ =20 zhangyunfei 2008-08-09 _____ =20 =B7=A2=BC=FE=C8=CB=A3=BA Spiros Spirou =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-08-05 18:11:31 =CA=D5=BC=FE=C8=CB=A3=BA Alan Arolovitch =B3=AD=CB=CD=A3=BA decade@ietf.org =D6=F7=CC=E2=A3=BA Re: [decade] Comment for motivations and goals of = DECADE =20 Hi all, =20 On 05 =A6=A1=A6=D4=A6=C3 2009, at 12:02 =A6=AC=A6=AC, Alan = Arolovitch wrote: =20 > If I follow you correctly, you limit the function of = in-network > storage > to content origination, when all addressable content is = always > available >=20 > in the storage. > In this case indeed there's a simple flow of sharing = content into > the storage ("upload") and retrieving it back. > You can think of this scenario as P2P-based YouTube service. >=20 > There are other feasible and interesting scenarios where the = in- > network > storage > acts as a cache, when only some of addressable content is available in > the storage. > It could be because the content is not locally available, = to support > differentiated > service levels or to gain some scalability benefits > In this case the in-network storage system would have to acquire =20 > content > from P2P overlay and/or other forms of networked storage, on its own. =20 I fully agree with Alan. If I understood correctly, it seems there are =20 2 separate concepts here: =20 1) Delegation of uploading. Instead of uploading themselves, app nodes =20 delegate that task to the in-network storage (cache). 2) In-network storage content provisioning. The in-network = storage needs to know what content to store and how to get it from = the app. =20 IMO, (2) needs a protocol between the in-network storage and = the app =20 resource directory (e.g. trackers in BitTorrent). The in-network = =20 storage would use such a protocol to query the resource = directory for =20 e.g. the most popular content in it's domain. However, there's = no clear incentive for a resource directory to offer such a = protocol. =20 Thanks, =20 Spiros _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade --Boundary_(ID_YoUvmw8e6dVT6d2DfLW1Ng) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi = All,

 

=

I am pleased to jump this = discussion and hope not too late. It is very clear to me the need for a standard = protocol for in-network storage access. However, it seems a necessary to revise DECADE problem = statement. As I stated in bar BOF meeting, the main driver for this work is not for = saving the uplink BW. Here are motivations I see:

1)     = Support a standard in-network storage access that is = application agnostic

2)     = Allow the contents at in-network storage sharing with single = or multiple users who may run different applications =  

3)     = Enable more advanced caching at in-network storages (no need = depend on applications)

4)     = Bring network operator opportunity to offer in-network = storage service along with network service

5)     = In-network storage is the trend of industry moving, a = standard protocol will help in-network storage venders as = well

 

=

Cheers,

Lucy

 

=

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: Friday, August 08, = 2008 9:01 PM
To: Spiros Spirou; Alan = Arolovitch
Cc: decade@ietf.org
Subject: Re: [decade] = Comment for motivations and goals of DECADE

 

Hi all,

   I agree with Spiros's opinion. As pointed earlier, I don't think the = In-network  storage  content  provisioning protocol between the = caches or between caches and apps are within the scope of DECADE.There are two = options about this protocol: 1) Reuse exisiting proprietary protocols; Cache is = just like a common peer when doing this;But it need regular update of the = cache systems.2) There are already attempts like PPSP doing such standard protocols.

The real value of DECADE is point1,Delegation  of  uploading, from = an opertor's point of view.

 

  &nb= sp;           &nbs= p;            = ;    BR

  &nb= sp;           &nbs= p;            = ;     Yunfei

 

zhangyunfei

2008-08-09

=B7=A2=BC=FE=C8=CB=A3=BA Spiros Spirou

=B7=A2=CB=CD=CA=B1=BC=E4=A3= =BA 2009-08-05 18:11:31

=CA=D5=BC=FE=C8=CB=A3=BA Alan Arolovitch

=B3=AD=CB=CD=A3=BA decade@ietf.org

=D6=F7=CC=E2=A3=BA Re: [decade] Comment for motivations and goals of DECADE

 

Hi =  all,

 

On =  05  =A6=A1=A6=D4=A6=C3  2009,  at  12:02 =  =A6=AC=A6=AC,  Alan  Arolovitch  wrote:

 

> =  If  I  follow  you  correctly,  you  limit =  the  function  of  in-network   =  

>  storage

> =  to  content  origination,  when  all  addressable  content  is  always   =  

>  available

> 

> =  in  the  storage.

> =  In  this  case  indeed  there's  a  simple =  flow  of  sharing  content =  into

> =  the  storage  ("upload")  and  retrieving =  it  back.

> =  You  can  think  of  this  scenario  as  P2P-based  YouTube =  service.

> 

>  There  are  other  feasible  and =  interesting  scenarios  where  the  in- =  

>  network

> =  storage

> =  acts  as  a  cache,  when  only  some  of  addressable  content  is  available =  in

> =  the  storage.

> =  It  could  be  because  the  content  is =  not  locally  available,  to =  support

>  differentiated

>  service  levels  or  to  gain  some =  scalability  benefits

> =  In  this  case  the  in-network  storage =  system  would  have  to  acquire   =  

>  content

> =  from  P2P  overlay  and/or  other  forms  of  networked  storage,  on  its =  own.

 

I =  fully  agree  with  Alan.  If  I  understood  correctly,  it  seems  there  are   =  

2  separate  concepts  here:

 

1)  Delegation  of  uploading.  Instead  of  uploading  themselves,  app  nodes   =  

delegate  that  task  to  the  in-network  storage  (cache).

2)  In-network  storage  content  provisioning. =  The  in-network  storage    

needs  to  know  what  content  to  store  and =  how  to  get  it  from  the =  app.

 

IMO, =  (2)  needs  a  protocol  between  the =  in-network  storage  and  the  app   =  

resource  directory  (e.g.  trackers  in  BitTorrent).  The  in-network    

storage  would  use  such  a  protocol  to =  query  the  resource  directory  for   =  

e.g. =  the  most  popular  content  in  it's  domain.  However,  there's  no   =  

clear  incentive  for  a  resource  directory =  to  offer  such  a =  protocol.

 

Thanks,<= /font>

 

Spiros

__________________________= _____________________

decade  mailing  list

decade@ietf.org=

https://www.ietf.org/mailm= an/listinfo/decade

--Boundary_(ID_YoUvmw8e6dVT6d2DfLW1Ng)-- From guyingjie@huawei.com Mon Aug 24 01:10:33 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 AACAC3A6AF8 for ; Mon, 24 Aug 2009 01:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[AWL=-0.782, 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 imtB+NhTWM5M for ; Mon, 24 Aug 2009 01:10:33 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BF2D53A67E4 for ; Mon, 24 Aug 2009 01:10:31 -0700 (PDT) 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 <0KOV0054OFX7RI@szxga02-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 16:07:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOV00HJGFX7XP@szxga02-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 16:07:55 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOV002KUFX691@szxml06-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 16:07:55 +0800 (CST) Date: Mon, 24 Aug 2009 16:07:54 +0800 From: "Y.J. Gu" In-reply-to: <200908050926.29812.richard.alimi@yale.edu> To: decade@ietf.org Message-id: <004801ca2491$fbd88790$400ca40a@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: AcoV0l9RNJW31UZrTiGaOercb9fCiAOvmdww Subject: [decade] Should content be repeatedly stored on different In-network storage? 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, 24 Aug 2009 08:10:33 -0000 Maybe the subject of the mail is not very clear. I'd like to explain it. Applicant In-network storage, I creat the name to represent the In-network storage who download a content for its client from another In-network storage. Should the Applicant In-network storage store the content it downloads, to server the later requests for this content from other clients? Regards Yingjie Gu From melodysong@huawei.com Mon Aug 24 02:15:09 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 BE3A83A69A1 for ; Mon, 24 Aug 2009 02:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.205 X-Spam-Level: * X-Spam-Status: No, score=1.205 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 zXlaHi90H0Uc for ; Mon, 24 Aug 2009 02:15:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F0D643A68BC for ; Mon, 24 Aug 2009 02:15:08 -0700 (PDT) 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 <0KOV00FAWIW6OF@szxga02-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 17:12:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOV00L6BIW65K@szxga02-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 17:12:06 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOV002FVIW5Z1@szxml04-in.huawei.com> for decade@ietf.org; Mon, 24 Aug 2009 17:12:06 +0800 (CST) Date: Mon, 24 Aug 2009 17:12:05 +0800 From: Song Haibin In-reply-to: <004801ca2491$fbd88790$400ca40a@china.huawei.com> To: "'Y.J. Gu'" , decade@ietf.org Message-id: <008d01ca249a$f382a770$0f0ca40a@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: AcoV0l9RNJW31UZrTiGaOercb9fCiAOvmdwwAAH9qfA= Subject: Re: [decade] Should content be repeatedly stored on different In-network storage? 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, 24 Aug 2009 09:15:09 -0000 Hi Yingjie, In general, assuming that an out-of-path method has been used for protecting the copyright issues, and the in-network storage is allocated to different users with many individual accounts, I would say a P2P client(in-network storage user) could decide whether to store the content for himself in its in-network storage account, and of course it can share the content in its in-network storage account to other peers. However, in implementation, you may have many methods to optimize it to avoid duplication on the same server or on the servers of an local area. Thanks! Haibin >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Y.J. Gu >Sent: Monday, August 24, 2009 4:08 PM >To: decade@ietf.org >Subject: [decade] Should content be repeatedly stored on >different In-network storage? > >Maybe the subject of the mail is not very clear. >I'd like to explain it. > >Applicant In-network storage, I creat the name to represent >the In-network storage who download a content for its client >from another In-network storage. >Should the Applicant In-network storage store the content it >downloads, to server the later requests for this content from >other clients? > > > >Regards > >Yingjie Gu > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From christian.1.schmidt@nsn.com Mon Aug 24 04:40:56 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 55F0C3A6971 for ; Mon, 24 Aug 2009 04:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.659, 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 ckd8pNsdEnKO for ; Mon, 24 Aug 2009 04:40:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2B5D33A6D1B for ; Mon, 24 Aug 2009 04:40:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7OBecj4004481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 13:40:38 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7OBeXPr015483; Mon, 24 Aug 2009 13:40:38 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 13:40:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 13:40:33 +0200 Message-ID: In-Reply-To: <008d01ca249a$f382a770$0f0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE Thread-Index: AcoV0l9RNJW31UZrTiGaOercb9fCiAOvmdwwAAH9qfAABZidoA== References: <004801ca2491$fbd88790$400ca40a@china.huawei.com> <008d01ca249a$f382a770$0f0ca40a@china.huawei.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Song Haibin" , X-OriginalArrivalTime: 24 Aug 2009 11:40:34.0358 (UTC) FILETIME=[B1288560:01CA24AF] Subject: [decade] 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: Mon, 24 Aug 2009 11:40:56 -0000 What is the name standing for? D - Distributed? E - External? C - Cache? A - Application? D - Data? E - Experience? Or what was the original shorting for? Regards Christian From guyingjie@huawei.com Mon Aug 24 17:55: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 C54F728C20F for ; Mon, 24 Aug 2009 17:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_05=-1.11, 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 Rqa8NAD-pb1W for ; Mon, 24 Aug 2009 17:55:24 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CD12B3A682A for ; Mon, 24 Aug 2009 17:55:23 -0700 (PDT) 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 <0KOW00386QK7Q0@szxga04-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 08:55:19 +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 <0KOW0048RQK7WC@szxga04-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 08:55:19 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOW003OFQK6W4@szxml04-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 08:55:19 +0800 (CST) Date: Tue, 25 Aug 2009 08:55:27 +0800 From: "Y.J. Gu" In-reply-to: To: "'Schmidt, Christian 1. (NSN - DE/Munich)'" , 'ext Song Haibin' , decade@ietf.org Message-id: <000001ca251e$bd0b9560$400ca40a@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: AcoV0l9RNJW31UZrTiGaOercb9fCiAOvmdwwAAH9qfAABZidoAAbyk0g Subject: Re: [decade] 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: Tue, 25 Aug 2009 00:55:24 -0000 Hi Christian It's DECoupled Application Data Enroute. As for the goal of DECADE, you can refer to the earlier post. Regards Yingjie Gu > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Schmidt, > Christian 1. (NSN - DE/Munich) > Sent: Monday, August 24, 2009 7:41 PM > To: ext Song Haibin; decade@ietf.org > Subject: [decade] DECADE > > What is the name standing for? > > D - Distributed? > E - External? > C - Cache? > A - Application? > D - Data? > E - Experience? > > Or what was the original shorting for? > > Regards > Christian > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Mon Aug 24 23:12:00 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 C3E983A6EE0 for ; Mon, 24 Aug 2009 23:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZnerxV7k55h for ; Mon, 24 Aug 2009 23:12:00 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CA5873A6EDB for ; Mon, 24 Aug 2009 23:11:59 -0700 (PDT) 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 <0KOX00D1E57OV3@szxga02-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 14:11:49 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOX00IED57ORE@szxga02-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 14:11:48 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOX00A7857O8V@szxml06-in.huawei.com> for decade@ietf.org; Tue, 25 Aug 2009 14:11:48 +0800 (CST) Date: Tue, 25 Aug 2009 14:11:48 +0800 From: Song Haibin In-reply-to: <000001ca251e$bd0b9560$400ca40a@china.huawei.com> To: "'Schmidt, Christian 1. (NSN - DE/Munich)'" , decade@ietf.org Message-id: <008601ca254a$ee02a9c0$0f0ca40a@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: AcoV0l9RNJW31UZrTiGaOercb9fCiAOvmdwwAAH9qfAABZidoAAbyk0gAAsECcA= Subject: Re: [decade] 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: Tue, 25 Aug 2009 06:12:00 -0000 Hi Christian, I'm sorry for the mistake. I just added the full name for DECADE to the list welcome message :) Thanks! Haibin >-----Original Message----- >From: Y.J. Gu [mailto:guyingjie@huawei.com] >Sent: Tuesday, August 25, 2009 8:55 AM >To: 'Schmidt, Christian 1. (NSN - DE/Munich)'; 'ext Song >Haibin'; decade@ietf.org >Subject: RE: [decade] DECADE > >Hi Christian > >It's DECoupled Application Data Enroute. >As for the goal of DECADE, you can refer to the earlier post. > >Regards > >Yingjie Gu > > > >> -----Original Message----- >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Schmidt, Christian 1. >> (NSN - DE/Munich) >> Sent: Monday, August 24, 2009 7:41 PM >> To: ext Song Haibin; decade@ietf.org >> Subject: [decade] DECADE >> >> What is the name standing for? >> >> D - Distributed? >> E - External? >> C - Cache? >> A - Application? >> D - Data? >> E - Experience? >> >> Or what was the original shorting for? >> >> Regards >> Christian >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade > From davidbryan@gmail.com Wed Aug 26 12:51:28 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 71F293A67F0 for ; Wed, 26 Aug 2009 12:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiAGEG+fhq4c for ; Wed, 26 Aug 2009 12:51:27 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 795193A6867 for ; Wed, 26 Aug 2009 12:51:24 -0700 (PDT) Received: by iwn38 with SMTP id 38so323324iwn.29 for ; Wed, 26 Aug 2009 12:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pgGTThi6H87jFyylc0/agdRztSQqlmtIwJf5664KyuI=; b=jVbIKTdr4UGZP/4qDRnLI0OoNAFB9M2oX3fp/dMULBq72Bqf3eapJgUO2wjFoSs9IS XrN2Gjd8mV+GVksMYzySmh/emtiEIRjuZSoXOsdKVlgKDfr8EL3ZR56BUVShoa8wOq1z k37MLfLxis5be+WT5lZgUDAFMCbepHG9kR2rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sYshDud1qiehvqvFXmS7mKlXUY5CHyN79q22lytIbU10QDhkSZEj97XngjagMRue/0 ZltnqPkZpbg3wH+9it9Nsu2eFSa5AI5bKTB18IcsGyBx3lg9iKsMrbfVMXv5FAVjzaC8 qW3ytbmGaIPJUXT2zQhtBef8JuRRFQPWoobas= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.231.13.69 with SMTP id b5mr4708726iba.40.1251316276790; Wed, 26 Aug 2009 12:51:16 -0700 (PDT) In-Reply-To: <008d01ca249a$f382a770$0f0ca40a@china.huawei.com> References: <004801ca2491$fbd88790$400ca40a@china.huawei.com> <008d01ca249a$f382a770$0f0ca40a@china.huawei.com> Date: Wed, 26 Aug 2009 15:51:16 -0400 X-Google-Sender-Auth: b7f207604f10215f Message-ID: <8b2769930908261251h370b7ceajfca68ffafa85124a@mail.gmail.com> From: "David A. Bryan" To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] Should content be repeatedly stored on different In-network storage? 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, 26 Aug 2009 19:51:28 -0000 I would agree with Song that this would likely be something that is implementation (or deployment) dependent. Ignoring the (possibly very salient in this context) question about copyright,I can see a couple of ways to do this: 1) The user (and the user only) decides what goes up in their storage area. Obviously, this has maximum control on the part of the user, and for privacy reasons is very appealing. That said, this variety is unlikely to lead to as much of an optimization of the network, since users may or may not choose to cache, etc., so may not be a practical way of approaching this. 2) A system where it is completely transparent. In other words, once someone downloads from me, it automatically is in my network storage, and likely the remote parties as well. It could be removed when the store is full, the file/chunk/whatever is a certain age, in a FIFO style. Basically, this turns into a cache. This (or 3 below) would likely result in far better overall improvement in network performance than 1, although I admit that is not backed up by any research or data, just my gut feeling looking at the options. 3) Something in between. Here I would picture some space the user could use to place content in deliberately, and some space that is effectively used as a cache. It is worth noting that at first glance (I have to admit I haven't thought might about it) it appears that the underlying protocol constructs that would be needed to do this are the same -- the decision is just made in the "network storage server" as to if data passing through is cached or not -- so this may be an interesting thing to think about from a deployment, charter, and scope perspective, but in practice, may end up having very little impact on what a possible protocol would look like. David On Mon, Aug 24, 2009 at 5:12 AM, Song Haibin wrote: > Hi Yingjie, > > In general, assuming that an out-of-path method has been used for protecting > the copyright issues, and the in-network storage is allocated to different > users with many individual accounts, I would say a P2P client(in-network > storage user) could decide whether to store the content for himself in its > in-network storage account, and of course it can share the content in its > in-network storage account to other peers. However, in implementation, you > may have many methods to optimize it to avoid duplication on the same server > or on the servers of an local area. > > Thanks! > Haibin > > > >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >>On Behalf Of Y.J. Gu >>Sent: Monday, August 24, 2009 4:08 PM >>To: decade@ietf.org >>Subject: [decade] Should content be repeatedly stored on >>different In-network storage? >> >>Maybe the subject of the mail is not very clear. >>I'd like to explain it. >> >>Applicant In-network storage, I creat the name to represent >>the In-network storage who download a content for its client >>from another In-network storage. >>Should the Applicant In-network storage store the content it >>downloads, to server the later requests for this content from >>other clients? >> >> >> >>Regards >> >>Yingjie Gu >> >>_______________________________________________ >>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 davidbryan@gmail.com Wed Aug 26 14:14:14 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 E2E903A6781 for ; Wed, 26 Aug 2009 14:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9iQkDZWMhYK for ; Wed, 26 Aug 2009 14:14:14 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id D28923A6C78 for ; Wed, 26 Aug 2009 14:14:13 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so81836qwi.31 for ; Wed, 26 Aug 2009 14:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Cd5/0L1dmhhsVbsmTaiCG/wYDwMFR/lExwhA97cQXWE=; b=Q/R3BejACsE4X/PUuif8Ck6yvFzvHy6emTMeUX5OW63TsxnPBgeyFESBLl+Mcw5ilo gX3yDjrEhtSCdSmK3jgUVs5iyjwDV+s0L0iTonjxlkAg3r/x8qKW61HPe6R5/CawVwa4 /RbfLubLAJS1IaaTG06Cut+3OEsuEF2ZANDYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xQYZ/MON4ipzNDBD8UNxyCCGI0EPblvQy7/Fdg32o6RaIkLbfiiOexrIGAO41u1IjX mZEhiq8DaZlDG5fHS0WPpVSOcUgcQEtKHZtiOn6+gbkTWEiSC/8i2eA7lPq6uKCRUiOo RYcwy/CI6ZCeB9qNA13280JwewMGG4BbKN2fg= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.224.39.70 with SMTP id f6mr5494885qae.341.1251321255375; Wed, 26 Aug 2009 14:14:15 -0700 (PDT) In-Reply-To: <8b2769930908261251h370b7ceajfca68ffafa85124a@mail.gmail.com> References: <004801ca2491$fbd88790$400ca40a@china.huawei.com> <008d01ca249a$f382a770$0f0ca40a@china.huawei.com> <8b2769930908261251h370b7ceajfca68ffafa85124a@mail.gmail.com> Date: Wed, 26 Aug 2009 17:14:14 -0400 X-Google-Sender-Auth: f1ac6d4d453e0311 Message-ID: <8b2769930908261414ha06d9a6nf18d91c362616053@mail.gmail.com> From: "David A. Bryan" To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] Should content be repeatedly stored on different In-network storage? 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, 26 Aug 2009 21:14:15 -0000 One clarification -- while I am talking in 2 and 3 about things that are "transparent", I mean to the user -- not at the protocol layer. The application is still aware of the fact it is using DECADE here, so it isn't really a cache (which of course is different from what DECADE is trying to do), but the behavior to the user appears similar, in that recent shared and downloaded items would appear in it. Someone pinged me offline and asked, and I realized my email was a bit unclear on that point... David On Wed, Aug 26, 2009 at 3:51 PM, David A. Bryan wrote: > I would agree with Song that this would likely be something that is > implementation (or deployment) dependent. Ignoring the (possibly very > salient in this context) question about copyright,I can see a couple > of ways to do this: > > 1) The user (and the user only) decides what goes up in their storage > area. Obviously, this has maximum control on the part of the user, and > for privacy reasons is very appealing. That said, this variety is > unlikely to lead to as much of an optimization of the network, since > users may or may not choose to cache, etc., so may not be a practical > way of approaching this. > > 2) A system where it is completely transparent. In other words, once > someone downloads from me, it automatically is in my network storage, > and likely the remote parties as well. It could be removed when the > store is full, the file/chunk/whatever is a certain age, in a FIFO > style. Basically, this turns into a cache. This (or 3 below) would > likely result in far better overall improvement in network performance > than 1, although I admit that is not backed up by any research or > data, just my gut feeling looking at the options. > > 3) Something in between. Here I would picture some space the user > could use to place content in deliberately, and some space that is > effectively used as a cache. > > It is worth noting that at first glance (I have to admit I haven't > thought might about it) it appears that the underlying protocol > constructs that would be needed to do this are the same -- the > decision is just made in the "network storage server" as to if data > passing through is cached or not -- so this may be an interesting > thing to think about from a deployment, charter, and scope > perspective, but in practice, may end up having very little impact on > what a possible protocol would look like. > > David > > On Mon, Aug 24, 2009 at 5:12 AM, Song Haibin wrote: >> Hi Yingjie, >> >> In general, assuming that an out-of-path method has been used for protecting >> the copyright issues, and the in-network storage is allocated to different >> users with many individual accounts, I would say a P2P client(in-network >> storage user) could decide whether to store the content for himself in its >> in-network storage account, and of course it can share the content in its >> in-network storage account to other peers. However, in implementation, you >> may have many methods to optimize it to avoid duplication on the same server >> or on the servers of an local area. >> >> Thanks! >> Haibin >> >> >> >>>-----Original Message----- >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >>>On Behalf Of Y.J. Gu >>>Sent: Monday, August 24, 2009 4:08 PM >>>To: decade@ietf.org >>>Subject: [decade] Should content be repeatedly stored on >>>different In-network storage? >>> >>>Maybe the subject of the mail is not very clear. >>>I'd like to explain it. >>> >>>Applicant In-network storage, I creat the name to represent >>>the In-network storage who download a content for its client >>>from another In-network storage. >>>Should the Applicant In-network storage store the content it >>>downloads, to server the later requests for this content from >>>other clients? >>> >>> >>> >>>Regards >>> >>>Yingjie Gu >>> >>>_______________________________________________ >>>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 davidbryan@gmail.com Wed Aug 26 14:30:28 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 65BD628C4F2 for ; Wed, 26 Aug 2009 14:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s-H02bqC7kJ for ; Wed, 26 Aug 2009 14:30:27 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 8A5E628C4E7 for ; Wed, 26 Aug 2009 14:30:27 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so87499qwi.31 for ; Wed, 26 Aug 2009 14:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cL/W4oPpepx5mMApT8yZsSclsvF0FLWG3aExzQbsunY=; b=SeSpvI/QtVu7cvm1Wuc/OfEekUHLumfIwgcnl51OZ+J0qqLAaH9bR7SwHvPfw/3g+p HKTmctYLQ78Ehep76prKdBkvmwE7P6itAnFIf9wVGn7nmnqDIF9lKRK6vU0Kbk2M2/3q 6LCvOOShddQDlG876CKAZWsMM1s7bFXPQyb8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=n4lSK+vkPkf4AG3K3W+Ri5P5Ny6Bj723e3p5CWB4UX9ASCKaS++GEP33kY2rX2GZes qcvdr/KCBBSHeozh4QzuVGqYA7C1y23b8mOTIHV5fr4mfiCtpb16KDt9YGvor3tvVis2 nu958uMiAex/+S6wezWEbnR/vT5l1UVlTMXj4= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.224.51.231 with SMTP id e39mr5507264qag.337.1251322230526; Wed, 26 Aug 2009 14:30:30 -0700 (PDT) Date: Wed, 26 Aug 2009 17:30:30 -0400 X-Google-Sender-Auth: f62d53e1910b664c Message-ID: <8b2769930908261430l25a68ecfg87b6605355ac1b18@mail.gmail.com> From: "David A. Bryan" To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [decade] Are there P2P protocols that would (architecturally) be incompatible with 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: Wed, 26 Aug 2009 21:30:28 -0000 As I have been spending some time today thinking about DECADE, I was wondering if anyone knows of an existing P2P application or protocol that would not work with decade for security reasons. The basic idea is that if A shares a file, and B retrieves it, A provides a response that could be the address of a DECADE server, and either B retrieves, or B asks it's DECADE server to retrieve on B's behalf. If there are P2P protocols that enforce or verify that when I ask A for a file it is really A via a mechanism like IP address checking (as opposed to something like signed data), how would we work with this into DECADE. In other words, what if the protocol, when A says "I have the file" requires the file to come from A directly, and B would reject the data if it came from another peer. In general, I can't think of a situation like this today (and many security papers in the literature have shown that security based on source IP or Peer-IDs derived from IPs are inherently insecure), but was curious if anyone knows of an existing application where this is, at least today, true? I can certainly imagine that it might *look* secure to enforce by IP address, and there may be some deployed out there doing that today. Anyone know? David From melodysong@huawei.com Fri Aug 28 01:48:34 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 C131C3A6A35 for ; Fri, 28 Aug 2009 01:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=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 GVcWBgdSaW62 for ; Fri, 28 Aug 2009 01:48:33 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 73C4028C1A1 for ; Fri, 28 Aug 2009 01:48:05 -0700 (PDT) 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 <0KP200JS2WG1ZA@szxga01-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 16:48:01 +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 <0KP2007JEWG1BO@szxga01-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 16:48:01 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP2004FFWG0TN@szxml04-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 16:48:01 +0800 (CST) Date: Fri, 28 Aug 2009 16:48:00 +0800 From: Song Haibin In-reply-to: <8b2769930908261251h370b7ceajfca68ffafa85124a@mail.gmail.com> To: "'David A. Bryan'" Message-id: <008001ca27bc$3f9896a0$0f0ca40a@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: AcomhpYlqE9IZve+QgK+eQ9OBh2hlABJWxhQ Cc: decade@ietf.org Subject: Re: [decade] Should content be repeatedly stored on differentIn-network storage? 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, 28 Aug 2009 08:48:34 -0000 Hi David, I like these three ways for P2P contents in-network storage. I agree that a standard in-network storage access protocol could be applicable to all these three ways. Here is my understanding of them. For (1), I think I understand how it works. That's similar to what in the SAILOR presentation at DECADE BAR BOF. In this method, User A can read/write from/to its in-network storage, and also A can download from peer B or peer B's in-network storage, and decide whether to store that content in A's in-network storage (in-path). That's to say, what contents will be stored in A's network storage is fully under control of user A. On the other hand, A is aware of what is in its in-network storage, and could use its in-network storage instead of itself to send data to other peers on requests. For (2), the difference from (1) is that user A does not have to decide what will be in its in-network storage. When A dowloads a content from B(assume that B's in-network storage does not have the content), then the content will be stored in both A and B's in-network storage automatically. In this way, B's in in-network storage will tell B what contents are stored there. So that when receiving a request for the same data content from another peer later, B can make the decision whether to download from it or its in-network storage. A's in-network storage will also tell A what contents are stored in the core when there is update. I'm not sure if I catch the right thing here. There might be the possiblity of (3) if the two above would be complementary. Thanks! Haibin >-----Original Message----- >From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On >Behalf Of David A. Bryan >Sent: Thursday, August 27, 2009 3:51 AM >To: Song Haibin >Cc: Y.J. Gu; decade@ietf.org >Subject: Re: [decade] Should content be repeatedly stored on >differentIn-network storage? > >I would agree with Song that this would likely be something >that is implementation (or deployment) dependent. Ignoring the >(possibly very salient in this context) question about >copyright,I can see a couple of ways to do this: > >1) The user (and the user only) decides what goes up in their >storage area. Obviously, this has maximum control on the part >of the user, and for privacy reasons is very appealing. That >said, this variety is unlikely to lead to as much of an >optimization of the network, since users may or may not choose >to cache, etc., so may not be a practical way of approaching this. > >2) A system where it is completely transparent. In other >words, once someone downloads from me, it automatically is in >my network storage, and likely the remote parties as well. It >could be removed when the store is full, the >file/chunk/whatever is a certain age, in a FIFO style. >Basically, this turns into a cache. This (or 3 below) would >likely result in far better overall improvement in network >performance than 1, although I admit that is not backed up by >any research or data, just my gut feeling looking at the options. > >3) Something in between. Here I would picture some space the >user could use to place content in deliberately, and some >space that is effectively used as a cache. > >It is worth noting that at first glance (I have to admit I >haven't thought might about it) it appears that the underlying >protocol constructs that would be needed to do this are the >same -- the decision is just made in the "network storage >server" as to if data passing through is cached or not -- so >this may be an interesting thing to think about from a >deployment, charter, and scope perspective, but in practice, >may end up having very little impact on what a possible >protocol would look like. > >David > >On Mon, Aug 24, 2009 at 5:12 AM, Song >Haibin wrote: >> Hi Yingjie, >> >> In general, assuming that an out-of-path method has been used for >> protecting the copyright issues, and the in-network storage is >> allocated to different users with many individual accounts, I would >> say a P2P client(in-network storage user) could decide whether to >> store the content for himself in its in-network storage account, and >> of course it can share the content in its in-network storage account >> to other peers. However, in implementation, you may have >many methods >> to optimize it to avoid duplication on the same server or on >the servers of an local area. >> >> Thanks! >> Haibin >> >> >> >>>-----Original Message----- >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>Behalf Of Y.J. Gu >>>Sent: Monday, August 24, 2009 4:08 PM >>>To: decade@ietf.org >>>Subject: [decade] Should content be repeatedly stored on different >>>In-network storage? >>> >>>Maybe the subject of the mail is not very clear. >>>I'd like to explain it. >>> >>>Applicant In-network storage, I creat the name to represent the >>>In-network storage who download a content for its client >from another >>>In-network storage. >>>Should the Applicant In-network storage store the content it >>>downloads, to server the later requests for this content from other >>>clients? >>> >>> >>> >>>Regards >>> >>>Yingjie Gu >>> >>>_______________________________________________ >>>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 melodysong@huawei.com Fri Aug 28 02:04:02 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 B26F028C2B3 for ; Fri, 28 Aug 2009 02:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=0.474, 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 JyhiCSr1CBPL for ; Fri, 28 Aug 2009 02:04:01 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BCCEE28C2D8 for ; Fri, 28 Aug 2009 02:04:01 -0700 (PDT) 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 <0KP200CXAX6LIN@szxga02-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 17:03:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200B5KX6LY2@szxga02-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 17:03:57 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP2007FGX6KH8@szxml04-in.huawei.com> for decade@ietf.org; Fri, 28 Aug 2009 17:03:57 +0800 (CST) Date: Fri, 28 Aug 2009 17:03:56 +0800 From: Song Haibin In-reply-to: <8b2769930908261430l25a68ecfg87b6605355ac1b18@mail.gmail.com> To: "'David A. Bryan'" , decade@ietf.org Message-id: <008101ca27be$793052c0$0f0ca40a@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: AcomlHmQwxy5cInSQYWFabC1RPiPBwBJ+6Ug Subject: Re: [decade] Are there P2P protocols that would (architecturally) beincompatible with 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: Fri, 28 Aug 2009 09:04:02 -0000 Hi David, > >If there are P2P protocols that enforce or verify that when I >ask A for a file it is really A via a mechanism like IP >address checking (as opposed to something like signed data), >how would we work with this into DECADE. In other words, what >if the protocol, when A says "I have the file" requires the >file to come from A directly, and B would reject the data if >it came from another peer. > I'm not sure if there are any P2P applications doing that IP address checking. But as I know, peers often connect to each other directly for data exchange, and there is no mechanism like "redirection" for data retrieving. In order to support DECADE that A tells B the data address of its in-network storage, it needs a redirection mechanism. P2P applications need to do a few message modifications accordingly to support DECADE. If there is something like IP address checking mechanism for the source peer that would prevent integrating with DECADE, it must be corrected accordingly. Who knows which P2P application is doing that? Thanks! Haibin >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of David A. Bryan >Sent: Thursday, August 27, 2009 5:31 AM >To: decade@ietf.org >Subject: [decade] Are there P2P protocols that would >(architecturally) beincompatible with DECADE? > >As I have been spending some time today thinking about DECADE, >I was wondering if anyone knows of an existing P2P application >or protocol that would not work with decade for security reasons. > >The basic idea is that if A shares a file, and B retrieves it, >A provides a response that could be the address of a DECADE >server, and either B retrieves, or B asks it's DECADE server >to retrieve on B's behalf. > >If there are P2P protocols that enforce or verify that when I >ask A for a file it is really A via a mechanism like IP >address checking (as opposed to something like signed data), >how would we work with this into DECADE. In other words, what >if the protocol, when A says "I have the file" requires the >file to come from A directly, and B would reject the data if >it came from another peer. > >In general, I can't think of a situation like this today (and >many security papers in the literature have shown that >security based on source IP or Peer-IDs derived from IPs are >inherently insecure), but was curious if anyone knows of an >existing application where this is, at least today, true? I >can certainly imagine that it might *look* secure to enforce >by IP address, and there may be some deployed out there doing >that today. Anyone know? > >David >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From strufe.pub@googlemail.com Fri Aug 28 08:06:35 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 302EA28C2F2 for ; Fri, 28 Aug 2009 08:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmE8brTeDFMi for ; Fri, 28 Aug 2009 08:06:35 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 9378A28B23E for ; Fri, 28 Aug 2009 08:06:34 -0700 (PDT) Received: by fxm17 with SMTP id 17so1626055fxm.37 for ; Fri, 28 Aug 2009 08:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=N7bZ6+W14ypnrhbe9l3h2FsydFguhuqPJE+0r0nfsrM=; b=OH6PbEYiOrkY6eB44vbvLAEF6+EBEOgmXaGYPAmKjnyUjO2F45+4YtALR0HJymjqeC +13PdvoqlGSt3dAZG47UGTUjQHXQyGohYBJdZjGLMcZ65xq7VOU+gV1rjASOM+LlkSxo wBqsz9kv+UD7f+wNgmwZhYWQGH+k1Hh6/874Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=JrRpqBdvaA3KBNhP5RNj5PIfu6dGBZAfBiFjulbFzrw68us3nUVIdRlH4y2YWKja2M CnwDZ9WYA9nLmzepn4/KDX3m8s0mtptenP9GspTt2SDX6FQ+0FgJ0FzZeO6fmg6Cp1lj uPjONo0u/S5mU5JP4iAF2cKdN7Il0I0+FNc1k= Received: by 10.103.80.25 with SMTP id h25mr338522mul.15.1251471997852; Fri, 28 Aug 2009 08:06:37 -0700 (PDT) Received: from ?130.83.163.220? (dyn28.tk.informatik.tu-darmstadt.de [130.83.163.220]) by mx.google.com with ESMTPS id i7sm6124908mue.18.2009.08.28.08.06.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Aug 2009 08:06:37 -0700 (PDT) Message-ID: <4A97F27B.5060105@gmail.com> Date: Fri, 28 Aug 2009 17:06:35 +0200 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [decade] CfP ..:::SESOC 2010:::.. (Security and Social Networking) 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, 28 Aug 2009 15:06:35 -0000 [ a gentle reminder ] [ apologies for cross-posting ] $%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$% ( ( ) SESOC 2010 ) ( ( ) International Workshop on ) ( SECurity and SOCial Networking ( ) ) ( March 29 / April 2 2010 ( ) Mannheim, Germany ) ( (as part of IEEE PerCom 2010) ( ) ) ( http://www.sesoc.org ( ) ) %&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&* Future pervasive communication systems aim at supporting social and collaborative communications: the evolving topologies are expected to resemble the actual social networks of the communicating users and information on their characteristics can be a powerful aid for any network operation. New emerging technologies that use information on the social characteristics of their participants raise entirely new privacy concerns and require new reflections on security problems such as trust establishment, cooperation enforcement or key management. The aim of this workshop is to encompass research advances in all areas of security, trust and privacy in pervasive communication systems, integrating the social structure of the network as well. ============================= Topics of Interest ============================= - new aspects of trust - privacy concerns - availability and resilience - community based secure communication - data confidentiality, data integrity - anonymity, pseudonymity - key management - secure bootstrapping - security issues in forwarding, routing - security aspects regarding cooperation - new reputation systems - new attack paradigms - new requirements for software security - malware ============================= Important Dates ============================= Submission deadline: October 18, 2009 Notification date: December 21, 2010 Camera ready submission: January 29, 2010 ============================= Submission instructions ============================= Submitted papers must be unpublished and not considered elsewhere for publication. Camera-ready versions of accepted papers will be limited to 6 pages in IEEE 8.5x11 conference format, and formatted in accordance with the IEEE Computer Society author guidelines. The link for the templates and further guidelines for preparing and submitting the manuscript are available on the workshop website. All papers are managed electronically through easychair, the submission website is: http://www.easychair.org/conferences/?conf=sesoc2010 Submitted papers will undergo a rigorous and double-blind review process handled by the Technical Program Committee. Authors' names must not appear in the paper. All accepted papers need to have a full registration to the PerCom 2010 Conference (There is no workshop only registration). Moreover, no-shows of accepted papers at the workshop will result in those papers not being included in the IEEE Digital Library. ============================= Committee ============================= General Chairs: Refik Molva EURECOM, France Gene Tsudik University of California Irvine, USA Organizing Chairs: Melek Önen EURECOM, France Thorsten Strufe Technische Universität Darmstadt, Germany Web Chair: Antonio Cutillo EURECOM, France Technical Program Committee: Imad Aad Nokia, Switzerland Davide Balzarotti EURECOM, France Erik-Oliver Blass EURECOM, France Jens-Matthias Bohli NEC Europe, Germany Michael Brinkmeier TU Ilmenau, Germany Sonja Buchegger Deutsche Telekom Laboratories, Germany Levente Buttyán BUTE, Hungary Claude Castelluccia INRIA, France Lorenzo Cavallaro UCSB, USA Ahmet Çamtepe TU Berlin, Germany Mauro Conti Vrije Universiteit, The Netherlands Jon Crowcroft Computer Lab Cambridge University, UK Marc Dacier Symantec Europe, France Anwitaman Datta NTU, Singapore Roberto Di Pietro Università di Roma, La Sapenzia, Italy Alexander Eichhorn Simula, Norway Stephen Farrell NewBay Software, Ireland Artur Hecker Telecom ParisTech, France Sotiris Ioannidis FORTH, Greece Stefan Katzenbeisser CASED, Germany Albert Levi Sabanci University, Turkey Mark Manulis CASED, Germany Jörn Müller-Quade Uni Karlsruhe, Germany Guevara Noubir North Eastern University, USA Christian Rohner Uppsala Universitet, Sweden Günter Schäfer TU Ilmenau, Germany Dirk Westhoff NEC Europe, Germany -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/ From richard_woundy@cable.comcast.com Fri Aug 28 08:35:57 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 03F4B3A6C25 for ; Fri, 28 Aug 2009 08:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 lCcGDsJOBVJB for ; Fri, 28 Aug 2009 08:35:56 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id CC72E28C389 for ; Fri, 28 Aug 2009 08:35:55 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.77833345; Fri, 28 Aug 2009 11:35:47 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 11:35:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 11:35:46 -0400 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB1744BD@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <008101ca27be$793052c0$0f0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Are there P2P protocols that would (architecturally) beincompatible with DECADE? Thread-Index: AcomlHmQwxy5cInSQYWFabC1RPiPBwBJ+6UgAA32N1A= References: <8b2769930908261430l25a68ecfg87b6605355ac1b18@mail.gmail.com> <008101ca27be$793052c0$0f0ca40a@china.huawei.com> From: "Woundy, Richard" To: "Song Haibin" , "David A. Bryan" , X-OriginalArrivalTime: 28 Aug 2009 15:35:48.0228 (UTC) FILETIME=[37552C40:01CA27F5] Subject: Re: [decade] Are there P2P protocols that would (architecturally) beincompatible with 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: Fri, 28 Aug 2009 15:35:57 -0000 > I'm not sure if there are any P2P applications doing that IP address checking. The Vuze P2P client has an "IP filter" function, and supposedly so does uTorrent. You might also need to worry about the NAT functionality in a subscriber's home gateway, and its sensitivity to IP address checks. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin Sent: Friday, August 28, 2009 5:04 AM To: 'David A. Bryan'; decade@ietf.org Subject: Re: [decade] Are there P2P protocols that would (architecturally) beincompatible with DECADE? Hi David, > >If there are P2P protocols that enforce or verify that when I=20 >ask A for a file it is really A via a mechanism like IP=20 >address checking (as opposed to something like signed data),=20 >how would we work with this into DECADE. In other words, what=20 >if the protocol, when A says "I have the file" requires the=20 >file to come from A directly, and B would reject the data if=20 >it came from another peer. > I'm not sure if there are any P2P applications doing that IP address checking. But as I know, peers often connect to each other directly for data exchange, and there is no mechanism like "redirection" for data retrieving. In order to support DECADE that A tells B the data address of its in-network storage, it needs a redirection mechanism. P2P applications need to do a few message modifications accordingly to support DECADE. If there is something like IP address checking mechanism for the source peer that would prevent integrating with DECADE, it must be corrected accordingly.=20 Who knows which P2P application is doing that? Thanks! Haibin =20 >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 >On Behalf Of David A. Bryan >Sent: Thursday, August 27, 2009 5:31 AM >To: decade@ietf.org >Subject: [decade] Are there P2P protocols that would=20 >(architecturally) beincompatible with DECADE? > >As I have been spending some time today thinking about DECADE,=20 >I was wondering if anyone knows of an existing P2P application=20 >or protocol that would not work with decade for security reasons. > >The basic idea is that if A shares a file, and B retrieves it,=20 >A provides a response that could be the address of a DECADE=20 >server, and either B retrieves, or B asks it's DECADE server=20 >to retrieve on B's behalf. > >If there are P2P protocols that enforce or verify that when I=20 >ask A for a file it is really A via a mechanism like IP=20 >address checking (as opposed to something like signed data),=20 >how would we work with this into DECADE. In other words, what=20 >if the protocol, when A says "I have the file" requires the=20 >file to come from A directly, and B would reject the data if=20 >it came from another peer. > >In general, I can't think of a situation like this today (and=20 >many security papers in the literature have shown that=20 >security based on source IP or Peer-IDs derived from IPs are=20 >inherently insecure), but was curious if anyone knows of an=20 >existing application where this is, at least today, true? I=20 >can certainly imagine that it might *look* secure to enforce=20 >by IP address, and there may be some deployed out there doing=20 >that today. Anyone know? > >David >_______________________________________________ >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 strufe.pub@googlemail.com Fri Aug 28 07:44:19 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 E271E3A6953 for ; Fri, 28 Aug 2009 07:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHpMG2IJqGny for ; Fri, 28 Aug 2009 07:44:18 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CFCCE3A6A67 for ; Fri, 28 Aug 2009 07:44:17 -0700 (PDT) Received: by bwz19 with SMTP id 19so1648376bwz.37 for ; Fri, 28 Aug 2009 07:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=N7bZ6+W14ypnrhbe9l3h2FsydFguhuqPJE+0r0nfsrM=; b=anUn1HhwIjH4rZJikW2vlIOfOHeb1+aMEt9YR5w+GBViTDMv12wnWQ7pS8NlAtiCl1 ImrjtWl++nceba30FfbALyCFdpZ8Nti2/zMEHqOBYCnfEID18vcOgL8w4XcgAQixhJ11 lJlGeSMVUZfWF8X8YhIj6W4Qw97bk1ohmDSAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Nkg0QZbDUP3/jl0oBsEzt66LtEgzZv+DwNccN75nnikUnKZ2bRGpv7PvGmyxMsS7vh XQRREI2lIs0kcDt4MCk4c+fnwc4C7DWdexVz87q7vKJ71zA13rq1pV6cN7ummE8LrwEe La0GkCekHcAnLqLDxSSWxhvebAjslmp+jy2Hs= Received: by 10.102.149.9 with SMTP id w9mr327101mud.77.1251470660120; Fri, 28 Aug 2009 07:44:20 -0700 (PDT) Received: from ?130.83.163.220? (dyn28.tk.informatik.tu-darmstadt.de [130.83.163.220]) by mx.google.com with ESMTPS id w5sm5447764mue.34.2009.08.28.07.44.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Aug 2009 07:44:19 -0700 (PDT) Message-ID: <4A97ED42.8070600@gmail.com> Date: Fri, 28 Aug 2009 16:44:18 +0200 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 28 Aug 2009 17:17:56 -0700 Subject: [decade] CfP ..:::SESOC 2010:::.. (Security and Social Networking) 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, 28 Aug 2009 15:00:10 -0000 [ a gentle reminder ] [ apologies for cross-posting ] $%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$% ( ( ) SESOC 2010 ) ( ( ) International Workshop on ) ( SECurity and SOCial Networking ( ) ) ( March 29 / April 2 2010 ( ) Mannheim, Germany ) ( (as part of IEEE PerCom 2010) ( ) ) ( http://www.sesoc.org ( ) ) %&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&*$%#§&*§$#%&*$%#§&*$%§&* Future pervasive communication systems aim at supporting social and collaborative communications: the evolving topologies are expected to resemble the actual social networks of the communicating users and information on their characteristics can be a powerful aid for any network operation. New emerging technologies that use information on the social characteristics of their participants raise entirely new privacy concerns and require new reflections on security problems such as trust establishment, cooperation enforcement or key management. The aim of this workshop is to encompass research advances in all areas of security, trust and privacy in pervasive communication systems, integrating the social structure of the network as well. ============================= Topics of Interest ============================= - new aspects of trust - privacy concerns - availability and resilience - community based secure communication - data confidentiality, data integrity - anonymity, pseudonymity - key management - secure bootstrapping - security issues in forwarding, routing - security aspects regarding cooperation - new reputation systems - new attack paradigms - new requirements for software security - malware ============================= Important Dates ============================= Submission deadline: October 18, 2009 Notification date: December 21, 2010 Camera ready submission: January 29, 2010 ============================= Submission instructions ============================= Submitted papers must be unpublished and not considered elsewhere for publication. Camera-ready versions of accepted papers will be limited to 6 pages in IEEE 8.5x11 conference format, and formatted in accordance with the IEEE Computer Society author guidelines. The link for the templates and further guidelines for preparing and submitting the manuscript are available on the workshop website. All papers are managed electronically through easychair, the submission website is: http://www.easychair.org/conferences/?conf=sesoc2010 Submitted papers will undergo a rigorous and double-blind review process handled by the Technical Program Committee. Authors' names must not appear in the paper. All accepted papers need to have a full registration to the PerCom 2010 Conference (There is no workshop only registration). Moreover, no-shows of accepted papers at the workshop will result in those papers not being included in the IEEE Digital Library. ============================= Committee ============================= General Chairs: Refik Molva EURECOM, France Gene Tsudik University of California Irvine, USA Organizing Chairs: Melek Önen EURECOM, France Thorsten Strufe Technische Universität Darmstadt, Germany Web Chair: Antonio Cutillo EURECOM, France Technical Program Committee: Imad Aad Nokia, Switzerland Davide Balzarotti EURECOM, France Erik-Oliver Blass EURECOM, France Jens-Matthias Bohli NEC Europe, Germany Michael Brinkmeier TU Ilmenau, Germany Sonja Buchegger Deutsche Telekom Laboratories, Germany Levente Buttyán BUTE, Hungary Claude Castelluccia INRIA, France Lorenzo Cavallaro UCSB, USA Ahmet Çamtepe TU Berlin, Germany Mauro Conti Vrije Universiteit, The Netherlands Jon Crowcroft Computer Lab Cambridge University, UK Marc Dacier Symantec Europe, France Anwitaman Datta NTU, Singapore Roberto Di Pietro Università di Roma, La Sapenzia, Italy Alexander Eichhorn Simula, Norway Stephen Farrell NewBay Software, Ireland Artur Hecker Telecom ParisTech, France Sotiris Ioannidis FORTH, Greece Stefan Katzenbeisser CASED, Germany Albert Levi Sabanci University, Turkey Mark Manulis CASED, Germany Jörn Müller-Quade Uni Karlsruhe, Germany Guevara Noubir North Eastern University, USA Christian Rohner Uppsala Universitet, Sweden Günter Schäfer TU Ilmenau, Germany Dirk Westhoff NEC Europe, Germany -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/ From guyingjie@huawei.com Fri Aug 28 18:55:32 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 8D6E83A6A89 for ; Fri, 28 Aug 2009 18:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.673 X-Spam-Level: X-Spam-Status: No, score=0.673 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, J_CHICKENPOX_91=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 eOUwE55nYAKd for ; Fri, 28 Aug 2009 18:55:31 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 375AE3A6A02 for ; Fri, 28 Aug 2009 18:55:31 -0700 (PDT) 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 <0KP400HES7ZVK4@szxga04-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 09:55:07 +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 <0KP400LLY7ZVSO@szxga04-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 09:55:07 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP400ALI7ZU4M@szxml04-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 09:55:07 +0800 (CST) Date: Sat, 29 Aug 2009 09:55:06 +0800 From: "Y.J. Gu" In-reply-to: <008001ca27bc$3f9896a0$0f0ca40a@china.huawei.com> To: 'Song Haibin' , "'David A. Bryan'" Message-id: <000301ca284b$bbc83980$400ca40a@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: AcomhpYlqE9IZve+QgK+eQ9OBh2hlABJWxhQACZgLyA= Cc: decade@ietf.org Subject: Re: [decade] Should content be repeatedly stored on differentIn-network storage? 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: Sat, 29 Aug 2009 01:55:32 -0000 Hi, Haibin and David. See in line pls. Regards Yingjie Gu > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > Sent: Friday, August 28, 2009 4:48 PM > To: 'David A. Bryan' > Cc: decade@ietf.org > Subject: Re: [decade] Should content be repeatedly stored on > differentIn-network storage? > > Hi David, > > I like these three ways for P2P contents in-network storage. > I agree that a standard in-network storage access protocol > could be applicable to all these three ways. Here is my > understanding of them. > > For (1), I think I understand how it works. That's similar to > what in the SAILOR presentation at DECADE BAR BOF. In this > method, User A can read/write from/to its in-network storage, > and also A can download from peer B or peer B's in-network > storage, and decide whether to store that content in A's > in-network storage (in-path). That's to say, what contents > will be stored in A's network storage is fully under control > of user A. On the other hand, A is aware of what is in its > in-network storage, and could use its in-network storage > instead of itself to send data to other peers on requests. In this case, does A's in-network storage need to bear all that responsibility that B's in-network storage holds for the data? For example, does that mean A's In-network storage have to authenticate other peers to retrieve the data, as A might download the data from B's In-network storage with a token? With B's token or a new token set by A to authenticate? And some other examples like "Data updating/aging" ? > For (2), the difference from (1) is that user A does not have > to decide what will be in its in-network storage. When A > dowloads a content from B(assume that B's in-network storage > does not have the content), then the content > will be stored in both A and B's in-network storage > automatically. In this > way, B's in in-network storage will tell B what contents are > stored there. > So that when receiving a request for the same data content > from another peer later, B can make the decision whether to > download from it or its in-network storage. A's in-network > storage will also tell A what contents are stored in the core > when there is update. I'm not sure if I catch the right thing here. As far as I'm concerned, I would say DECADE should not be transparent to users. The data that is distributed might be private, and the user need to have totally control over the data. And if it's transparent to user, we need do much more effort on IP filter issues than it's not transparent. > There might be the possiblity of (3) if the two above would > be complementary. > The way between (1) and (2) might be better. AS for (1), A has too much control over B's data, and in (2) B has too little control over its data. There might need a negotiation between A and B (or between their in-network storages) about whether to cache the data in a remote storage and how the remote-cached data is managed(updating, aging, deleting). And B or B's in-network storage has a 'map' about where its data is stored so that B can approach them when necessary. > > Thanks! > Haibin > > > > >-----Original Message----- > >From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On > Behalf Of > >David A. Bryan > >Sent: Thursday, August 27, 2009 3:51 AM > >To: Song Haibin > >Cc: Y.J. Gu; decade@ietf.org > >Subject: Re: [decade] Should content be repeatedly stored on > >differentIn-network storage? > > > >I would agree with Song that this would likely be something that is > >implementation (or deployment) dependent. Ignoring the > (possibly very > >salient in this context) question about copyright,I can see > a couple of > >ways to do this: > > > >1) The user (and the user only) decides what goes up in > their storage > >area. Obviously, this has maximum control on the part of the > user, and > >for privacy reasons is very appealing. That said, this variety is > >unlikely to lead to as much of an optimization of the network, since > >users may or may not choose to cache, etc., so may not be a > practical > >way of approaching this. > > > >2) A system where it is completely transparent. In other words, once > >someone downloads from me, it automatically is in my network > storage, > >and likely the remote parties as well. It could be removed when the > >store is full, the file/chunk/whatever is a certain age, in a FIFO > >style. > >Basically, this turns into a cache. This (or 3 below) would likely > >result in far better overall improvement in network > performance than 1, > >although I admit that is not backed up by any research or > data, just my > >gut feeling looking at the options. > > > >3) Something in between. Here I would picture some space the > user could > >use to place content in deliberately, and some space that is > >effectively used as a cache. > > > >It is worth noting that at first glance (I have to admit I haven't > >thought might about it) it appears that the underlying protocol > >constructs that would be needed to do this are the same -- > the decision > >is just made in the "network storage server" as to if data passing > >through is cached or not -- so this may be an interesting thing to > >think about from a deployment, charter, and scope > perspective, but in > >practice, may end up having very little impact on what a possible > >protocol would look like. > > > >David > > > >On Mon, Aug 24, 2009 at 5:12 AM, Song > >Haibin wrote: > >> Hi Yingjie, > >> > >> In general, assuming that an out-of-path method has been used for > >> protecting the copyright issues, and the in-network storage is > >> allocated to different users with many individual > accounts, I would > >> say a P2P client(in-network storage user) could decide whether to > >> store the content for himself in its in-network storage > account, and > >> of course it can share the content in its in-network > storage account > >> to other peers. However, in implementation, you may have > >many methods > >> to optimize it to avoid duplication on the same server or on > >the servers of an local area. > >> > >> Thanks! > >> Haibin > >> > >> > >> > >>>-----Original Message----- > >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > >>>Behalf Of Y.J. Gu > >>>Sent: Monday, August 24, 2009 4:08 PM > >>>To: decade@ietf.org > >>>Subject: [decade] Should content be repeatedly stored on different > >>>In-network storage? > >>> > >>>Maybe the subject of the mail is not very clear. > >>>I'd like to explain it. > >>> > >>>Applicant In-network storage, I creat the name to represent the > >>>In-network storage who download a content for its client > >from another > >>>In-network storage. > >>>Should the Applicant In-network storage store the content it > >>>downloads, to server the later requests for this content > from other > >>>clients? > >>> > >>> > >>> > >>>Regards > >>> > >>>Yingjie Gu > >>> > >>>_______________________________________________ > >>>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 > >> > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Fri Aug 28 20:46:14 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 8D4C43A6856 for ; Fri, 28 Aug 2009 20:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.594 X-Spam-Level: * X-Spam-Status: No, score=1.594 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, J_CHICKENPOX_91=0.6, J_CHICKENPOX_92=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 q4VM9d7Jkm8m for ; Fri, 28 Aug 2009 20:46:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 098343A6957 for ; Fri, 28 Aug 2009 20:46:13 -0700 (PDT) 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 <0KP400BJBD4XTK@szxga03-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 11:46:09 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP400LMLD4XE6@szxga03-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 11:46:09 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP40078RD4WZB@szxml06-in.huawei.com> for decade@ietf.org; Sat, 29 Aug 2009 11:46:09 +0800 (CST) Date: Sat, 29 Aug 2009 11:46:08 +0800 From: Song Haibin In-reply-to: <000301ca284b$bbc83980$400ca40a@china.huawei.com> To: "'Y.J. Gu'" , "'David A. Bryan'" Message-id: <006401ca285b$3e6a4f90$0f0ca40a@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: AcomhpYlqE9IZve+QgK+eQ9OBh2hlABJWxhQACZgLyAAA+yk0A== Cc: decade@ietf.org Subject: Re: [decade] Should content be repeatedly stored on differentIn-network storage? 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: Sat, 29 Aug 2009 03:46:14 -0000 Hi Yingjie, See in line. >-----Original Message----- >From: Y.J. Gu [mailto:guyingjie@huawei.com] >Sent: Saturday, August 29, 2009 9:55 AM >To: 'Song Haibin'; 'David A. Bryan' >Cc: decade@ietf.org >Subject: RE: [decade] Should content be repeatedly stored on >differentIn-network storage? > >Hi, Haibin and David. >See in line pls. > >Regards > >Yingjie Gu > > > >> -----Original Message----- >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin >> Sent: Friday, August 28, 2009 4:48 PM >> To: 'David A. Bryan' >> Cc: decade@ietf.org >> Subject: Re: [decade] Should content be repeatedly stored on >> differentIn-network storage? >> >> Hi David, >> >> I like these three ways for P2P contents in-network storage. >> I agree that a standard in-network storage access protocol could be >> applicable to all these three ways. Here is my understanding of them. >> >> For (1), I think I understand how it works. That's similar >to what in >> the SAILOR presentation at DECADE BAR BOF. In this method, >User A can >> read/write from/to its in-network storage, and also A can download >> from peer B or peer B's in-network storage, and decide whether to >> store that content in A's in-network storage (in-path). >That's to say, >> what contents will be stored in A's network storage is fully under >> control of user A. On the other hand, A is aware of what is in its >> in-network storage, and could use its in-network storage instead of >> itself to send data to other peers on requests. > >In this case, does A's in-network storage need to bear all >that responsibility that B's in-network storage holds for the data? >For example, does that mean A's In-network storage have to >authenticate other peers to retrieve the data, as A might >download the data from B's In-network storage with a token? >With B's token or a new token set by A to authenticate? And >some other examples like "Data updating/aging" ? > A's in-network storage will not do the authentication on behalf of B, it only does that for A. "Updating/aging" might be done by existing mechanisms used by P2P applications instead of DECADE. DECADE could be used for user A to delete an expired data from its in-network storage or update a data object with a new one. The goal of DECADE is not a full solution but a simple protocol that can be integrated into P2P applications. >> For (2), the difference from (1) is that user A does not have to >> decide what will be in its in-network storage. When A dowloads a >> content from B(assume that B's in-network storage does not have the >> content), then the content will be stored in both A and B's >in-network >> storage >> automatically. In this >> way, B's in in-network storage will tell B what contents are stored >> there. >> So that when receiving a request for the same data content from >> another peer later, B can make the decision whether to download from >> it or its in-network storage. A's in-network storage will >also tell A >> what contents are stored in the core when there is update. I'm not >> sure if I catch the right thing here. > >As far as I'm concerned, I would say DECADE should not be >transparent to users. The data that is distributed might be >private, and the user need to have totally control over the >data. And if it's transparent to user, we need do much more >effort on IP filter issues than it's not transparent. > >> There might be the possiblity of (3) if the two above would be >> complementary. >> >The way between (1) and (2) might be better. AS for (1), A has >too much control over B's data, It's not totally right. A may have the right to distribute the data object in its in-network storage to other peers, or with how many processing resources(bw,conncetions...) the data object is shared to other peers, but it could not modify the data object if there is protection for the data object itself. and in (2) B has too little >control over its data. >There might need a negotiation between A and B (or between >their in-network >storages) about whether to cache the data in a remote storage >and how the remote-cached data is managed(updating, aging, >deleting). And B or B's in-network storage has a 'map' about >where its data is stored so that B can approach them when necessary. >> I think you mean the owner of the content could manage where the content can be sotored and monitor it. Please leave these strategies to applications. Haibin >> Thanks! >> Haibin >> >> >> >> >-----Original Message----- >> >From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On >> Behalf Of >> >David A. Bryan >> >Sent: Thursday, August 27, 2009 3:51 AM >> >To: Song Haibin >> >Cc: Y.J. Gu; decade@ietf.org >> >Subject: Re: [decade] Should content be repeatedly stored on >> >differentIn-network storage? >> > >> >I would agree with Song that this would likely be something that is >> >implementation (or deployment) dependent. Ignoring the >> (possibly very >> >salient in this context) question about copyright,I can see >> a couple of >> >ways to do this: >> > >> >1) The user (and the user only) decides what goes up in >> their storage >> >area. Obviously, this has maximum control on the part of the >> user, and >> >for privacy reasons is very appealing. That said, this variety is >> >unlikely to lead to as much of an optimization of the >network, since >> >users may or may not choose to cache, etc., so may not be a >> practical >> >way of approaching this. >> > >> >2) A system where it is completely transparent. In other >words, once >> >someone downloads from me, it automatically is in my network >> storage, >> >and likely the remote parties as well. It could be removed when the >> >store is full, the file/chunk/whatever is a certain age, in a FIFO >> >style. >> >Basically, this turns into a cache. This (or 3 below) would likely >> >result in far better overall improvement in network >> performance than 1, >> >although I admit that is not backed up by any research or >> data, just my >> >gut feeling looking at the options. >> > >> >3) Something in between. Here I would picture some space the >> user could >> >use to place content in deliberately, and some space that is >> >effectively used as a cache. >> > >> >It is worth noting that at first glance (I have to admit I haven't >> >thought might about it) it appears that the underlying protocol >> >constructs that would be needed to do this are the same -- >> the decision >> >is just made in the "network storage server" as to if data passing >> >through is cached or not -- so this may be an interesting thing to >> >think about from a deployment, charter, and scope >> perspective, but in >> >practice, may end up having very little impact on what a possible >> >protocol would look like. >> > >> >David >> > >> >On Mon, Aug 24, 2009 at 5:12 AM, Song Haibin >> >wrote: >> >> Hi Yingjie, >> >> >> >> In general, assuming that an out-of-path method has been used for >> >> protecting the copyright issues, and the in-network storage is >> >> allocated to different users with many individual >> accounts, I would >> >> say a P2P client(in-network storage user) could decide whether to >> >> store the content for himself in its in-network storage >> account, and >> >> of course it can share the content in its in-network >> storage account >> >> to other peers. However, in implementation, you may have >> >many methods >> >> to optimize it to avoid duplication on the same server or on >> >the servers of an local area. >> >> >> >> Thanks! >> >> Haibin >> >> >> >> >> >> >> >>>-----Original Message----- >> >>>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >> >>>Behalf Of Y.J. Gu >> >>>Sent: Monday, August 24, 2009 4:08 PM >> >>>To: decade@ietf.org >> >>>Subject: [decade] Should content be repeatedly stored on >different >> >>>In-network storage? >> >>> >> >>>Maybe the subject of the mail is not very clear. >> >>>I'd like to explain it. >> >>> >> >>>Applicant In-network storage, I creat the name to represent the >> >>>In-network storage who download a content for its client >> >from another >> >>>In-network storage. >> >>>Should the Applicant In-network storage store the content it >> >>>downloads, to server the later requests for this content >> from other >> >>>clients? >> >>> >> >>> >> >>> >> >>>Regards >> >>> >> >>>Yingjie Gu >> >>> >> >>>_______________________________________________ >> >>>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 >> >> >> > >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >